[Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-flex-algo-24: (with DISCUSS)

[Alvaro Retana via Datatracker <[e-mail]>]

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.

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.

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.

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.

(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.

[§13 already addresses the case of an unsupported metric-type.]

(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.

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.