Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 1 Sep 2008 20:47:32 -0700

Joe,
 
> 
> However, I would be glad to credit Ananth with the large 
> number of 'attacks' on Postel's RFC793 design principle, "be 
> liberal in what you accept from others" from 1981. ;-)

Now, don't put me in attacker's shoes! :-) 

My point was : TCP secure has been hanging around for about 3 years and
other drafts which have been published later (some of which have become
RFC), all of them seem to want to add/change/modify a reference to those
in TCP secure, which keeps popping up now and then! I have no issues,
whatsoever, for putting relevant references, it is just that it it is
beginning to feel like a routine thing and that prompted my response to
Fernando about citing TCP secure as a reference in some of the those
drafts. 

I also agree that Watson's document should be mentioned in all these
drafts since it is the one which started talking about "slipping in the
window RST's......."

-Anantha

-Anantha
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAki4bGQACgkQE5f5cImnZrs5igCeKhNfbUiHweoYHQTvJDaxn/8L
> s7QAoMQvLTK91Nxg95tPnccyYwGULhp9
> =Ou+1
> -----END PGP SIGNATURE-----
> 
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Ted Faber <[email-masked]>
Date: Fri, 5 Sep 2008 18:38:32 -0700

On Thu, Aug 21, 2008 at 12:40:43PM -0500, David Borman wrote:
> 
> Wes and I would like to start the WG Last Call for:
> 
>  Title           : Improving TCP's Robustness to Blind In-Window  
> Attacks'
>  Author(s)       : A. Ramaiah, R. Stewart & M. Dalal
>  Filename        : draft-ietf-tcpm-tcpsecure-10.txt
>  Pages           : 27
>  Date            : July 9, 2008
>  Intended Status : Proposed Standard
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt
> 
> It is our understanding that all the feedback has been incorporated  
> into this latest version and that there are no known outstanding  
> issues with this document.
> 
> Please send feedback to the list, even if it is just a "yes, go ahead  
> and publish".
> 
> The WGLC will end on Friday, September 5, 2009.

Overall I think this is a good draft and should advance.  I have
comments, which I'll present in page order:

Probably the most technical comment I have is the objection to the
"There was no sound technical reasoning for choosing the Data mitigation
as MAY", which is on P15.

P2:
The 4-tuple is called a socket pair in 793.  Even if you don't want to
adopt that terminology, it's probably worth mentioning.  I also don't
like "RST, SYN or DATA segment."  These are TCP segments with the RST or
SYN flag set and I'd describe them that way.  ONce you've had a chance
to define "RST segment" as a segment with the RST bit set, you can use
the short form.

I'd delete "either" from "This can cause the connection to either abort
or possibly cause data corruption."  I'd consider deleting "possibly" as
well.

P4:

"The TCP spoofing attacks, which are seen in the Internet today," - I'd
say "The off-path TCP spoofing attacks".  We're still describing the
problem, so let's be clear.  The next paragraph starts with a
description of the attacks this draft cares about, but until then be
precise.

"... making the odds of guessing correctly the 4-tuple..."  I think
"correctly guessing" is more common.  I'd actually suggest "... making
it much easier to guess the 4-tuple."

P5:

"One of the important things to note is that, for the attack to succeed
the RST..." -> delete the comma.

"A slight enhancement to the TCP's segment processing" -> delete the
"the".

P6:

"Every application has control of a number of factors that effect
drastically the probability of a successful spoofing attack."  You mean
"affect" not "effect".  I'd also use "drastically affect" rather than
"affect drastically".  The order of the adverb is a matter of style,
using "affect" changes the meaning of the sentence to the one you
intend.

On the figures in the "To successfully inject a spoofed packet..."
paragraph:

1. Use parens, not [].
2. Finish the math.  If you want to say 1/2 * 2^32 = 2^31 rather than
just dropping 2^31 that's fine, but we're going to be comparing these
requirements, so don't hide the results.  "[SITW] shows that the mean
number of tries needed to inject a RST command is (2^31/window) rather
than the 2^31 assumed before."

P7:

