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

[Eric Rescorla <[e-mail]>]

On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind <[e-mail]>
wrote:

> One more side comment on the magic number: actually the magic number makes
> it easy for network operator to identify IKE/IPSec traffic on any port and
> block all packets that below to a flow that started with this pattern in
> the first payload packet. So if you really think you need a magic number,
> you should probably always encrypt it.
>
>
My impression was that the point of this was not to evade future operators
who are trying to block IKE, but merely to deal with the problem of
over-aggressive
middleboxes which currently block IKE, mostly accidentally. Certainly
that's how
we think of things over in WebRTC land.

-Ekr


> On 27.04.2017 15:42, Mirja Kühlewind 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 <[e-mail]
>>> <mailto:[e-mail]>> 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? 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
>>>             [e-mail] <mailto:[e-mail]>
>>>             https://www.ietf.org/mailman/listinfo/ipsec
>>>             <https://www.ietf.org/mailman/listinfo/ipsec>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     IPsec mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/ipsec
>>>     <https://www.ietf.org/mailman/listinfo/ipsec>
>>>
>>>
>>>
>>