Re: [Lsr] Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)

[Peter Psenak <[e-mail]>]

On 05/12/18 17:34 , Spencer Dawkins at IETF wrote:
> Hi, Acee,
> On Tue, Dec 4, 2018 at 6:37 PM Acee Lindem (acee) <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Spencer,
>
>     I'm replying as document shepherd.
>
>
> It's a pleasure to be talking when we're not both sleepwalking on a 777 :-)
>
> Please note that all of these are comments, so covered under "do the
> right thing".
>
>     On 12/4/18, 1:40 PM, "Spencer Dawkins"
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>          Spencer Dawkins has entered the following ballot position for
>          draft-ietf-ospf-ospfv3-segment-routing-extensions-20: No Objection
>
>          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-ospf-ospfv3-segment-routing-extensions/
>
>
>
>
>     ----------------------------------------------------------------------
>          COMMENT:
>
>     ----------------------------------------------------------------------
>
>          The Introduction would have been much clearer for me if these
>     paragraphs were
>          much closer to the top of the section - they're at the bottom
>     of the section
>          now.
>
>            This draft describes the OSPFv3 extensions required for Segment
>             Routing with MPLS data plane.
>
>             Segment Routing architecture is described in [RFC8402].
>
>             Segment Routing use cases are described in [RFC7855].
>
>          With that change, I'm not sure how much of the discussion in
>     the Introduction
>          would still be required, but do the right thing, of course.
>
>          I'd make the same suggestion for the Abstract,
>
>            Segment Routing (SR) allows a flexible definition of
>     end-to-end paths
>             within IGP topologies by encoding paths as sequences of
>     topological
>             sub-paths, called "segments".  These segments are advertised
>     by the
>             link-state routing protocols (IS-IS and OSPF).
>
>             This draft describes the OSPFv3 extensions required for Segment
>             Routing with MPLS data plane.
>
>          if it was more than two paragraphs long ...
>
>     You mean "were" since this is subjective. I'm not sure what you're
>     asking for since your comment has something to do with ordering and,
>     as you note, the abstract is two paragraphs long.
>
>
> Sorry this wasn't clear.
>
> What I meant was, the Introduction is long enough that moving the
> high-order bits to the top is helpful; the Abstract also has the
> high-order bits at the bottom, but it's a short distance to the bottom.
> If you flipped the Abstract, that might be helpful, and would match the
> Introduction, but if you don't, I think making the change in the
> Introduction would be sufficient.

ok, I made the change to Introduction section
>
>
>          I am thinking that the reference
>
>            There are additional segment types, e.g., Binding SID defined in
>             [RFC8402].
>
>          would be more useful at the beginning of Section 3, because
>     that's where you
>          list the additional segment types, but the reference is back in the
>          Introduction (with only one example of the segment types).
>
>     Actually, the Binding SID is no longer in the encodings so this
>     could be removed.
>
>
> An even better reason to remove this sentence :D ...
>
> That would put the reference to RFC 8402 in Section 3, I assume.

I removed both references to binding SID.

thanks,
Peter

>
>          I'm thinking the SHOULD in this text
>
>            Existing security extensions as described in [RFC5340] and
>     [RFC8362]
>             apply to these segment routing extensions.  While OSPFv3 is
>     under a
>             single administrative domain, there can be deployments where
>             potential attackers have access to one or more networks in
>     the OSPFv3
>             routing domain.  In these deployments, stronger authentication
>             mechanisms such as those specified in [RFC4552] or [RFC7166]
>     SHOULD
>             be used.
>
>          is not an RFC 2119 SHOULD that describes interworking, so
>     something like
>
>             In these deployments, stronger authentication
>             mechanisms such as those specified in [RFC4552] or [RFC7166] are
>             needed.
>
>     I'll defer to our AD, Alvaro. We have normative text in other
>     "Security Considerations" sections.
>
>
> Oh, sure. That wasn't my heartburn at all. My point was
>
>
>          would be better, but if this IS a SHOULD, I'm curious why you
>     wouldn't use
>          stronger authentication mechanisms if they're needed. You might
>     want to add
>          guidance about that, so it's not confused with MUST (BUT WE
>     KNOW YOU WON'T) as
>          defined in https://tools.ietf.org/html/rfc6919#section-1.
>
>
> that I'm reading the text as saying "you're more vulnerable to
> attackers, so you SHOULD use stronger authentication mechanisms, but you
> might not, for reasons left to the implementer". Is there a reason that
> you might decide not to use stronger authentication mechanisms when
> you're more vulnerable to attackers? If so, you might provide it as an
> example, so the implementers can do the right thing.
>
> (I spent enough time in the SIP community talking to product managers
> who wanted to pay for MUSTs, but didn't think they needed to pay for
> SHOULDs, that I'm perhaps overreacting to a problem you folks in RTG
> don't have. Do the right thing, of course!)
>
>          Is there another document that says things like
>
>            Implementations MUST assure that malformed TLV and Sub-TLV
>     defined in
>             this document are detected and do not provide a
>     vulnerability for
>             attackers to crash the OSPFv3 router or routing process.
>     Reception
>             of a malformed TLV or Sub-TLV SHOULD be counted and/or
>     logged for
>             further analysis.  Logging of malformed TLVs and Sub-TLVs
>     SHOULD be
>             rate-limited to prevent a Denial of Service (DoS) attack
>     (distributed
>             or otherwise) from overloading the OSPFv3 control plane.
>
>          ? This doesn't seem very SR-specific, although I'm guessing. If
>     there's a
>          broader document, I don't object to including this guidance
>     here, but adding a
>          reference to a broader document might be useful.
>
>     We do have similar text in section 5 of RFC8362. However, it is not
>     in the "Security Considerations" and the statement about
>     rate-limiting is not there. It doesn’t hurt to repeat it and it
>     provides confidence that "security" has been appropriately
>     "considered".
>
>
> Agree, and thanks for considering all my comments.
>
> Spencer
>
>
>     Thanks,
>     Acee
>
>
>