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

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

Yes, just saying...

On 27.04.2017 15:50, Eric Rescorla wrote:
>
>
> On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind <[e-mail]
> <mailto:[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.
>
>
> My impression was that the point of this was not to evade future operators
> who are trying to block IKE, but merely to deal with the problem of
> over-aggressive
> middleboxes which currently block IKE, mostly accidentally. Certainly that's how
> we think of things over in WebRTC land.
>
> -Ekr
>
>
>     On 27.04.2017 15 <tel:27.04.2017%2015>: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 <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.
>
>         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>>
>
>
>
>