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

[Bob Hinden <[e-mail]>]

Rifaat,

> On Apr 17, 2017, at 10:31 AM, Rifaat Shekh-Yusef <[e-mail]> wrote:
> 
> 
> 
> 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.

Good, I will include that in the next version.

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

Right, it’s a lead in to:

   The node MUST
   reduce the size of the packets it is sending along the path.

Thanks,
Bob