Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

Tommy Pauly <tpauly@apple.com> Thu, 27 April 2017 15:08 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAD12956C for <ipsec@ietfa.amsl.com>; Thu, 27 Apr 2017 08:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 ziNANvQvUAfw for <ipsec@ietfa.amsl.com>; Thu, 27 Apr 2017 08:08:23 -0700 (PDT)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5644E129AEB for <ipsec@ietf.org>; Thu, 27 Apr 2017 08:07:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493305630; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DLE7DZRvQQ/C1Erna150W6ZeSJ8hmN6/PEW0PJO8GPc=; b=fIFu4cH6RHWmYiavcmg/zOIwCTfuoWYH6i44toOaV/pPC3PUHerjignGJvb9l6Mc DHmoY6iqUv4QBdAuGF+kDMy4E4orsU8Mikfhu4a6owSpSbT/DxY4f7rNZlkKnNxx sPzAysr0eoh7ECmYb1Wex7wfRPixV9K2IU9uQsdbQoNQkT3/jg5qUt3GvVYECZHI mkcXSXmgAL4wPXi44NOtQl0jx0Pc3EBVOw8jC+XCj1lFzhuTcBjW6kgI4AcKYumP AUx2BWFIS1xR3NOFbd1i98fHMJg2EOk0jjvsSh1Ui/QKzAzH6TfAxJvexdfCdNgp Xy20dyELLCoxDxSQ97IdGw==;
Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 2F.8E.29279.D1902095; Thu, 27 Apr 2017 08:07:10 -0700 (PDT)
X-AuditID: 11973e11-bebfb7000000725f-46-5902091d555f
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay7.apple.com (Apple SCV relay) with SMTP id 6A.FB.18088.C1902095; Thu, 27 Apr 2017 08:07:09 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from [17.153.74.134] (unknown [17.153.74.134]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP20037VPZWCT00@nwk-mmpp-sz11.apple.com>; Thu, 27 Apr 2017 08:07:08 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <f3839e6c-f39d-4a5f-620a-0b7501b8377b@kuehlewind.net>
Date: Thu, 27 Apr 2017 08:07:07 -0700
Cc: Eric Rescorla <ekr@rtfm.com>, ipsecme-chairs@ietf.org, Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-ipsecme-tcp-encaps@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <A73D413A-B482-48CE-939D-520771FD6719@apple.com>
References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <CABcZeBMj9UpzD+CpvOMKOkUsYNSL-UQCwuYt__5XCXtH=zyesA@mail.gmail.com> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <CABcZeBOJ7c0p1v=qNh61tGAT3Nx6s4CKALhxsBWjRHSdTXHdJQ@mail.gmail.com> <aa6676de-e390-d562-7cf2-45a77c981e5f@kuehlewind.net> <CABcZeBM1zeU1OA+MsUMeMWfMc3zyY=TAHsWhnc7Nfo_8fpLXJQ@mail.gmail.com> <f3839e6c-f39d-4a5f-620a-0b7501b8377b@kuehlewind.net>
To: Mirja Kühlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3424)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FCYqivHyRRp8HAPp8X7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoEr48/vdUwFcyUr3k3dxdbAeF2oi5GTQ0LARGJKwwVWEFtIYA2TxPTJdTDx PVO2sncxcgHFDzFKTH/VwQiS4BUQlPgx+R5LFyMHB7OAusSUKbkQNROZJO6/mcUGEhcWkJDY vCcRJC4sMIFR4vW1WewgvWwCKhLHv21gBrE5BZwkTu87ATaHRUBVYsOPXJAws8A6RolPPzkh bG2JJ+8gbuMVsJF4ev0tE8SurSwStw6fArtHRMBKonn7IxaIo2UlJqzbzAxSJCFwn03i2Ot9 7BMYhWchuXsWwt2zkOxYwMi8ilEoNzEzRzczz0gvsaAgJ1UvOT93EyMoPqbbCe5gPL7K6hCj AAejEg9vxCfGSCHWxLLiytxDjNIcLErivMo7/kcICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YEydnfJ09ZXg87t1t86qbrwe4LLZ8PzGywHXsrZwP87yi7eUyj1f7cdfslBB6IPpd2POucs2 2Uk01DbPiL/K6lj/e2boupgqrs19h+fd+6a11+/+bK+rHxtvTKz9scPmzL65TZMMXbIzCuOT VWxdV6haabyP/7/jX6i8Wrvm9ki9xA8mc5UPKyuxFGckGmoxFxUnAgCxsFe/cAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUi2FA8W1eWkynSYOV/Hov3f84wWqx4fY7d YsaficwWL65/ZLbYv+UFm8XMOR9YLI6ef87mwO6xZMlPJo/DXxeyeLR8XMjqMflxG3MASxSX TUpqTmZZapG+XQJXxp/f65gK5kpWvJu6i62B8bpQFyMnh4SAicSeKVvZuxi5OIQEDjFKTH/V wQiS4BUQlPgx+R5LFyMHB7OAusSUKbkQNROZJO6/mcUGEhcWkJDYvCcRJC4sMIFR4vW1Wewg vWwCKhLHv21gBrE5BZwkTu87ATaHRUBVYsOPXJAws8A6RolPPzkhbG2JJ+8usEKstZF4ev0t E8SurSwStw6fArtHRMBKonn7IxaIo2UlJqzbzDyBUWAWklNnIZw6C8nYBYzMqxgFilJzEivN 9RILCnJS9ZLzczcxggO6MHUHY+Nyq0OMAhyMSjy8EZ8YI4VYE8uKK3OBYcHBrCTCm3kFKMSb klhZlVqUH19UmpNafIixCuiXicxSosn5wGjLK4k3NDExMDE2NjM2Njcxp4qwkjjv8jagzQLp iSWp2ampBalFMMuZODilGhjtbphEn1knM1HQcfvX3YJ3sh3KIuVbQiqfKZVbnz5lnmD05XR1 pdq28A9quVf7phxqtP7czuQ9oyVCN2xpQ9j6H6pbGb0+v17A96fxfkFhdtrPwMXTN8ivm/zx KEfAqzKNI8ddFnF5X25OdLsSXyj23ln20bKcjnCjUFMWh9z7jx6q+FyX3KPEUpyRaKjFXFSc CADHGx96wwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/sg44aikqqppPbBSlHIoYMZHeM3c>
Subject: Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 15:08:25 -0000


