[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ikev2-05.txt comments
In your previous mail you wrote:
> 2.23 NAT Traversal
...
> Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When
> working through a NAT, it is generally better to pass IKE packets
> over port 4500 because some older NATs modify IKE traffic on port 500
> in an attempt to transparently establish IPsec connections. Such NATs
> may interfere with the straightforward NAT traversal envisioned by
> this document, so an IPsec endpoint that discovers a NAT between it
> and its correspondent SHOULD send all subsequent traffic to and from
^^^^^^
MUST
The NAT-T protocol does not work with current NAT boxes if you try to
run it over port 500. We must change the port from the 500 to 4500
immediately when we detect NAT.
=> I am not convinced by this "immediately" and this has an impact on
legacy authentication or other stuff which add messages to the IKE_AUTH
"exchange".
Also the NAT-DETECTION-SOURCE-IP and
NAT-DETECTION-DESTINATION-IP must be in the first two packets, so we
can detect NAT before we start negotiating the child SA
=> same concern.
(especially if
we want to add the ORIGINAL-ADDRESS notification or similar to support
transport mode ESP).
=> I don't buy this. IMHO the only constraint is NAT must be detected
before the IPsec SAs are used. But used != negociated.
With implicit peer address update, the NAT detection can be done in IKE_AUTH
and the switch to UDP 4500 performed only after IKE_AUTH. There are many
advantages to keep same addresses and ports in all messages of the initial
phase.
> IKE MUST listen on port 4500 as well as port 500. IKE MUST respond
> to the IP address and port from which packets arrived.
>
> The IKE responder MUST include in its IKE_SA_INIT response Notify
> payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION-
> DESTINATION-IP. The IKE initiator MUST check these payloads if
> present and if they do not match the addresses in the outer packet
> MUST tunnel all future IKE, ESP, and AH packets associated with
> this IKE-SA over UDP port 4500.
I assume that this means that we do not negotiate the UDP-tunnel or
UDP-transport mode as in IKEv1? This is fine with me, but I think we
need some more text here to say so.
=> I agree (on both points).
Also we need some references to how to actually encapsulate the ESP
packets etc. We also need to specify better how to detect which side
is behind NAT (the UDP encapsulation protocol needs that information
to enabled keepalives only from the host behind NAT, and the IKE needs
that to enable implicit port updating if and only if the other end is
behind NAT (it MUST NOT be enabled if the other end is not behind
NAT)).
=> good comment.
I.e something like this:
----------------------------------------------------------------------
The IKE responder MUST include in its IKE_SA_INIT response
Notify payloads of type NAT-DETECTION-SOURCE-IP and
NAT-DETECTION- DESTINATION-IP. The IKE initiator MUST check
these payloads if present and if they do not match the
addresses in the outer packet MUST switch to port 4500 for the
IKE traffic and all IPsec SAs traffic (ESP packets) MUST use
the UDP encapsulation over port 4500 as defined in the
[Hutt02].
The changing to port 4500 MUST happen immediately after
IKE_SA_INIT exchange, i.e IKE_AUTH payloads are sent with port
4500 (the reply to IKE_SA_INIT must come back to port 500, as
specified by generic rule that reply back to address where you
=> this generic rule is not enough clear in the current document.
got the packet, and also because the mapping for the port 4500
is not yet open in the NAT box, i.e the first packet must come
from the inside).
=> so you should agree that the asymmetry of the current draft is bad,
i.e., the responder cannot be behind the NAT box. My proposal has
not this problem...
The purpose of NAT-DETECTION-SOURCE-IP and
NAT-DETECTION-DESTINATION-IP notifications is twofold, It not
only detects the presence of NAT between two IKE peers, it
also detects where the NAT is. The location of the NAT device
is important in that the keepalives need to initiate from the
peer "behind" the NAT, and also so that implicit address
updating is only enabled if and only if the other end is
behind NAT.
...
=> It seems we share some concerns about the current text about
NAT traversal (:-).
2.24 NAT Traversal Implicit Address Updating
=> it would be fine to use the "peer address" term.
There are cases where NAT box decides to remove mappings that are
...
=> this is another example of missing text in the current draft.
Keepalives cannot be used for this purposes as they are not
=> there are many types of keepalives. You should be more accurate,
for instance "UDP keepalives cannot ...".
authenticated, but any IKE authenticated IKE packet or UDP
=> IKE messages are authenticated if they run over the IKE SA
encapsulated ESP packet can be used to detect that the IP address
=> s/ESP/IPsec/
or the port has changed.
=> in fact it is enough to get a valid (known SPI, authenticated) IPsec
or IKE packet.
> NAT-DETECTION-SOURCE-IP 24582
>
> This notification is used to by its recipient to determine
> whether the source is behind a NAT box. The data associated
> with this notification is a SHA-1 digest of the SPIs, IP
> address and port on which this packet was sent. There MAY
> be multiple notify payloads of this type in a message if the
> sender does not know which of several network attachments
> will be used to send the packet. The recipient of this
> notification MAY compare the supplied value to a hash of the
> source IP address and port and if they don't match it MAY
^^^
> invoke NAT specific handling (like using UDP encapsulation
> of ESP packets and subsequent IKE packets). Alternately, it
> MAY reject the connection attempt if NAT traversal is not
> supported.
>From the "The recipient of this notification ..." change to this:
----------------------------------------------------------------------
The recipient of this notification MAY compare the
supplied value to a hash of the source IP address and
port and if they don't match it SHOULD enable NAT
traversal (see section 2.23). Alternately, it MAY reject
the connection attempt if NAT traversal is not
supported.
=> s/supported/& or enabled/ and I am in favor of MUSTs.
Note we have a conflict about the term "enable", I propose
for your usage the term activate ?
If this check fails it means that the other end is
behind NAT and this end SHOULD enable the NAT Traversal
implicit address updating (see section 2.24).
=> s/SHOULD/MUST/ ?
and replace with this:
----------------------------------------------------------------------
The recipient of this notification MAY compare the
supplied value to a hash of the destination IP address
and port and if they don't match it SHOULD invoke NAT
traversal (see section 2.23). Alternately, it MAY reject
the connection attempt if NAT traversal is not
supported.
=> same comment.
If this check fails it means that this end is behind NAT
and this end should start sending keepalives as defined
in the [Hutt02].
=> s/should/SHOULD/ ?
> 5 Security Considerations
The NAT traversal needs some more entries here (copied from
draft-ietf-ipsec-nat-t-ike-05):
=> I agree!
----------------------------------------------------------------------
As the internal address space is only 32 bits, and it is usually very
sparse, it might be possible for the attacker to find out the internal
address used behind the NAT box by trying all possible IP-addresses
and trying to find the matching hash. The port numbers are normally
fixed to 500, and the SPIs can be extracted from the packet. This
limits the hash calculations down to 2^32. If educated guess of use of
private address space is done, then the number of hash calculations
needed to find out the internal IP address goes down to the 2^24 + 2 *
(2^16).
Updating the IKE SA / ESP UDP encapsulation IP addresses and ports for
each valid authenticated packet can cause DoS in case we have attacker
who can listen all traffic in the network, and can change the order of
the packet and inject new packets before the packet he has already
seen. I.e attacker can take the authenticated packet from the host
behind NAT, change the packet UDP source or destination ports or IP
addresses and sent it out to the other end before the real packet
reaches there. The host not behind the NAT will update its IP address
and port mapping and sends further traffic to wrong host or port. This
situation is fixed immediately when the attacker stops modifying the
packets as the first real packet will fix the situation back to
normal. Implementations SHOULD AUDIT the event every time the mapping
is changed, as in normal case it should not happen that often.
=> fine. It seems you share my argument that the implicit peer address
update mechanism is the best defense against a rogue NAT.
Thanks
Francis.Dupont@enst-bretagne.fr