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

[Alvaro Retana <[e-mail]>]

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.