Subject: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Feb 2017 08:30:04 +0100

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 10 Feb 2017 13:28:00 +0000

Hi Leif,

Thank you for the review of the document. 

RFC 4736 (basis for this document), Security Section 9, has coverage for this aspect – “Furthermore, a head-end LSR may decide to ignore explicit notification coming from a mid-point residing in another domain.”

Thanks,
Rakesh

On 2017-02-10, 2:30 AM, "Leif Johansson" <[email-masked]> wrote:

    Reviewer: Leif Johansson

    
    	
    	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Feb 2017 15:22:12 +0100

> RFC 4736 (basis for this document), Security Section 9, has coverage for this aspect – “Furthermore, a head-end LSR may decide to ignore explicit notification coming from a mid-point residing in an…

Ah ok so trust is placed in the domain? I guess that property is
something that could be made explicit in the security considerations
(or maybe its obvious to people in the field)

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 10 Feb 2017 14:43:28 +0000

Hi Leif,

Thanks for your reply. Please see inline <RG> …

On 2017-02-10, 9:22 AM, "Leif Johansson" <[email-masked]> wrote:

<RG> Yes, this and other considerations are covered in the referenced RFCs (RFC 4736 and RFC 5920).

Thanks,
Rakesh