"...please refer to draft [RFC4953]" -> "please refer to [RFC4953]"
It's not a draft any more.

P8:

Why use 1) and 2) and A), B), C)?  Pick one.

"The previous text, quoted from [RFC0793], woould thus become:" -> That
sounds a lot like we're mandating the change rather than it being a
SHOULD.  Do we really need this restatement at all?

P13:

"...so the chances of successfully injecting data into a connection are
1 in (2^32/RCV.WND *2)."  In describing the RST attacks, we spoke in
terms of mean number of tries, and I'd be consistent here.  Similarly
I'd do the math all the way: " ... so the mean number of tries needed to
inject data successfully is  2*2^32/RWND = 2^33/RCV.WND."

This section used a) and b) instead of either A) and B) or 1) and 2)
(used earlier for the same purpose). Again, pick one.

P15:

"There was no strong technical reasoning for choosing the Data mitigation
as MAY."
First, everywhere else the you use "DATA", I'd use it here.

Second, if I failed to make the case before, let me make it now.  The
DATA injection is 4 times less likely than either the RST or the SYN
attacks (2^33 vs 2^31) and may be visible to the application as garbled
data.  If the attack is visible an application can gracefully
terminate the connection and re-establish the conversation - unlike the
RST/SYN cases.  As the attack is harder to carry out, and a successful
attack may be easier to recover from, I recommend a MAY.  I don't care
if you repeat that argument, but I do believe that there are sound
technical reasons for the MAY, and I'd like to see the sentence that
started this comment elided.

P16:

"Currently there is no known bad behavior that can be attributed to the
lack of ACK throttling, but as a general principle, if ever invoked,
something incorrect is occurring and such a mechanism will act as a
failsafe that protects both the sender and the network." -> "While we
have not encountered a case where the lack of ACK throttling can be
exploited, as a fail-safe mechanism we recommend its use.  An
implementation may take an excessive number of invocations of the
throttling mechanism as an indication that network conditions are
unusual or hostile."

P18:

"...the middle box design does not comply to [RFC0793]."   No middlebox
complies with RFC793; I suggest "...the middle box is generating packets
a conformant TCP endpoint would not generate."

P22:

"ACK throttling was introduced to this document bt combining the
suggestions from the tcpm working group."  That seems out of place in
"Contributors".  That section is to acknowledge the efforts of
individuals.

P24:

Why are RFC's 4302 and 4303 normative?  And if they are why isn't
RFC2385?  They're all referred to as possible mitigations.  My
preference is making 4302 and 4303 non-normative, but it's very likely
that I'm missing a rule here.

Quotation marks are misplaced on the Medina05 reference.

The NISCC reference lacks a date.

P25:

Quotation marks are misplaced on the SITW reference.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: David Borman <[email-masked]>
Date: Fri, 19 Sep 2008 09:39:06 -0500

Hi,

I haven't seen any response from the authors on Ted's message.  We are  
well past the WGLC, but I would like the authors to address the issues  
that Ted brings up, and submit a new version of the draft before we  
pass this up to the IESG.  I haven't seen any other comments on this  
draft, so we are assuming that everyone else is happy with this  
version, after Ted's comments are addressed.

Once there is a new version available addressing Ted's comments, we'll  
pass this on to the IESG for publication as an RFC.  So, if anyone has  
further comments and neglected to speak up, now is the time to do so!

			-David Borman & Wes Eddy
			TCPM WG co-chairs

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Sep 2008 08:45:14 -0700

One issue I'd like to re-confirm: we have, in this document, a
hierarchical use of the RFC2119 terms of MUST/SHOULD/MAY, i.e.:

whole doc: SHOULD
	certain portions are listed as MUST

i.e., "if SHOULD, then MUST..."

This is, based on recent discussions I've had with others while
explaining this off-list, an uncommon use of 2119 language AFAICT.

It would be useful to get IESG guidance on this; if such use is common,
then the doc can be left in its current form. If its use is uncommon but
desired, then we need to explain the issue in some detail (i.e., a whole
paragraph called out as a section, IMO). If its use is not desired by
the IESG, then we need to adjust the recommendations accordingly (i.e.,
all MUSTs would drop to SHOULDs).

Joe

---

From: David Borman <[email-masked]>
Date: Fri, 19 Sep 2008 11:33:27 -0500

(WG chair hat off)

The SHOULD/MAY in the applicability statement is about who benefits  
most from tcpsecure, and in the rest of the document the MUST/SHOULD/ 
MAY are about implementing tcpsecure.  We (the WG) wanted the  
distinction in the applicability statement about which situations will  
benefit the most from tcpsecure.

So for this issue, I think the document is fine as is.

			-David Borman

On Sep 19, 2008, at 10:45 AM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Version: GnuPG v1.4.3 (MingW32)
> iD8DBQFI08kKE5f5cImnZrsRAuMoAJ43+3GJLSi5p7zEOkvLZtuzYfeV0gCg5x7N
> yqGeykNAk2sBFupRaFqmo3s=
> =VG60

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Fri, 19 Sep 2008 12:04:26 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of David Borman
>Sent: Friday, September 19, 2008 12:33 PM
>
>(WG chair hat off)
>

I'm personally in agreement.  I don't find it confusing at all, since
it's clear that if you choose not to take the upper SHOULD path, then
the set of dependent MUSTs don't apply; but I also read requirements
documents frequently, so YMMV :).

I don't, personally, think this issue is worth fretting over.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Sep 2008 10:14:40 -0700

David Borman wrote:
> (WG chair hat off)
> 
> The SHOULD/MAY in the applicability statement is about who benefits most
> from tcpsecure, and in the rest of the document the MUST/SHOULD/MAY are
> about implementing tcpsecure.  We (the WG) wanted the distinction in the
> applicability statement about which situations will benefit the most
> from tcpsecure.

Yes, we agreed on that, but that distinction is, AFAICT, unusual in the
IETF. I.e., most people I talked to expected the component
recommendations to reflect the overall context; they were extremely
surprised at our view that a hierarchy of recommendations was how
standards were written.

I'd like to suggest we get advice on this matter from outside the WG,
since this isn't an internal issue.

Joe

---

From: David Borman <[email-masked]>
Date: Fri, 19 Sep 2008 12:33:31 -0500

Joe,

I don't view it as a hierarchy.  The SHOULD/MAY in the applicability  
statement is about giving clarity to what situations tcpsecure is most  
applicable.  The rest is about how you implement tcpsecure.

But even if you do view it as a hierarchy, it is nothing out of the  
ordinary.  No optional standard is going to be a MUST for who needs to  
implement it, but then the rest of the standard itself will have still  
have MUSTs in it for how to do the implementation.  The only thing  
that might be unique here is that the applicability statement has an  
explicit SHOULD/MAY in it; they could be changed to should/may and I  
don't think anything would be lost, but I also think it is fine as it  
is.

			-David (still with WG chair hat off)

On Sep 19, 2008, at 12:14 PM, Joe Touch wrote:

>> most
>>>>>> "The TCP spoofing attacks, which are seen in the Internet  
>>>>>> today," -
>>>>>> I'd
>>>>>> drastically the probability of a successful spoofing attack."   
>>>>>> You
>>>>>> mean
>>>>>> "The previous text, quoted from [RFC0793], woould thus become:"  
>>>>>> ->
>>>>>> That
>>>>>> "...so the chances of successfully injecting data into a  
>>>>>> connection
>>>>>> are
>>>>>> terminate the connection and re-establish the conversation -  
>>>>>> unlike
>>>>>> the
>>>>>> "Currently there is no known bad behavior that can be  
>>>>>> attributed to
>>>>>> the
> iD8DBQFI094AE5f5cImnZrsRAtw3AKCs7g9FCoAKb0DS9QCNRrRIEIKSjgCglgnl
> wsD07E8spIc9N5fh0w/Po1w=
> =lDym

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Sep 2008 12:04:45 -0700

> applicable.  The rest is about how you implement tcpsecure.

I agree that we all understand our intent, and I agree with the intent.

> have MUSTs in it for how to do the implementation.  

