[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rewrite of IKEv2 Section 2.11 Address and Port Agility



 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 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.
   
=> 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).

   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.

=> 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

Francis.Dupont@enst-bretagne.fr