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

From: Spencer Dawkins <[email-masked]>
Date: Tue, 04 Dec 2018 10:40:01 -0800

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 ...

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).

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.

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.

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Dec 2018 00:37:12 +0000

Hi Spencer, 

I'm replying as document shepherd. 

On 12/4/18, 1:40 PM, "Spencer Dawkins" <[email-masked]> wrote:

    

    

    

    

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. 

    

Actually, the Binding SID is no longer in the encodings so this could be removed.

    

I'll defer to our AD, Alvaro. We have normative text in other "Security Considerations" sections. 

    

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". 

Thanks,
Acee

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 5 Dec 2018 10:34:07 -0600

Hi, Acee,

> 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".

>     Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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.

> Actually, the Binding SID is no longer in the encodings so this could be

An even better reason to remove this sentence :D ...

That would put the reference to RFC 8402 in Section 3, I assume.

> Considerations" sections.

Oh, sure. That wasn't my heartburn at all. My point was

>     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!)

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Dec 2018 18:00:00 +0000

Hey Spencer,

On Dec 5, 2018, at 11:34 AM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Acee,
On Tue, Dec 4, 2018 at 6:37 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,

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" <[email-masked]<mailto:[email-masked]>> wrote:

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.

We will remove the references to binding SID. I think we put the reference to RFC 8402 earlier in the Introduction.

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 RFC5340 or RFC8362. However the latter is simpler from an operational standpoint.

Thanks,
Acee

Spencer

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 06 Dec 2018 12:22:17 +0100

On 05/12/18 17:34 , Spencer Dawkins at IETF wrote:
>     On 12/4/18, 1:40 PM, "Spencer Dawkins"
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     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.
>
> 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
> That would put the reference to RFC 8402 in Section 3, I assume.

I removed both references to binding SID.

thanks,
Peter

> 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!)
>
>     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".
>
>

---

From: "Thomas Beaver" <[email-masked]>
Date: Thu, 6 Dec 2018 09:42:28 -0500

Personally, I think the structure of this draft reads perfectly fine. The referenced RFCs for use case and architecture were introduced at a point where the reader’s interest in more background information would naturally come into play. I think we should probably focus on more of the technical aspects, or specifics that may need clarification; In contrast to restructuring unnecessarily.

Regards,

Thomas Beaver

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 5, 2018 1:00 PM
To: Spencer Dawkins at IETF <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; IESG <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Lsr] Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)

Hey Spencer, 

On Dec 5, 2018, at 11:34 AM, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Acee, 

On Tue, Dec 4, 2018 at 6:37 PM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Spencer, 

 

On 12/4/18, 1:40 PM, "Spencer Dawkins" <[email-masked] <mailto:[email-masked]> > wrote:

Sorry this wasn't clear. 

 

 

Thanks,

Acee

Spencer

Thanks,
Acee