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

Re: bidding down attach on NAT-T



 In your previous mail you wrote:

   Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
   
   > => I believe you missed the fact I didn't try to make NAT traversal
   > secure (I clearly wrote I believe it is near impossible): you are
   > in my side, i.e., you consider that NAT traversal has an untrackable
   > security issue with attackers which behave like NATs.
   
   While I agree that peers should not use NAT-T if there is no NAT
   between them,

=> fine, we agree at 100%.

   I do think that NAT-T support should be required.

=> I have no objection but:
 - configuration must have a knob to disable NAT-T support
 - NAT detection must be secure.

   You never know when there will be a NAT between you and your peer.
   
=> I agree but there are some cases where you don't want to support
a NAT between you and your peer.

   Note that you CAN securely detect a NAT (and I consider a pseudo-NAT
   to be equivalent to a NAT in this sense) because the IKE messages are
   secured.

=> yes but the current draft does the NAT detection in the only unsecured
IKE messages, i.e, too soon!

   So the only real attack is some router performing NAT on you
   -- but that router could just as easily drop your packets too, so I
   don't think this is a credible threat.
   
=> this should be the only real attack!

   Personally, I feel that being able to use IPsec through a NAT is more
   important than worrying about some router dropping your packets or
   trying to re-NAT you.
   
=> I agree but I'd like to have NAT traversal active only when I know
it is possible to get a NAT on the path (i.e., a disable knob in the
config) and when there really is a NAT on the path (i.e., secure the
NAT detection).

Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
with it (I am *not*)?

Thanks

Francis.Dupont@enst-bretagne.fr