Re: Adding revised identities to IKEv2

[Stephen Kent <kent@bbn.com>]

At 2:47 PM +0100 11/15/02, Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    ...  
>   	- when names are used as identities, we need to be able to
>    map the name to a current address (during SA establishment) so that
>    we can make later decisions on a per-packet basis using the current
>    address. in this case, we verify that the named entity is at whatever
>    address is asserted by it in real time, and just use that address
>    going forward.
>
>=> this mapping from names to addresses is in this statement done
>by looking the source address of received messages (i.e., address
>IKE runs over). This cannot provide in all cases the needed flexibility
>and safety. For instance the address can be changed "en route",
>the peer can put a rogue address (a real concern for 1+1 exchanges),
>etc. And if another mapping mechanism is used (IPaddress alternate
>Subject names in certificates, DNS/DNSsec, etc) the balance between
>flexibility and safety is not the same.
>But my main concern is that this balance is not controled: this is just
>the result of never documented implementation choices...

Francis,

An intermediate IPsec device has only per-packet header data 
available as a basis for making access control decisions for traffic 
on an extant SA. Thus we must bind the traffic for the SA to a set of 
addresses that we know about when we establish the SA. For tunnel 
mode, the outer addresses can change during the SA without breaking 
the SA, but the inner addresses must remain constant (or at least be 
part of the same set established during SA establishment). Those 
addresses cannot be changed by black routers, NAT devices, etc., 
since they are inside the protection boundary.

I don't think this characterization of the use of symbolic names and 
mapping to addresses is an implementation choice issue, as you 
suggest above. It is an architectural issue.

Steve