Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-09

[Ketan Talaulikar <[e-mail]>]

Hi Peter,

Thanks for this updated version and it addresses my comments.

The route tag functionality for IP Algo reachability is best provided by
the upcoming draft-ietf-lsr-ospf-admin-tags. As co-authors of that draft,
could either you or Acee cover applicability for both IP Algo and SRv6
Locator?

That way we have functional parity for IP algorithm reachability for OSPF
all taken care of.

Thanks,
Ketan


On Thu, 4 May, 2023, 5:39 pm Peter Psenak, <[e-mail]> wrote:

> Hi Ketan,
>
> please find the updated version and the diffs from previous one attached.
>
> Please let me know if you have any comments or suggestions.
>
> thanks,
> Peter
>
> On 03/05/2023 15:30, Ketan Talaulikar wrote:
> > Hi Peter,
> >
> > Please check inline below.
> >
> > On Wed, May 3, 2023 at 6:16 PM Peter Psenak <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Ketan,
> >
> >     On 03/05/2023 06:09, Ketan Talaulikar wrote:
> >      > Hello Authors/All,
> >      >
> >      > I think there are a couple of issues with this document related to
> >      > OSPFv2 aspects. My apologies for this last minute notice and not
> >      > catching them earlier during the WGLC. >
> >      > 1) The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV is not
> >     carrying
> >      > the indication of Type1/Type2 for External and NSSA-External route
> >      > advertisements. A way to fix/address this would be to introduce a
> >     1 byte
> >      > flags in the Reserved space and then introduce the "E -bit"
> >     similar to
> >      > how it is there in the base OSPFv2 External LSAs -
> >      > https://datatracker.ietf.org/doc/html/rfc2328#appendix-A.4.5
> >     <https://datatracker.ietf.org/doc/html/rfc2328#appendix-A.4.5>
> >      > <https://datatracker.ietf.org/doc/html/rfc2328#appendix-A.4.5
> >     <https://datatracker.ietf.org/doc/html/rfc2328#appendix-A.4.5>>
> >
> >     can't we live without the Ext. Type-2 metric for the IP algo prefixes
> >     and treat then as Type 1 ext metric always?
> >     The real advantage of the Type-2 metric is not really significant.
> >
> >
> > KT> That is an option but it would create deviations from the base OSPF
> > processing for IP Algo reachability. That may be more of an issue for
> > implementations and may be even operators used to OSPF. It may be easier
> > to just fix the encoding to allow the indication of Type 1/2.
> >
> >
> >      >
> >      > 2) Also for OSPFv2, since we don't have the base OSPFv2 LSA for
> Algo
> >      > reachability, we are missing some key sub-TLVs in the OSPFv2
> >     Extended
> >      > Prefix Sub-TLVs that would be required for IP FlexAlgo
> >     reachability -
> >      > mainly Forwarding Address and Route Tag.
> >
> >     Similarly using the forwarding address is something which has limited
> >     benefits and we do not need it for the IP Algo prefixes.
> >
> >     The only problem is during the NSSA translation, where the spec
> >     mandates
> >     the non-zero forwarding address. Is that something that we really
> need?
> >
> >
> > KT> Same as the previous comment. We will hit some corner cases and may
> > need to carve out these exceptions. It may be simpler to just add these
> > sub-TLVs.
> >
> >
> >      >
> >      > 3) Along with the above changes, perhaps some text is required to
> >      > indicate the use of these new sub-TLVs and how OSPFv2 base route
> >      > calculations apply for various route types (specifically external
> >     and NSSA)?
> >
> >     how is that different to regular prefix (RFC2328)?
> >
> >
> > KT> The route calculations don't change - only that everything is done
> > using only the OSPFv2 Extended Prefix LSAs instead of the base OSPF
> > LSAs. One can say it is implicit so I wonder if it helps to make this
> > explicit.
> >
> >
> >     thanks,
> >     Peter
> >
> >      >
> >      > 4) A nit: in a few places in sec 6.3, the OSPFv2 IP Algorithm
> Prefix
> >      > Reachability is being referred to as TLV instead of sub-TLV.
> Similar
> >      > issue in sec 6.4 for OSPFv3.
> >      >
> >      > Thanks,
> >      > Ketan
> >      >
> >      >
> >      > On Wed, May 3, 2023 at 12:01 AM John Scudder
> >      > <jgs=[e-mail]
> >     <mailto:[e-mail]>
> >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>>
> >      > wrote:
> >      >
> >      >     Hi Peter,
> >      >
> >      >     All good, I figured it was something like that. Two residual
> >     nits —
> >      >
> >      >     1. One “datapalne” got left in. I guess you need something to
> >     seed
> >      >     version 11 after all…
> >      >
> >      >     2. It looks like this one got omitted:
> >      >
> >      >     @@ -579,8 +592,18 @@
> >      >          receiver.
> >      >
> >      >          The metric value in the parent TLV is RECOMMENDED to be
> >     set to
> >      >     -   LSInfinity [RFC2328].  This recommendation only servers
> for
> >      >     debugging
> >      >     +   LSInfinity [RFC2328].  This recommendation only serves
> >     for debugging
> >      >          purposes and does not impact the functionality.
> >      >     +---
> >      >     +jgs: Thanks for adding the additional explanation. I made a
> >     minor
> >      >     editing
> >      >     +correction in-line, but I also have a slightly more extensive
> >      >     revision to
> >      >     +suggest:
> >      >     +
> >      >     +NEW:
> >      >     +     This recommendation is provided as a network
> >     troubleshooting
> >      >     +     convenience; if it is not followed the protocol will
> still
> >      >     +     function correctly.
> >      >     +—
> >      >
> >      >     Obviously, I don’t insist on the proposed rewrite. But even
> >     if you
> >      >     don’t use it you presumably should take the s/servers/serves/
> >      >     proofreading correction.
> >      >
> >      >     I’m going to go ahead and request IETF Last Call, but feel
> >     free to
> >      >     push a revision with corrections if you want.
> >      >
> >      >     —John
> >      >
> >      >      > On May 2, 2023, at 6:06 AM, Peter Psenak
> >      >     <ppsenak=[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>> wrote:
> >      >      >
> >      >      >
> >      >      > Hi John,
> >      >      >
> >      >      > I apologize for the misses, likely the result of multiple
> >     editors
> >      >      > updating the draft in parallel.
> >      >      >
> >      >      > I also fixed the nits and updated the security sections as
> you
> >      >     proposed.
> >      >      >
> >      >      > Version 10 has been published.
> >      >      >
> >      >      > thanks,
> >      >      > Peter
> >      >      >
> >      >      >
> >      >      >
> >      >      >
> >      >      >
> >      >      > On 01/05/2023 20:54, John Scudder wrote:
> >      >      >> Hi Peter (and Shraddha),
> >      >      >>
> >      >      >>> On Apr 28, 2023, at 9:13 AM, Peter Psenak
> >      >     <ppsenak=[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>> wrote:
> >      >      >>>
> >      >      >>> Shradha and I have worked to address your comments.
> >      >      >>> The new version of the draft has been published.
> >      >      >>
> >      >      >> Thanks for that. I’ve reviewed the diffs in 09. I’ve
> >     attached a
> >      >     short review of it; there are some minor proofreading
> >     changes, but
> >      >     also one place a substantive edit was overlooked that I’ve
> >     flagged
> >      >     in Section 6.2. I also made a further suggestion on your
> Security
> >      >     Considerations.
> >      >      >>
> >      >      >> I think one more revision and we will be ready for IETF
> >     Last Call.
> >      >      >>
> >      >      >> Thanks,
> >      >      >>
> >      >      >> —John
> >      >      >>
> >      >      >> --- draft-ietf-lsr-ip-flexalgo-09.txt 2023-05-01
> >      >     13:21:34.000000000 -0400
> >      >      >> +++ draft-ietf-lsr-ip-flexalgo-09-jgs-comments.txt
> >     2023-05-01
> >      >     14:47:16.000000000 -0400
> >      >      >> @@ -138,9 +138,9 @@
> >      >      >>     result, traffic for different sessions is destined to
> a
> >      >     different
> >      >      >>     destination IP address.
> >      >      >>
> >      >      >> -   IP address allocated to the UPF can be associated
> with an
> >      >     algoritm.
> >      >      >> +   The IP address allocated to the UPF can be associated
> >     with
> >      >     an algorithm.
> >      >      >>     The mobile user traffic is then forwarded along the
> path
> >      >     based on the
> >      >      >> -   algorithm specific metric and constraints.  As a
> result,
> >      >     traffic can
> >      >      >> +   algorithm-specific metric and constraints.  As a
> result,
> >      >     traffic can
> >      >      >>     be sent over a path that is optimized for minimal
> >     latency or
> >      >     highest
> >      >      >>     bandwidth.  This mechanism is used to achieve SLA
> >     (Service Level
> >      >      >>     Agreement) appropriate for a user session.
> >      >      >> @@ -186,9 +186,9 @@
> >      >      >>
> >      >      >>     Advertisement of participation in IP Flex-Algorithm
> >     does not
> >      >     impact
> >      >      >>     the router participation signaled for other
> >     data-planes.  For
> >      >      >> -   Example, it is possible that a router participates in
> a
> >      >     particular
> >      >      >> -   flex-algo for IP datapalne but does not participate
> >     in the
> >      >     same flex-
> >      >      >> -   algo for SR dataplane.
> >      >      >> +   example, it is possible that a router participates in
> a
> >      >     particular
> >      >      >> +   flex-algo for the IP dataplane but does not
> >     participate in
> >      >     the same flex-
> >      >      >> +   algo for the SR dataplane.
> >      >      >>
> >      >      >>     The following sections describe how the IP
> Flex-Algorithm
> >      >      >>     participation is advertised in IGP protocols.
> >      >      >> @@ -196,6 +196,11 @@
> >      >      >>  5.1.  The IS-IS IP Algorithm Sub-TLV
> >      >      >>
> >      >      >>     The ISIS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV
> >     of the
> >      >     IS-IS
> >      >      >> +---
> >      >      >> +jgs: Was it deliberate that you didn't accept the
> >     suggestion to
> >      >      >> +hyphenate "ISIS" above, or an oversight? If deliberate,
> >     how come?
> >      >      >> +If accidental, please change in next rev.
> >      >      >> +---
> >      >      >>     Router Capability TLV [RFC7981] and has the following
> >     format:
> >      >      >>
> >      >      >>          0                   1                   2
> >      >           3
> >      >      >> @@ -302,9 +307,9 @@
> >      >      >>  6.  Advertising IP Flex-Algorithm Reachability
> >      >      >>
> >      >      >>     To be able to associate the prefix with the
> >     Flex-Algorithm, the
> >      >      >> -   existing prefix reachability advertisements can not
> >     be used,
> >      >     because
> >      >      >> +   existing prefix reachability advertisements cannot be
> >     used,
> >      >     because
> >      >      >>     they advertise the prefix reachability in default
> >     algorithm 0.
> >      >      >> -   Instead, a new IP Flex-Algorithm reachability
> >     advertisements are
> >      >      >> +   Instead, new IP Flex-Algorithm reachability
> >     advertisements are
> >      >      >>     defined in IS-IS and OSPF.
> >      >      >>
> >      >      >>     The M-flag in the FAD is not applicable to IP
> Algorithm
> >      >     Prefixes.
> >      >      >> @@ -410,6 +415,11 @@
> >      >      >>     all of them do not advertise the same algorithm, it
> MUST
> >      >     ignore all
> >      >      >>     of them and MUST NOT install any forwarding entries
> >     based on
> >      >     these
> >      >      >>     advertisements.  This situation SHOULD be logged as
> >     an error.
> >      >      >> +---
> >      >      >> +jgs: Thanks for these rewrites. Unfortunately there is a
> >      >     similar case
> >      >      >> +later (Section 6.2) which was missed. It needs a similar
> >     rewrite,
> >      >      >> +I will flag it below, please refer back to this section.
> >      >      >> +---
> >      >      >>
> >      >      >>     In cases where a prefix advertisement is received in
> >     both a IPv4
> >      >      >>     Prefix Reachability TLV and an IPv4 Algorithm Prefix
> >      >     Reachability
> >      >      >> @@ -434,6 +444,9 @@
> >      >      >>     with a different Algorithm, MUST ignore all of them
> >     and MUST NOT
> >      >      >>     install any forwarding entries based on these
> >      >     advertisements.  This
> >      >      >>     situation SHOULD be logged as an error.
> >      >      >> +---
> >      >      >> +jgs: These two paragraphs need a rewrite similar to
> >     Section 6.1.
> >      >      >> +---
> >      >      >>
> >      >      >>     In cases where a prefix advertisement is received in
> >     both an
> >      >     IPv6
> >      >      >>     Prefix Reachability TLV and an IPv6 Algorithm Prefix
> >      >     Reachability
> >      >      >> @@ -579,8 +592,18 @@
> >      >      >>     receiver.
> >      >      >>
> >      >      >>     The metric value in the parent TLV is RECOMMENDED to
> >     be set to
> >      >      >> -   LSInfinity [RFC2328].  This recommendation only
> >     servers for
> >      >     debugging
> >      >      >> +   LSInfinity [RFC2328].  This recommendation only
> >     serves for
> >      >     debugging
> >      >      >>     purposes and does not impact the functionality.
> >      >      >> +---
> >      >      >> +jgs: Thanks for adding the additional explanation. I
> made a
> >      >     minor editing
> >      >      >> +correction in-line, but I also have a slightly more
> >     extensive
> >      >     revision to
> >      >      >> +suggest:
> >      >      >> +
> >      >      >> +NEW:
> >      >      >> +     This recommendation is provided as a network
> >     troubleshooting
> >      >      >> +     convenience; if it is not followed the protocol
> >     will still
> >      >      >> +     function correctly.
> >      >      >> +---
> >      >      >>
> >      >      >>     An OSPFv3 router receiving multiple OSPFv3 IP
> >     Algorithm Prefix
> >      >      >>     Reachability Sub-TLVs in the same parent TLV, MUST
> select
> >      >     the first
> >      >      >> @@ -932,13 +955,47 @@
> >      >      >>     This document inherits security considerations from
> >     [RFC9350].
> >      >      >>
> >      >      >>     This document introduces one additional way to
> >     disrupt Flexible
> >      >      >> -   algorithm based networks.  If the node that is
> >     authenticated
> >      >     is taken
> >      >      >> -   over by an attacker, such rogue node can advertise a
> >     prefix
> >      >      >> +   Algorithm based networks.  If a node that is
> >     authenticated
> >      >     is taken
> >      >      >> +   over by an attacker, such a rogue node can advertise
> >     a prefix
> >      >      >>     reachability for a particular IP Flexible-algorithm X
> >     while that
> >      >      >>     prefix has been advertised in algorithm Y.  This kind
> of
> >      >     attack makes
> >      >      >> -   the prefix unreachable.  Such attack is not
> >     preventable through
> >      >      >> +   the prefix unreachable.  Such an attack is not
> >     preventable
> >      >     through
> >      >      >>     authentication, and it is not different from
> >     advertising any
> >      >     other
> >      >      >>     incorrect information through IS-IS or OSPF.
> >      >      >> +---
> >      >      >> +jgs: Thanks for this. I think you should provide a
> >     reference to
> >      >      >> +illustrate what you're talking about, e.g. "This kind of
> >     attack
> >      >     makes
> >      >      >> +the prefix unreachable (to see why this is, consider, for
> >      >     example, the
> >      >      >> +rule given in the second-last paragraph of Section 6.1)".
> >      >      >> +
> >      >      >> +I see you cribbed the text from RFC 9350, which is not a
> >     bad idea
> >      >      >> +considering that was recently approved by the IESG so
> >      >     presumably they
> >      >      >> +like the look of it. But in that case, I think it would
> be a
> >      >     good idea
> >      >      >> +to copy the 9350 section more comprehensively. Something
> >     like this:
> >      >      >> +
> >      >      >> +   This document adds one new way to disrupt IGP
> >     networks that
> >      >     are using
> >      >      >> +   Flex-Algorithm: an attacker can suppress reachability
> >     for a
> >      >     given
> >      >      >> +   prefix whose reachability is advertised by a
> >     legitimate node
> >      >     for a
> >      >      >> +   particular IP Flex-Algorithm X, by advertising the
> same
> >      >     prefix in
> >      >      >> +   Flex-Algorithm Y from another, malicious node. (To
> >     see why
> >      >     this is,
> >      >      >> +   consider, for example, the rule given in the
> second-last
> >      >     paragraph of
> >      >      >> +   Section 6.1.)
> >      >      >> +
> >      >      >> +   This attack can be addressed by the existing security
> >      >     extensions, as
> >      >      >> +   described in [RFC5304] and [RFC5310] for IS-IS, in
> >     [RFC2328] and
> >      >      >> +   [RFC7474] for OSPFv2, and in [RFC4552] and [RFC5340]
> >     for OSPFv3.
> >      >      >> +
> >      >      >> +   If a node that is authenticated is taken over by an
> >      >     attacker, such a
> >      >      >> +   rogue node can perform the attack described above.
> >     Such an
> >      >     attack is
> >      >      >> +   not preventable through authentication, and it is not
> >      >     different from
> >      >      >> +   advertising any other incorrect information through
> >     IS-IS or
> >      >     OSPF.
> >      >      >> +
> >      >      >> +I was tempted to rewrite further (I was bugged that
> >     "node that is
> >      >      >> +authenticated" isn't a well-defined term) but I think the
> >      >     argument that
> >      >      >> +this text already passed IESG review recently, is pretty
> >      >     compelling, so
> >      >      >> +the above is just a minimal substitution into the RFC
> >     9350 security
> >      >      >> +considerations.
> >      >      >> +---
> >      >      >>
> >      >      >>  13.  Acknowledgements
> >      >      >>
> >      >      >>
> >      >      >>
> >      >      >>
> >      >      >>
> >      >      >
> >      >
> >      >     _______________________________________________
> >      >     Lsr mailing list
> >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      > https://www.ietf.org/mailman/listinfo/lsr
> >     <https://www.ietf.org/mailman/listinfo/lsr>
> >      >     <https://www.ietf.org/mailman/listinfo/lsr
> >     <https://www.ietf.org/mailman/listinfo/lsr>>
> >      >
> >
>