This is the part that others have commented to me on, and the primary
point of my note. If we can point to an optional standard that has MUSTs
therein, fine. If not, we're blazing new ground.

> The only thing that
> might be unique here is that the applicability statement has an explicit
> SHOULD/MAY in it; they could be changed to should/may and I don't think
> anything would be lost, but I also think it is fine as it is.

It would definitely be lost; the doc would then have only MUSTs for
certain items, which are not MUSTs if the overall document is a SHOULD.

This is the punchline; i.e., if we feel that we can't make document-wide
recommendations at different levels than individual items, then the
document-wide concern needs to be reflected in the level of individual
items, and then I would claim that the current MUSTs should be converted
to SHOULDs. (I don't see other impacts).

Joe

---

From: David Borman <[email-masked]>
Date: Fri, 19 Sep 2008 15:01:03 -0500

On Sep 19, 2008, at 2:04 PM, Joe Touch wrote:

...
> therein, fine. If not, we're blazing new ground.

That's easy, just look at any optional standards track RFC.  Here are  
a few recent RFCs that I just picked at random:

RFC 5001 "DNS Name Server Identifier (NSID) Option"
RFC 5007 "DHCPv6 Leasequery"
RFC 5010 "The Dynamic Host Configuration Protocol Version 4 (DHCPv4)  
Relay Agent Flags Suboption"
RFC 5044 "Marker PDU Aligned Framing for TCP Specification"

None of these are mandatory, so at best they would be SHOULD for the  
overall document, and yet they all have MUSTs in them.  Need I go on?   
The only difference I can see is that these standards don't have  
explicit SHOULD/MAY in their applicability sections.

> to SHOULDs. (I don't see other impacts).

Again, the SHOULD/MAY in the applicability section is about who can  
benefit from tcpsecure, and has nothing to do with how to implement  
tcpsecure.  The other MUST/SHOULD/MAYs in tcpsecure are about how to  
implement tcpsecure.

It's "you SHOULD/MAY implement this, but if you do, you MUST do it  
this way".  That's just normal standards stuff.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Sep 2008 13:28:17 -0700

Hi, David,

If we have docs we can point to, we're fine. I had questions from others
on this point; if we have precedent, we're set.

Joe

David Borman wrote:
> That's easy, just look at any optional standards track RFC.  Here are a
> few recent RFCs that I just picked at random:
> 
> It's "you SHOULD/MAY implement this, but if you do, you MUST do it this
> way".  That's just normal standards stuff.
> 
>             -David Borman

---

From: David Borman <[email-masked]>
Date: Fri, 19 Sep 2008 15:34:31 -0500

Ok,

(WG chair hat on)

It looks like we have consensus on this.  The wording in the  
Applicability section with SHOULD/MUST is fine, and when I write up  
the proto for passing tcpsecure on to the IESG, I'll include a comment  
that this issue was brought up during WGLC and cite references to  
other RFCs as examples.

			-David Borman

On Sep 19, 2008, at 3:28 PM, Joe Touch wrote:

>> this
> iD8DBQFI1AthE5f5cImnZrsRAmTuAJ9reCQq4gM4b9Yzbidr61YRrFvbQwCfSkr9
> uf1SV+aHEvZkmsUr9TUIf8A=
> =iUCX

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 28 Sep 2008 14:03:55 -0700

Ted,
  Appreciate the detailed comments. Pl see inline responses.

> From: Ted Faber [mailto:[email-masked]] 
> Sent: Friday, September 05, 2008 6:39 PM
> To: David Borman
> Cc: [email-masked]; [email-masked]; Mitesh Dalal (mdalal); 
> Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
> 
> Overall I think this is a good draft and should advance.  I 
> have comments, which I'll present in page order:
> 
> Probably the most technical comment I have is the objection 
> to the "There was no sound technical reasoning for choosing 
> the Data mitigation as MAY", which is on P15.
> 
> P2:
> The 4-tuple is called a socket pair in 793.  Even if you 
> don't want to adopt that terminology, it's probably worth 
> mentioning.  I also don't like "RST, SYN or DATA segment."  
> These are TCP segments with the RST or SYN flag set and I'd 
> describe them that way.  ONce you've had a chance to define 
> "RST segment" as a segment with the RST bit set, you can use 
> the short form.

Good point. Will do.

> 
> I'd delete "either" from "This can cause the connection to 
> either abort or possibly cause data corruption."  I'd 
> consider deleting "possibly" as well.

Makes sense. Will do.

> today," - I'd say "The off-path TCP spoofing attacks".  We're 
> still describing the problem, so let's be clear.  The next 
> paragraph starts with a description of the attacks this draft 
> cares about, but until then be precise.
> 
> "... making the odds of guessing correctly the 4-tuple..."  I 
> think "correctly guessing" is more common.  I'd actually 
> suggest "... making it much easier to guess the 4-tuple."

Ok. 

> 
> P5:
> 
> "One of the important things to note is that, for the attack 
> to succeed the RST..." -> delete the comma.
> 
> "A slight enhancement to the TCP's segment processing" -> 
> delete the "the".

Both points taken.

> 
> P6:
> 
> "Every application has control of a number of factors that 
> effect drastically the probability of a successful spoofing 
> attack."  You mean "affect" not "effect".  I'd also use 
> "drastically affect" rather than "affect drastically".  The 
> order of the adverb is a matter of style, using "affect" 
> changes the meaning of the sentence to the one you intend.

Cool. Will do.

> 2. Finish the math.  If you want to say 1/2 * 2^32 = 2^31 
> rather than just dropping 2^31 that's fine, but we're going 
> to be comparing these requirements, so don't hide the 
> results.  "[SITW] shows that the mean number of tries needed 
> to inject a RST command is (2^31/window) rather than the 2^31 
> assumed before."

Ok.

> It's not a draft any more.

Ok.

> "The previous text, quoted from [RFC0793], woould thus 
> become:" -> That sounds a lot like we're mandating the change 
> rather than it being a SHOULD.  Do we really need this 
> restatement at all?

Hmm.. I thought it was more clearer that way. 

> connection are
> 1 in (2^32/RCV.WND *2)."  In describing the RST attacks, we 
> spoke in terms of mean number of tries, and I'd be consistent 
> here.  Similarly I'd do the math all the way: " ... so the 
> mean number of tries needed to inject data successfully is  
> 2*2^32/RWND = 2^33/RCV.WND."

Sure, it is good to be consistent. But the math which you depict above
seems incorrect to me. What was said earlier in the document is
(referenced from Watson's paper ) is :

============
   "[SITW] demonstrated that
   this assumption was incorrect and that instead of [1/2 * 2^32]
   packets (assuming a random distribution) [1/2 * (2^32/window)]
   packets is required.

   Substituting numbers into this formula we see that for a window size
   of 32,768, an average of 65,536 packets would need to be transmitted
   in order to "spoof" a TCP segment that would be acceptable to a TCP
   receiver.  A window size of 65,535 reduces this even further to
   32,768 packets.  At today's access bandwidths an attack of that size
   is feasible.

===============

So for data injection, this should become 2^32/RCV.WND. (i.e, [1/2 *
2^32 *2]/window )

> 
> This section used a) and b) instead of either A) and B) or 1) 
> and 2) (used earlier for the same purpose). Again, pick one.

