Hi Roman,
thanks for your comments, please see inline (##PP):
On 03/10/2022 22:09, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection
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/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Charlie Kaufman for the SECDIR review.
** Section 4.
We want the mapping between the Flex-Algorithm and its
meaning to be flexible and defined by the user.
Is a “Flex-Algorithm” (with hyphen) the same as a “Flex Algorithm” (no hyphen)
defined in Section 3? Why the difference in notation?
##PP
for "Flexible Algorithm" vs "Flexible-Algorithmun" I have unified to
"Flexible Algorithm" across the document.
The term "Flex-Algorithm" is separate and is defined as
"a numeric identifier in the range 128-255 that
is associated via configuration with the Flexible Algorithm
Definition."
** Section 4.
The set consisting of (a) calculation-type, (b) metric-type, and (c)
a set of constraints is referred to as a Flexible-Algorithm
Definition.
Flexible-Algorithm is a numeric identifier in the range 128-255 that
is associated via configuration with the Flexible-Algorithm
Definition.
This text repeats the text in Section 3 verbatim. Is it needed twice?
##PP
section 3 is a terminology section, while section 4 formally defines the
flex-algo. I would tend to keep it in both places.
** Section 5.
... and (b) are in the same Flex-Algorithm
definition advertisement scope
What is a “FAD advertisement scope?” Should this be an additional term defined
in Section 3?
##PP
scope for ISIS is defined in section 5.1 and for OSPF in section 5.2.
Since the scope is protocol specific, it can not be defined as a common
term.
** Section 5.1. Should the explanation of “Metric-Type” say that it’s value
comes from the “IGP Metric-Type Registry” per Section 18.1.2?
##PP
Done.
Section 5.1. Is it possible for a peer not to support a particular
Metric-Type? If so, have is that signaled?
##PP
The handling of such case is described in section 5.3.:
"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."
** Section 5.1.
An IS-IS L1/L2 router MAY be configured to re-generate the winning
FAD from level 2, ...
What is the “winning FAD?”
##PP
it is specified in section 5.3:
"The FAD selected according to these rules is also known as the
"winning FAD"."
** Section 5.1 and 5.2. Editorial. Definition of Flex-Algorithm in the TLV.
-- Section 5.1
Flex-Algorithm: Single octet value between 128 and 255 inclusive.
-- Section 5.2
Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255
inclusive.
Should this text be the same?
##PP
fixed
** Section 5.2. Editorial. Why is the text defining Metric-Type repeated
verbatim from what is written in Section 5.1, but Calc-Type and Priority cite
Section 5.1?
##PP
the reason is that referenced RFCs for ISIS and OSPF in terms of Min
Unidirectional Link Delay and Traffic Engineering metric are different.
** Section 6.4.
New flag bits may be defined in the future. Implementations MUST
check all advertised flag bits in the received IS-IS FADF Sub-TLV -
not just the subset currently defined.
Let’s assume bits other than those define in this document are set. Is there
an IANA registry to check to understand their semantics?
##PP
yes, please see section 18.2.
I made a reference from section 6.4 and 7.4 to 18.2.
** Section 13.1.
During the route computation, it is possible for the Flex-Algorithm
specific metric to exceed the maximum value that can be stored in an
unsigned 32-bit variable. In such scenarios, the value MUST be
considered to be of value 0xFFFFFFFF during the computation and
advertised as such.
Should this guidance be referenced in Section 8 – that 0xFFFFFFFF could be
0xFFFFFFFF or an overflow value?
##PP
Sections 8 and 9 already have the reference to section 13:
"The usage of the Flex-Algorithm prefix metric is described in
Section 13."
** Section 17.
This draft adds two new ways to disrupt IGP networks:
An attacker can hijack a particular Flex-Algorithm by advertising
a FAD with a priority of 255 (or any priority higher than that of
the legitimate nodes).
An attacker could make it look like a router supports a particular
Flex-Algorithm when it actually doesn't, or vice versa.
What are the consequences of the described attacker behaviors? Is
“disrupt[ing] the IGP networks” just a denial of service? Could it also be
steering traffic in a particular way to allow inspection or modification; or to
avoid network based mitigations?
##PP
If someone modifies the FAD for certain algorithm, the traffic could be
routed differently over the network, still reaching the destination
though. In theory by routing the traffic via specific node or link, one
can do an inspection. But for that to happen, one would need to get a
physical access to the network, in which case it can do inspection for
any traffic, not just flex-algo.
Standard methods like IGP authentication can avoid these types of attacks.
----
I will wait for comments from other IESG members before pushing a new
revision.
thanks,
Peter
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
