Skip to main content

Last Call Review of draft-ietf-spring-oam-usecase-06
review-ietf-spring-oam-usecase-06-secdir-lc-takahashi-2017-06-30-00

Request Review of draft-ietf-spring-oam-usecase
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-06-30
Requested 2017-06-16
Authors Ruediger Geib , Clarence Filsfils , Carlos Pignataro , Nagendra Kumar Nainar
I-D last updated 2017-06-30
Completed reviews Rtgdir Last Call review of -06 by Joel M. Halpern (diff)
Opsdir Last Call review of -06 by Joel Jaeggli (diff)
Genart Last Call review of -06 by Pete Resnick (diff)
Secdir Last Call review of -06 by Takeshi Takahashi (diff)
Secdir Telechat review of -09 by Takeshi Takahashi (diff)
Assignment Reviewer Takeshi Takahashi
State Completed
Request Last Call review on draft-ietf-spring-oam-usecase by Security Area Directorate Assigned
Reviewed revision 06 (document currently at 10)
Result Has nits
Completed 2017-06-30
review-ietf-spring-oam-usecase-06-secdir-lc-takahashi-2017-06-30-00
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.

 

[General summary]

This document has small nits.

 

[Clarification Questions]

In the "Security Considerations" section, the draft says that "some
fundamental MPLS security properties need to be discussed."

It would be nicer if you could elaborate more details of the "properties" in
the section or put some reference that describes the details.

 

The "Security Considerations" section in RFC 4379 says, "Overall, the
security needs for LSP ping are similar to those of ICMP" and elaborates
issues such as DoS attack and spoofing.

Is the proposed MPLS monitoring system free from these issues?

Since this draft discusses the path monitoring system in coparison with RFC
4379 from time to time, it would be nice if these security issues are also
addressed. (Indeed, I could not find the term "denial" in this document at
all.)

 

Thank you.

Take