Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09

[Lars Eggert <[e-mail]>]

Hi,

On 2010-1-27, at 22:20, Fernando Gont wrote:
>> I have one main issue. The very detailed example of the operation of 
>> the mitigation technique in Section 7.3, and especially the pseudo 
>> code that implements what the document still calls the "proposed" 
>> solutions in Section 7.4 in my opinion go beyond the WG consensus we 
>> had, which was to document and discuss the mitigation techniques 
>> implemented in current stacks.
> 
> The pseudo-code is just that: documentation of how the counter-measure
> works. While there's also verbose description of how the counter-measure
> works, I'd argue that for many of us the pseudo-code ends-up being a
> clearer explanation.

I'm not arguing that it's clearer, I'm saying that this level of details seems unnecessary for an Informational document.

> That said, this text has been in the I-D since
> draft-gont-tcpm-icmp-attacks-04.txt (circa September 5, 2005), when it
> had not yet been adopted as a wg item. I has been four and a half years
> since that, an plenty of revisions since then. And the I-D has passed WGLC.

So you're saying I should have flagged this earlier. And I probably should have. But now I'm re-reviewing the document during AD Review, and I felt this was an issue, so I'm raising it.

>> I'd be interested to hear the WG's thoughts esp. on this issue, but 
>> of course also on the rest of my comments below.
> 
> Are we kinda going back to WGLC?

No, we're not. I do realize that the document has passed WGLC with these sections in it, so if the WG tells me "this is a conscious decision, we like this text to be in there" that's fine, but I want to make sure that that's the case and not "oh, actually, this is maybe an issue." (I know that passing WGLC in the current form is an implicit OK from the WG - I'm asking for an explicit one.)

>> Section 1., paragraph 5:
>>> This document aims to raise awareness of the use of ICMP to perform
>>> a variety of attacks against TCP, and discusses several counter- 
>>> measures that eliminate or minimize the impact of these attacks. 
>>> Most of the these counter-measures can be implemented while still 
>>> remaining compliant with the current specifications, as they simply
>>> describe reasons for not taking the advice provided in the 
>>> specifications in terms of "SHOULDs", but still comply with the 
>>> requirements stated as "MUSTs".
>> 
>> Recommend to add a sentence that this document does NOT constitute an
>> IETF recommendation to implement said countermeasures, and why.
> 
> Being an informational document, it does not constitute an IETF
> recommendation.
> 
> That said, why it's not a formal IETF recommendation... that's a very
> good question, that not only me, but also vendors would like to know the
> answer.
> 
> I do recall somebody making a comment in an IETF meeting that I attended
> (back in 2005), asking "why not informational?", and we ended up
> changing from std track to informational.

We did deliberate this for issue quite a bit, if I recall correctly. In the end, I think the WG felt that that the different implemented mitigation techniques had downsides that were too serious to go for PS.

(I'm not saying I necessarily agree with this sentiment, but I think that was the decision process.)

My comment was that the document might want to explicitly say this, so readers who might wonder why this isn't PS know.

> It remains an interesting question why we insist in ignoring
> reality-based world.... (but you know I have already debated this one).
> 
> If you ask this question again, I'm afraid you'll get a response from
> me, and another one from Joe (and probably not many others). Vendors,
> and people in general working in real-world code have already applied
> most of the stuff discussed in the I-D, and probably won't bother
> getting into this type of debate.
> 
> Actually, all this endless debates about "you might receive an ICMP
> error message after five minutes... so you shouldn't implement this", or
> "it's incorrect to do this unless you know for sure you're under attack"
> is IMO far from the "E" in "IETF", and the reason many of the
> implementers we'd need to join the list, don't. We're seen as not
> belonging to reality-based world.

I don't want to restart the Informational vs. PS discussion. The WG has decided that already.

>> Section 7.3., paragraph 0:
>>> 7.3.  The counter-measure for the PMTUD attack in action
>> 
>> DISCUSS: Section 7.3 is in my opinion going into way too much detail
>> for the purposes of this ID. The extremely detailed example in 
>> Sections 7.3.1-7.3.4 should really go into a specification of the 
>> mitigation technique (for which we have no WG consensus) and is IMO 
>> not needed in this Informational document.
> 
> Again, this has been in the I-D for more than four years (these
> particular sections even predate the pseudo-code). And they document and
> explain the counter-measure. If we don't include this, the reader has to
> figure this out for himself. I don't know why we insist so much in
> making documents irrelevant, rather than useful, to the reader.

I believe the WG consensus was to document and discuss the mitigation techniques that some stacks are using in this document. I don't believe the intent was to include a detailed technical specification and pseudo code for the mitigation techniques.

IMO, those are much more appropriate for a PS specification than an Informational document. If the WG wants to recommend these techniques as PS, then it should publish them as PS, and not via an Informational document that reads like a PS document.

>> Section 7.4., paragraph 0:
>>> 7.4.  Pseudo-code for the counter-measure for the blind 
>>> performance- degrading attack
>> 
>> DISCUSS: I believe it is fully out of scope for this Informational 
>> document to include pseudo code for a mechanism that the WG has 
>> decided to not recommend as PS.
> 
> The document was adopted with this section in place, has gone through
> plenty of revisions since then (i.e., 2005), has been reviewed by
> implementers more than probably any other I-D that this working group
> has produced, and has passed WGLC with this text in place.

I know. As I said above, I want to double-check that the WG is sure that this is what they want to publish.

> This is not the first time that you seem to ignore wg consensus (it has
> happened with the draft-ietf-tcp-security already, as noted off-list at
> the time). IMO, this discourages people in general, and particularly
> implementers, to get involved in the IETF process in general, and with
> TCPM in particular.

First, I strongly disagree that I'm ignoring WG consensus in any way. It is part of my duties as AD to review the documents that are coming out of a WG in my area for issues before I forward them to the IESG, because I will need to ballot Yes on them. I've done the review, found an issue, and am asking the WG for explicit feedback.

Second, please tell me in which case you believe that I have previously ignored WG consensus. You're making a very serious accusation here, so please back it up.

Lars