Hi, Acee, On Wed, Dec 5, 2018 at 12:07 PM Acee Lindem (acee) <[email protected]> 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 < > [email protected]> wrote: > > > > Hi, Acee, > > On Tue, Dec 4, 2018 at 6:37 PM Acee Lindem (acee) <[email protected]> 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" <[email protected]> > 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 > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
