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
both UDP encapsulated and normal IPsec packets for same SA.

I guess most of the implementations do not do this now, and it really
does not matter for the pre-mobike implementations as there is no
reason to enable UDP encapsulation in the middle of the IKE SA, but
for mobike it is important, i.e. there the UDP encapsulation is
separate option that can be enabled and disabled at any time (decided
by the sender of the packet).

Note, that with mobike the UDP encapsulation might also be enabled or
disabled in the middle of the SA without any notification to the other
end.

Here is an example of that:

The initiator has two interfaces, each with one IP (I1 = 192.168.2.22,
I2 = 10.0.1.11). The responder has one IP (R1 = 192.168.1.1). The
initiator is using I1,R1 address pair for its traffic and there is no
NAT between that, i.e. the UDP encapsulation is disabled.

Then the IP address I1 is disabled (i.e. interface removed, link layer
goes down, dhcp lease expires etc), and the initiator knows that I1 ->
R1 does not work anymore, even without probing it. It decides to move
all traffic to the I2,R1 address pair. It suspects that there might be
NAT as the I2 is private use address (10.0.1.11), so while it moves
all IPsec traffic to the new address pair at the same time when it
starts address update. It does this because it knows that it cannot
send those packets to I1,R1 pair as it does not exists anymore, so
there is possibility that those will reach the other end with I2,R1
pair, and turning on UDP encapsulation at that time because it
suspects there is NAT does not cost that much, but will enchance the
probability that packets actually reach the responder.

The address update goes forward and the responder updates the
addresses accordingly, and detects from the NAT_DETECTION payloads
that there is no NAT, so he keeps UDP encapsulation disabled, but
still accepts the packets sent by the initiator with UDP
encapsulation. When the initiator gets responders reply to the address
update packet it will also detect that there was no NAT even when
initiator assumed so, and it will disabled UDP encapsulation at that
point (last step of the section 3.5 in the RFC 4555).

So in the end initiator enabled UDP encapsulation for a few packets
while doing the address updated, but disabled it immediately when it
detected there was no NAT between. 
-- 
[email protected]