Alvaro,
please see inline (##PP2)
On 06/10/2022 02:30, Alvaro Retana wrote:
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.]
##PP2
fixed
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.
##PP2
advertising the SR-Algorithm TLV is optional.
https://datatracker.ietf.org/doc/html/rfc8665#section-3.1
"The SR-Algorithm TLV is optional. It SHOULD only be advertised once
in the Router Information Opaque LSA."
Advertising any set of algorithms in this TLV is supported. A router is
free to add or remove any algorithm value from the TLV. This is all well
supported by both above mentioned RFCs. I don't see any need for update.
(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.
##PP2
I have added following to the section 11:
"Advertisement of the participation for any particular Flex-Algorithm
in any data-plane is subject to the condition specified in
Section 5.3."
Would that be sufficient?
(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. ...
##PP2
Added following text to section 15.4, that I renamed it to "FAD
Definition and Changes"
"When configuring a node to participate in a specific Flex-Algorithm,
the components of the FAD (calculation-type, metric-type,
constraints) should be considered carefully. The configuration of
participation in a particular Flex-Algorithm doesn't guarantee that
the node will actively participate in it, because it may not support
the calculation-type, metric type or some constraint advertised by
the winning FAD (see Section 5.3). Changes in the FAD configuration
should also be considered in light of the capabilities of the
participating routers in the scope of the FAD advertisement."
...
(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. ;-)
##PP2
I added the following text to the Security Consideration:
"If the node that is authenticated is taken over by an attacker, such
rogue node can advertise the FAD for any Flex-Algorithm. Doing so
may result in traffic for such Flex-Algorithm to be misrouted, or not
being delivered at all, for example, by using an unsupported metric-
type, calculation-type, or constraint. Such attack is not
preventable through authentication, and it is not different from
advertising any other incorrect information through IS-IS or OSPF."
thanks.
Peter
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
