Re: [tcpm] Tcpsecure draft

Patrick,

   Pl see some comments inline to your queries.. 

> -----Original Message-----
> From: Patrick Collison [mailto:patrick@collison.ie] 
> Sent: Sunday, March 16, 2008 7:48 PM
> To: Anantha Ramaiah (ananth)
> Subject: Tcpsecure draft
> 
> Hi,
> 
> I just read the latest tcpsecure draft
> (http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure
> -09.txt),
> and have a question. I'm sure where the best place to ask is; 
> feel free to tell me to go elsewhere!

The mailing list is tcpm@ietf.org. Some ietf lists have the requirement
that you have to be subscribed to the list to send questions or else the
emails would be on hold before until some verification is done. I am not
sure about tcpm.

> 
> In section 3.2 B, it's stated that a valid sequence number 
> attached to a RST packet MUST reset the connection without 
> further transmission.

Yes this is just the default behaviour anyway since the valid seq# would
RST the connection. (ie., without the draft being implemented)

> 
> This has the problem that an attacker with very good 
> information (for example, where intermediate routers are 
> somehow colluding with the attacker -- as with Audible Magic 
> being deployed at ISPs,
> http://w2.eff.org/share/audible_magic.php) can trivially 
> guess the correct sequence number range, and send a couple of 
> RSTs that are all-but guaranteed to trigger a reset.

Yep, all bets are lost if the attacker can guess the correct sequence #
unless other protection mechanisms (which the draft talks about) are in
place.

> 
> I raise this because I'm in the process of implementing RST 
> spoofing protection in xnu, and saw that the draft has a very 
> similar solution to what I'd ended up with (zero-length ACKs 
> on receipt of RST, plus throttling). To mitigate the above 
> case, where the attacker can easily guess the correct 
> sequence number, I plan to either 1) send an ACK for all RSTs 
> (within the bounds of the ACK throttling) or 2) send an ACK 
> for all RSTs once a single bad RST packet has been received 
> for a particular TCP.

Couple of issues, I can see :-

#1 The attacker can send 2 consecutive RST's (with some random delay
between those) with exact sequence number, with your soluton you will
respond with ACK for the first RST segment, and suppose you receive the
second RST (again from the attacker), you will tear down the connection.

#2 you are penalizing a well behaving host which sends the exact seq#,
in other words, with your solution an RST would always incur a extra RTT
to tear down the connection. 

> 
> Both solutions have their drawbacks, so this will probably be 
> solved by means of a tuneable parameter, with 2 likely being 
> the default.

Sure, but see above corner case. 

> 
> Have the authors considered this situation? (And if so, was 
> it decided that the changes that mitigating this would require are too
> extensive?)

No, if the sequence # of the incoming RST = RCV.NXT, TCP would tear down
the connection, that's what we have. One of the main objections by some
people was that this solution "adds" an "arc' in the TCP state diagram
and if we would have proposed sending an ACK for all RST's (including
the ones matching the seq#) then it would have invited even more
resistance. But you are free to propose this :-)  

> 
> Lastly, is there a public mailing list where the discussion 
> surrounding these drafts has taken place?

Yes, the working version of this draft is -09- and that should give you
a clue on the age of this draft :-)

Your second question is already answered above. I am also taking the
liberty to cc the mailing list to keep them in the loop.

-Anantha
> 
> Cheers,
> 
> Patrick
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm