Hi Ketan, > On May 5, 2023, at 01:00, Ketan Talaulikar <[email protected]> wrote: > > 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.
No - you are right. I guess I should have consulted the RFC 8362 authors š Thanks, Acee > > Thanks, > Ketan > > > On Thu, May 4, 2023 at 11:55āÆPM Acee Lindem <[email protected] > <mailto:[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 >> > <[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>> >> >> 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>> >> >> > >> > <draft-ietf-lsr-ip-flexalgo-diff-10-11.html><draft-ietf-lsr-ip-flexalgo-11.txt>_______________________________________________ >> > Lsr mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/lsr >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
