Subject: rewrite of IKEv2 Section 2.11 Address and Port Agility

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Apr 2003 16:17:37 +0200

The current text is:

2.11 Address and Port Agility

   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over. The IP
   addresses and ports in the outer header are, however, not themselves
   cryptographically protected, and IKE is designed to work even through
   Network Address Translation (NAT) boxes. An implementation MUST
   accept incoming connection requests even if not received from UDP
   port 500 or 4500, and MUST respond to the address and port from which
   the request was received.  IKE functions identically over IPv4 or
   IPv6.

There are a lot of details to change:
 - the proxy case
 - clearer rule for responses
 - peer address protection when NAT traversal is not active (i.e.,
   when UDP port 500 is used)
 - peer address set management
The whole stuff is in draft-dupont-ikev2-addrmgmt-02.txt but needs to
be integrated into the current draft.
Here is my proposal:

2.11 Address and Port Agility

   An implementation MUST accept incoming connection requests even if
   not received from UDP port 500 or 4500, and MUST respond to the
   address and port from which the request was received. IKE functions
   identically over IPv4 or IPv6 and is designed to work either
   through Network Address Translation (NAT) boxes or with a
   cryptographically protection of the IP addresses and ports in the
   outer header. IKE runs over UDP ports 500 and 4500, and implicitly
   sets up ESP and AH associations for the same IP addresses it runs
   over, i.e., for the peer addresses.

   The response rule has no exception: the response to a request MUST
   be sent from the destination address and port of the request to the
   source address and port of the request using the same transport
   protocol. In case of a retransmitted request, the last received
   message only SHALL be taken into account.

   The NAT detection is performed in the IKE_SA_INIT exchange. All
   messages following this first exchange are either over UDP port
   4500 if NAT traversal support is active, or over UDP port 500 with
   a REQUIRED cryptographically protection of peer addresses and ports
   by PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications.
   If multiple peer address notifications for the same peer are
   included in a message, the first one MUST be the used peer address.
   In order to associate some possible peer source addresses to
   possible peer destination addresses, the source and destination
   peer addresses notifications MAY be mixed (i.e., not in the common
   order source(s) first, destination(s) after). For instance S1, S2,
   D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction
   with D1, S3 with D2 or D3. According to its policy, a peer MAY
   verify the peer address sets at any time, commonly in the IKE_AUTH
   exchange or when they change, for instance using the SubjAltName
   ASN.1 sequence field of X.509v3 certificates.

   When ESP or AH associations in transport mode are setup with
   different addresses in the traffic selectors, i.e., when IKE is
   acting as a client negotiator on behalf of another party, the
   addresses used in the transport mode SAs are the addresses of the
   traffic selectors. A proper authorization in the local policy of
   peers is REQUIRED and this case SHOULD be supported. Note that the
   IPsec SAs built in this proxy case can not be handled by any
   address management mechanism like NAT traversal support.

Thanks

[email-masked]

PS: my next message will be about the peer address update which can
be included now or postponed as the rekeying already provides a way
to get the same result (but not at the same price).

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 15:59:27 -0400

Francis,

There seems to be some fundamental differences in the approach that you
take to handling NAT traversal and the approach which is currently in
ikev2.  The approach in ikev2 is substantially similar to what is
in the IKEv1 NAT traversal documents, which were authored by Tero
Kivinen, Brian Swander, Ari Huttunen, and Victor Volpe, and for which
there is implementation experience and a non-trivial amount of testing
with currently deployed NAT boxes.

Your proposals for changing how NAT traversal would work in ikev2 does
not seem to have drawn much resonance with the rest of the working
group.  In particular, your desire to require that the administrators
explicitly declare whether or not NAT traversal should be turned on
seems to be at odds with many other wg participants.  While it is true
that someone on the network path can pretend to be a NAT and redirect
the connection, someone who controls a machine on the network path
between two end points can achieve this easily anyway.  Furthermore,
in the road-warrior scenario, most end-users will not necessarily know
whether or not they are behind a NAT --- and I think most would agree
that it is desireable that users not be forced to know details of how
their ISP is provisioning their network service.

							- Ted

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Apr 2003 00:35:07 +0200

In your previous mail you wrote:

   There seems to be some fundamental differences in the approach that you
   take to handling NAT traversal and the approach which is currently 
   ikev2.

=> I am afraid that it is mainly a problem of wording, for instance
when I've just reread my messages (I've tried to understand why
you believe there are deep differences) it's seemed I failed to
explain clearly enough than active NAT traversal and peer address
protection are mutually exclusive. I'm afraid you didn't read my
messages in the right order too (the first one is the peer address
protection format, the second is the 2.11 rewrite and the last one
is the peer address update payload).

   The approach in ikev2 is substantially similar to what is
   
=> in fact not only I agree but I'd like that Tero's comments will
be ASAP included in the draft because the current text is both not
enough clear and incomplete (the implicit peer address update is
not specified when it is very useful).

   group.

=> unfortunately there is a security flaw in the common NAT traversal
support in signaling protocols like IKE, and it drew resonance in the
mobile-ip WG (cf draft-ietf-mobileip-nat-traversal-XX.txt). IMHO
as there is some relationship problems between the ipsec and the
mobile-ip WGs, this issue should be taken into account.

   In particular, your desire to require that the administrators
   explicitly declare whether or not NAT traversal should be turned on

=> is it the NAT traversal support enabled/disabled?

   seems to be at odds with many other wg participants.  While it is true
   that someone on the network path can pretend to be a NAT and redirect
   the connection, someone who controls a machine on the network path
   between two end points can achieve this easily anyway.

=> but it can't continue to redirect the traffic if it leaves the path.
The issue with signaling protocols is the attacker who only hacks some
packets will redirect a possibly large amount of traffic for a long
time. It is too late to fix IKEv1 but I can't believe you'd like to
publish IKEv2 with this kind of flaw...

   Furthermore, in the road-warrior scenario, most end-users will not
   necessarily know whether or not they are behind a NAT

=> they wish that they are not behind a NAT (:-)!

   and I think most would agree that it is desireable that users not
   be forced to know details of how their ISP is provisioning their
   network service.
   
=> I don't parse your last sentence: in these 3 messages I never suggest
to forbid NAT traversal, I only considered there is a knob in the policy
(not a global one, the decision is done in the IKE_AUTH exchange, i.e.,
after NAT detection and for the responder with the ID and the authentication
stuff) which says if the NAT traversal support is enabled or disabled.
I even added in the rationale/introduction part that the policy should
allow to activate the NAT traversal support when no NAT was detected.
But as I wrote, I am waiting for the next text about NAT traversal in
order to see if there still are little details to discuss.
 BTW in the case of a road-warrior over IPv4, the policy should allow
NAT traversal support on the client and on the server (in the VPN software
I use the policy is in fact controlled by the server). But between
two SGs and when the administrator knows there is no NAT, he should get
the possibility to forbid NAT traversal support. The same when IPv6
is used. And as far as I know, all reasonable softwares either lack
NAT traversal support or provide this kind of knob in their config
(i.e., I can't see what is the problem).

Thanks