[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:

   >   The issue is that said attacker can force all transmissions from the
   > gateway to the client to go via itself. It does this by pretending to
   > be a NAT, and futzing with the source IP/port#. The gateway will use that
   > address for the packets it sends.
   
   I would claim that an attacker can only do this if it is on the path
   between the two IPsec endpoints. The attacker would have to prevent
   delivery of the packet with the original IP address/port # and send a
   packet with the same innards but a different source IP/port#. At this
   point, I would claim the attacker *is* a NAT, since that's exactly what
   NATs do.
   
=> I agree: this is why I called the attacker in this context a
pseudo-NAT.

   >   So, what in the end is the effect of having the IKE/ESP flow sent via
   > some malicious third party? Assuming that the third party does not drop
   > any packets in the flow, we have:
   >      a) additional latency.
   >      b) traffic analysis.
   
   But any party on the path between the two IPsec endpoints can do this
   anyway - with or without invoking NAT-T.
   
   That's not to say that these threats aren't serious. Just that there is
   nothing we could possibly do within IKE or ESP to improve the situation.
   
   What am I missing?
   
=> the attacker can divert a lot of ESP traffic when it modifies only
a very small number of IKE messages. It can, for instance, quit the
path between the two IKE peers as soon as its job is done (this is
why I called it a transient pseudo-NAT).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: for this part of my "bidding down" argument, we need only to agree
that NAT traversal is less secure than no NAT traversal. Especially we
don't need to find defense against the "transient pseudo-NAT" attack
other than to protect the peer addresses (easy and efficient but
not compatible with NAT traversal).