Skip to main content

Telechat Review of draft-ietf-6man-rfc1981bis-06

Request Review of draft-ietf-6man-rfc1981bis
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-04-25
Requested 2017-04-07
Authors Jack McCann <>, Stephen E. Deering <>, Jeffrey Mogul <>, Bob Hinden
Draft last updated 2017-04-17
Completed reviews Intdir Early review of -03 by Donald E. Eastlake 3rd (diff)
Secdir Last Call review of -04 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Opsdir Last Call review of -04 by Susan Hares (diff)
Tsvart Telechat review of -04 by Dr. Joseph D. Touch (diff)
Rtgdir Last Call review of -06 by Ines Robles (diff)
Secdir Telechat review of -06 by Rifaat Shekh-Yusef (diff)
Genart Telechat review of -06 by Stewart Bryant (diff)
Assignment Reviewer Rifaat Shekh-Yusef
State Completed
Review review-ietf-6man-rfc1981bis-06-secdir-telechat-shekh-yusef-2017-04-17
Reviewed revision 06 (document currently at 08)
Result Has Issues
Completed 2017-04-17
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.


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?


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