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

[Mirja Kühlewind <[e-mail]>]

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.



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