On October 5, 2022 at 12:02:30 PM, Peter Psenak wrote:
Peter: Hi! ... > > (1) When is a router's participation in a particular Flex-Algorithm > > advertised? ... > > Presumably, the operator configures support for a specific Flex-Algorithm > > with a FAD in mind. IOW, there should be no surprises. However, I would > > like to see the relationship between the support/participation > > configuration and the FAD components explicitly called out. > > ##PP > Section 5.3 says: > > "If a node is configured to participate in a particular Flexible- > Algorithm, but there is no valid Flex-Algorithm definition available > for it, or the selected Flex-Algorithm definition includes > calculation-type, metric-type, constraint, flag, or Sub-TLV that is > not supported by the node, it MUST stop participating in such > Flexible-Algorithm. That implies that it MUST NOT announce > participation for such Flexible-Algorithm as specified in Section 11 > and it MUST remove any forwarding state associated with it." First off, sorry I missed this text. :-( [Nit: I think I searched for Calc-Type, not calculation-type. "Calculation type" is also used. Please be consistent.] > Is there anything more that you have in mind? Yes, a couple of things: (1) The text above instructs implementations of [RFC8667] and [RFC8665] to stop advertising the specific Flex-Algorithm value, but those RFCs (if I remember correctly) don't say anything about *not* advertising the SR-Algorithm TLV/sub-TLV. This document should formally Update those RFCs. (2) The text related to the Update should be in §11, which is where the participation advertisement is specified. Text should also be added to §11.2 to indicate that other data-planes have to do the same thing. (3) My original request: I would like to see the relationship between the support/participation configuration and the FAD components explicitly called out...from the operator's point of view. Even if the protocol is specified to react, the operator may configure with different expectations. I'm thinking of something along the lines of (in §15.*): When configuring a node to participate in a specific Flex-Algorithm, the components of the definition (calc, metric) should be considered carefully. The configuration of a Flex-Algo ID doesn't guarantee that the node will actively participate in the topology because it may not support the cal or metric types... Changes in the FAD configuration should also be considered in light of the capabilities of the routers in the flooding domain. ... ... > > (3) The Security Considerations section says that the attacks listed can be > > addressed through authentication. However, it fails to consider what a rogue > > node (one that is authenticated and taken over by an attacker) can do. > > ##PP > if someone gets hold of the node that is authenticated it can advertise > all sorts of bogus data that results in network becoming non functional. > I don't know what we can do at the protocol level to avoid it. > > > > > This type of attack is not preventable through authentication, and it is not > > different from advertising any other incorrect information through IS-IS/ > > OSPF. It should be mentioned in the Security Considerations section. > > > > Also, the effect of a hijacked/modified FAD may result in traffic not being > > delivered at all -- for example, by using an unsupported Metric-Type or > > Calc-Type. > > ##PP > I don't disagree. I'm not sure if you also don't disagree that this case should be mentioned in the Security Considerations. ;-) It is not a new type of problem, but a new way to to do it. Thanks! Alvaro. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
