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

Re: draft-ietf-ipsec-ikev2-05.txt comments



 In your previous mail you wrote:

   Francis Dupont writes:
   >    I do not think there are real world cases where the responder is
   >    behind NAT, especialy dynamic NATs :-)
   >    
   > => I can imagine as many as you are ready to read (:-), for instance
   
   I can imagine lots of things, but that does not make it real world
   case. 
   
=> I believe I've got one real world example: peer-to-peer stuff
where both peers can be behind a NAT and confidentiality should be
supported end-to-end. There is a rendezvous system in order to
"configure" the NATs but it doesn't participate to peer-to-peer
communications...
Note that I believe in this case IKE should be run directly over
UDP 4500 and in the unlikely case there is no NAT at all peers
should (in order to avoid a bidding down attack) fallback (i.e.,
retry as soon as they detect no NATs) to UDP 500.
So the rendezvous system should deal with UDP 4500 and a large
part of NAT-T MUST be supported (this is a good argument for
a MUST).

   > one can use some kind of callback mechanism in order to enforce the
   > side of the initiator (firewalls are good reasons to do that).
   
   Where is that used in real world NOW?
   
=> I've seen this kind of mechanisms for firewall traversal (usually
the rules are very different in the two ways).

   > To summarize, I can't see why we refuse the opportunity to support
   > any position for the NAT.
   
   I do think NAT can be in any position with current draft already, so
   there is no need to make the protocol more complicated because of some
   imagined cases.
   
=> IMHO the current draft is a bit underspecified, for instance it
should explicitely permit to run IKE over port 4500 from the beginning
(so there will be only one mapping and as soon as an exchange succeed
the whole stuff, including IPsec SAs, works).

   For example the callback mechanism would propably want to do the

=> I disagree: a property of the callback is to use the asymmetry
of some IKE features (cf the privacy reopen stuff) in the convenient
way. So let just support any position for NATs: no NAT, initiator
behind a NAT, responder behind a NAT, both peers behind NATs.
With careful wording this should be possible.

   initial authentication before calling back, thus in the current
   protocol the original responder will already know the mapping for the
   port 4500, and there are NAT keepalives already going for that port,
   so it can directly connect to that port and use that as callback
   address. 

=> note you explicitely use an IKE which always runs over UDP 4500.
IMHO this is the good solution and it should be documented (current
draft suggests the first exchange must be over UDP 500).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: so in your part (NAT-T) you should add some words about IKE_SA_INIT
over UDP 4500 and what to do if no NAT is detected:
 - switch to UDP 500 for next messages (i.e., the opposite of
   NAT detection)
 - continue on UDP 4500 with a possible bidding down attack because
   NAT-T is less efficient (note it is no more less secure because
   the implicit update MUST NOT be enabled when the other peer is
   not behind a NAT, does the extra overhead really matter?)
I propose to give the choice to the initiator with the first one by default?
You should add something for the case all NATs are removed (i.e., an
implicit update to the real peer addresses) with the same tradeoff.