[anonsec] comments on the BTNS core I-D

Nicolas.Williams at sun.com (Nico) Thu, 26 July 2007 19:37 UTC

From: Nicolas.Williams at sun.com (Nico)
Date: Thu, 26 Jul 2007 14:37:31 -0500
Subject: [anonsec] comments on the BTNS core I-D
In-Reply-To: <f8as41$dt0$1@sea.gmane.org>
References: <p06240505c2cd5414684e@[]> <f89aup$pa$1@sea.gmane.org> <p06240508c2ce6ce745e0@[]> <f8as41$dt0$1@sea.gmane.org>
Message-ID: <20070726193730.GB2444@Sun.COM>

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.