Skip to main content

Last Call Review of draft-ietf-ospf-segment-routing-msd-18
review-ietf-ospf-segment-routing-msd-18-secdir-lc-roca-2018-09-06-00

Request Review of draft-ietf-ospf-segment-routing-msd
Requested revision No specific revision (document currently at 25)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-08-29
Requested 2018-08-15
Authors Jeff Tantsura , Uma Chunduri , Sam Aldrin , Peter Psenak
Draft last updated 2018-09-06
Completed reviews Rtgdir Early review of -10 by Tal Mizrahi (diff)
Rtgdir Last Call review of -15 by Tal Mizrahi (diff)
Secdir Last Call review of -18 by Vincent Roca (diff)
Genart Last Call review of -17 by Paul Kyzivat (diff)
Genart Telechat review of -20 by Paul Kyzivat (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-ospf-segment-routing-msd-18-secdir-lc-roca-2018-09-06
Reviewed revision 18 (document currently at 25)
Result Has Nits
Completed 2018-09-06
review-ietf-ospf-segment-routing-msd-18-secdir-lc-roca-2018-09-06-00
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