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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 17 Apr 2017 09:21:20 -0400

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.

Issue 2 - Section 4, 5th paragraph:

Should the term "near future" be clearly defined here?

Nits
====

Page 6, first paragraph:
Drop the "to" before the word "appear"

Regards,
 Rifaat

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Apr 2017 09:22:20 -0700

Rafaat,

Thanks for the review.  Comments below.

Bob

> On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 

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.

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

> 
> 
> Nits
> ====
> 
> Page 6, first paragraph:
> Drop the "to" before the word “appear"

Thanks, will fix.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 17 Apr 2017 13:31:23 -0400

>    when data is transferred.
Sounds reasonable.

> 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

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Apr 2017 10:42:52 -0700

Rifaat,

> On Apr 17, 2017, at 10:31 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> 
> 

Good, I will include that in the next version.

> But I am still trying to make sense of the first sentence, especially the "MUST attempt" part.
> 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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 17 Apr 2017 20:06:52 -0400

Thanks Bob!

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

> the "MUST attempt" part.