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

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

Hi Tero,

a few quick replies but we also discussed this yesterday at the telechat and 
agreed on a way forward.

On 27.04.2017 16:12, Tero Kivinen wrote:
> 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 understood this. My point breaks down to a) the case where you would use 
two services at the same time on the same port (see below) and b) some 
language changes that do favor to use 4500 where possible and not explicitly 
advise to use other assigned specific ports in the line of what Ekr already 
proposed.

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

Actually this is another good point. If you have multiple open ports, you can 
give more advise which one to try when and in which order, e.g. always try 
4500 first (first UDP then TCP which the draft I believe already says), then 
others.

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

There is a difference of distinguishing other/old version of IKE or trying to 
distinguish IKE from other protocols. The point is for IKE you can define the 
magic number as reserved but you probably don't really want to reserve the 
same bits for all other protocols than you may run in parallel on the port. 
As long as you don't 'officially' make this reservation by updating the 
respective specs of other protocols, you can never be sure that there will 
not be a conflict in future version of these protocols.

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

That's fine as long as the multiplexing is between version of IKE only.

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

Then let's just not support this case and let's specify in the draft that you 
cannot run another service on the used 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.
>