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

Eric Rescorla <ekr@rtfm.com> Thu, 27 April 2017 14:28 UTC

Return-Path: <ekr@rtfm.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 C6A4A129687 for <ipsec@ietfa.amsl.com>; Thu, 27 Apr 2017 07:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qKvWqiahAQYi for <ipsec@ietfa.amsl.com>; Thu, 27 Apr 2017 07:28:11 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 8557A1296B0 for <ipsec@ietf.org>; Thu, 27 Apr 2017 07:27:52 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id u70so16411675ywe.2 for <ipsec@ietf.org>; Thu, 27 Apr 2017 07:27:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7RMjzndP9doxVk5Bx2ZyLQKXOfl5CDLzs4Lz8l0Dfxk=; b=IgsAJAlo9IwIOXbwfGa0RfDIEamVoh/HdwHV3xapS87PeJGO3QQeV7BI0pbdkiE8YR 63rSLFAd70Dq/uDYw4sYU5xysHdrlDP9cOayD5B3cZszn6ojBoMBXB5kS6VRNfZPEApH wjne7rf2T7s5n3PY0dl510mZbEMbrzPWabVGB7t0V1VeoRFiT52GLnYPXgou3UbC1MNW BO3yQhsSb52u4ENxNZisQZkH+VU0ZQNZpVFOeXbEbdnrBrjR3aTSoD7vFlDwXQlkGKTl dlyjfHXSltGaAxSazamT0NU2FqbRnO9Ge+naXqM7X/up1oYNQ85JjgimjFKqukFod8/s 8plw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7RMjzndP9doxVk5Bx2ZyLQKXOfl5CDLzs4Lz8l0Dfxk=; b=jzksKLph8FETTA8xuwQUx6OWFDPYLMiIVVQnlibNbS1Gup88BcXbUJPy5AD6S9OQeS 5ku4Vfg4GWAwfqWzUHtdLCDn/9ljBx8kSQIKbrN6SF+cTbRRXNVJrKaoRCZS80uM+vRz yTzVclD79eqHl4K5R3n4qXQKtkOhNPlpDrwkMdpXzVLTAb68Z60V2DHsBZXnnTuHefff gqZEdwPXUflaDXSPpLlJXd+XpwbRdQbI9GIl0DU/xFu/xNbmaCLt0IGTtBYTD3sbh0+P Fd1wbQcXK3arr0Vl6OcEvHdhtt49yMHo1B+YebrbC7gkWYEHZ9GnhXIYZYnJHCFTQR3U 4WTQ==
X-Gm-Message-State: AN3rC/7zs1xK6CVwSc6lldjcr7EzhsxDziOIgO0SeAWQbwgzuoaGVtuY Kv2VFFzxFEY1cSI4R+lxBBlhji9t5w==
X-Received: by 10.129.95.68 with SMTP id t65mr4703034ywb.74.1493303271638; Thu, 27 Apr 2017 07:27:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 07:27:11 -0700 (PDT)
In-Reply-To: <aa6676de-e390-d562-7cf2-45a77c981e5f@kuehlewind.net>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Apr 2017 07:27:11 -0700
Message-ID: <CABcZeBM1zeU1OA+MsUMeMWfMc3zyY=TAHsWhnc7Nfo_8fpLXJQ@mail.gmail.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
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>
Content-Type: multipart/alternative; boundary="001a1147e56e0c5380054e26c36d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/3umCo811-HXsOSpfT5DtfB7HbfQ>
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:28:15 -0000

On Thu, Apr 27, 2017 at 7:21 AM, Mirja Kühlewind <ietf@kuehlewind.net>
wrote:

