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

[Tero Kivinen <[e-mail]>]

Eric Rescorla writes:
> AFAICT there are two separate issues:
> 
> - The use of 4500, which, as Tero says, we can just update the registry to
> point to this document for.
> - The use of 443, which seems more complicated

Yes. 

> WRT 443, I would assert the following facts:
> 
> - It's not awesome that people use 443 (though understandable because of
> overly-aggressive firewalls)
> - People aren't going to stop using 443 (because it goes through NATs well)

Especially as this has already been specified by the 3gpp TS.24.302
[1], [2].

One of the reasons we are doing this is that 3GPP defined how to run
IPsec over TCP, and they decided to use port 443 and TLS framing for
that (or HTTP proxy supporting HTTPCONNECT).

I.e., they specified firewall traversal that will make TCP connection
to port 443 of the ePDG address, and do normal TLS handshake over
that, and then run TCP stream over that which will have IKEv2 and ESP
frames similar what is defined here.

When IPsec WG decided this is something that should be standardized
for general use, we took that but we did not want to limit it to port
443 and TLS framing only, so we decided that we would define it mostly
on port TCP/4500 without TLS.

The original draft had text about the TLS in main body, but as it was
moved to Appendix during the working group process.

So regardless what we do here 3GPP will be running IPsec over TLS over
TCP port 443 (i.e., IPsec, not HTTP inside the TLS).

To be aligned with them we did for example change the length field
before the messages to be 16-bit instead of original 32-bits. On the
other hand we did add IKETCP stream prefix there, as that allows us to
detect this is IETF version of the IPsec over TCP, not some
proprietary or 3gpp method done before (just in case there are other
differences we did not spot). 

[1] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1073
[2] http://www.3gpp.org/ftp//Specs/archive/24_series/24.302/24302-e30.zip

> Generally, I think it's more useful for documents to reflect
> reality, even if we don't like that reality, and 443 only appears in
> the appendix, so that seems fairly innocuous to me. Perhaps we can
> leave the 443 in the appendix with some note like:

This was the reason why WG originally wanted to move it to Appendix,
and not remove it completely. 

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

I think that text would be fine for me at least (but I am not author
of this draft). 

> What would people think about that?
> 
> Tommy, Tero, the stream prefix doesn't seem totally ideal. Would
> there be wiggle room to specify ALPN here? Or maybe a longer prefix?

The stream prefix is done also on the port 4500 or any other
configured port, and those will not use TLS. Only the port 443 (or
other configured ports defined to use TLS) will use TLS. Also the TLS
wrapper before the IPsec / IKE might be completely sepearate module,
and transferring things from there to IPsec module might be hard.

The stream prefix is also inside the TLS wrapping (see B.1. example),
i.e., it is the first bytes that come from the stream coming out from
the TLS after the TLS handshake is finished. So for the IPsec module,
it does not need to know whether there was TLS warpping around the TCP
stream or not, it will get stream of octets starting with "IKETCP",
and then followed by IKE or ESP packets.

Also, note, that responder might use the fact that when new connection
comes in and it starts with "IKETCP" as indication that there is no
TLS wrapping around the frames, and give them directly to IPsec
module. If there is something else, then it might try to do TLS
handshake and if that successed, then check if inside the TLS there is
"IKETCP" stream prefix and if so, then give that data to the IPsec
module. This is something they could do on any port they are
configured to listen, not only port 4500 or 443. Or it could be they
are configured so that port 4500 is always without TLS framing, port
443 is always with TLS framing, and other configured ports have
automatic TLS detection and processing enabled....
-- 
[e-mail]