Valery Smyslov writes: > > * Find ways of making the packets smaller: move to PSK, fiddle > > with trust anchors so that only one cert is needed, avoid sending > > CRLs, hash-and-URL, etc. These are not always successful, and > > often require more configuration than we would like. > > Not an option either. Corporate PKI has plenty of requirements to > deal with and the requirement to make certificates smaller is the > least. Hash-and-URL is a nice feature, but it requires an additional > infrastructure that not every customer is willing to deploy.
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. > > * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port > > 500 is already allocated to "ISAKMP". We have had IKE running over > > TCP for several years for remote access clients. This was done > > because remote access clients connect from behind some very dodgy > > NAT devices, and some of those do drop fragments. Getting this > > behavior at the ISP is novel. > > IKE over TCP has its drawbacks. It eliminates the ability of IKE to > be stateless (with COOKIE), thus considerably increasing its > vulnerability to DoS attack. Switching between UDP and TCP > (especially in the middle of exchange) considerably complicates > protocol that is already complex in that part (remember switching to > port 4500 on the fly). 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. 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, 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). 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. > I'm in favor of developing standard way of fragmenting big packets > in IKEv2. I beleive there might be relatively simple solutions not > breaking core protocol implementation. I think TCP is better approach. It has already solved most of the hard problems, and we can use very small wrapper layer to support it in the IKEv2. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
