Re: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

Joe Touch <touch@isi.edu> Fri, 19 May 2017 21:05 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED845129B19 for <int-area@ietfa.amsl.com>; Fri, 19 May 2017 14:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR5unlIDJ5iD for <int-area@ietfa.amsl.com>; Fri, 19 May 2017 14:05:11 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BF3129488 for <int-area@ietf.org>; Fri, 19 May 2017 14:05:11 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4JL4ZcV024221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 May 2017 14:04:46 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, Xuxiaohu <xuxiaohu@huawei.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>
References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <CALx6S37nrJNGLdRHWx9DYNQyS54YdwLCXcG9Mp3zi4L_wrr6=g@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <d30774ba-e61f-dfa3-c64c-0612b287a34e@isi.edu>
Date: Fri, 19 May 2017 14:04:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CALx6S37nrJNGLdRHWx9DYNQyS54YdwLCXcG9Mp3zi4L_wrr6=g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A9729B98EC8081C0AD6B6DE8"
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/sqA-NQ0szhU7OzElS3eCjZWGFHI>
Subject: Re: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 May 2017 21:05:13 -0000

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