Re: a proposal of address management for IKEv2

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   [e-mail] (Francis Dupont) writes:
   > 2.1.4 Extensions of the IKEv2 draft
   > 
   >     The first things to fix in the current IKEv2 draft [1] are the
   >     notifications for NAT traversal (NAT-DETECTION-*-IP):
   > 
   >      - They use a hash of the SPIs, address and port, following
   >        a specification for IKEv1. This makes no sense for IKEv2.
   
   Why not? The reason they are hashed, is that some users do not want to
   give out information about the addresses used inside internal net.
   They might want to give that information out AFTER the authentication
   (i.e after phase 1 has completed, not during the phase 1), and they
   may want to give that information out only when using transport mode
   (there is no need to give the ip address and port out in case of
   tunnel mode). 
   
=> I don't buy this argument because it implies there is a known NAT
on the path. In this case any address which cannot be the address
seen by the other peer does the job. Same for the port (even I can't
find a reason to keep the port secret).

   >      - There is no specified way to request the inclusion of
   >        these notifications in messages.
   
   In the IKEv1 they were always included if the support for NAT-T was
   detected by vendor-IDs, in IKEv2 I would say we MUST always include
   them. 
   
=> I don't know if we can reach a consensus about this in an IPv6
context (where there should be no NATs :-)...

   > 2.2 NAT traversal requirements
   >
   >      - When there are several VPN clients behind a NAT, the ability to
   >        request a three way handshake (a.k.a. a return routability
   >        check) is needed [6].
   
   three way handshake does not really help here nor is it needed. It
   will make the attackers job little bit harder, but if the attacker can
   modify the packets on the wire, he can also redirect and modify the
   packets used by the three way handshake.
   
   The reason for that is that there is no way we can authenticate the
   outer address of the NAT, and no matter how many packets we send it
   will not help there.
   
=> the purpose of the RR check is mainly operational according
to Jayant Shukla. There are other cases where an RR check improves
a bit the security, as it is cheap IMHO we should keep a way to
perform it.

   > 3.4 Implicit address update
   > 
   >     For address update, there is a choice between implicit and
   >     explicit mechanisms for IPsec SAs and IKE SAs.
   > 
   >     We claim that the implicit mechanism for IPsec SAs is far too
   >     unsecure: this mechanism is very (too?) simple. When a packet is
   >     received from another address, the peer addresses of the IPsec SA
   >     pair are updated. This opens the door to easy denial of service
   >     attacks and assumes extra-processing by the receiver device.
   
   Note, that the attacker needs to continue attacking before he can gain
   anything. If he only modifies one packet the correct address will be
   updated back when the next packet is sent. I.e for the attacker to
   cause denial of service attack he needs to along the path and modify
   every single packet going on one direction.
   
=> no, you forgot the reverse way (the other SA of the pair) which
is updated too.

   In most cases if he can do that he can also remove all the packets and
   that is much easier denial of service attack, than modifying the
   packets. 

=> your argument assumes the routing is symmetrical. If it is not
an attacker on one path can mess the reverse path.

   >     For the implicit mechanism for IKE SAs the things are even
   >     simpler. The implicit mechanism is mainly activated by keepalive
   >     exchanges: to switch from the implicit mechanism to the explicit
   >     one, only an update notification has to be included. The real
   >     difference is in the explicit case an observed peer address change
   >     is only a trigger.
   
   And the attacker can still take the explicit return routability test
   packet and forward it to proper place and finish the 3 way handshake
   to get the same attack. Again he needs to stay in the path and he
   needs to do some extra work, but I don't really think that will be
   that much harder to do.
   
=> this attack works *only* when the NAT traversal feature is enabled
(and I argued that in this case you have near no defense, look at
draft-dupont-transient-pseudonat-01.txt). For mobility or multihoming
any peer address modification en route is easily detected by peer
address notification.

   > 3.5 Explicit address update
   >     The explicit mechanism MUST be used. A new notification has to
   >     be defined. We propose to copy it from the delete notification.
   
   I disagree.
   
=> about the idea of an explicit mechanism itself or about the details?

   >     When the receiver of an update request has to check the validity
   >     of the new peer address, it MAY use a return routability check
   >     sending an informational request at the new address and waiting
   >     for an answer. As informational exchanges are protected no more is
   >     needed.
   
   No, informational exchanges are not protected, because the IP address
   of the packet are not protected, thus this does not protect anything. 
   
=> the peer addresses are protected by the peer address notification
when the NAT traversal feature is disable (see a previous answer).

   >     Example of a return routability check:
   > 
   >      I --- address update request --> R
   >      I <-- informational RR request - R
   >      I --- informational RR reply --> R
   >        now the responder knows the initiator should be where it said.
   >      I <--- address update reply ---- R
   
   And the attack against this is that the attacker takes the
   informational RR request from the point it was going and sends it to
   the I, and then it will modify the reply by the I to have the ip
   address where the original RR request was going. 
   
=> idem. I never pretended to have a solution to the NAT traversal
feature intrinsic security flaw. Thanks for many examples of it (:-).
Now, if the NAT traversal feature is disabled, do you believe there
are remaining new security threats?

   > 4. Security Considerations
   ...
   >    The second (a.k.a. the return routability check) works only with at
   >    least three messages, i.e., for the initial exchange (with the
   >    address stability requirement) and for the explicit optional
   >    checks. IMHO these checks SHOULD be required by default.
   
   As those checks are easy to spoof also, they do not really offer any
   more protection. Instead of modifying 1 packet, we need to modify 3. 

=> I agree the RR check provides only weak security (please don't
forward this to the mobile-ip WG list :-). But without it in the
mobility or multihoming cases, we can only trust your peer...
With it, you can catch some config errors and the attack has to
be an active one.

Regards

[e-mail]