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
