some concerns about last IKEv2 draft

[Tero Kivinen <kivinen@ssh.fi>]

Francis Dupont writes:
>       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. A host not behind a NAT
>       SHOULD NOT do this because it opens a DoS attack possibility. Any
>       authenticated IKE packet or any authenticated IKE encapsulated ESP
>       packet can be used to detect that the IP address or the port has
>       changed.
> 
>  => the SHOULD and the SHOULD NOT apply to the same case (host no behind
>     a NAT). Obviously there is a typo, IMHO the right version is:
>     "A host behind a NAT SHOULD NOT do this ...".

Yep, that seems to be typo. 

>     BTW the "any authenticated IKE encapsulated ESP" wording is poor and
>     should be removed, or replaced by something which takes into account
>     the whole IPsec traffic (both for the detection of the address change
>     and for the update of the endpoint behind NAT address).

I think there was also typo, it should say:

"any authenticated UDP encapsulated ESP packet"

Note, that we do not need to care about AH, as they cannot be
encapsulated in the UDP (the current NAT-T does not have support for
AH). 

>  - just after this paragraph, there is:
> 
>       Note that similar but probably not identical actions will likely
>       be needed to make IKE work with Mobile IP, but such processing is
>       not addressed by this document.
> 
>  => the Mobile IP case can be symmetrical so an identical action can't
>     work in all cases because it would open the door to the DoS attack.

I think the current wording is ok, i.e it says we do not handle those
cases here. I do not understand what your actual concern is in that
paragraph?

>  - there is nothing about the protection of peer addresses, so IKEv2 can
>    be used to launch DoS attacks... I still believe the easiest fix is
>    to make the peer addresses explicit parameters of the IKE SA.

As described above the other mobility, multihoming, sctp, roaming etc
issues are left out from this document, and there will be another
document (from different wg) to take care of those later.

There is NO easy way we can make IKEv2 so that there is no possibility
to do launch DoS attacks. The attacker can always cause the other end
to send cookie request to the faked address, i.e causing a DoS. Only
way to protect against that would require the responder to somehow
authenticate the first packet sent by the initiator without sending
anything back, and that would propably need costly public key
operation, causing easy DoS against the responder.

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). If the
other end is behind NAT, then the host behind NAT can be diverted to
send packets to wrong host (DoS attack), but the situation will be
fixed immediately when the attacker stops modifying packets and first
packet from the real host behind NAT comes to the host behind NAT.

There is no way to protect against that without co-operating with the
NAT box, if we want to allow NAT boxes to be rebooted etc. That part
of the document is only SHOULD so if implementor can leave it out if
he does not care about the problem. I.e for example is willing to pay
the cost of couple of minutes of the packets dissappearing and
reauthentication after NAT changes the IP address. The problem with
reauthentication is that it might require new password/secur-id etc to
be requested from the user.
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/