IETF MOBIKE WG mailing list ()

Eric Fung | 29 Aug 2006 21:23

Changing to port 4500

RFC 4555, Sec. 3.3 says that if both peers support MOBIKE and NAT-T, then they 
must change to port 4500 even if NAT was not detected between them.

But in the design document, RFC 4621, Sec 5.2.3 says that the port change 
should be done immediately after IKE_SA_INIT and before IKE_AUTH. However, 
support for MOBIKE is declared during the IKE_AUTH exchange.

I suppose it's not a big deal, since peers will be listening on port 4500 
anyway. But when should the initiator and responder change ports in the 
scenario where there is no NAT between them?

headers

Tero Kivinen | 30 Aug 2006 09:27

Changing to port 4500

Eric Fung writes:
> RFC 4555, Sec. 3.3 says that if both peers support MOBIKE and NAT-T,
> then they must change to port 4500 even if NAT was not detected
> between them.

Yes. 

> But in the design document, RFC 4621, Sec 5.2.3 says that the port change 
> should be done immediately after IKE_SA_INIT and before IKE_AUTH. However, 
> support for MOBIKE is declared during the IKE_AUTH exchange.

RFC4555 does the same. If you check the example in section 2.2 you see
that initiator changes to the port 4500 immediately after IKE_SA_INIT.
It knows at that point that the other end supports NAT-T (the other
end sent NAT_DETECTION_*_IP notifications) and it knows it supports
MOBIKE, so he does the change at that point, even when he is not sure
if the other end supports MOBIKE. 

> I suppose it's not a big deal, since peers will be listening on port 4500 
> anyway. But when should the initiator and responder change ports in the 
> scenario where there is no NAT between them?

RFC 4621 and RFC 4555 agree on that, i.e. IKE_AUTH is already done on
port 4500. 

RFC 4621 is more clear as it says we change to port 4500 immediately
upon detecting that the other end supports NAT-T (this implicitly also
says that we support NAT-T and MOBIKE).

The RFC 4555 has a bit underspecified text saying we change if both

(Continue reading)

headers

Eric Fung | 6 Sep 2006 17:47

Re: Changing to port 4500

Tero Kivinen wrote:

> The RFC 4555 has a bit underspecified text saying we change if both
> ends supports both, but actually we do not need to  know whether
> remote end supports MOBIKE, knowing that it supports NAT-T is
> enough. Anyways examples make it very clear that we change to port
> 4500 for the IKE_AUTH.

If there is no NAT between the peers and we change to port 4500, should ESP 
packets be UDP encapsulated or not?  I don't see any pertinent guidance in RFC 
4306 and at least one implementation I'm testing against differs in its 
interpretation.

Thanks.

headers

Tero Kivinen | 7 Sep 2006 09:32

Re: Changing to port 4500

Eric Fung writes:
> > The RFC 4555 has a bit underspecified text saying we change if both
> > ends supports both, but actually we do not need to  know whether
> > remote end supports MOBIKE, knowing that it supports NAT-T is
> > enough. Anyways examples make it very clear that we change to port
> > 4500 for the IKE_AUTH.
> 
> If there is no NAT between the peers and we change to port 4500,
> should ESP packets be UDP encapsulated or not? I don't see any
> pertinent guidance in RFC 4306 and at least one implementation I'm
> testing against differs in its interpretation.

RFC4555 specifies that UDP Encapsulation (i.e NAT Traversal) can be
enabled and disabled at will, i.e. in normal case it should be enabled
if NAT is detected on the selected addresses. The 4555 does not forbid
enabling it even if no NAT is deteceted, as it might also be needed to
go through firewalls etc, but it does not give guidance whether it
should be enabled or not.

Anyways the sender can use UDP encapsulation or not, and the recipient
needs to be able to receive packets with UDP encapsulation and without
UDP encapsulation always (at least for the mobike if NAT-T is
supported).

The RFC 4306 says that you MUST enable UDP encapsulation if NAT is
detected, but it does not say anything whether you can enable it if no
NAT is detected. It is silent about this issue, but nothing there says
that it should process UDP encapsulated IPsec packets any differently
than non UDP encapsulated IPsec packets, so I would guess the correct
answer is that also RFC 4306 compliant implementations should accept

(Continue reading)