Subject: Re: [IPsec] ikev2bis clarification on port floating

From: Scott C Moonen <[email-masked]>
Date: Mon, 11 Jan 2010 14:40:35 -0500

Further question -- is it ok for the IKE negotiation *not* to float and 
then for the ESP traffic to later arrive UDP-encapped on port 4500?  It 
seems like it would be wise not to send UDP-encapped ESP unless you've 
already verified that the 4500-4500 port pairing works during an IKE 
exchange.  But the text in section 2.31 doesn't seem to exclude that 
possibility.

Personally, I think we should:

1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. 
Possible starting point: "receive and process IPsec packets with or 
without UDP encapsulation at any time."
2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the 
peer supports NAT traversal (i.e., an existing SA is being authenticated, 
which itself exchanged NAT_DETECTION_* payloads even if it may not have 
detected a NAT).
3) Disallow this elective use of UDP-encap unless you have already floated 
the IKE SA.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Scott C Moonen/Raleigh/IBM
To:
[email-masked]
Date:
01/11/2010 01:10 PM
Subject:
ikev2bis clarification on port floating

ikev2bis says:

   An initiator can float to port 4500, regardless whether or not there
   is NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

Dan has suggested that we clarify the part about UDP encapsulation. 
However, I have an additional question about the port floating aspect.  Do 
we intend to say that an initiator may float to 4500, period, or is it 
only allowed to do so if NAT_DETECTION_* payloads are exchanged?  Can the 
initiator have any confidence that the responder is even listening on port 
4500 unless the responder sends a NAT-detection payload?  Also, we have 
not defined floating, so it is not clear what is really intended here.  By 
"float" do we mean that the initiator may send the IKE_SA_INIT request 
to/from port 4500?  Or are you only allowed to float on the IKE_AUTH 
request?

Presumably there is at least some justification for floating the 
IKE_SA_INIT request if you have an existing SA that you are 
reauthenticating.  But in the absence of a NAT_DETECTION_* payload or an 
existing SA, I'm not sure that floating should be allowed, since the MUST 
for listening on port 4500 appears only within the conditional context of 
NAT traversal support.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Jan 2010 10:32:45 +0200

Scott C Moonen writes:
> then for the ESP traffic to later arrive UDP-encapped on port 4500?

Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the
implementation knows other end supports NAT-T).

> It seems like it would be wise not to send UDP-encapped ESP unless
> you've already verified that the 4500-4500 port pairing works during
> an IKE exchange. But the text in section 2.31 doesn't seem to
> exclude that possibility.

That was the intention, i.e. even when there was no NAT (regardless
whether you use port 500 or 4500), but other end did support NAT-T
(i.e. NAT_DETECTION_* payloads were exchanged), then you can use
either normal ESP packets, or UDP encapsulated ESP packets on port
4500.

This is something that is already required for MOBIKE, as with MOBIKE
the host might suddenly notice that you moved to new IP-address which
do have NAT, thus you might need to enable NAT-T. On the other hand
with MOBIKE you always change to use port 4500 in the beginning to
simplify things.

The current text does not say when you would be sending such packets,
it just says that you MUST be able to receive them. 

> without UDP encapsulation at any time."

That change seems to be good.

> which itself exchanged NAT_DETECTION_* payloads even if it may not have 

Why do you want to disallow that?

You might not have prior knowledge, but you might have good hints that
other end needs to support NAT-T or otherwise communications does not
work so better start at port 4500 directly.

Also some minimal implementations supporting NAT-T could always start
at port 4500 as they do not support normal IPsec at all, only UDP
encapsulated IPsec and they always act as they were behind NAT.

> 3) Disallow this elective use of UDP-encap unless you have already floated 

Again why do that? I think it is easier to just make it so that you
can always use normal IPsec or UDP encapsulated IPsec if you support
NAT-T regardless whether you have changed ports etc...

I.e if you get packet to your IKE NAT port (4500) you check the SPI
and if it is there you strip UDP header and pass it to IPsec engine.
If there is 4 bytes of zeros in the beginning then you pass it to the
UDP stack.

