Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

I'm interested in the proposed RST ack challenge/response mechanism.

I expect the case that the valid packet received containing the RST
flag is _not_ the packet the receiver was expecting with the next
expected sequence number to be quite common, with packet reordering in
the Internet, loss (and don't users often kill slow browser
connections?), and whatnot. Connections don't always get closed under
the best of conditions.

It strikes me that, a priori, both sender and receiver know and can
remember the initial sequence number ever used on their connection,
which is (pseudo-randomly) selected. Randomness of initial sequence
numbers was recently improved, after much media fuss:

http://www.google.com/search?q=initial+sequence+number+randomness

We can use this randomness to our advantage.

This first sequence number information can be used to form part of the
challenge-response; if the sender has sent an RST packet whose
sequence number lies in the window, but it is not the next expected
packet, the ack sent back by the receiver can be an indicator for the
RST sender to pass the first sequence number in a subsequent packet
(also containing a confirming RST flag. 'I told you to close. I'm
telling you to close again. And here's a reminder of when we first
spoke and agreed to open. It's a random number we both know.'.)

I suppose this could be passed as (sigh) a new TCP option -- or,
better, you could just use the existing sequence number field.

Existing TCP implementations would ignore this second RST packet
containing the original first sequence number in that field if that
correct number lies outside the window, and if it's inside, well,
you've already sent one RST anyway. You're likely backwards
compatible.

This weak authentication might give added protection to long-lived TCP
flows, as the attacker would need to snoop on the start of the
connection to know that first sequence number - and if she's doing
that, your unsecure data can already be hers. (Why is there so much
fuss about a weak DoS attack and no fuss about the widespread reliance
on an unsecure transfer protocol?)

And in tying to sequence space, which is where our problem lies,
storing and resending the initial sequence number on request as a
cookie seems somewhat easier to code and deal with than the later and
optional timestamps (K Poon's suggestion), as we avoid option fields
entirely.

L.

apologies if this has already been suggested in these related threads.
Unfortunately, my life prevents me from reading email full-time.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@eim.surrey.ac.uk>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm