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]>
> 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]> 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
