David McGrew (mcgrew) writes: > >Just a note: the relative saving of point compression is larger when > >sending hash + URL instead of the CERT. > > What's the scenario here? If hash + URL is sent, the certificate still > has to be retrieved.
Usually not, as it is already cached in the client. I.e. it only needs to fetched first time unknown hash is seen. After fetching it first time, and validating the cert the recipient of the hash + URL does not need to fetch it again when the same peer connects later. In most cases the devices talking to each other using IPsec is quite small set of devices, so caching their certificates does not take too much resources (especially if you just store the public key, hash and end of validity time (i.e. when you need to do something next time, either fetch CRL, or revalidate the cert because it expired etc). > It might not be part of the IKE exchange, but moving it to HTTP > doesn't mean that it doesn't contribute to bytes on the wire (or > over the air, in the case of wireless). The another reason for this feature in IKEv2 is to make the IKE_AUTH packet smaller, so it does not need to be fragmented. IKE_AUTH packet is UDP and there are some problems in some environments if it gets too big and starts to get fragmented. This option moves big parts of the IKE_AUTH packet away from UDP packet to separete TCP session. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