Ok.

> 
> P15:
> 
> "There was no strong technical reasoning for choosing the 
> Data mitigation as MAY."

Sure.

> 
> Second, if I failed to make the case before, let me make it 
> now.  The DATA injection is 4 times less likely than either 
> the RST or the SYN attacks (2^33 vs 2^31) and may be visible 

Hmm.. It should be actually twice less likely 2^32 versus 2^31, based on
above.

> to the application as garbled data.  If the attack is visible 
> an application can gracefully terminate the connection and 
> re-establish the conversation - unlike the RST/SYN cases.  As 
> the attack is harder to carry out, and a successful attack 
> may be easier to recover from, I recommend a MAY.  I don't 
> care if you repeat that argument, but I do believe that there 
> are sound technical reasons for the MAY, and I'd like to see 
> the sentence that started this comment elided.

I think the general understanding was that any malicious event
responsible for the connection to go down is a problem. So I am not sure
whether I can buy this argument. OTOH, if you are classifying the
strength based on how easy/difficuly it is to contruct the attack vector
and cause harm to the connection, and if that is what is the consensus,
then so be it. I can mention this in the document.

> attributed to the lack of ACK throttling, but as a general 
> principle, if ever invoked, something incorrect is occurring 
> and such a mechanism will act as a failsafe that protects 
> both the sender and the network." -> "While we have not 
> encountered a case where the lack of ACK throttling can be 
> implementation may take an excessive number of invocations of 
> the throttling mechanism as an indication that network 
> conditions are unusual or hostile."

