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

Re: some concerns about last IKEv2 draft



 In your previous mail you wrote:

   I think the current draft does say that.

=> I don't think so, or at least it is unclear.

   It says that host not behind
   NAT SHOULD send all packets to the last valid authenticated source
   address seen from the peer. And then it says that both IKE packets and
   UDP encapsulated ESP packets can be used to get that last
   authenticated source address. 
   
=> we agree about what to do. The text says:

       There are cases where a NAT box decides to remove mappings that
       are still alive (for example, the keepalive interval is too long,
       or the NAT box is rebooted). To recover in these cases, hosts that
       are not behind a NAT SHOULD send all packets (including retried
       packets) to the IP address and port from the last valid
       authenticated packet from the other end.

The context suggests IKE packets, so we should agree about a clarification,
for instance by adding ESP packets to the "(including retried".

   >    In the current version attacker can cause packets to diver to
   >    different address by modifying the packets on the fly, but only one by
   >    one basis (i.e each packet needs to be diverted separately).
   > 
   > => unfortunately this is true only for IKE itself, not for the IPsec
   > traffic managed with IKE.
   
   IPsec traffic does not change addresses at all unless there is NAT
   between. The current draft explictly says that the IPsec SA is created
   implictly between the ip address used for the IKE SA.

=> no, this is not explicit. My proposal is to make this clearly explicit,
and it seems you agree with me.

   I.e unless there
   is NAT-T the ESP packets will always same source and destination IP
   pair that what was used when they were negotiated.
   
=> this "when they were negotiated" has to be clarified. And I prefer
(for security reasons, with a SHOULD) to use the IKE SA addresses
than the addresses in the CREATE_CHILD_SA message (in this context,
i.e., no NAT-T or not for the peer behind a NAT).

   There will be new wg/document describing how to change the address of
   the already exising SAs later, but in the current document it is
   simply said that it cannot be done yet.

=> agree.

Thanks

Francis.Dupont@enst-bretagne.fr