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

[Alvaro Retana <[e-mail]>]

Ahmed: Ping!!

We’re really close…

Alvaro.

On July 26, 2018 at 4:27:25 PM, Benjamin Kaduk ([e-mail]) 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.
> >>
>