Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Sun, Sep 02, 2018 at 02:28:58PM -0700, Ahmed Bashandy wrote:
> It seems like it was some editing error
> 
> 
> I uploaded version 15 and oput back the parapgraph

Thanks, but I think there is still an editing error, e.g., "Because this document
recognizes that reachability, which presents a different risk profile." is
not a complete sentence.  (I assume this is an extra pasted line in the
original source format, though the datatracker only shows .txt and .pdf so
I can't check for myself.)

-Benjamin

> 
> Ahmed
> 
> 
> 
> On 7/26/18 1:27 PM, Benjamin Kaduk wrote:
> > Hi Ahmed,
> >
> > Thanks for posting the update (and sorry for only getting to it now).
> >
> > The two specific points I raised in my DISCUSS ballot are properly
> > addressed, but before I go clear that I was hoping you could help me
> > remember why the following text was removed when going from -13 to -14:
> >
> >     [...] Because this document recognizes that
> >     miscofiguration and/or programming may result in false or conflicting
> >     label binding advertisements, thereby compromising traffic
> >     forwarding, the document recommends strict configuration/
> >     programmability control as well as montoring the SID advertised and
> >     log/error messages by the operator to avoid or at least significantly
> >     minimize the possibility of such risk.
> >
> > I couldn't find anything in my email history that helped jog my memory.
> >
> > Thanks,
> >
> > Benjamin
> >
> > On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote:
> >> Hi,
> >>
> >> I just posted version 14
> >> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt
> >>
> >> Thanks
> >>
> >> Ahmed
> >>
> >>
> >>
> >> On 7/10/18 7:11 AM, Benjamin Kaduk wrote:
> >>> Hi Bruno,
> >>>
> >>> Thanks for the additional clarifications in the suggested text -- it looks
> >>> good to me, so you and Ahmed should please go ahead with it (once
> >>> submissions open up again).
> >>>
> >>> -Benjamin
> >>>
> >>> On Tue, Jul 10, 2018 at 12:49:28PM +0000, [e-mail] wrote:
> >>>> Hi Benjamin,
> >>>>
> >>>> Thanks for the discussion.
> >>>> Please see inline [Bruno2]
> >>>>
> >>>>> From: Benjamin Kaduk [mailto:[e-mail]]
> >>>>    > Sent: Tuesday, July 10, 2018 12:53 AM
> >>>>    > On Mon, Jul 09, 2018 at 12:36:20PM +0000, [e-mail] wrote:
> >>>>    > > Hi Benjamin,
> >>>>    > >
> >>>>    > > Thanks for your comments.
> >>>>    > > Please see inline another addition to Ahmed's answer. [Bruno]
> >>>>    > >
> >>>>    > > > From: Ahmed Bashandy [mailto:[e-mail]]
> >>>>    > >  > Sent: Monday, July 09, 2018 2:30 AM
> >>>>    > > >
> >>>>    > >  > Hi
> >>>>    > >  > Thanks for the review
> >>>>    > >  >
> >>>>    > >  > See reply to the comment at #Ahmed
> >>>>    > >  >
> >>>>    > >  > Ahmed
> >>>>    > >  >
> >>>>    > >  >
> >>>>    > >  > On 6/20/18 9:40 AM, Benjamin Kaduk wrote:
> >>>>    > >  > > Benjamin Kaduk has entered the following ballot position for
> >>>>    > >  > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss
> >>>>    > >  > >
> >>>>    > >  > > 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-spring-segment-routing-ldp-interop/
> >>>>    > >  > >
> >>>>    > >  > >
> >>>>    > >  > >
> >>>>    > >  > > ----------------------------------------------------------------------
> >>>>    > >  > > DISCUSS:
> >>>>    > >  > > ----------------------------------------------------------------------
> >>>>    > >  > >
> >>>>    > >  > > I may be missing something, but I don't see anything that says whether the
> >>>>    > >  > > preference field introduced in Section 3.2.3 uses larger values or smaller
> >>>>    > >  > > values for more-preferred SRMSes.
> >>>>    > >  > #Ahmed:
> >>>>    > >  > If I understand this statement correctly, the concern is about which
> >>>>    > >  > label(s) get assigned to which prefix(es). This concern is addressed as
> >>>>    > >  > follows
> >>>>    > >  >
> >>>>    > >  >  From the MPLS architecture point of view, there is nothing wrong in
> >>>>    > >  > having multiple labels for the same prefix. Segment routing in general
> >>>>    > >  > and this document in particular did not introduce this behavior nor did
> >>>>    > >  > they prohibit/restrict/relax it. For example, an implementation that
> >>>>    > >  > allows the operator to locally assign multiple local labels to the same
> >>>>    > >  > prefix may continue to apply this behavior whether the platform supports
> >>>>    > >  > segment routing or not, in which case it is up to the implementation
> >>>>    > >  > and/or the configuration affecting the MPLS forwarding plane to specify
> >>>>    > >  > how to behave when multiple labels are assigned to the same prefix. Such
> >>>>    > >  > behavior is a general MPLS behavior that outside the scope of and is not
> >>>>    > >  > modified by segment routing.
> >>>>    > >  >
> >>>>    > >  > However the opposite, where the same label gets assigned to multiple
> >>>>    > >  > prefixes resulting in label collision is problematic. This document
> >>>>    > >  > prohibits label collision resulting from the use of SRMS (which is
> >>>>    > >  > introduced by this document) in the first bullet starting at the 3rd
> >>>>    > >  > line of page 12:
> >>>>    > >  >    "-  If there is an incoming label collision as specified in
> >>>>    > >  >        [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified
> >>>>    > >  >        in [I-D.ietf-spring-segment-routing-mpls] to resolve the
> >>>>    > >  >        collision.""
> >>>>    > >  >
> >>>>    > >  > >
> >>>>    > >  > >
> >>>>    > >  > > The introduction of the SRMS is also introducing a new way for a protocol
> >>>>    > >  > > participant to make claims about route prefixes directed at "third parties"
> >>>>    > >  > > (non-MS, non-MC routers).  While routing protocols in general do require high
> >>>>    > >  > > levels of trust in all participants in order for proper routing to occur, this
> >>>>    > >  > > addition seems to create a "first among equals" situation that could be called
> >>>>    > >  > > out more clearly in the security considerations.  (I do appreciate that the
> >>>>    > >  > > requirement for preferring SIDs advertised in prefix reachability
> >>>>    > >  > > advertisements over those advertised in mapping server advertisements does help
> >>>>    > >  > > alleviate some of the risk.)
> >>>>    > >
> >>>>    > > [Bruno]
> >>>>    > > 1) As the SID attached to the prefix reachability is more preferred than the SID advertised by the
> >>>>    > SRMS, I would kind of argue that the SRMS is more "last among equals" :-)
> >>>>    > > 2) I agree that routing protocols, especially Link State Internal Routing Protocols, do require high
> >>>>    > levels of trusts among participants. In particular, please note that any node can already advertise
> >>>>    > any IP prefix (with any attached SID), and with any metric/cost, hence attracting the traffic. In this
> >>>>    > regards, I don't really see an increased risk in IGP routing.
> >>>>    >
> >>>>    > I don't really see an increased risk per se, either (since all routers can
> >>>>    > break routing in all sorts of ways), but I do see a new mechanism by which
> >>>>    > certain routers can cause routing breakage.  So I was thinking "first among
> >>>>    > equals" in terms of "more ways to break things", not "can break things with
> >>>>    > a larger magnitude of breakage".  You are right that the preference order
> >>>>    > that Ahmed described does mean that this new "mechanism for breakage" is
> >>>>    > only applicable when there are no explicit prefix-SID advertisements
> >>>>    > received via the IGP.  So in that sense this new mechanism for breakage is
> >>>>    > "last among equals", as you say, because it can only take effect if the IGP
> >>>>    > leaves room for it.
> >>>>    
> >>>> [Bruno2] Ack; I believe we are in sync.
> >>>>    
> >>>>    > > 3) I agree that SRMS allows for a "centralized" SID advertisement. I personally don't feel that this
> >>>>    > is more risky than a "centralized" BGP Route Reflector. However, I'm not against raising this in the
> >>>>    > security consideration section.
> >>>>    > > Please see below a proposed text. Please comment/propose text as required.
> >>>>    > >
> >>>>    > > OLD:
> >>>>    > >  This document introduces another form of label binding
> >>>>    > >    advertisements.  The security associated with these advertisement is
> >>>>    > >    part of the security applied to routing protocols such as IS-IS
> >>>>    > >    [RFC5304] and OSPF [RFC5709] which both optionally make use of
> >>>>    > >    cryptographic authentication mechanisms.  This document also
> >>>>    > >    specifies a mechanism by which the ill effects of advertising
> >>>>    > >    conflicting label bindings can be mitigated.
> >>>>    > >
> >>>>    > > NEW:
> >>>>    > >    This document introduces another form of label binding
> >>>>    > >    advertisements. The security associated with these advertisements is
> >>>>    > >    part of the security applied to routing protocols such as IS-IS
> >>>>    > >    [RFC5304] and OSPF [RFC5709] which both optionally make use of
> >>>>    > >    cryptographic authentication mechanisms.
> >>>>    > >    This form of advertisement is more centralized, on behalf of the node advertising the IP
> >>>>    > reachability.
> >>>>    > >    This document also
> >>>>    > >    specifies a mechanism by which the ill effects of advertising
> >>>>    > >    conflicting label bindings can be mitigated. In particular, advertisements from the node
> >>>>    > advertsising the IP reachability is more preference than the centralized one.
> >>>>    >
> >>>>    > I think that's enough to resolve my DISCUSS point.  I would prefer if there
> >>>>    > was a little bit more text, such as "more centralized, on behalf of the
> >>>>    > node advertising the IP reachability, which presents a different risk
> >>>>    > profile than existing mechanisms for distributing label bindings", but your
> >>>>    > version does cover the key point.
> >>>>
> >>>> [Bruno2] ok. Proposed NEW2:
> >>>>
> >>>> This document introduces another form of label binding
> >>>> advertisements. The security associated with these advertisements is
> >>>> part of the security applied to routing protocols such as IS-IS
> >>>> [RFC5304] and OSPF [RFC5709] which both optionally make use of
> >>>> cryptographic authentication mechanisms.
> >>>> This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile.
> >>>> This document also
> >>>> specifies a mechanism by which the ill effects of advertising
> >>>> conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one.
> >>>>
> >>>>
> >>>>
> >>>> In short, I used your proposed text but removed " than existing mechanisms for distributing label bindings" as this could be read as "LDP". We could add more text to distinguish, but IMO the current text seems fine.
> >>>>
> >>>>
> >>>>    >  (And to be clear, I am not trying to say
> >>>>    > that the centralized risk is better or worse in all cases; it's just
> >>>>    > different, so we should call that out to the reader and inform their decision
> >>>>    > making.)
> >>>>
> >>>> [Bruno2] In sync. I agree with you that we should call that out to the reader and inform their decision making. Thanks for bringing the comment.
> >>>> I'll work with Ahmed, to have the draft reflect this, as he has the pen.
> >>>>
> >>>> Thanks,
> >>>> Bruno
> >>>>
> >>>>    
> >>>>    > Thanks,
> >>>>    >
> >>>>    > Benjamin
> >>>>    >
> >>>>    > >
> >>>>    > > Thanks,
> >>>>    > > --Bruno
> >>>>    > >
> >>>>    > >  > #Ahmed:
> >>>>    > >  > If I understand your comment, the concern is about
> >>>>    > >  > "first-come-first-serve" behavior. I believe this concern is addressed
> >>>>    > >  > as follows
> >>>>    > >  > (1) The sentence starting at the fourth line of the second paragraph in
> >>>>    > >  > page 10 says:
> >>>>    > >  >     For a given prefix, if an MC receives an SR mapping advertisement
> >>>>    > >  >     from a mapping server and also has received a prefix-SID
> >>>>    > >  >     advertisement for that same prefix in a prefix reachability
> >>>>    > >  >     advertisement, then the MC MUST prefer the SID advertised in the
> >>>>    > >  >     prefix reachability advertisement over the mapping server
> >>>>    > >  >     advertisement i.e., the mapping server advertisment MUST be ignored
> >>>>    > >  >     for that prefix.
> >>>>    > >  >
> >>>>    > >  > (2) The last bullet at the bottom of page 11 says:
> >>>>    > >  >     -  For any prefix for which it did not receive a prefix-SID
> >>>>    > >  >        advertisement, the MCC applies the SRMS mapping advertisments with
> >>>>    > >  >        the highest preference.
> >>>>    > >  >
> >>>>    > >  > (3) The first bullet near the top pf page 12 says:
> >>>>    > >  >     -  If there is an incoming label collision as specified in
> >>>>    > >  >        [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified
> >>>>    > >  >        in [I-D.ietf-spring-segment-routing-mpls] to resolve the
> >>>>    > >  >        collision.
> >>>>    > >  >
> >>>>    > >  > So for the same set of received advertisements (SRMS advertisements,
> >>>>    > >  > prefix-SID advertisements, or combination of both), the same set of
> >>>>    > >  > labels will be assigned to the same prefix. As mentioned in my previous
> >>>>    > >  > comments, if multiple labels get assigned to the same prefix, the
> >>>>    > >  > behavior is not related to segment routing
> >>>>    > >  >
> >>>>    > >  > Regarding placing a comment in the security section, IMO a specification
> >>>>    > >  > of which advertisement(s) to use when receiving multiple (conflicting or
> >>>>    > >  > non-conflicting) advertisements has nothing to do with security. It is
> >>>>    > >  > an externally visible protocol(s) behavior that should be specified in
> >>>>    > >  > the sections covering the protocol(s) themselves rather than security
> >>>>    > >  > consideration of the protocol(s).
> >>>>    > >  >
> >>>>    > >  > But if you still think there is a need to mention something in the
> >>>>    > >  > security section, a suggestion from your side will be greatly appreciated .
> >>>>    > >  > >
> >>>>    > >  > >
> >>>>    > >  > > ----------------------------------------------------------------------
> >>>>    > >  > > COMMENT:
> >>>>    > >  > > ----------------------------------------------------------------------
> >>>>    > >  > >
> >>>>    > >  > > I support Alissa's suggestion about the text covering cryptographic authentication.
> >>>>    > >  > #Ahmed: I modified the statement as Alissa suggested in version 14 that
> >>>>    > >  > will be published in the next 1-2 days
> >>>>    > >  > >
> >>>>    > >  > > "[100,300]" and "(100,200)" are each used as an example SRGB.  In
> >>>>    > >  > > some contexts the round versus square brackets indicate a
> >>>>    > >  > > distinction between "closed" (includes endpoints) and "open" (does
> >>>>    > >  > > not include endpoints) intervals.  If there's no need to make such a
> >>>>    > >  > > distinction, I suggest standardizing one one format.
> >>>>    > >  > #Ahmed: I changed both of them to use [] in version because we mean
> >>>>    > >  > inclusive
> >>>>    > >  > >
> >>>>    > >  > > As was mentioned in the secdir review, it would be good to expand FEC and LFA on first
> >>>>    > usage.
> >>>>    > >  > #Ahmed: Corrected in version 14 that will be published in the next 1-2 days
> >>>>    > >  > >
> >>>>    > >  > > Section 1
> >>>>    > >  > >
> >>>>    > >  > >     Section 2 describes the co-existence of SR with other MPLS Control
> >>>>    > >  > >     Plane. [...]
> >>>>    > >  > >
> >>>>    > >  > > nit: "other MPLS Control Plane" seems to be an incomplete compound noun
> >>>>    > >  > > -- is it other control plane technologies that are being considered?
> >>>>    > >  > #Ahmed: I added "protocols" in version 14 to clarify that
> >>>>    > >  > >
> >>>>    > >  > > Section 2
> >>>>    > >  > >
> >>>>    > >  > >     Note that this static label allocation capability of the label
> >>>>    > >  > >     manager exists for many years across several vendors and hence is not
> >>>>    > >  > >     new.  Furthermore, note that the label-manager ability to statically
> >>>>    > >  > >     allocate a range of labels to a specific application is not new
> >>>>    > >  > >     either. [...]
> >>>>    > >  > >
> >>>>    > >  > > nits: "has existed", "label-manager's ability".
> >>>>    > >  > #Ahmed: Corrected (thanks a lot)
> >>>>    > >  > >
> >>>>    > >  > > Section 2.1
> >>>>    > >  > >
> >>>>    > >  > >     MPLS2MPLS refers the forwarding behavior where a router receives an
> >>>>    > >  > >     labeled packet and switches it out as a labeled packet.  Several
> >>>>    > >  > >
> >>>>    > >  > > nit: "refers to", "a labeled packet"
> >>>>    > >  > #Ahmed: Corrected
> >>>>    > >  > >
> >>>>    > >  > > Section 3.2
> >>>>    > >  > >
> >>>>    > >  > >     This section defines the Segment Routing Mapping Server (SRMS).  The
> >>>>    > >  > >     SRMS is a IGP node advertising mapping between Segment Identifiers
> >>>>    > >  > >     (SID) and prefixes advertised by other IGP nodes.  The SRMS uses a
> >>>>    > >  > >     dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol
> >>>>    > >  > >     specific and defined in [I-D.ietf-isis-segment-routing-extensions],
> >>>>    > >  > >     [I-D.ietf-ospf-segment-routing-extensions], and
> >>>>    > >  > >     [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
> >>>>    > >  > >
> >>>>    > >  > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a
> >>>>    > >  > > better parenthetical?
> >>>>    > >  > #Ahmed: Corrected in the next version
> >>>>    > >  > >
> >>>>    > >  > >     The example diagram depicted in Figure 3 assumes that the operator
> >>>>    > >  > >     configures P5 to act as a Segment Routing Mapping Server (SRMS) and
> >>>>    > >  > >     advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103)
> >>>>    > >  > >     and (PE4, 104).
> >>>>    > >  > >
> >>>>    > >  > > nit: I think this is Figure 2.
> >>>>    > >  > #Ahmed: Corrected in the next version
> >>>>    > >  > >
> >>>>    > >  > > Section 3.2.1
> >>>>    > >  > >
> >>>>    > >  > >     [...] Examples
> >>>>    > >  > >     of explicit prefix-SID advertisment are the prefix-SID sub-TLVs
> >>>>    > >  > >     defined in ([I-D.ietf-isis-segment-routing-extensions],
> >>>>    > >  > >     [I-D.ietf-ospf-segment-routing-extensions], and
> >>>>    > >  > >     [I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
> >>>>    > >  > >
> >>>>    > >  > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat)
> >>>>    > >  > > be appropriate for inclusion in this list?
> >>>>    > >  > >
> >>>>    > >  > >     for that prefix.  Hence assigning a prefix-SID to a prefix using the
> >>>>    > >  > >     SRMS functionality does not preclude assigning the same or different
> >>>>    > >  > >     prefix-SID(s) to the same prefix using explict prefix-SID
> >>>>    > >  > >     advertisement such as the aforementioned prefix-SID sub-TLV.
> >>>>    > >  > #Ahmed: The SRMS functionality is specific to IGPs as mentioned in the
> >>>>    > >  > second sentence of the second paragraph in Section 3.2
> >>>>    > >  > >
> >>>>    > >  > > nit: I think the aforementioned things were a list, so "sub-TLVs" plural
> >>>>    > >  > > would be appropriate.
> >>>>    > >  > >
> >>>>    > >  > > Including the name for IS-IS TLV 135 might be helpful for the
> >>>>    > >  > > reader.
> >>>>    > >  > >
> >>>>    > >  > #Ahmed: Corrected as suggested in the next version
> >>>>    > >
> >>>>    > >
> >>>>    > >
> >>>>    > ________________________________________________________________________________
> >>>>    > _________________________________________
> >>>>    > >
> >>>>    > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou
> >>>>    > privilegiees et ne doivent donc
> >>>>    > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par
> >>>>    > erreur, veuillez le signaler
> >>>>    > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant
> >>>>    > susceptibles d'alteration,
> >>>>    > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>>    > >
> >>>>    > > This message and its attachments may contain confidential or privileged information that may be
> >>>>    > protected by law;
> >>>>    > > they should not be distributed, used or copied without authorisation.
> >>>>    > > If you have received this email in error, please notify the sender and delete this message and its
> >>>>    > attachments.
> >>>>    > > As emails may be altered, Orange is not liable for messages that have been modified, changed
> >>>>    > or falsified.
> >>>>    > > Thank you.
> >>>>    > >
> >>>>
> >>>> _________________________________________________________________________________________________________________________
> >>>>
> >>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>>
> >>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
> >>>> they should not be distributed, used or copied without authorisation.
> >>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
> >>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> >>>> Thank you.
> >>>>
>