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

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

 In your previous mail you wrote:

   Francis Dupont writes:
   > => perhaps it is too easy:
   >  - it is less secure than at the end of IKE_AUTH
   
   Can you explain why (except that sending the discovery notifications
   in clear text packet)?
   
=> this is a reason but there are others, for instance the NAT detection
is in fact done on only one message, the reply of IKE_SA_INIT: you can't
perform a three way handshake or with other words a return routability
check.

   >  - it doesn't work if the responder is behind a NAT

   It should work fine in that case too. There is nothing special
   whichever end is behind NAT. Initiator will detect if either end is
   behind NAT and will then switch to new port and if the responder is
   behind NAT it must either be statically configured NAT (i.e both port
   500 and 4500 going to that machine behind NAT), or initiator found out
   the address of the other end from some directory service and in that
   case it should also put in bit saying that it is behind NAT, and the
   initiator should start with port 4500 directly.
   
=> so you loose all the other cases (with peer-to-peer, we can see some
support for the case where both ends are behind NATs for instance) and
more you assume a MUST for NAT traversal support (for the start with port
4500). You should make this last point clearer.

   >  - it doesn't work if the responder doesn't implement NAT-T
   >    (i.e., if it is not ready to receive packets on UDP 4500)
   
   If it does not support NAT-T then there is nothing we can do if there
   is NAT between. 
   
=> I disagree: either we give a way to manage the failure, or we enforce
NAT-T support (i.e., put a MUST for its support).

   >  - the detection is made only by the initiator
   
   No, both ends will know which ends are behind NAT after the
   IKE_SA_INIT. 
   
=> both will know but only the initiator does something with this
knowledge. IMHO this is an unecessary asymmetry.

   > => in my proposal, the node behind the NAT (usually the initiator but
   > this is not necessary) must send a packet as soon as SAs are up.
   
   This complicates the state machine more...
   
=> this is a matter of taste.

   > => it does matter if it wants to protect itself against attacks using
   > a spoofed source peer address.
   
   It has nothing to do with NAT-T, the responder must reply back to the
   address where the packet was requested anyway, and it should rate
   limit replies anyways. 
   
=> I disagree: defense against DoS is far easier when DoS packets can be
distinguished from valid packets.

   >    The responder can be behind NAT, but in such case the initiator needs
   >    to find the external address of the NAT box to start the exchange in
   >    first place. Also the NAT must normally be kind of static NAT.
   > => this is less general, i.e., we should find real world cases where
   > it doesn't work.
   
   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
one can use some kind of callback mechanism in order to enforce the
side of the initiator (firewalls are good reasons to do that).
To summarize, I can't see why we refuse the opportunity to support
any position for the NAT.

Thanks

Francis.Dupont@enst-bretagne.fr