Your change looks elegant. Will do.

> complies with RFC793; I suggest "...the middle box is 
> generating packets a conformant TCP endpoint would not generate."

Ok.

> 
> P22:
> 
> "ACK throttling was introduced to this document bt combining 
> the suggestions from the tcpm working group."  That seems out 
> of place in "Contributors".  That section is to acknowledge 
> the efforts of individuals.

Makes sense.. Good eye!

> 
> P24:
> 
> Why are RFC's 4302 and 4303 normative?  And if they are why 
> isn't RFC2385?  They're all referred to as possible 
> mitigations.  My preference is making 4302 and 4303 
> non-normative, but it's very likely that I'm missing a rule here.

I am not sure about the rules here?  David/Wes what needs to be done
here ?

> Quotation marks are misplaced on the Medina05 reference.

Ok.

> Quotation marks are misplaced on the SITW reference.

This was put in long back.... I need to check.

I'll incorporate these comments along with others received in the next
(final, hopefully ?) version.

Once again, thanks for the detailed review.

-Anantha

---

From: David Borman <[email-masked]>
Date: Mon, 29 Sep 2008 09:43:13 -0500

> I am not sure about the rules here?  David/Wes what needs to be done

Typically normative references are things that a document depends on  
for understanding and/or implementation.  The only references to RFC  
4302 & 4303 are to say that the only real way to secure a connection  
is using IPsec, and since this document deals with the absence of  
them, I agree with Ted, these should be informative references.

			-David

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 07:53:18 -0700

FWIW, it seems like RFC1122 should be moved to normative.

