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

[Tommy Pauly <[e-mail]>]

> On 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.

The working group determined that the point of the protocol is not to evade any possibility for middleboxes to block the traffic, but instead to allow connectivity through middle boxes that are essentially 'accidentally' blocking IKE/ESP. If an operator wants to block this traffic explicitly, that is fine. However, it is very common that networks on public access points will block everything by default based on what they consider to be 'web' traffic; they do not inspect more deeply.

Thanks,
Tommy

> 
> 
> 
> 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>
>>> 
>>> 
>> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec