[anonsec] comments on the BTNS core I-D

[Nicolas.Williams at sun.com (Nico)]

On Thu, Jul 26, 2007 at 02:19:28PM -0500, Michael Richardson wrote:
> Stephen Kent wrote:
> > 	- If the ID asserted by a peer does not match any PAD entry, 
> > then a BTNS-enabled IPsec implementation replaces the ID with into 
> > the new ID of type "PUBLICKEY" that is created by extracting the 
> > public key from the IKE CERT (or ??) payload
> > 
> > 	- the PAD is searched again, using this new ID type and value

Indeed, if there are any PAD entries matching a specific public key,
then those must take precedence over the catch-all BTNS PAD entry.

> > 	- if there is a match, the associated PAD entry (which will 
> > be a BTNS entry) is used to control the SPD search
> > 
> > 	- if there is no match, the IKE SA is rejected
> 
> Good text. We'll use it.
> Q: does this relax the requirement for the PAD entry to be lowest priority?

No.  PAD entries that match specific PUBLICKEY IDs must come before the
catch-all BTNS PAD entry (which MUST be last); they must also come
logically after any PAD entries matching other ID types.

> The two searches can be implemented with a single scan, with a priority based 
> comparison (i.e. keep on the best match).

Indeed.  We need only describe a canonical approach though, but we could
certainly say that a one-pass optimization is feasible.

Nico
--