Subject: [secdir] Secdir review of draft-ietf-ospf-segment-routing-msd-18

From: Vincent Roca <[email-masked]>
Date: Fri, 31 Aug 2018 12:09:01 +0200

Hello,

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

The Security Considerations section refers to RFC7474 for "Security concerns for OSPF".
However, RFC7474 is limited to OSPFv2, not v3. This should be reflected here as the authors
previously explained that "OSPF means both OSPFv2 and OSPFv3" (Abstract).

I also think that a final "." is missing at the end of:
"Further security analysis for OSPF protocol is done in [RFC6863]"

Although a little bit old (2013), this Informational RFC6863 is a good reference that highlights
security issues and suggests work items to fix/mitigate them. In particular OSPFv3 security that
relies on IPsec raises deployment issues. There are other items. I don't know if the situation
has significantly changed since this RFC.

Then the authors refer to the Security Considerations sections of [RFC7770], [RFC7684] and [RFC8362].
Basically, RFC 7770 says that the Security Considerations "should be described as additional
capabilities are proposed for advertisement" and that's all.

RFC 7684 is limited to OSPFv2, and here also it is explained that:
        "OSPFv2 applications utilizing these OSPFv2 extensions must define the security
        considerations relating to those applications..."
Then there is a discussion on malformed information/TLV that should be ignored.

Finally, RFC 8362, dedicated to OSPFv3, refers to old RFCs, prior to the above RFC6863 reference.

These three RFCs are good references but they do not provide much insight unlike what the authors
suggest. I understand that: (1) security threats do exist, and (2) implementers should take care of
malformed received packets (e.g, bad TLV). This could be highlighted in this document and references
provided to support it.

Then the second paragraph quickly discusses the consequences of advertising incorrect MSD values.
The sentence is ambiguous. I understand:
        "[...]: either in a path computation failing and the service (becoming?) unavailable,
        or (in an) instantiation of a path that can't be supported by the head-end ([...])."
Am I correct? Please fix it.
Also I don't understand the definition of head-end (e.g., what does "imposition" mean?). The authors
should either be more explicit and/or refer to an architectural document.
Then, an "incorrect MSD" may refer either to a value that is either smaller or larger than it should.
What are the consequences in each case and how does it relate to the two consequences mentioned in
this paragraph?

Is there something else?
Is there a Denial of Service risk specific to this extension, or is it vulnerable to replay attacks?
I don't think so but it's worth clarifying.

Other comments:

** Intro: there's an mbiguous sentence
"In order for BGP-LS to signal MSD for all the nodes and links in the network MSD is relevant, [...]"
Do you mean "where MSD is relevant" or something else?

Regards,

  Vincent

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 31 Aug 2018 14:12:32 -0700

Hi Vincent,

Many thanks for your review!

Please see inline

For your convenience I have also published an updated document (v20), please let me know whether your concerns have been addressed and if anything else need to be added/changed

Cheers,

Jeff

From: Vincent Roca <[email-masked]>
Date: Friday, August 31, 2018 at 03:09
To: The IESG <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: Vincent Roca <[email-masked]>
Subject: Secdir review of draft-ietf-ospf-segment-routing-msd-18
Resent-From: <[email-masked]>
Resent-To: Jeff Tantsura <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "BRUNGARD, DEBORAH A" <[email-masked]>, Alvaro Retana <[email-masked]>, Acee Lindem <[email-masked]>
Resent-Date: Fri, 31 Aug 2018 03:09:08 -0700 (PDT)

Hello,

Summary: Ready with nits

[jeff] I will add RFC4552 and RFC7166 to address OSPFv3 

[jeff] fixed

[jeff] No, RFC6863 is still the main reference for OSPF security analysis

provided to support it.

[jeff] relevant text added

[jeff] would the following text work?

Advertisement of an incorrect MSD value may result:

   If the value is lower than supported - path computation failing to compute a viable path.

   If the value is larger than supported - instantiation of a path that can't be supported by the head-end (the node performing the SID imposition).

[jeff] label imposition is a commonly used term to describe PUSH function on a MPLS device, even though RFC3031 uses “PUSH” term, in general PUSH and impose are used interchangeably, I don’t think it requires any additional explanation however, would be happy to include  in the Terminology section “imposition == RFC3031 PUSH”, please let me know

[jeff] head-end is the node where label stack is being imposed (PUSHED), head-end/tail-end are common terms to describe a devices where an LSP/tunnel starts and ends – do you feel it needs further explanation?

this paragraph?

[jeff] please see above

Is there something else?

[jeff] no, will clarify 

Other comments:

[jeff] MSD is relevant to the nodes that impose the labels, “where” simplifies the sentence, added for better readability, thanks!

Regards,

  Vincent