Subject: Re: [IPsec] Issue #175: Better wording for NAT mobility issues

From: Raj Singh <[email-masked]>
Date: Fri, 5 Feb 2010 08:18:22 +0530

Hi Paul,

One clear change is that updating the address, port info is changed from
authenticated packet
to integrity protected packet.
Does this change is to allow recovery from NAT mapping removal during
establishment of IKEv2 SA
e.g. with EAP authentication, during retransmission of IKE_AUTH exchange ?
If Yes, can we have a explicit say for it?

Regards,
Raj

On Fri, Feb 5, 2010 at 7:15 AM, Paul Hoffman <[email-masked]> wrote:

> The last bullet in 2.23 is confusing. A proposed rewrite is:
>
> Old:
>
> 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 do not
> support other methods of recovery such as MOBIKE [MOBIKE], and that
> are not behind a NAT, SHOULD send all packets (including
> retransmission packets) to the IP address and port from the last
> valid authenticated packet from the other end (that is, they should
> dynamically update the address).  A host behind a NAT SHOULD NOT do
> this because it opens a possible denial of service attack.  Any
> authenticated IKE packet or any authenticated UDP- encapsulated ESP
> packet can be used to detect that the IP address or the port has
> changed.  When IKEv2 is used with MOBIKE, dynamically updating the
> addresses described above interferes with MOBIKE's way of recovering
> from the same situation.  See Section 3.8 of [MOBIKE] for more
> information.
>
> New:
>
> 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). This will be apparent to a host if it receives
> a packet whose integrity protection validates, but has a different
> port, address, or both from the one that was associated with the SA
> in the validated packet. When such a validated packet is found, a
> host that does not support other methods of recovery such as MOBIKE
> [MOBIKE], and that is not behind a NAT, SHOULD send all packets
> (including retransmission packets) to the IP address and port in the
> validated packet, and SHOULD store this as the new address and port
> combination for the SA (that is, they SHOULD dynamically update the
> address). A host behind a NAT SHOULD NOT do this type of dynamic
> address update if a validated packet has different port and/or
> address values because it opens a possible denial of service attack
> (such as allowing an attacker to break the connection with a single
> packet). When IKEv2 is used with MOBIKE, dynamically updating the
> addresses described above interferes with MOBIKE's way of recovering
> from the same situation.  See Section 3.8 of [MOBIKE] for more
> information.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Feb 2010 17:54:13 +0200

> to integrity protected packet.

In this case that does not really matter.

> Does this change is to allow recovery from NAT mapping removal
> during establishment of IKEv2 SA e.g. with EAP authentication,
> during retransmission of IKE_AUTH exchange ? If Yes, can we have a
> explicit say for it?

This is not necessarely needed, as the IKE_AUTH replies are IKE
packets, which are always sent back with their addresses reversed,
thus those replies will go back anyways, and there cannot be any other
packets (IKE or ESP) before the IKE_AUTH finishes, and that last
IKE_AUTH packet is already also authenticated (in addition to the
integrity protected), thus the last IKE_AUTH packet will already cause
the mappings to be updated.

So either wording is fine. What is not fine is to do the changes if
the packet is replayed.
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Tue, 9 Feb 2010 11:01:34 +0530

2010/2/8 Tero Kivinen <[email-masked]>

> So either wording is fine. What is not fine is to do the changes if

Suppose responder got IKE_AUTH request (NIP1, NP1), and now mapping got
removed at NAT box.
If responder will send packet to packet to last integrity protected packet
i.e. IKE_AUTH request.
It will send IKE_AUTH packet to (NIP1, NP1), but now NAT mappings are
removed, so it will not reach to the initiator.
If we are using EAP authentication then first IKE_AUTH will not contain AUTH
payload, so its NOT authenticated packet.
Its only integrity protected. Thats was the thought behind the question.

--

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Feb 2010 13:34:56 +0200

> If responder will send packet to packet to last integrity protected packet

No. Section 3.1 clearly says that ALL ike response messages are always
replied back to the address and port where the request came from, i.e.
"that the IP addresses and UDP ports from the headers are reversed and
used for return packets."

And as responder always gets the IKE_AUTH requests from initiator, and
it always sends IKE_AUTH responses back, there is no need for anything
else than the normal IKE message processing.

> removed, so it will not reach to the initiator.

That is fine, but as the IKE_AUTH response does not reach the
inititor, initiator will resend its request, and NAT will create new
mapping for it, and its headers could then say (NIP1, NP2), and when
responder sees that, it will retransmit its IKE_AUTH response to that
address. 

> payload, so its NOT authenticated packet.

Yes.

> Its only integrity protected. Thats was the thought behind the question.

Yes.

But as there is already clear rule how to process those
request/response pairs in the section 3.1 (which is not NAT-T
specific, but generic IKEv2 processing rules), there is no special
case here for NAT-T.

When the final IKE_AUTH exchange comes (the one containing the AUTH
payload), then the responder have the last authenticated IKE packet,
and it will take the addresses and ports from there to be used in
future exchanges (IKE exchanges, or UDP-encapsulted ESP packets). 
-- 
[email-masked]