[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding revised identities to IKEv2



 In your previous mail you wrote:

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

=> so the addresses I talk about are the outer addresses.

   >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...
   
   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.
   
=> my concern is about outer addresses: we need flexibility in order
to change when needed these addresses (I believe we agree about this
point) and we need safety in order to avoid DoS attacks using SA
establishment with rogue outer addresses.

   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.
   
=> it should be an architectural issue but if the specifications
don't say anything clear about it, it becomes an implementation choice,
i.e., it follows the path we don't want.
As I have written, the revised identities proposal cuts the spurious
link between identities and addresses, so the issue can become back
an architectural one.

Regards

Francis.Dupont@enst-bretagne.fr