Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05

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

>-----Original Message-----
>From: Fernando Gont [mailto:[e-mail]] On
>Behalf Of Fernando Gont
>Sent: Thursday, June 11, 2009 4:30 AM
>Hello, Wes,
>
>> As both a WG-participant and co-chair, I think that the
>> Appendix A explanations of which ICMPs need to be paid
>> attention to because some of them say things that I'm
>> not sure are totally supported by prior RFCs.
>
>Any specific issues?


I'll go one-by-one through them and follow up with any in
addition to the one we already started talking about:


>> For
>> instance, I'm not certain that setting the DF bit is
>> only possible for hosts that support PMTUD ... is there
>> a reference for that?
>
>What's the reason for setting the DF flag for IP packets carrying TCP
>segments if you don't implement PMTUD?


I know of a number of embedded OS kernels and real-time systems
that either don't implement IP reassembly or disable it.  Some
of the stacks geared towards real-time will also set DF on the
packets that they send as the frag/reassembly is presumed to be
an impediment to guaranteeing their delay bounds.


>> Further, it discusses ambiguity
>> in 1122, that we should be clarifying in the main text
>> rather than an appendix, I think ... what does the rest
>> of the WG think?
>
>The appendix was at some point part of the main text. I moved the text
>into an appendix probably on request of somebody, but not because I
>thought the text should be there. So I have no problem moving the
>entirre appendix (or part of it) back into the main part of the
>document.


Oh, I didn't realize we'd already juggled it around :).
It makes sense to me to analyze the different message
types this way as motivation for the recommendations on
how to treat them, which is why I expected it to be in
the body, but if there was already consensus to have it
as an appendix, then that's fine too.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------