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

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

See below.

On 27.04.2017 16:10, Eric Rescorla wrote:
>
>
> On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind <[e-mail]
> <mailto:[e-mail]>> 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 <tel:27.04.2017%2014>:51, Eric Rescorla wrote:
>
>
>
>         On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[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.
>
>
> Hmm... Maybe I don't understand your overall theory here. It seems like having
> reserved ports for protocols but letting people run them on any port they want
> to is kind of common practice. See, for instance:
> https://tools.ietf.org/html/rfc7230#section-2.7.1
>
> "  If the host identifier is provided as an IP address, the origin
>    server is the listener (if any) on the indicated TCP port at that IP
>    address. If host is a registered name, the registered name is an
>    indirect identifier for use with a name resolution service, such as
>    DNS, to find an address for that origin server. If the port
>    subcomponent is empty or not given, TCP port 80 (the reserved port
>    for WWW services) is the default."

This doesn't say you can/should use any port you want (it says you can use 
another port than 80) but you should till avoid to use any other port that 
runs a different TCP service.

Mirja


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