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

[Joe Touch <[e-mail]>]

Hi, all,

I'd like to second all of Wes's* points below.

I don't have a problem with including the code; it may be unnecessary,
but lots of informational docs have exactly that kind of detail to
explain things.

I do agree that it would be useful to avoid the term "proposed", as the
WG consensus as I recall it was to document what was implemented and
discuss the issues thereof, but not to make a recommendation.

I also agree with Lars's suggestion (and Wes's concurrence) that it
would be useful to be explicit in the fact that this doc does not make
such a recommendation.

I won't belabor other points below; I think Wes said it nicely.

Joe

-----

* PS - anyone have a good pointer to how to turn proper nouns that end
in 's' into possessive adjectives? I found a few, and at least one
suggests that "genitive of origin" always adds the 's' ;-)

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> This is as a WG participant, not a co-chair.  As some of
> the document heritage predates me co-chairing, I'd have to
> take a very careful look at mail archives and meeting
> minutes in order to say anything about consensus in a
> co-chair role.
> 
> That said ...
> 
> I would appreciate less posturing about representing vendors
> and maintaining relevancy to them, and more focus on what
> potential action we can take to resolve the DISCUSSes.
> 
> My contributions toward that are inline below.
> 
> --
> Wes Eddy
> MTI Systems
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Fernando Gont
>> Sent: Wednesday, January 27, 2010 3:21 PM
>> To: Lars Eggert
>> Cc: [e-mail] WG
>> Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09
>>
>>
>>> 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.
>>
>> 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.
> 
> 
> When I checked on this myself, it was indeed representing
> what's been accepted into some implementations.
> 
> I believe Fernando has done the right thing at the beginning of
> section 7.2 by mentioning right away that PLPMTUD eliminates
> this vulnerability.  I did not really see strong WG consensus
> as to whether PLPMTUD should be recommended more strongly as
> a mitigation in lieu of the rest of section 7.2, 7.3, and 7.4,
> and those sections do provide useful explanation and rationale
> of what's been implemented, in my opinion.  I personally
> think PLPMTUD is a much better thing to recommend, but see
> the argument about convergence time may be valid, and the WG
> didn't seem to express strong favor in either direction on this
> matter.
> 
> *
> However, Lars is entirely right that this could be worded more
> clearly as an implemented behavior rather than a proposal that
> we're making as the WG.  This was always the WG consensus of the
> document's purpose, from what I can tell.
> *
> 
> I think one way to proceed is, for instance, to reword:
> """
>    Section 7.3 shows the proposed counter-measure in action.
>    Section 7.4 shows the proposed counter-measure in pseudo-code.
> 
>    This behavior has been implemented in NetBSD [NetBSD] and OpenBSD
>    [OpenBSD] since 2005.
> """
> into:
> """
>   Sections 7.3 and 7.4 show the behavior and psuedocode for the
>   mitigation implemented in NetBSD and OpenBSD.
> """
> and do a find-replace of the word "proposed" as appropriate in the
> rest of the section in order to convey what we really mean: that
> this is what's being done, not what TCPM necessarily says people
> need to do.
> 
> 
>>> 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?
> 
> 
> I think Lars is just asking to quickly confirm consensus in this area
> and make sure the exact text represents that consensus.
> 
> 
>>> 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.
> 
> 
> 
> They are very much welcome to approach with a proposal to
> standardize it ... however, they haven't so the topic is moot.
> None of us need to try to channel them and speak for them here;
> the list is open, and last I checked, there were hundreds of
> addresses of the form "vendor.com" subscribed.
> 
> As RFC tracks are frequently misunderstood, the sentence Lars
> proposes seems useful and uncontroversial to me.  I'm not sure
> why we can't just add it as there's no harm done by it.
> 
> 
> 
>> 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.
>>
>> 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.
> 
> 
> Veering off-topic ... can we table this type of discussion?  It's
> not conducive to resolving the questions at hand.
> 
> 
>>> 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 would agree with Fernando on this.  I expressed a similar
> concern as Lars does a year or so ago, and there didn't
> seem to be much significant feeling on this from the rest of
> the WG.  As long as this material is hedged correctly as
> explaining the implemented behavior, I think the WG consensus
> of describing implemented behavior is met.  We are just
> describing it in incredible detail rather than giving a
> high-level view.  This is not necessarily bad, I think.
> 
> 
> 
>>> 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.
>>
>> 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.
> 
> 
> Veering off track again ... please table this.
> 
> As mentioned above, I think if the section's content is hedged
> correctly as describing the implementation that exists, rather
> than a WG-proposed behavior, then we'll be within consensus.
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm