Re: Some IKE/NAT questions

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 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