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

[Peter Psenak <[e-mail]>]

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