Hi, all, Speaking as lead of the IANA ports expert review team, and co-author of RFCs 6335 and 7605 on port assignment and use...
On 5/19/2017 7:56 AM, Tom Herbert wrote: >> Second, UDP itself has been widely used as a tunnel technology due to its >> load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP >> [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, >> NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to >> distinguish these different UDP tunnel payload types. For IP-in-UDP, there >> has been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) >> which was originally discussed in Softwire WG >> (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems >> ugly to use a version field within the GUE header to distinguish IPvx header >> from the GUE header itself. Is the UDP destination port number resource >> running out? > >From RFC7605, section 6 "Conservation": Yes, they're a limited, finite resource. No, they're not so critical that we cannot assign one more. However, there is a basic principle that "one" is fine, but "one" that leads to another, then another, etc., generally is not. That's why IANA expects that new assigned ports include version support, so that new versions can reuse an assignment rather than requiring a new one. > Also, it's not just the assignment that is a pain, port numbers to > need to be managed in networks. If we introduce a new port number in > the datacenter management tools, firewalls, packet capture need to be > updated. > > A feature of GUE is that the payload transform option allows DTLS to > be done on the payload. This obviates needing to ask for two port > numbers (a DTLS variant and non-DTLS variant) as several of the > encapsulation methods you listed above have done. See RFC7605: >> New services SHOULD support security capabilities, either directly or via a content protection such as TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] or Datagram TLS (DTLS) [RFC6347 <https://tools.ietf.org/html/rfc6347>], or transport protection such as the TCP-AO [RFC5925 <https://tools.ietf.org/html/rfc5925>]. Insecure versions of new or existing secure services SHOULD be avoided because of the new vulnerability they create. I.e., something like DTLS support would be expected. A non-DTLS variant might be accommodated on the same port using negotiation, but a separate assignment may no longer be appropriate (even though this was done in the past, esp. where negotiation was not possible). > ... >> Third, if the GUE devotes itself to save the UDP destination port number for >> the interest of the internet community, the 2-bit version field abused as a >> payload type indicator is obviously not enough:) >> > I'm not sure how it's "obviously not enough". Version 1 handles the > currently deployed two IP protocol versions. The technique allows for > supporting two more IP protocol versions to be supported without > burning another version number. One of these version numbers could easily indicate a longer or additional version field, which could be extended indefinitely. Joe
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
