draft-ietf-ipsec-ikev2-tutorial-01.txt

Francis Dupont <Francis.Dupont@enst-bretagne.fr> Sun, 09 March 2003 20:30 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00808 for <ipsec-archive@lists.ietf.org>; Sun, 9 Mar 2003 15:30:33 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12494 Sun, 9 Mar 2003 11:29:51 -0500 (EST)
Message-Id: <200303091632.h29GWZof017065@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: ipsec@lists.tislabs.com
Subject: draft-ietf-ipsec-ikev2-tutorial-01.txt
Date: Sun, 09 Mar 2003 17:32:35 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

I have many comments about draft-ietf-ipsec-ikev2-tutorial-01.txt
section 9.0 NAT Traversal:

   NAT-Traversal [KSH01]
   designed a mechanism that was deployed in IKEv1, and IKEv2 copied the
   design.

=> this is unfortunately *not* true. [KSH01] is more complete (it
   supports transport mode) and secure (it has not the bidding down
   attack against the NAT-T detection).

   The NAT-Traversal design accommodated existing NATs as much
   as possible (without sacrificing security or significantly impacting
   performance).

=> I disagree about the first point (without sacrificing security)
because IKE/IPsec NAT-T is clearly less secure than IKE/IPsec without it.
But this is a problem which has no easy/simple solution so my concern
is only about the misleading statement.

   And it even allows a network using some addressing scheme different
   from IPv4 to connect to the Internet.

=> this wording won't make IPv6 people happy.

   The reason it
   is a hash rather than the actual address is because some people have
   argued that the actual address of a node behind a NAT might be
   secret.

=> this is the reason given by Tero Kivinen. My address management
provides the same thing (in a better way according the text which
follows the quote) by a "hashed" address family.

   In addition to sending the child-SA packets on 4500, IKE (once the
   NAT is detected) sends the remaining messages of the IKE handshake
   over port 4500 instead of 500 (and does not insist on receiving them
   from source port 4500).

=> this is not accurate because this (port 4500) applies to all further
packets after the current exchange (the "after" constraint comes from
the reply to reversed address and port rule).

=> there are missing points, for instance NAT-T should include an
implicit peer address update mechanism because the NAT is by definition
out of control and can change mappings for the peer behind it.
With such a mechanism the first packet sent by the peer behind the NAT
will update its mapped peer address on the other peer. This has other
advantages:
 - it makes the switch to port 4500 possible after the second (IKE_AUTH)
   exchange, so the NAT detection can be safely done in this second
   exchange.
 - it is the best defense against an attacker which plays the role of
   a NAT and diverts the IPsec traffic by mapping the peer address to
   a victim address.

Regards

Francis.Dupont@enst-bretagne.fr

PS: the formating of the draft is still disaster.