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

Mirja Kühlewind <ietf@kuehlewind.net> Thu, 27 April 2017 14:39 UTC

Return-Path: <ietf@kuehlewind.net>
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 6CBAC129534 for <ipsec@ietfa.amsl.com>; Thu, 27 Apr 2017 07:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 f7KFPfxBsFhI for <ipsec@ietfa.amsl.com>; Thu, 27 Apr 2017 07:39:22 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E65126CC7 for <ipsec@ietf.org>; Thu, 27 Apr 2017 07:39:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=c3gJZDMJId/oNJhLXewmeTs0kjaYEmU8kuL5H8pYBqT2ewIhgdjpcVDO8owMEE7ir1//ILLTemM0INGeVKdO9P3VSz+qDBuNePr3IxEIzQpwyNs9nj1V68ukkTrIlVQ9Kihn84dzIId/bhLBo/SKFLd+oZ8n3GMB4l6ruj07dY4=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 30332 invoked from network); 27 Apr 2017 16:32:39 +0200
Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 16:32:39 +0200
To: Eric Rescorla <ekr@rtfm.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>
Cc: ipsecme-chairs@ietf.org, Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly <tpauly@apple.com>
From: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <f3839e6c-f39d-4a5f-620a-0b7501b8377b@kuehlewind.net>
Date: Thu, 27 Apr 2017 16:32:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBM1zeU1OA+MsUMeMWfMc3zyY=TAHsWhnc7Nfo_8fpLXJQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PPP-Message-ID: <20170427143239.30322.69521@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/UCDE7ECtUdRNQ2g0WGnK-o6EB84>
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 14:39:28 -0000

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.

Mirja