[anonsec] question: ID payload in BTNS IKE negotiation

[mcr at sandelman.ca (Michael Richardson)]

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

Shinta Sugimoto wrote:
> 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.

Unless you propose to move during the lifetime of the connection, this 
concern does not apply.

If you do move, then you establish a new SA. You use your new address.
This is BTNS, you don't need long-term credential for PAD lookup. That's the 
whole point.

If you are multihomed, and you might switch prefix, then you probably want 
MOBIKE, at which point, you might be able to propose multiple addresses.

> 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.

I disagree strongly. It works just fine.

>> 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

Because it's just an entry in the PAD.

> (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?

You are now assuming that both ends know that they are doing BTNS.
A number of the models assume that one end has strong authentication for the 
other end, in which case, it would expect something specific in the ID field.

Note that each end may have independent notions of whether or not the peer 
will strongly authenticate it.  As long as the public keys are present in a
CERT payload, we do not have to tell the peers what mode of BTNS they are in.
It may be that we will get strong authentication because the administrators 
of both peers have configured keys into their trusted store after checking 
fingerprints over the phone, in PGP signed email, etc.