Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]