Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard

From: "Tom Petch" <[email-masked]>
Date: Mon, 18 May 2009 07:02:39 +0200

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Fernando Gont" <[email-masked]>
Cc: <[email-masked]>; "Anantha Ramaiah (ananth)" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 17, 2009 11:03 PM
Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving
TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard

> On 2009-04-17 17:14, Fernando Gont wrote:
> > On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth)
> > <[email-masked]> wrote:
> >
> >>> * The document never mentions the fact that this document is
> >>> IPR-encumbered.
> ...
> > I personally believe this should be noted in all RFCs on which there's
> > a known IPR. However, Joel Halpern mentioned this is not current
> > practice. If that's the case, I'd have no problem with leaving it "as
> > is". (FWIW, if you look at our tcp-security document, we do recommend
> > the implementation of the counter-measures you propose, but just note
> > that there's an IPR, and that implementers should research how this
> > would affect them).
>
> Personal belief doesn't come into it. It's strictly defined in a BCP.
> RFC3979 tells us the rules about this. Basically, the RFC Editor will
> do what is required:
>
> "4.  Actions for Documents for which IPR Disclosure(s) Have Been Received
>
>    (A) When any Intellectual Property Right is disclosed before
>        publication as an  RFC, with respect to any technology or
>        specification, described in a Contribution in the manner set
>        forth in Section 6 of this document, the RFC Editor shall ensure
>        that the document include a note indicating the existence of such
>        claimed Intellectual Property Rights in any RFC published from
>        the Contribution.  (See Section 5 below.)"
>
> [Section 5 defines the exact text to be included in such RFCs.
> I believe you can use <?rfc iprnotified="yes"?> in xml2rfc.]

This is what I thought but ....

RFC5425 has recently been published and I can find no mention of IPR claims in
it.  The IESG Protocol Action
Message-Id: <[email-masked]>
calls out the fact that claims were made, in fact repeatedly so, against each
successive version of the I-D.  So why nothing in the RFC?  What am I missing?

Tom Petch

> "11.  No IPR Disclosures in IETF Documents
>
>    IETF and RFC Editor Documents must not contain any mention of
>    specific IPR.  All specific IPR disclosures must be submitted as
>    described in Section 6.  Specific IPR disclosures must not be in the
>    affected IETF and RFC Editor Documents because the reader could be
>    misled.  The inclusion of a particular IPR disclosure in a document
>    could be interpreted to mean that the IETF, IESG, or RFC Editor has
>    formed an opinion on the validity, enforceability, or applicability
>    of the IPR.  The reader could also be misled to think that the
>    included IPR disclosures are the only IPR disclosures the IETF has
>    received concerning the IETF document.  Readers should always refer
>    to the on-line web page to get a full list of IPR disclosures
>    received by the IETF concerning any Contribution.
>    (http://www.ietf.org/ipr/)"
>
>       Brian
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Lars Eggert <[email-masked]>
Date: Fri, 22 May 2009 12:02:03 +0900

Hi, authors,

it's been over a month since the IETF last call ended, and I have not  
seen a document revision or even an attempt at discussing the comments  
you have received. Please start this discussion and eventually revise  
the document.

Thanks,
Lars

On 2009-4-17, at 5:11, Eggert Lars (Nokia-NRC/Espoo) wrote:

> Hi, authors,
>
> the IETF last call has ended, and it looks like the few comments I've
> seen will require some text changes, so I'm placing this document in
> the Revised ID Needed state.
>
> Also: Has the discussion of the comments that Fernando made concluded?
>
> Lars
>
>
> On 2009-4-2, at 18:07, The IESG wrote:
>
>> The IESG has received a request from the TCP Maintenance and Minor
>> Extensions WG (tcpm) to consider the following document:
>>
>> - 'Improving TCP's Robustness to Blind In-Window Attacks '
>>  <draft-ietf-tcpm-tcpsecure-11.txt> as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to
>> the
>> [email-masked] mailing lists by 2009-04-16. Exceptionally,
>> comments may be sent to [email-masked] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0
>>
>> The following IPR Declarations may be related to this I-D:
>>
>> https://datatracker.ietf.org/ipr/421/
>>
>>
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> <smime.p7s><ATT00001.txt>

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 21 May 2009 22:33:14 -0700

Lars,
   There were some comments by Sandra Murphy which we have had
discussion. I had already responded to Fernando's comments and the
agreed upon comments are being incorporated. 
   That said, I agree that we have been slow in getting the next
revision for which I sincerely apologize, well for a change this time it
is us!  
-Anantha 

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Thursday, May 21, 2009 8:02 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure 
> (Improving TCP's Robustness to Blind In-Window Attacks) to 
> Proposed Standard
> 
> Hi, authors,
> 
> it's been over a month since the IETF last call ended, and I 
> have not seen a document revision or even an attempt at 
> discussing the comments you have received. Please start this 
> discussion and eventually revise the document.
> 
> Thanks,
> Lars
> 
> >> the [email-masked] mailing lists by 2009-04-16. Exceptionally,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 May 2009 18:59:32 -0300

> agreed upon comments are being incorporated. 

IIRC, there had been comments from Brian Carpenter about specific

> I believe you can use <?rfc iprnotified="yes"?> in xml2rfc.]

I'm not sure what's the chairs' and ADs' take on this issue.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 22 May 2009 17:37:44 -0700

Fernando,
    I will summarize all the comments which have been incorporated when
I post the next revision. I have no issues trying out the <?rfc
iprnotified="yes"?> suggestion by Brian. My email to Lars was primarily
to say that "there have been discussions about the comments and the next
revision is work in progress"
    Does that clarify?
-Anantha

> From: Fernando Gont 
> [mailto:[email-masked]] On Behalf Of 
> Fernando Gont
> Sent: Friday, May 22, 2009 3:00 PM
> To: Anantha Ramaiah (ananth)
> Cc: Lars Eggert; [email-masked]; 
> [email-masked]
> IIRC, there had been comments from Brian Carpenter about 
> specific requirements for text in RFC 3979. Here's a quote 
> from Brian's post:
> 
> 
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2009 12:23:48 -0300

Hello, Anantha,

> iprnotified="yes"?> suggestion by Brian. 

Great!

> My email to Lars was primarily

Sure it does. I was just wondering what had been the outcome of the
e-mails discussion.

We had also had a brief discussion on more technical stuff. But I'm not
sure if there are any changes that will be incorporated in the next rev
in response to that e-mail exchange. Maybe you could post a heads up on
the upcoming changes?

Thanks!

Kind regards,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 31 May 2009 23:30:04 -0700

Fernando,
    I was modifying the document to update the last call comments and I
would want to make sure if we are on same page w.r.t to your comments.
Pl see inline. 

> From: [email-masked] 
> Sent: Thursday, April 16, 2009 10:15 PM
> Cc: [email-masked]; [email-masked]
> > > IPR-encumbered. As far as I recall, much of the dicussion within 
> > > tcpm with respect to the level of requirements of this document 
> > > (MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the 
> > > document should include a warning mentioning that there's 
> an IPR on 
> > > the document, so that implementers can consider this 
> point in their 
> > > decision of whether to implement the described mechanisms or not.
> >
> > I am confused what to do since this is being brought up 
> very late in 
> > the game. That said, there are *many* drafts/RFC's that have IPR on 
> > them in the whole of ietf. Do all them explicitly state the 
> IPR link ? 
> > I'll leave it to the collective wisdom of the group and the 
> chairs to 
> > offer guidance on this matter.
> 
> I personally believe this should be noted in all RFCs on 
> which there's a known IPR. However, Joel Halpern mentioned 
> this is not current practice. If that's the case, I'd have no 
> problem with leaving it "as is". (FWIW, if you look at our 
> tcp-security document, we do recommend the implementation of 
> the counter-measures you propose, but just note that there's 
> an IPR, and that implementers should research how this would 
> affect them).

I think we seem to have concluded this. As per Brian Carpenter's
suggestion I have done an iprnotified = yes in my xml2rfc. I hope that
should take care of this.

<snip>

> 
> > Now the scope of this document is to improve robustness to 
> TCP esp. in 
> > cases where the TCP connection is not protected by other means like 
> > TCP MD5 or TCP AO etc., Now this point is very clear in the 
> document. 
> > That said I have no issues putting a reference to the port 
> > randomization in the document.
> 
> What I mean is that anybody that cares about this stuff 
> (FWIW, I do) would also implement port randmization, ISN 
> randomization, etc. One might argue that there's no use in

It depends on how you view this document. To me, this document is about
improving TCP's robustness on some type of scenarios. It is not intended
to be a plethora of all possible TCP attacks and mitigations.  
> 
> > > and other quite a few times in the tcpm wg list, pre and 
> post wglc, 
> > > but this comment was never addressed. It's particularly 
> curious that 
> > > port randomization is not mentioned when tsvwg is working on it 
> > > (draft-ietf-tsvwg-port-randomization).
> >
> > Yes, you did raise this issue last time, but I did defer it 
> to the WG 
> > and did not receive any response, so I simply left it at that.
> 
> IIRC, both Joe and me had agreed on this one (yeah, we did :-) ).

Like I said earlier, I have no issues putting a reference to port
randomization document. Can you suggest a right place for this?
> 
> 
> 
> > > * Among the factors that determine how easy these attacks be 
> > > exploited is the window size. This document should 
> provide, at the 
> > > very least, pointers with advice on what to do with the 
> tcp window. 
> > > While quickly skimming through RFC 4953, it
> >
> > It does mentions about the window size relationship, For example in 
> > the beginning sections of the document we briefly mention 
> the window 
> > size and the # of packets that is required to generate a 
> successful attack.
> 
> What I mean is: you should not use windows that are larger 
> than necessary. Using larger windows than necessary doesn't 
> come for free (e.g., it increases the chances of an attacker 
> of successfully performing these attacks).

Provide advice on window sizes is deemed beyond the scope of this
document, IMO.

> 
> 
> > > * Yet another factor is TCP ISN randomization. At the very least, 
> > > this document could/should a pointer to RFC 1948. We do offer a 
> > > lengthy discussion of this and other issues in 
> > > draft-gont-tcp-security and 
> > > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
> >
> > Why should it talk about ISN randomization since ISN 
> randomization, is 
> > somewhat orthogonal to the type of attack here, it is not 
> even one of 
> > the attack vector.
> 
> If I can predict the ISN, I don't have to guess it. 
> Therefore, it's easier to successfully perform the attack.

Well, predicting ISN helps, but it really depends on how much volume of
data that got exchanged and the current sliding window snapshot (snduna
-- sndnxt) which really determines the acceptability of a segment.

> 
> 
> 
> > > * The counter-measure of for the SYN-based reset attack may have 
> > > missed a common heuristics for the handling of SYN segments. See 
> > > pages 86 and
> > > 87 of the UK CPNI paper on TCP security. FWIW, we argue that the 
> > > processing of SYN segments proposed in [Ramaiah et al, 
> 2008] should 
> > > apply only for connections in any of the synchronized 
> states other 
> > > than the TIME-WAIT state.
> >
> > We just followed RFC 793 as the base and the changes are made w.r.t 
> > that. TIME-WAIT may be an exception but doesn't RFC 793 already has 
> > that language correct?
> 
> Well, the timestamps was published *after* RFC 793. So RFC 
> imsply doesn't address this, because timestamps didn't exist 
> at the time.

Why are you bringing in timestamps, the huerisitic suggested by RFC 1122
applies *without* timestamps in place.

Just to be clear : The current mitigation *does* not preclude any host
to have the TIME-WAIT hueristic suggested as a MAY condition in RFC
1122. The scope of the document is to only change the language w.r.t
793.

That said, I'll leave it to the collective wisdom of the WG to comment
on this, if there is a strong consensus I don't issues to add some text.

> 
> 
> 
> > > * When it comes to TCP-based blind-connection reset 
> attacks, there's 
> > > a much more trivial -- yet not discussed before? -- 
> alternative. See 
> > > Section 11.1.3 and Section 11.1.4 in 
> draft-gont-tcp-security and the 
> > > CPNI paper 
> > > 
> (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf).
> > > These variants should, at the very least, be mentioned 
> and a pointer 
> > > provided to them as, at least in theory, are much easier 
> to exploit.
> >
> > Those sounds like some new proposals (security and precedence) 
> > different stacks would have taken different measures to 
> address this issue.
> > Anyways this is something new and hence needs more discussion and 
> > evaluation. Has these ideas been submitted in a draft to 
> TCPM? (your 
> > recent BCP document tcp-security, covers it ?)
> 
> Yes, the tcp-security I-D covers it. This stuff came as a 
> surprise while assessing RFC 793. One would expect that these 
> attacks don't work in practice--- but you never know. 
> However, IETF-wise they do...
> therefore I think it should be mentioned as another potential 
> connection-reset attack vector (*much* easier, as you don't 
> even have to guess the sequence number)

Like I said this document has been only taking about the 3 attacks from
the beginning when this document was out (5 years), I see no point in
delaying this document any further by adding new attacks without the
consensus of the WG.

Thanks,
-Anantha