Hi Acee, All these aspects are already covered by RFC8362 for OSPFv3 and I believe we are good there.
External Prefix TLV already has the E-bit : https://datatracker.ietf.org/doc/html/rfc8362#section-3.6 We already have the sub-TLVs for Forwarding Address and Route Tag that can be reused : https://datatracker.ietf.org/doc/html/rfc8362#section-8.2 Please correct if I am missing anything. Thanks, Ketan On Thu, May 4, 2023 at 11:55 PM Acee Lindem <[email protected]> wrote: > Hi Peter, > > I believe you need the additions you added for OSPFv2 for OSPFv3 as well. > For OSPFv3, they are only applicable to the External-Prefix TLV. > > Thanks, > Acee > > > On May 4, 2023, at 8:09 AM, Peter Psenak <ppsenak= > [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]>> 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 > >> > <[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]>>> 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]>>> 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]>> > >> > 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>> > >> > > > > <draft-ietf-lsr-ip-flexalgo-diff-10-11.html><draft-ietf-lsr-ip-flexalgo-11.txt>_______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
