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

bidding down attach on NAT-T



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Francis" == Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
    Francis> => the IKEv2 mechanism has to be revised because it is subject
    Francis> to a bidding down attack. Can we open a thread about this?

  As I understood things, this issue is not that a third party can 
force UDP encapsulation of the ESP packets by playing with the UDP
headers of the IKE exchange.

  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. 
  We can not, in general have the gateway refuse to change its notion of
where to send things because: 
       1) the attacker could have started futzing at the beginning of the
	  exchange anyway.
       2) a NAT may legitimately assign new port numbers/IP addresses to
	  the flow.

  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.
     
  I assume that the crypto is good. If it isn't, and the attacker can break
the crypto, all bets are off anyway.

  The most serious thing that the third party can do is to hijack the flow
with the intent to disrupt the flow. This is a denial of service attack.

  I have a notion on how to deal with this, but before I get into it,
I'd like be sure that we are solving the right problem.

  The problem is: is there a way for the client/gateway to agree that they
have a functional UDP pipe between each other before committing to a change.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [



    

  


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPmUAXIqHRg3pndX9AQEphwQA1hNr9fabCWeEjQ60V0HQcKY84YEp365d
tqI6IHAh5gF65V3YKcNoPdOeSkmgHcfWwm3o/+cuJu9pBuT/3/wPYuyVJXwFmTKG
kK0MoqCzFLDdSq4nbyu4Sb2MZqdOV2lhV2Evl9xYiBCo3qgEnMd9Dwez+Vei2Ymj
HeJxznmEUSI=
=7TL/
-----END PGP SIGNATURE-----