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

[Vincent Roca <[e-mail]>]

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