Mirja Kühlewind writes: > > 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.
Note, that configurations can only use ports which are defined to be used by the responder. I.e., if the responder is configured to listen port 4500 and port 443 (with TLS wrapping), there is no point of initiator to try port 80, as it will not work. I.e., in practice this will end up the operators picking suitable number of port numbers they will configure their system to respond to, and most likely they will try to use services which are not in use normally by the responder. I.e., if the responder is running web-server, it cannot very easily also use the port 80 (or 443) for the IPsec traffic, thus it might pick ports 4500, 8000, 8080 or some other random ports which might go through the filters which are already blocking all UDP traffic, and at least port 4500 for TCP. So this is same thing we have now in web. I am quite often running web servers on random ports just because some places have had filters blocking some ports. For example one of my friends company network blocked connection to port 8080, but did not block connections to port 2020, so my web server was running (also) on that port... So unless you are saying "TCP/UDP ports on all protocols MUST NOT be configurable, and only port numbers reserved for those services are allowed" there is nothing we can really do. (and even if you say that, nothing is going to change, as people are so used to getting past stupid firewalls). > 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. This is what the document tries to say. I.e., for some ports (like 443), there might be some other framings (like TLS) in place, and for other ports there might not be. As IPsec will require pre-configuration this information which ports are used, and what framing protocol is used comes from the configuration. > 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? Yes and no. There are some old IKEv1 based proprietary TCP encapsulation methods, and I think some of those might actually use port 500 and perhaps also port 4500. So vendor implementing those, might want to do multiplexing based on whether there is the stream prefix in front or not to see whether the old proprietary method is used, or the one defined in document is used. Another issue might be that the SGW terminating the TCP 443 connection, might also support some proprietary TLS VPN implementation and differntiating from that is also something I can see that vendors might want to do. So I do not know if anybody is really do it now, but I can see reasons why people might want to multiplex the proprietary things they are now running on those ports 500/4500/443 with the standard we are defining here. > 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. If it is operationally possible, and there is no old proprietary protocols to be supported, I would assume most implementations would not want to bother with the multiplexing different protocols on one port. I.e., new implementations and new setups will most likely then move for example the adminstative interface over https to separate IP-address, just to make sure that it is easier to implement and operate. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