> On Apr 27, 2017, at 7:32 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:
> 
> See below
> 
> On 27.04.2017 16:27, Eric Rescorla wrote:
>> 
>>            "This document leaves the selection of TCP ports up to
>>               implementations.  It is suggested to use TCP port 4500, which is
>>               allocated for IPsec NAT Traversal."
>> 
>>            Which sounds to me like an invitation to squat on any open port
>>            regardless what the port is supposed to be used for (hoping that the
>>            magic number would avoid any collision). I don't think that a
>>        good thing
>>            to right in an RFC.
>> 
>> 
>>        Hmm... Maybe I don't understand your overall theory here. It seems
>>        like having
>>        reserved ports for protocols but letting people run them on any port
>>        they want
>>        to is kind of common practice. See, for instance:
>>        https://tools.ietf.org/html/rfc7230#section-2.7.1
>>        <https://tools.ietf.org/html/rfc7230#section-2.7.1>
>> 
>>        "  If the host identifier is provided as an IP address, the origin
>>           server is the listener (if any) on the indicated TCP port at that IP
>>           address. If host is a registered name, the registered name is an
>>           indirect identifier for use with a name resolution service, such as
>>           DNS, to find an address for that origin server. If the port
>>           subcomponent is empty or not given, TCP port 80 (the reserved port
>>           for WWW services) is the default."
>> 
>> 
>>    This doesn't say you can/should use any port you want (it says you can
>>    use another port than 80) but you should till avoid to use any other port
>>    that runs a different TCP service.
>> 
>> 
>> Well, that may be part of your background assumptions, but the document
>> doesn't say that. It just tells you how to use a different port and is silent on
>> what port you should use.
>> 
> 
> That's what we have the registry for. The difference is, it's okay to use a random port (instead of one specific reserved one) but this draft explicitly is intended to use other reserved ports.

The only recommended port in the draft is 4500, which is what is reserved in the registry. The use of any other port is by configuration only. As Tero and others have explained, all IKE connections are made to pre-known pre-configured hosts. All the IKE implementations I am aware of allow the useable IKE ports to be customized.

I'm fine removing any mention of other specific ports, even in the appendix. However, the fact that configurations can choose what ports to use is something that needs to be left open. The point of the port registry is to allow devices to expect what service will be offered on a given port when they connect. If two peers mutually decide to share their own configuration, they can do that.

Thanks,
Tommy

> 
> Mirja
> 
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec