RE: Some IKE/NAT questions

["Fridie, Brian" <BFridie@Datavision.com>]

=> we had already this discussion (port 500 or a new port).
BTW NAT traversal has a major security problem and it is very
fine to be able to associate the port 4500 to IPsec (i.e.,
not only IKE) with active NAT traversal.
 
What is the major security problem?
 
Thx
 
-----Original Message----- 
From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] 
Sent: Tue 2/25/2003 4:13 AM 
To: radia.perlman@sun.com 
Cc: ipsec@lists.tislabs.com 
Subject: Re: Some IKE/NAT questions 



	 In your previous mail you wrote:
	
	   I'm reading my sneak preview soon-to-be-available version
	   of IKEv2, and also trying to write a tutorial. Anyway,
	   that's caused me to think deeply about NATs and IKE. Here
	   are some questions.
	  
	=> you should read my "address management for IKEv2" proposal
	(draft-dupont-ikev2-addrmgmt-00.txt). I am working on a second
	version, I'll send it to you in private.
	
	   1) Why are there NAT-DETECTION-SOURCE-IP and
	   NAT-DETECTION-DESTINATION-IPs in message 1,
	
	=> they can't be in message 1 because the used hash is not
	yet negociated...
	
	   since Bob isn't going to do anything with them?
	   It's only those notify payloads in message 2 that
	   affect the protocol, if I'm reading the spec
	   correctly.
	  
	=> the specs seems to have many little issues, this is why
	I wrote my proposal.
	
	   2) Would it be useful to do a "You Tarzan" optional
	   payload in message 1? That would allow Alice to initiate
	   communication with a node behind a NAT box that doesn't
	   have a global IP address, but does have a name. The
	   NAT gateway could look for this field in IKE messages
	   and translate the destination IP address to be Bob's
	   (Tarzan's) inner IP address.
	  
	=> the only reasonable help you can get from NATs is
	their auto-destruction (:-). IMHO I don't believe this
	(NAT name to address translation) will work or is desirable.
	
	   3) There's some conniptions going on because helpful
	   NAT boxes are doing strange things with packets on UDP
	   port 500, because of how IKEv1 was specified. (If I'm
	   understanding things, life
	   would have been simpler if IKEv1 simply said to
	   reply to the UDP port from which the packet was
	   received, but instead it said reply to 500).
	
	=> yes, this is the issue. In IKEv2 there is an absolute rule
	about this: replies use reversed addresses and ports.a
	
	   But IKEv1 didn't so NATs look for port 500 and do weird things.
	
	=> more weird things (:-).
	
	   As a result, IKEv2 seems to be trying to detect whether
	   there's a NAT, and if so, to use port 3500 so that IKEv2
	
	=> 4500
	
	   can do the right thing, i.e., if a NAT has translated
	   the UDP port, simply reply to whatever port you get the
	   packet on.
	  
	=> yes, the NAT traversal itself is well defined in IKEv2.
	The issue is there are some little details (as you've found
	according to your next messages) which need to be improved/fixed.
	
	   Anyway, why not always use port 3500, and stop using
	   500 for IKEv2 (other than perhaps trying port 500 in
	   case you're talking to an IKEv1-only node).
	  
	=> we had already this discussion (port 500 or a new port).
	BTW NAT traversal has a major security problem and it is very
	fine to be able to associate the port 4500 to IPsec (i.e.,
	not only IKE) with active NAT traversal.
	
	Thanks
	
	Francis.Dupont@enst-bretagne.fr
	
	





*** CONFIDENTIALITY NOTICE ***
This email and any files transmitted with it are confidential and intended for the listed recipient(s).  If you have received this email in error please notify the sender by return mail.  Opinions, conclusions and other information in this message that do not relate to official company business shall be understood as neither given nor endorsed by Datavision, Inc.