Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 27 April 2017 15:21 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.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 20A0E1296CD; Thu, 27 Apr 2017 08:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TtlNnZBMBFc5; Thu, 27 Apr 2017 08:21:56 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 578C2129A9B; Thu, 27 Apr 2017 08:21:02 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id v14so29905204pfd.2; Thu, 27 Apr 2017 08:21:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9EPCMnPJ3Tt4q6rNW9qRkjdiYevPkM+Z20F48SPZVsU=; b=Wy18qkDeKhHIgAMbfKOf1OwvnemnoF00W7eemSmFvJciKFWmYZ97ilXrNn3o6O24cD fTBireBpCQrV0nDt2YFQx0OgURuSAcsXnaMHcA1uJwMl+NUTN4Dhp+15PAuzxZs6s1k8 o4dHXbN0+Eury/l87L4DVoktzHbDaXfWfEUGfaXqQX7TnK80tdrkoFChT/maC3ZytPGI ExEmZxz9IngH3it6yYnNMlfTzBC9JVSLPQRmrko9ezF1CwxhOERrNteQKYPYn48ASxku xG8BNjOOFp3a1K/l9IPHqAuv7eB1KcPVHjy8mQ/MNqhE+oE4eTJf2nw1Elb42wx0r529 VQyQ==
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:content-transfer-encoding; bh=9EPCMnPJ3Tt4q6rNW9qRkjdiYevPkM+Z20F48SPZVsU=; b=j3nzikQM0icM72/ZrqOldhEOhAag3hqcbhJ9/JSYOMNYmpGZtNqjEd9QLZMwSNm7Bi d2N8szOtEOLWvyzfVuvAjFNweECijbcML+djLy2mOsKCNEoJAi/K9qd2wkswLbhnxdjg amGT2X2xcbB96gOTRBnt1+12RfPEWV0wWut4Gfw5uhRSNsPtJVuAPUhn6zolFNm0IqeV 0i2VFZJ0sdplb6U11bnF8rmjAd2dWOgjT4NefQptNSzJ0/doShhkjnBpS2yLaOozNjuo LY7cZTuy9jyVYBJXJ1LFAilLQ1XB6HW0P3y1IoAtTiWbOz2tohdBt7NwhReF2lJEAN3A qDlw==
X-Gm-Message-State: AN3rC/6RJBVD9juqcvPOt5k4UeYiZzNB84R+2Dd2C+Z5eK8Vyz5CLBRu IfSbcczkeLHHT8ihTkm4lPCuRUZcIA==
X-Received: by 10.99.62.68 with SMTP id l65mr6335703pga.172.1493306461742; Thu, 27 Apr 2017 08:21:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.185.143 with HTTP; Thu, 27 Apr 2017 08:20:21 -0700 (PDT)
In-Reply-To: <22fac532-f30b-03e3-0757-aed213e5a346@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>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 27 Apr 2017 11:20:21 -0400
Message-ID: <CAHbuEH42tWuxmyVka+S71+pwx0X3ebhE+MyArH3G5PCaaSVnnQ@mail.gmail.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
Cc: Eric Rescorla <ekr@rtfm.com>, ipsecme-chairs@ietf.org, Tero Kivinen <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly <tpauly@apple.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/4sMOzV2sUb4oR1Feb0wVKsYEjv8>
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:21:58 -0000
Hi Mirja, I think I can help with one of your questions. inline On Thu, Apr 27, 2017 at 9:42 AM, Mirja Kühlewind <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:51, Eric Rescorla wrote: >> >> >> >> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <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. > > 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? Well, Warren pointed out somewhere in a thread that you might have an admin interface operating through the use of port 443. From my experience, if this happens, there is a different connection method (virtual server - address/port) that allows for this to happen. I hope that is helpful. Kathleen 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> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> >> >> > -- Best regards, Kathleen
- [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