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

[Fernando Gont <[e-mail]>]

Hi, Lars,

Comments in-line.... (other comments in my next e-mail...)



> 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.



> 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?



> 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.

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.



> 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.



> 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.

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