Re: a proposal of address management for IKEv2

[Tero Kivinen <kivinen@ssh.fi>]

Francis.Dupont@enst-bretagne.fr (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). 

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

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

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

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. 

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

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

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

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

> 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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/