[anonsec] question: ID payload in BTNS IKE negotiation

[Shinta Sugimoto]

Hello Michael,

Thank you for the response.  Please find my comments inline.

On Sun, 13 May 2007 19:51:50 -0400
Michael Richardson <mcr at sandelman.ca> wrote:

> Shinta Sugimoto wrote:
> > In BTNS IKE negotiation, what should ID payload (IDi/IDr) be?
> > I understand that public key is the instance which represents
> > identity of the host in BTNS.  But reading the spec, I did not fully
> 
> To first order, it shouldn't matter, however that will lead to 
> interoperability issues.

I see.  So the spec should be clear on this point.

> 
> My suggestion is that it should be IPV4/IPV6_ID of the host.

Hmm.  This seems to me fine for static and/or single-homed environment,
but not ideal for mobile and/or multihomed environment (e.g. RFC 4555)
where IP address is not suitable for the purpose of identifying peers.
So, I think it would be better to use something different than IP
address for ID payload although I don't have good answer either at the
moment.

> 
> > understand how IKE negotiation is done in particular usage of ID
> > payload.  My interpretation of the spec is that an identity of
> > a peer (=public key) is represented by the CERT payload.  If so,
> > what is the role of ID payload in BTNS IKE negotiation?
> > And what should be included in the IDi, IDr?
> 
> The ID payload tells you how to look up the policy in the PAD.

Yes, that is true.  And the use of identifier which is based on
IP address (ID_IPV4_ADDR/ID_IPV6_ADDR) will limit the applicability
of BTNS to static/single-homed environment as I mentioned above.

> You will have to look into the PAD at least, to discover that you had no 
> explicit policy for this peer, and that therefore, it should be put into
> "BTNS" category.

Yes.

I still need clarification of the intention of BTNS spec for ID.  The
spec (draft-btns-core-02) says:

> 2.  BTNS
> 
>    The IPsec processing model, IKE and IKEv2 are hereby modified as
>    follows:
> 
>    o  A new ID type is added, 'PUBLICKEY'; IDs of this type have public
>       keys as values.  This ID type is not used on the wire.

I assume that the above sentence recommends not to use ID_PUBLICKEY as
an ID payload.  If so, what is the reason behind?  I see that it
(including ID_PUBLICKEY in ID payload) would simply be a duplication
because the public key is to be stored in CERT payload, but I believe
it still makes sense to use ID type which is independent from IP address
for ID payload.  Any comments?


Regards,
Shinta