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.
- draft-ietf-ipsec-ikev2-tutorial-01.txt Francis Dupont