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

[Peter Psenak <[e-mail]>]

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