Skip to main content

Last Call Review of draft-ietf-mpls-lsp-ping-relay-reply-04
review-ietf-mpls-lsp-ping-relay-reply-04-secdir-lc-turner-2014-12-18-00

Request Review of draft-ietf-mpls-lsp-ping-relay-reply
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-13
Requested 2014-10-02
Authors Luo Jian , Lizhong Jin , Thomas Nadeau , George Swallow
I-D last updated 2014-12-18
Completed reviews Genart Last Call review of -04 by Joel M. Halpern (diff)
Genart Last Call review of -10 by Joel M. Halpern (diff)
Secdir Last Call review of -04 by Sean Turner (diff)
Opsdir Last Call review of -04 by Carlos Pignataro (diff)
Opsdir Last Call review of -10 by Carlos Pignataro (diff)
Rtgdir Early review of -10 by Andrew G. Malis (diff)
Assignment Reviewer Sean Turner
State Completed
Request Last Call review on draft-ietf-mpls-lsp-ping-relay-reply by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 11)
Result Has nits
Completed 2014-12-18
review-ietf-mpls-lsp-ping-relay-reply-04-secdir-lc-turner-2014-12-18-00
Do not be alarmed.  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 with the intent
of improving security requirements and considerations in IETF drafts.
Comments not addressed in last call may be included in AD reviews
during the IESG review.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Version: 06
Summary: Ready with some non-security/non-privacy nits.

Ping mechanisms always give me the heebie-jeebies [1]
because of the security concerns associated with them (i.e., DoS, 
spoofing/hijacking/etc., and unauthorized disclosure).  This document
specifies an extension to the existing ECHO mechanism in RFC 4379
and it does nothing to address these concerns in fact it increases the
concerns wrt DoS. *BUT* it rightly points this increase exposure out in
the security considerations section.  It provides remediation techniques
similar to those specified in RFC 4379: rate limit and validate source
against access list.  This draft, unlike RFC 4379, does recommend that
operators wishing to not disclose their nodes blank the address out in
the TLV.  This draft also refers to RFC 4379 for additional security
considerations.

WARNING - questions and nits follow:

s3 - 1st paragraph: Relayed Echo Reply “replaces” Echo Reply - does this
mean you’re deprecating the use of “Echo Reply”?

s4.1: Is the outermost label allowed to be set to 255 to support the
“ping” mode or must it always be set to 1, 2, etc. to support “traceroute"
mode - as described in RFC 4379 s4.3?   I know s5 is just an example
but it really looks like this extension is just supposed to be for fault
isolation.

s4.1 - last paragraph: Does the next initiator put it’s address in the stack
before or after the previous initiator?  I assume it’s after, but I maybe
missed that part?  Would be good to state that explicitly.

Cheers,
spt

[1] 

http://en.wikipedia.org/wiki/Heebie-jeebies_

(idiom)