Re: bidding down attach on NAT-T

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

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


>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:
    >> 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.

    Charlie> I would claim that an attacker can only do this if it is on the
    Charlie> path between the two IPsec endpoints. The attacker would have to
    Charlie> prevent delivery of the packet with the original IP address/port

  Well, they do not need to be in the reverse path.
  It enough to be in the forward path.  (client->gateway)

  The replay protection means that it isn't enough to replay the packet,
unless one can do it faster than the original packet. So, I agree that the
attacker pretty much has to be inline. 

    >> 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.

    Charlie> But any party on the path between the two IPsec endpoints can do
    Charlie> this anyway - with or without invoking NAT-T.

  I agree. 
  I'm wasn't explicit in saying that these aren't unique attacks to NAT-T.

    Charlie> That's not to say that these threats aren't serious. Just that
    Charlie> there is nothing we could possibly do within IKE or ESP to
    Charlie> improve the situation.

  The thing that we could do, is require some kind of three way handshake to
change the UDP port #/IP address. That could be a rekey.

  This assures that the flow doesn't get aimed at some innocent bystandard
until the real client speaks again. 

  The sequence would go something like this:

      gateway receives new UDP port #/IP
#1    sends notify to old UDP port #/IP,
	    indicating that it thinks it should change
#2    sends notify to new UDP port #/IP,
	    indicating that it thinks it is time to rekey

  A client receiving #1 can reply, saying "no thank you" if it doesn't
want to rekey yet.
  A client receiving #2 can reply with a rekey.
  A client receiving both could cancel the rekey with some token from
#1. 
 
  This might all fit into Dead Peer Detection.

  Note that an observer can easily figure out which is IKE traffic and
which is ESP traffic. The truly paranoid may want to have the gateway send
the IKE traffic inside the ESP tunnel. This seems very fragile to me.

]       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

iQCVAwUBPmYyR4qHRg3pndX9AQE2OwP/a6wpIgkeXPPBktRkgbqzjI7ftC4QQLhH
OOgp5urjM/br3B+UhtNqfW6/Z968xUi8s3GqEjSctT1nBt0DbBCGdg4F5leF0d/G
GvZ1FxDG7zdUvC42Rcb1BVA29PS5rneWFMHGQTx2b9Vq82DPFfjScagdOLcDeFmt
eMmIGiegWQI=
=eZWE
-----END PGP SIGNATURE-----