Regarding some of the recent thread regarding the numbers in section
1.3 (Ted's comments, "finish the math"), I've noted before, as well,
that section 1.3 is redundant with RFC4953. Replicating the math isn't
needed. Also, the prediction regarding the impact of BW on the attack is
a guess in this doc, whereas in RFC4953 the relationship is explained.

Joe

David Borman wrote:
> Typically normative references are things that a document depends on for
> understanding and/or implementation.  The only references to RFC 4302 &
> 4303 are to say that the only real way to secure a connection is using
> IPsec, and since this document deals with the absence of them, I agree
> with Ted, these should be informative references.
> 
>             -David
>

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 08:19:59 -0700

> a guess in this doc, whereas in RFC4953 the relationship is explained.

I don't have an y strong attachment to where the arithmatic is done, but
expressions like (2*2^32) need to be simplified so it's easy for a
reader to compare the risks.

If the authors are cool with a pointer to 4953 for derivations, I am,
too, but the final numbers should appear here as well.

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 08:32:17 -0700

> too, but the final numbers should appear here as well.

Agreed - a summary statement and the final numbers or conclusions from
4953 need to be contained in this doc.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 08:40:15 -0700

> 4953 need to be contained in this doc.

Just to be clear, I don't have a preference, and apparently I wasn't
quite clear enough on thst.

If the authors are determined to include the derivation here, that's
fine with me, as it's fine with me to point off to 4953.  My only 2
concerns are that the final figures be simplified in this draft and that
the two documents agree(!).

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 29 Sep 2008 08:57:42 -0700

Yes, in the current document (tcpsecure) the math is all about how many
numbers (quantifies difficulty) one has to guess and doesn't explain in
detail how much time this would take to ultimately kill the connection
taking into account varying bandwidth. I am fine adding another explicit
reference here if needed. The current math still need to exist, and it
isn't redundant and is limited in scope. Maybe we can have real numbers
like 4294967296 instead of 2^32.

Good point about 1122, should be under normative. 

-Anantha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joe Touch
Sent: Monday, September 29, 2008 7:53 AM
To: David Borman
Cc: Ted Faber; [email-masked]; Anantha Ramaiah (ananth); Mitesh Dalal
(mdalal)
Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt

Joe

David Borman wrote:
>>> preference is making 4302 and 4303 non-normative, but it's very 
>>> likely that I'm missing a rule here.
>>
> 4302 &

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 09:07:24 -0700

>   Appreciate the detailed comments. Pl see inline responses.

My pleasure.

> (referenced from Watson's paper ) is :

The paragraph I'm commenting on reads:

   A third type of attack is also highlighted by both the RST and SYN
   attacks.  It is also possible to inject data into a TCP connection by
   simply guessing a sequence number within the current receive window
   of the victim.  The ACK value of any data segment is considered valid
   as long as it does not acknowledge data ahead of the next segment to
   send.  In other words an ACK value is acceptable if it is ((SND.UNA-
   (2^31-1)) <= SEG.ACK <= SND.NXT).  The (2^31 - 1) in the above
   inequality takes into account the fact that comparisons on TCP
   sequence and acknowledgement numbers is done using the modulo 32 bit
   arithmetic to accommodate the number wraparound.  This means that an
   attacker has to guess two ACK values with every guessed sequence
   number so that the chances of successfully injecting data into a
   connection are 1 in ((2^32 / RCV.WND) * 2).

I'm saying that, assuming the math is correct, that last expression
should be (2^33 / RCV.WND).  I didn't check the math.  If you also
believe the math is wrong, you have a larger edit. :-)

On rereading the argument, it does sound like a data injection attack
should be harder by a factor of 2 and that they multiplied by the wrong
expression (2^32 rather than 2^31).  So I think you're correct about the
math, and if so the final expression would be 2^32 / RCV.WND.

I'd be happier if someone else also looked at this paragraph for
technical accuracy.

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 09:21:40 -0700

> the two documents agree(!).

IMO, the whole point of developing 4953 was to document the problem and
define its impact mathematically so that other RFCs could refer to it.

This doc certainly needs to refer to the problem and the resulting
analysis, but there's no utility in replicating the derivations in 4953.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 10:28:07 -0700

Ted Faber wrote:
...
> I'd be happier if someone else also looked at this paragraph for

Further good reasons not to replicate the derivation, IMO.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 29 Sep 2008 10:40:20 -0700

> I'm saying that, assuming the math is correct, that last 
> expression should be (2^33 / RCV.WND).  I didn't check the 
> math.  If you also believe the math is wrong, you have a 
> larger edit. :-)
> 
> On rereading the argument, it does sound like a data 
> injection attack should be harder by a factor of 2 and that 
> they multiplied by the wrong expression (2^32 rather than 
> 2^31).  So I think you're correct about the math, and if so 
> the final expression would be 2^32 / RCV.WND.
> 
> I'd be happier if someone else also looked at this paragraph 
> for technical accuracy.

I have updated the document with the correct math. I agree that it would
be nice if a few more folks take a look.

Thanks,
Anantha

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 11:03:17 -0700

Anantha Ramaiah (ananth) wrote:
...
> be nice if a few more folks take a look.

I (and the WG) checked the math in 4953; I don't expect to recheck the
math when it's re-trod (is there a reason the WG should?)

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 11:43:29 -0700

> math when it's re-trod (is there a reason the WG should?)

I don't see the calculations on P.13 of tcpsecure (i.e., data insertion
probabilities) in 4953.  Can you point out what I missed?

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 13:14:59 -0700

> probabilities) in 4953.  Can you point out what I missed?

I was talking about section 1.3 on page 6 of tcpsecure, which is
redundant with 4953. Section 5.1 is different.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 14:19:36 -0700

> redundant with 4953. Section 5.1 is different.

Different thread then, this one's about the example on p. 13. :-)