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 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. 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)? 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= [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 <ppsenak= > [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 <ppsenak= > [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] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
