Hi Alvaro,
please see inline (##PP):
On 05/10/2022 16:18, Alvaro Retana via Datatracker wrote:
Alvaro Retana has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I am balloting DISCUSS because I believe that operational and security
considerations need to be addressed or at least mentioned.
I believe these points should be easy to address with some additional text.
(1) When is a router's participation in a particular Flex-Algorithm advertised?
It seems to me that there might be a "chicken-and-egg" problem that should at
least be mentioned in the Operational Considerations. Let me explain:
§11:
When a router is configured to support a particular Flex-Algorithm,
we say it is participating in that Flex-Algorithm.
§5:
To guarantee loop-free forwarding for paths computed for a particular
Flex-Algorithm, all routers that (a) are configured to participate in
a particular Flex-Algorithm, and (b) are in the same Flex-Algorithm
definition advertisement scope MUST agree on the definition of the
Flex-Algorithm. The following procedures ensure this condition is
fulfilled.
These statements make it look like support for a particular Flex-Algorithm is
advertised when the routing process is enabled -- because the router is
"configured to support/participate". However, at this point, the router may
not have received a FAD for the Flex-Algorithm it is advertising support for.
##PP
that is correct. Participation of the node in flex-algo is independent
of the FAD availability.
Besides the number of the Flex-Algorithm, the participation advertisement
implies support for a specific Metric-Type and Calc-Type. But, again, nodes
may be advertising this support blindly if the FAD is not known yet.
##PP
nodes do not advertise support for particular metric type or calculation
type. All that data is part of the FAD and if the winning FAD includes
anything that the participating node does not support, it MUST stop
participating in such flex-algo.
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."
Is there anything more that you have in mind?
Note that this issue is related to the ability of an attacker to hijack a
particular Flex-Algorithm, but oriented at the ability of the operator to cause
harm to their network.
##PP
to hijack the FAD for an algo, one would need to be able to originate a
LSP that includes the FAD. This is no different then introducing any
other bogus information and can be avoided using the standard methods
like LSP authenitication.
(2) Related to the point above.
What should a node configured to advertise support for a specific
Flex-Algorithm do if it receives a FAD that it cannot support? For example, if
the calc-type is unknown or unsupported.
##PP
please see the end of the section 5.3.
[§13 already addresses the case of an unsupported metric-type.]
##PP
not really, section 13 is talking about the specific case of inter-area
metric.
(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.
thanks,
Peter
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
