On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind <i...@kuehlewind.net> 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: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 <i...@kuehlewind.net >>> <mailto:i...@kuehlewind.net>> 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 >>> IPsec@ietf.org <mailto:IPsec@ietf.org> >>> https://www.ietf.org/mailman/listinfo/ipsec >>> <https://www.ietf.org/mailman/listinfo/ipsec> >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org <mailto:IPsec@ietf.org> >>> https://www.ietf.org/mailman/listinfo/ipsec >>> <https://www.ietf.org/mailman/listinfo/ipsec> >>> >>> >>> >>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
