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 1:32 AM, Mirja Kühlewind <[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?

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