Subject: [secdir] Secdir telechat review of draft-wu-l3sm-rfc8049bis-09

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 27 Nov 2017 13:38:20 -0800

Reviewer: Rifaat Shekh-Yusef
Review result: Ready

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.

The document defines a YANG data model that defines service configuration
elements that can be used in communication protocols between customers
and network operators. Those elements can also be used as input to
automated control and configuration applications.

The authors addressed my comments on version -05 of the document.
I have not further comments on this version of the draft.

Regards.
 Rifaat

---

From: Derrell Piper <[email-masked]>
Date: Mon, 27 Nov 2017 15:43:18 -0800

Reviewer: Derrell Piper
Review result: ready with nits

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.

This document describes a new version of tracroute designed for multicast.  In
the multicast environment, traceroute functions in reverse with each router on
the path back towards the client adding diagnostic information along the way.
This information can be used to diagnose a variety of network problems,
including packet loss (congestion) and configuration problems (TTL).

The security considerations section discusses a variety of requirements and
suggestions for multicast routers and the protocol includes an ADMIN_PROHIB
flag which can be used at a border router to prevent multicast traceroute from
being able to probe network topology or to perform traffic analysis.

This appears to be a useful diagnostic utility and the obvious security
concerns seem to have been addressed.

nits:

page 33, section 9.3 and 9.4

MAY should be capitalized in these two sections.

Derrell

---

From: Derrell Piper <[email-masked]>
Date: Mon, 27 Nov 2017 16:23:51 -0800

[Apologies for the repost, hopefully this one doesn’t wrap.  I also didn’t
include the “.all” suffix on the previous email.]

Reviewer: Derrell Piper

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.

This document describes a new version of tracroute designed for
multicast.  In the multicast environment, traceroute functions in
reverse with each router on the path back towards the client adding
diagnostic information along the way.  This information can be used to
diagnose a variety of network problems, including packet loss
(congestion) and configuration problems (TTL).

The security considerations section discusses a variety of requirements
and suggestions for multicast routers and the protocol includes an
ADMIN_PROHIB flag which can be used at a border router to prevent
multicast traceroute from being able to probe network topology or to
perform traffic analysis.

nits:

Derrell