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