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

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

Thanks Bob!

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

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