Hi,
Hash-and-URL do require customer to deploy www-server. I admit that
for some enterprices that might be burden to deploy, but quite a lot
of other enterprices do already have working deployed www-server they
can use...
The url can be static, the certificate stored on that url can be
static, new certificates needs to be pushed to www-server only and
only when the new certiticate is enrolled. The url can be something
like http://certs.example.com/<ca-short-name>/<hash-of-cert>.
Hash-and-URL should make the packets small enough that fragmentation
is not needed (especially if network supports 1280 byte packets).
* Build a fragmentation layer within IKE, so IKE messages are
broken into several packets that get reassembled at the
destination. This is the path taken by one of our competitors [1].
This means that IKE has segmentation in addition to other TCP-like
features such as retransmission.
I like this approach, but as far as I know this is done for IKEv1
only.
This also requires finding pmtu and so on which means this whole
protocol gets quite complicated.
Not necessary. For the sake of simplicity you may always fragment to
the smallest packets guaranteed to pass through (576 bytes for IP4).
IKE is not bulk transfer protocol, so performance is not an issue here.
If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not
enough, then I think IKE over TCP is the way to go. Most likely it
would be better to do it similarly we do NAT-T, i.e. instead of
switching to UDP port 4500 we would switch to TCP port 4500 for the
IKE_AUTH packets. Nothing prevents starting the creation of the TCP
connection while sending the first IKE_SA_INIT packet over UDP.
As with NAT-T we can either start over TCP port 4500 immediately from
the beginning, if we like (i.e. we know from previous experience or
from configuration that we should do that). As with NAT-T we can use
either UDP or TCP port 4500 at will, regardless whether NAT was
detected or not.
Also either end can send requests either over UDP or TCP and reply
would come back over same channel. In some cases we might want to
send packet first with UDP, and if we do not get any replies back for
our requests, we might want to fall back to TCP. In the other hand
there is no point of sending retransmissions to TCP connection, i.e.
we always only send one copy there (unless the TCP connection is
reset, and we recreate it). Anyways it is possible for both initiator
and responder to see same packet coming both over TCP and UDP, so
normal windowing and duplicate packet detection needs to be done (and
resending of replies if needed etc)
Using TCP port 4500 instead of TCP port 500 has the benefit that it
might bypass those filters someone was complaining about.
If we want to support ESP over that TCP channel too, then we need to
add some kind of framing which will tell the simulated UDP packet
length, i.e. similar what DNS does (prefix the packet with two byte
length field). On other hand we might want to add also non-IKE marker
somewhere too.
Don't you think it looks too complicated? Two different transport
each with two ports, special framing etc...
Adding one notification to the IKE_SA_INIT to indicate the support of
this feature would be need.
Note, that if we run IKE_SA_INIT over UDP, then we can still support
stateless cookies,
Successful COOKIE exchange make you sure that peer is real entity,
but in case of TCP this information can't help TCP/IP stack to
distinguith between bad and good boys. Or you have to constantly update
firewall rules enabling and disabling incoming TCP connections
from different addresses depending on success/failure of
COOKIE exchange.
and for packets requiring fragmentation there is no
stateless processing anyways (whether the state is in the system
reassembly system, new IKEv2 reassembly system, or in the TCP does not
really matter).
Any IKE exchange after COOKIE request is already statefull,
so I don't see any problem here.
One open issue is how this fits with MOBIKE. I.e. if we get address
updates over UDP, do we immediately also create matching TCP
connection, and what do we do if that TCP connection creation fails,
even when the UDP worked etc.
Yes, It will become more and more complex.
The ESP over TCP do cause some problems, as some implementations do
capture those packets already in the kernel without ever giving them
to the userland, and doing that from the TCP stream is bit harder and
requires bit more code.
Oh... ESP over TCP is very problematic... And if the transports are different
for IKE and ESP, we will catch all kinds of problems when IKE goes
smoothly, but following ESP doesn't work at all.
Regards,
Smyslov Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
