Re: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06

[Rifaat Shekh-Yusef <[e-mail]>]

On Mon, Apr 17, 2017 at 12:22 PM, Bob Hinden <[e-mail]> wrote:

> Rafaat,
>
> Thanks for the review.  Comments below.
>
> Bob
>
> > On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef <[e-mail]>
> wrote:
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > Summary: Ready with issues
> >
> >
> > The Security Considerations section describes the possible implications
> of
> > a malicious party sending false ICMPv6 Packet Too Big messages and
> > reasonable ways to mitigate their impact.
> >
> > The section also discusses the implication of filtering valid ICMPv6
> > Packet Too Big messages, which is one of the limitation of this
> mechanism,
> > and points to a more robust alternative.
> >
> >
> > Issues
> > ======
> >
> > Issue 1 - The Security Considerations section, page 14:
> >
> > The first paragraph is discussing the case of malicious party stopping a
> > victim from receiving legitimate Packet Too Big messages. The second
> > paragraph is discussing the filtering of such packets and implies the
> > potential implication of "black holing".
> >
> > It seems to me that in both of these use cases "black holing" is
> possible,
> > and should be clearly stated as such.
>
> How about if I add the following after the two indented paragraphs
> describing the attacks:
>
>    Both of these attacks can cause a black hole connections, that is, the
>    TCP three-way handshake completes correctly but the connection hangs
>    when data is transferred.
>
>
Sounds reasonable.


>
> >
> >
> > Issue 2 - Section 4, 5th paragraph:
> >
> > Should the term "near future" be clearly defined here?
>
> I think the text is clear given the sentences that follow.  The text is
> trying not to be too descriptive given that implementations will differ.
>  It could say things like “quickly” “as soon as possible”, etc., but I
> think that’s all about the same.
>
>
Yeah, I see what you mean, which makes sense.

But I am still trying to make sense of the first sentence, especially
the "*MUST
attempt*" part.
Is the part from "a node MUST attempt" until "near future" needed?

Anyway, this is a minor issue, because as you pointed out the following
sentence clearly defines what must be done by the node.

Regards,
 Rifaat





>
> >
> > Nits
> > ====
> >
> > Page 6, first paragraph:
> > Drop the "to" before the word “appear"
>
> Thanks, will fix.
>
>
> >
> > Regards,
> >  Rifaat
> >
> >
>
>