Skip to main content

Last Call Review of draft-ietf-teas-p2mp-loose-path-reopt-08
review-ietf-teas-p2mp-loose-path-reopt-08-secdir-lc-johansson-2017-02-16-00

Request Review of draft-ietf-teas-p2mp-loose-path-reopt
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-01-17
Requested 2017-01-03
Authors Tarek Saad , Rakesh Gandhi , Zafar Ali , Robert H. Venator , Yuji Kamite
I-D last updated 2017-02-16
Completed reviews Rtgdir Early review of -07 by Joel M. Halpern (diff)
Genart Last Call review of -08 by Dan Romascanu (diff)
Secdir Last Call review of -08 by Leif Johansson (diff)
Assignment Reviewer Leif Johansson
State Completed
Request Last Call review on draft-ietf-teas-p2mp-loose-path-reopt by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 09)
Result Has nits
Completed 2017-02-16
review-ietf-teas-p2mp-loose-path-reopt-08-secdir-lc-johansson-2017-02-16-00
Reviewer: Leif Johansson
Review result: Minor issues

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 draft describes a way to handle groupings of large sets of sub-
LSPs in a P2MP GMPLS setup for the purpose of traffic engineering
(re-)optimization by introducing the concept of "fragment identifiers"

Let me state up front that the topic is outside my normal area of
expertise. My only question is this: could an attacker fake messages
that would (to the receiver ingress node) appear to be part of a
fragmented group of sub-LSPs so as to trigger a full re-computation
of the tree? The text in the last but one paragraph of 4.2 would
seem to suggest that this attack is a possibility. At "worst" this
would be a denial-of-service attack but it should perhaps be addressed
in the security considerations section anyway.
	
	Cheers Leif