> See below.
>
> On 27.04.2017 16:10, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind <ietf@kuehlewind.net
>> <mailto:ietf@kuehlewind.net>> wrote:
>>
>>     Hi Ekr, hi all,
>>
>>     (not sure anymore which email best to reply to but I'm using this one
>> now
>>     to partly also reply to others).
>>
>>     See below.
>>
>>     On 27.04.2017 14 <tel:27.04.2017%2014>:51, Eric Rescorla wrote:
>>
>>
>>
>>         On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <
>> ietf@kuehlewind.net
>>         <mailto:ietf@kuehlewind.net>
>>         <mailto:ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>>> wrote:
>>
>>             I do see the problem you have and I understand why you
>> selected the
>>             solution you have but that does contradict quite a bit the
>> idea
>>         of the
>>             port registry and I don't think it's a safe and future prove
>>         solution.
>>             Even if people use this approach, I'm concern to publish it
>> in an
>>             Standards Track RFC, but I guess that's a discussion the IESG
>>         would need
>>             to have.
>>
>>
>>         Mirja,
>>
>>         I agree that this kind of port squatting is regrettable, but I
>> also don't
>>         think it really
>>         helps to not publish RFCs that document widely used protocols
>> because we
>>         are sad they port-squatted.
>>
>>         I proposed a way to deal with this in an earlier e-mail. Would
>> that be
>>         satisfactory
>>         to you. To retransmit, we add the following
>>
>>         "Note: While port 4500 is the reserved port for this protocol,
>> some
>>         existing
>>         implementations
>>         also use port 443. The Stream Prefix provides some mitigation
>> against
>>         cross-protocol
>>         attacks in this case, however, the use of port 443 is NOT
>> RECOMMENDED"
>>
>>         We could do something similar for port 80.
>>
>>         Would that work?
>>
>>
>>     This already is good but I think it's not enough. As Tero noted the
>>     working group thought that they rather specify a generic scheme which
>> I
>>     find problematic. Currently the drafts says:
>>
>>     "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
>>
>> "  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.

-Ekr


> Mirja
>
>
>
>> -Ekr
>>
>>
>>
>>     Now given the text you propose above, I actually assume that the text
>> I
>>     just cited will be removed but the whole document is written with this
>>     assumption and therefore there are a couple more places where wording
>>     probably needs to change.
>>
>>     I do understand well the problem and that 443 is used in practice.
>>     However, to match reality I would rather like to see a document that
>>     specifies the approach of encapsulating in TLS/TCP on port 443 that is
>>     used today and pure TCP encapsulation for use with port 4500 only.
>> Again
>>     i think that's where your proposed text is heading to but I think it
>>     needs more changes; in this case it would also make sense to add the
>> TLS
>>     part back in the main document for 443 only.
>>
>>     Further, I have one more question: The document is written in a way
>> that
>>     allows the implementation of multiple services on the used port. Is
>> that
>>     actually done in reality? If we could restrict the use of this
>>     encapsulation with servers that only are IKE servers (at least for the
>>     used port), you would actually not need the magic number anymore. I
>> guess
>>     you can still have the magic number if you really want it because that
>>     makes it easier to distinguish valid IKE/IPSec traffic from other
>> random
>>     traffic that might be send to this port but the other service running
>> on
>>     this port (on other servers) does not need to know about the magic
>> number
>>     because it is supposed to never see any IKe/IPSec TCP-encapsulated
>> traffic.
>>
>>     Does that make sense?
>>
>>     Mirja
>>
>>
>>
>>
>>         -Ekr
>>
>>
>>
>>
>>             Mirja
>>
>>
>>
>>                 We can soften the references in the appendix to the fact
>> that
>>         other
>>                 ports may, in fact, be used. As for the configuration, it
>> should
>>                 state 4500 as the default, but allow peers to configure
>> something
>>                 else out-of-band if they want to modify behavior (which is
>>         standard
>>                 even in UDP implementations of IKE).
>>
>>
>>                     Further, as also mentioned in the tsv-art review
>> (Thanks
>>         Wes!), this
>>                     draft does not sufficiently handle the case of TCP in
>> TCP
>>                     encapsulation.
>>                     Here a copy of the tsv-art review:
>>
>>                     Reviewer: Wesley Eddy
>>                     Review result: On the Right Track
>>
>>                     This document is clear and well-written.  It can
>> easily be
>>                     implemented
>>                     based on the description.
>>
>>                     There are a few additional issues that should be
>>         considered with
>>                     advice to implementers in Section 12 on performance
>>         considerations:
>>                     1) Invisibility of packet loss - Inner protocols that
>>         require packet
>>                     losses as a signal of congestion (e.g. TCP) will have
>> a
>>         challenge due
>>                     to not being able to see any packet losses since the
>>         outer TCP will
>>                     repair them (unless sending into a full outer TCP
>> socket
>>         buffer shows
>>                     up back to the inner TCP as a packet loss?).
>>
>>
>>                 Yes, this is definitely true. We try to capture that with
>> the
>>         line:
>>                 "This will make loss-
>>                    recovery of the inner TCP traffic less reactive and
>> more
>>         prone to
>>                    spurious retransmission timeouts."
>>
>>                 However, this can certainly be expanded upon.
>>
>>                     2) Nesting of ECN -  Inner TCP connections will not be
>>         able to use
>>                     effectively ECN on the portion of the path covered by
>> the
>>         outer TCP
>>                     connection.
>>
>>
>>                 Generally, IPsec tunnels will apply RFC 6040 for
>> translating ECN
>>                 markings between inner/outer packets. Since TCP
>> encapsulation
>>         places
>>                 the inner IP packets in a stream, there isn't a direct
>> mapping.
>>
>>                 An implementation could try to roughly map, but it may be
>> best to
>>                 suggest that the ECN markings for inner and outer packets
>> be left
>>                 separate. What is your opinion?
>>
>>                     3) Impact of congestion response on aggregate - The
>>         general "TCP in
>>                     TCP" problem is mentioned, and is mostly appropriate
>> for
>>         a single
>>                     flow.  If an aggregate of flows is sharing the same
>> outer TCP
>>                     connection, there may be additional concerns about how
>>         the congestion
>>                     response behavior impacts an aggregate of flows,
>> since it
>>         may cause a
>>                     shared delay spike even to low-rate flows rather than
>>         distributing
>>                     losses proportional to per-flow throughput.
>>
>>
>>                 Indeed. We can add further comments to that effect.
>>
>>                     4) Additional potential for bufferbloat - Since TCP
>> does
>>         not bound
>>                     latency, some applications in the IPsec-protected
>>         aggregate could
>>                     drive latency of the shared connection up and impact
>> the
>>         aggregate of
>>                     flows that may include real-time applications.  The
>>         socket buffer for
>>                     the outer TCP connection might need to be limited in
>> size
>>         to ensure
>>                     some bounds?
>>
>>
>>                 We can add a comment to suggest that the buffering should
>> be
>>         limited
>>                 on the outer connection if possible.
>>
>>
>>                     Not addressing these could lead to poor experiences in
>>         deployment, if
>>                     implementations make wrong assumptions or fail to
>>         consider them.
>>
>>
>>                 I do think all of these concerns go back to the overall
>>                 recommendation of "use direct ESP or UDP Encapsulation
>> whenever
>>                 possible". Anything to help back up that point is great!
>>
>>                 Thanks,
>>                 Tommy
>>
>>
>>                     In the security considerations section, there are
>> several
>>         RFCs on
>>                     mechanisms to increase robustness to RST attacks and
>> SYN
>>         floods that
>>                     could be mentioned if it's worthwhile.
>>
>>
>>
>>
>>                     _______________________________________________
>>                     IPsec mailing list
>>                     IPsec@ietf.org <mailto:IPsec@ietf.org>
>>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
>>                     https://www.ietf.org/mailman/listinfo/ipsec
>>         <https://www.ietf.org/mailman/listinfo/ipsec>
>>                     <https://www.ietf.org/mailman/listinfo/ipsec
>>         <https://www.ietf.org/mailman/listinfo/ipsec>>
>>
>>
>>
>>             _______________________________________________
>>             IPsec mailing list
>>             IPsec@ietf.org <mailto:IPsec@ietf.org> <mailto:IPsec@ietf.org
>>         <mailto:IPsec@ietf.org>>
>>             https://www.ietf.org/mailman/listinfo/ipsec
>>         <https://www.ietf.org/mailman/listinfo/ipsec>
>>             <https://www.ietf.org/mailman/listinfo/ipsec
>>         <https://www.ietf.org/mailman/listinfo/ipsec>>
>>
>>
>>
>>