Subject: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Aug 2017 10:34:45 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-teas-gmpls-lsp-fastreroute-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

What stops me from just providing a random IP address
that I don't control in BYPASS_ASSIGNMENT and thus
causing them to get spammed? I am assuming there are
mechanisms to prevent them, but it's not immediately
clear to me what those are, so they at minimum need
to spelled out in security considerations. This section
from RFC 4090 is not encouraging:

   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RSVP] remain
   relevant.

   Note that the facility backup method requires that a PLR and its
   selected merge point trust RSVP messages received from each other.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

You refer to Figure 2 on page 3 and it appears on page 12.
Probably either you should move it up or make a copy.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 2 Aug 2017 18:32:02 +0000

Hi Eric,

Thank you for the review and your comments. Please see in-line with <RG>.

On 2017-08-02, 1:34 PM, "Eric Rescorla" <[email-masked]> wrote:

    

    

<RG> Ok, how about adding following text in the security section?

“The security considerations pertaining to the original RSVP protocol [RFC2205] as well as Fast Reroute procedures described in [RFC4090] remain relevant to the updates in this document.”

    

<RG> Ok, we can fix it as part of the next edits.

Thanks,
Rakesh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Aug 2017 12:44:28 -0700

On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> “The security considerations pertaining to the original RSVP protocol
> [RFC2205] as well as Fast Reroute procedures described in [RFC4090] remain
> relevant to the updates in this document.”
>

I'm really looking for something subtantive, rather than just a pointer.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 2 Aug 2017 20:59:10 +0000

Hi Eric,

Please see inline with <RG2>

From: Eric Rescorla <[email-masked]>
Date: Wednesday, August 2, 2017 at 3:44 PM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, DEBORAH BRUNGARD <[email-masked]>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT)

On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

On 2017-08-02, 1:34 PM, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

    to spelled out in security considerations.

<RG2> As mentioned in the RFC4090, “PLR and MP trust the RSVP messages received from each other”. We can add this text in the document.
“If a MP does not find a matching bypass tunnel with given source and destination addresses locally, it ignores the BYPASS_ASSIGNMENT sub-object.”  Due to this, security risk introduced is minimal.
Thanks,
Rakesh

This section

Thanks,
Rakesh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Aug 2017 14:04:49 -0700

That seems fine

On Wed, Aug 2, 2017 at 1:59 PM, Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> *From: *Eric Rescorla <[email-masked]>
> *Date: *Wednesday, August 2, 2017 at 3:44 PM
> *To: *"=SMTP:rgandhi@cisco. com" <[email-masked]>
> *Cc: *The IESG <[email-masked]>, "draft-ietf-teas-gmpls-lsp-
> [email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, DEBORAH BRUNGARD <
> [email-masked]>
> *Subject: *Re: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10:
> (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgandhi) <
> [email-masked]> wrote:
>
> Hi Eric,
>
> <RG2> As mentioned in the RFC4090, “PLR and MP trust the RSVP messages
> received from each other”. We can add this text in the document.
>
> “If a MP does not find a matching bypass tunnel with given source and
> destination addresses locally, it ignores the BYPASS_ASSIGNMENT
> sub-object.”  Due to this, security risk introduced is minimal.
>
> Thanks,
>
> Rakesh
>
>
>
>
>
>
>
> This section

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 2 Aug 2017 21:20:44 +0000

Thanks Eric. FYI, Will update the Security Section as following that incorporates your suggestions.

“This document introduces a new BYPASS_ASSIGNMENT subobject for the RECORD_ROUTE Object that is carried in an RSVP signaling message.  Thus in the event of the interception of a signaling message, more information about LSP's fast reroute protection can be deduced than was previously the case.  This is judged to be a very minor security risk as this information is already available by other means.  If a MP does not find a matching bypass tunnel with given source and destination addresses locally, it ignores the BYPASS_ASSIGNMENT subobject.  Due to this, security risk introduced by inserting a random address in this subobject is minimal.  The Notify message for FRR Bypass Assignment Error defined in this document does not result in tear-down of the protected LSP and is not service affecting.

Security considerations for RSVP-TE and GMPLS signaling extensions are covered in [RFC3209<https://tools.ietf.org/html/rfc3209>] and [RFC3473<https://tools.ietf.org/html/rfc3473>].  Further, general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [RFC5920<https://tools.ietf.org/html/rfc5920>].  This document updates the mechanisms defined in [RFC4090], which also discusses related security measures and are also applicable to this document.  As specified in [RFC4090], a PLR and its selected merge point trust RSVP messages received from each other.  The security considerations pertaining to the original RSVP protocol [RFC2205] also remain relevant to the updates in this document.”

Thanks,
Rakesh

Date: Wednesday, August 2, 2017 at 5:04 PM

That seems fine

On Wed, Aug 2, 2017 at 1:59 PM, Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 2, 2017 at 3:44 PM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, DEBORAH BRUNGARD <[email-masked]<mailto:[email-masked]>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT)

This section

Thanks,
Rakesh