Re: Issue 60: Addresses in IKE_SA_INIT/AUTH (was: Comments of draft-ietf-mobike-protocol-04.txt)

Tero Kivinen wrote:

> 2)
>
> In section 4.2 we should always take the IP-addresses from the
> IKE_AUTH request, as there might be multiple IKE_SA_INIT request,
> and some of those might not create state at all (cookie,
> invalid_ke_payload). I think it would be simplier to say that the
> IP-addresses are always taken from the IP header of the IKE_AUTH
> packet having SA payload (regardless of the NAT-T or no NAT-T).
>
> In normal IKEv2 this does not matter, as if no NAT-T is used then
> the IP address must stay same, and if NAT-T is used then we take the
> last packet seen and use the IP-addresses from there. In Mobike we
> do need to define the exact time what IP-address is used, and I
> think the packet having the ADDITIONAL_*_ADDRESSES would be the most
> logical choise (i.e. the IKE_AUTH packet having the SA payload).

There's a reason why I wrote it that way: when not doing NAT-T, 
the address should be taken from the same packet which contains
NO_NATS_ALLOWED. And it seems that putting NO_NATS_ALLOWED in
IKE_SA_INIT is simpler than IKE_AUTH; see below on this...

> The section 4.8 says that NO_NATS_ALLOWED should be put to the
> IKE_SA_INIT (among other things), but we do want to keep IKE_SA_INIT
> as small as possible, so I think IKE_AUTH is much better place for
> that notify. That would also be in sync with my proposed change to
> the 4.2 where I proposed to say that use the IKE_AUTH packet having
> SA payload to get the IP address tobe used. NO_NATS_ALLOWED is not
> needed in the IKE_SA_INIT like NAT_DETECTION_*_IP notifies are, as
> they do not cause changing of the port numbers for the IKE_AUTH.

NO_NATS_ALLOWED takes less space than NAT_DETECTION_*_IP payloads,
so IMHO it's not unreasonable to put it in IKE_SA_INIT.

The real reason to put NO_NATS_ALLOWED in IKE_SA_INIT is that it's
much simpler to retry the request if we get UNEXPECTED_NAT_DETECTED
error back. In particular, this text from Section 4.8 would need major
revision if we take the address from IKE_AUTH:

   More specifically, when NAT Traversal is not enabled, all messages
   that can update the addresses associated with the IKE_SA and/or IPsec
   SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that
   contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS
   notifications) MUST also include a NO_NATS_ALLOWED notification.  The
   exchange responder MUST verify that the contents of the
   NO_NATS_ALLOWED notification match the addresses in the IP header.
   If they do not match, a response containing an
   UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the
   IKE_SA_INIT exchange, no state is created at the responder).  The
   response message is sent to the address and port that the
   corresponding request came from, not to the address contained in the
   NO_NATS_ALLOWED notification.

   If the exchange initiator receives an UNEXPECTED_NAT_DETECTION
   notification in response to its request, it SHOULD retry the
   operation several times using new IKE_SA_INIT/INFORMATIONAL requests.
   This ensures that an attacker who is able to modify only a single
   packet does not unnecessarily cause a path to remain unused.

> Also moving that NOFITY to the encrypted IKE_AUTH packet will
> prevent passive attackers of getting the information about the IP
> addresses and ports used in case host behind NAT is configured to
> try first with NO_NATS_ALLOWED before falling back and enabling
> NAT-T. It will also make the attacker acting as a NAT between two
> hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker
> can simply flip a bit inside the NO_NATS_ALLOWED payload to cause
> DoS, otherwise he need to flip bit in the IP-address or ports, which
> requires it to catch the return packet and forward it to the
> original requestor to cause attack. It is not much, but offers again
> a bit more protection against attacks.

A host that is worried about an attack as obscure as this is IMHO
unlikely to have a policy "first try without NAT-T; but if there's 
a NAT, enable NAT-T".

Furthermore, moving the payload doesn't actually prevent anything.
If there's no NAT, the addresses are visible in the IP header.
If there is a NAT, and the host behind NAT falls back to NAT-T, 
the eavesdropper can get the addresses anyway with a quite trivial 
amount of computation (as is already pointed out in the IKEv2 spec,
hashing does not prevent NAT detection payloads from leaking the 
internal addresses).

Best regards,
Pasi