Scott C Moonen writes:
> ikev2bis says:
This whole section is about NAT-T and it has text saying:
Support for NAT traversal is optional. In this section only,
requirements listed as MUST apply only to implementations
supporting NAT traversal.
meaning everything said here only applies if and only if
implementations support NAT traversal.
> An initiator can float to port 4500, regardless whether or not there
> is NAT, even at the beginning of IKE.
This text is saying same thing than what is said below i.e. as
responder MUST listen on port 4500 as well as port 500 and it MUST
respond to the IP address and port from which packets arrived (first
bullet point), then if initiator knows responder supports NAT-T it can
change to the port 4500 regardless whether there is NAT or not even
for IKE_SA_INIT packets.
The initiator still needs to know (or suspect) that the other end
supports NAT-T before doing that. One way of knowing that is that
there was previously IKE SA with the responder already and that was
dropped for some reason and inititor is recreating it (this is the
original reason for allowing this).
Another reason might be that initiator sees that its own IP-address is
from private address range (for example 10.0.0.22) and responders
IP-address is from global address range, and it is expected there is
NAT between, or otherwise the communiation will not work, thus other
end needs to support NAT-T or otherwise the communication will not
work.
Anyways this text needs to be modified to remove term "float", as we
decided earlier that (during RFC 3947/3948 time) that we DO NOT use
term float, but instead use term "change to port 4500" or "use port
4500" or similar. I.e. this text needs to be changed to say:
An initiator can use 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.
As we are talking about UDP encapsulation there, it is talking about
UDP encapsulated IPsec packets (ESP) not about IKE packets. I.e. this
says you needs to understand UDP encapsulated ESP packets even when
there is no NAT if port 4500 is used. And on the other hand you can
also use normal ESP packets even when you are using port 4500 (i.e. if
there is no NAT).
> UDP encapsulation MUST NOT be done on port 500.
This is saying that with port 500 you cannot use UDP encapsulated
IPsec (ESP) packets.
> 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.
This is saying that regardless whether you changed to port 4500 but if
both ends indicated that they support NAT-T by exhchanging
NAT_DETECTION_*_IP payloads), you still need to be able to process
both UDP encapsulated ESP (at port 4500) and normal IPsec ESP packets.
> 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.
This says both ends can decide themselves whether they use UDP
encapsulation or not, but they MUST use it if NAT was detected.
> 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?
Initiator can try to use port 4500. If responder supports NAT-T it
will respond to that and everything works. If responder does not
support NAT-T (or it is not allowed) then responder will not answer to
packets to port 4500.
Because of this the initiator might not want to use it unless it knows
that other end supports NAT-T.
> Can the initiator have any confidence that the responder is even
> listening on port 4500 unless the responder sends a NAT-detection
> payload?
If it knows from somewhere that other end supports NAT-T (from policy,
from previous communications, or because it knows it is behind NAT
(i.e. there is no point of trying to communicate if other end does not
support NAT)) it can use port 4500.
Responder MUST be listening on port 4500 if it suports NAT-T,
regardless whether NAT_DETECTION_* payloads have been exchanged. I.e.
you need to start listing on port 500 and 4500 at the same time when
you start the IKE daemon if you support NAT-T. You cannot postpone
opening port 4500 only after NAT_DETECTION_* payload exchanges.
> 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?
Using term "float" is wrong in the text. It should say "can use port
4500" instead of using term float.
And yes, you are allowed to send IKE_SA_INIT to/from port 4500.
> Presumably there is at least some justification for floating the
> IKE_SA_INIT request if you have an existing SA that you are
> reauthenticating.
That is one example. Another is that your IKE SA was dropped for some
reason, and you are recreating it (for example the GW was rebooted).
> 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.
It is conditional on the context of the implementation SUPPORTING
NAT-T, not whether it is in use. I.e. your code will have support for
NAT-T even when NAT_DETECTION_* payload are not exchanged so you need
to listen port 4500.
On the other hand if you disable NAT-T on your policy, then your
implementation does not support NAT-T at all in its current policy,
and then you do not listen port 4500 (or respond).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
