Subject: [tcpm] TCP Secure

From: <[email-masked]>
Date: Fri, 18 May 2007 15:00:10 +0100

Hi,

I was just wanting a couple of bits of clarification about TCP Secure:

Top of page 10: It isn't clear what happens to other segments after you
drop the RST? Are they just processed as normal? This is what is implied
but it would be useful if it were made explicitly clear.

What happens if there is any re-ordering before a valid RST or SYN is
sent? Can you clarify how your mitigations react to this. From my
understanding, the reason for originally accepting any RST or SYN in the
valid receive window was to allow for data reordering (as explicitly
stated in RFC793)

Finally: spotted three typos:

Page 5 para 3) "...before succeeding in his mischieve." --> "... before
succeeding in his mischief."
Page 11 3rd para up from bottom "...would not have a TCB..." -->
"...would not have a TCP..."
Page 19, para 2. Initial "i" not capitalized

Toby

________________________________________________________________________
____
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473
648734 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Mitesh Dalal \(mdalal\)" <[email-masked]>
Date: Wed, 23 May 2007 10:46:26 -0700

Hi Toby,
 
Please see inline.

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Friday, May 18, 2007 7:00 AM
	To: [email-masked]
	Subject: [tcpm] TCP Secure

	Hi, 

	I was just wanting a couple of bits of clarification about TCP
Secure: 

	Top of page 10: It isn't clear what happens to other segments
after you drop the RST? Are they just processed as normal? This is what
is implied but it would be useful if it were made explicitly clear. 

	Mitesh: yes, they are processed as normal as if the RST didnt
arrive. 

	What happens if there is any re-ordering before a valid RST or
SYN is sent? Can you clarify how your mitigations react to this. From my
understanding, the reason for originally accepting any RST or SYN in the
valid receive window was to allow for data reordering (as explicitly
stated in RFC793) 

	Mitesh: you mean the other side send bunch of data followed by a
RST, however we received the RST followed by the data ?

	In that case, we send an ACK for the RST and process the
following data and hopefully when we get the RST for the ACK that

	we had send, we will flush the connection.  

	Page 5 para 3) "...before succeeding in his mischieve." --> "...
before succeeding in his mischief." 
	Page 11 3rd para up from bottom "...would not have a TCB..." -->
"...would not have a TCP..." 
	Page 19, para 2. Initial "i" not capitalized  

	Thanks. We will get them in.

	Mitesh