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

["Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[e-mail]>]

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.