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>> >> >> >> >>
- [IPsec] Mirja Kühlewind's Discuss on draft-ietf-i… Mirja Kühlewind
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Tommy Pauly
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Tero Kivinen
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Tommy Pauly
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Tero Kivinen
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Spencer Dawkins at IETF
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tero Kivinen
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tero Kivinen
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Tommy Pauly
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Tommy Pauly
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Eric Rescorla
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind
- Re: [IPsec] Mirja Kühlewind's Discuss on draft-ie… Kathleen Moriarty
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Mirja Kühlewind
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tommy Pauly
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tommy Pauly
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tero Kivinen
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tero Kivinen
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tero Kivinen
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Mirja Kühlewind
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Eric Rescorla
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tommy Pauly
- Re: [IPsec] Mirja Kuehlewind's Discuss on draft-i… Tommy Pauly
- [IPsec] Should draft-ietf-ipsecme-tcp-encaps-10 u… Paul Wouters
- Re: [IPsec] Should draft-ietf-ipsecme-tcp-encaps-… Tommy Pauly