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

[Spencer Dawkins at IETF <[e-mail]>]

Not my discuss, but since I'm also supposed to worry about ports :-)

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

> Hi Tommy,
>
> please see below, only on the first point for now.
>
> On 26.04.2017 05:28, Tommy Pauly wrote:
>
>>
>>
>> On Apr 25, 2017, at 5:48 AM, Mirja Kühlewind <[e-mail]> wrote:
>>>
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-ipsecme-tcp-encaps-09: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/stat
>>> ement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> This draft suggests that ports that are assigned to other services can
>>> simply be used. This is not okay. If a port is assigned to a certain
>>> service, this service and/or the respective RFC defines how this port is
>>> used. Simply changing the specified behavior by requiring a check for a
>>> magic number cannot be done without updating the RFC that the port
>>> assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
>>> the IANA registry would need to be updated.
>>>
>>
>> At this point, the only portion of the document that mentions a port
>> other than 500 and 4500 is the appendix. We recommend that 4500 is used as
>> the port for TCP encapsulation. The IANA registry for 4500/tcp is already
>> assigned to IPSec NAT Traversal in RFC 3947; that document does not explain
>> how TCP is to be used, so the reference should be updated to point to the
>> document on TCP encapsulation.
>>
>
> So at least section 11 talks about port 80 as well. It doesn't explicitly
> recommend to use it, but because it's discussed there I would say that this
> is implicitly the intention:
>
> "A network device that monitors up to the application layer will
>    commonly expect to see HTTP traffic within a TCP socket running over
>    port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE),
>    this could be dropped by the security device."
>

I understand Mirja's point, and I understand why the draft doesn't tie the
protocol to one assigned port.

>
> Further it's clear that the whole intention on the existence of section 4
> is that you want to (mis)use ports that have been assigned for other
> services and are for that reason potentially not blocked.
>
> The (processing) problem here is that even if the bit pattern in section 4
> is currently not used and unlikely to ever be used by the protocol that is
> officially assigned to the port, there is nothing that excludes a future
> protocol spec to use these bits (and there is also nothing that makes
> designer of these protocols aware that these bits are already in use by a
> different protocol on the same port). So the minimum you basically would
> need to do is to update all RFCs for protocols on ports that you may want
> to use (and probably also the IANA registry for these ports to add a
> refernce to this document) and say that it is not possible to use this bit
> patter for the protocol itself and all future version of it. Of course you
> probably would need to involve those working groups that maintain these
> protocols and I also not sure how happy those groups would be about such an
> update.
>

What I'm thinking, is that this isn't a problem we can solve, draft by
draft.

Assuming that https://datatracker.ietf.org/doc/rfc3986/referencedby/ is a
reasonable proxy, the datatracker returns 775 documents that reference the
RFC that defines the URI scheme, which includes
https://tools.ietf.org/html/rfc3986#section-3.2.3, allowing the application
to specify a port which (of course) could be assigned to another protocol
in
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
.

That's a worst-case scenario, of course (some RFCs weren't deployed, some
are probably obsoleted by other RFCs, etc.), but I'm betting the number of
protocols with the same issue as HTTP(S) has here is somewhere in the
hundreds.

>
> I personally think that that is not a nice solution and if you e.g. want
> to use port 80 for IKE, you would need to define an IKE variant over
> HTTP/TCP. That doesn't sound great and I'm not sure if that a solution
> anybody would like to implement.
>
> 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.


So, yes, I agree with this, and suggest that we start that discussion on
next week's informal telechat.

But, to try to make progress on this Discuss ...

The reason optional ports in URIs work, is that someone handed you a URI
with that port number who has some reason to believe that the port number
is OK to use with the host included in the URI.

Is that a reasonable assumption about the way IPsec and IKE over TCP will
be deployed? That no Initiator would assume that another host is an IKE
Responder, without being configured to use that host?

Curiously,

Spencer


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