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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Acee,

On Wed, Dec 5, 2018 at 12:07 PM Acee Lindem (acee) <[e-mail]> wrote:

> Hey Spencer,
>
> Fixed RFC references in my reply.
>

Thanks for considering my comments, and correcting the RFC references.
Anything you do to unconfuse an AD is probably a good idea!

Spencer


> On Dec 5, 2018, at 11:34 AM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>
>
> Hi, Acee,
>
> On Tue, Dec 4, 2018 at 6:37 PM Acee Lindem (acee) <[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
> :-)
>
>
>
> Luckily the flight home was a breeze compared to my 25 hour 40 minute
> flight to Hong Kong.
>
>
>
>
>
> 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]>
> 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.
>
>
>
> I read this and we’ll consider but I don’t think we’ll move things around.
> All the SR RFCs/drafts have this abstract ordering and I can’t see just
> changing this one.
>
>
>
>
>
>
>     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.
>
>
>
>
>
> We will remove the references to binding SID. I think we put the reference
> to RFC 8402 earlier in the Introduction.
>
>
>
>
>
>
>
>     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!)
>
>
>
> I see your point but “SHOULD” is already pretty strong language but we
> wouldn’t be opposed to changing it to “MUST” since an implementation
> advanced enough to support OSPFv3 SR should support RFC4552 and/or RFC7166.
> However the latter is simpler from an operational standpoint.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>     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
>
>
>
>