No need to check whether there was NAT-T enabled for this specific
host etc.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 12 Jan 2010 09:21:35 -0500

Tero,

> > 2) Disallow floating on IKE_SA_INIT unless . . .
> Why do you want to disallow that? . . .
> 
> > 3) Disallow this elective use of UDP-encap unless . . .
> Again why do that?

I guess I'm thinking more about what is advisable (without out-of-band 
knowledge or inference) than what is permissible, so that may be out of 
scope.  And I should have said "recommend against" rather than "disallow".

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
[email-masked]
Date:
01/12/2010 03:36 AM
Subject:
Re: [IPsec] ikev2bis clarification on port floating

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Jan 2010 16:38:41 +0200

Hi Scott

When writing remote access VPN clients (running on phones, PCs, tablets, probably not z/OS) it's usually safe to assume that the peer (a gateway) supports NAT-T. This is because on the real Internet, a RAS that does not support NAT-T simply doesn't work. NATs are everywhere.

So it's possible to write a simplified client, that only does NAT-T (no ESP and no UDP port 500) and it doesn't even need to bother with the NAT_DETECTION payloads.

Allowing UDP 4500 even for the IKE_SA_INIT exchange allows such clients, and I don't see a reason to forbid them. Yes, they are not interoperable with perfectly legitimate IKEv2 implementations that do not support NAT-T, but that doesn't matter, because those minimal implementations are not fit to be RAS.

On Jan 12, 2010, at 4:21 PM, Scott C Moonen wrote:

Tero,

> > 3) Disallow this elective use of UDP-encap unless . . .

I guess I'm thinking more about what is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope.  And I should have said "recommend against" rather than "disallow".

Scott Moonen ([email-masked]<mailto:[email-masked]>)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:   Tero Kivinen <[email-masked]<mailto:[email-masked]>>
To:     Scott C Moonen/Raleigh/IBM@IBMUS
Cc:     [email-masked]<mailto:[email-masked]>
Date:   01/12/2010 03:36 AM
Subject:        Re: [IPsec] ikev2bis clarification on port floating

________________________________

No need to check whether there was NAT-T enabled for this specific
host etc.
--
[email-masked]<mailto:[email-masked]>

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 12 Jan 2010 10:21:22 -0500

Yoav, thanks.  I withdraw my suggestions #2 and #3 altogether, and 
(barring objections) we can just stick with the suggested rewording of 
"both UDP encapsulated and non-UDP encapsulated packets" to "IPsec packets 
with or without UDP encapsulation".

From:
Yoav Nir <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
Tero Kivinen <[email-masked]>, "[email-masked]" <[email-masked]>
Date:
01/12/2010 09:39 AM
Subject:
Re: [IPsec] ikev2bis clarification on port floating

Hi Scott

When writing remote access VPN clients (running on phones, PCs, tablets, 
probably not z/OS) it's usually safe to assume that the peer (a gateway) 
supports NAT-T. This is because on the real Internet, a RAS that does not 
support NAT-T simply doesn't work. NATs are everywhere.

So it's possible to write a simplified client, that only does NAT-T (no 
ESP and no UDP port 500) and it doesn't even need to bother with the 
NAT_DETECTION payloads.

Allowing UDP 4500 even for the IKE_SA_INIT exchange allows such clients, 
and I don't see a reason to forbid them. Yes, they are not interoperable 
with perfectly legitimate IKEv2 implementations that do not support NAT-T, 
but that doesn't matter, because those minimal implementations are not fit 
to be RAS.

Tero, 

From: 

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Jan 2010 11:28:28 +0200

> scope.  And I should have said "recommend against" rather than "disallow".

Ok, that makes much more sense. On the other hand the current text
tries to make the recipient part so that we do not need to change
that, even if someone later proposes modifications that use
out-of-band or similar knowledge and defines how those are used.

So it is ok to add text saying that you should not use those features
as a initiator, but you still must to be able to receive them as a
responder.
-- 
[email-masked]