Re: [secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-09

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Thanks Rifaat for the review of this document.

Hi Deborah, Lou, Pavan,

Any thoughts on the following suggestion?

“Because the document extends RFC4090, it should add "Updates: 4090" at the top of the document.”

Thanks,
Rakesh


From: Rifaat Shekh-Yusef <[e-mail]>
Date: Tuesday, July 4, 2017 at 9:32 AM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>
Subject: [secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-09
Resent-From: <[e-mail]>
Resent-To: "=SMTP:mtaillon@cisco. com" <[e-mail]>, <[e-mail]>, "=SMTP:rgandhi@cisco. com" <[e-mail]>, Zafar Ali <[e-mail]>, <[e-mail]>, <[e-mail]>, Lou Berger <[e-mail]>, <[e-mail]>, <[e-mail]>, DEBORAH BRUNGARD <[e-mail]>, <[e-mail]>
Resent-Date: Tuesday, July 4, 2017 at 9:40 AM

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 Nits


I did not have enough background on MLPS and GMPLS and their related RFCs,
so I had to do some reading to get some familiarity with this subject to be
able to provide some reasonable review of this document.

This document builds on an existing mechanism, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels" defined in RFC4090, which defines a mechanism to
establish a backup tunnels for local LSP tunnels. One limitation of the
existing mechanism is that in some situations it might assign different
uni-directional bypass tunnels for the forward and reverse directions.

This document extends the mechanism defined in RFC4090, by adding a new
BYPASS_ASSIGNMENT subobject to the existing RECORD_ROUTE Object (RRO) used
in PATH and RESV requests, to allow the establishment of a bi-directional
bypass tunnel.

The security of the existing mechanism still applies with the new mechanism,
and the security section discusses the implications of the new subobject and
the new error associated with that, which seems reasonable.

The document also points to an MPLS/GMPLS Security Framework (RFC5920)
document that has an extensive discussion of the security of MPLS/GMPLS
network in general that also applies to this document.


Nits

Because the document extends RFC4090, it should add "Updates: 4090" at the
top of the document.

Regards,
 Rifaat