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, <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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>>
> >
<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
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> > 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
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> 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
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> 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
> > [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > 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>>
> > <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>>>
> >
>
