Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana <[e-mail]>]

On March 18, 2024 at 10:49:39 AM, Francois Clad wrote:


Francois:

Hi!  Thanks for the update!

> Detailed replies inline. These include your follow-up comments as well as the
> review items that we missed in the first pass.
>
> Please let us know if you have any further feedback.

I have some suggestions below, please consider them for the next revision.


Thanks!

Alvaro.


...
> > I know that this document is not a deployment guide and that it cannot
> > cover all cases. But the current guidance is basically non-existent
> > given the large amount of choice.
>
> There are likely to various other considerations besides the C-SID lengths.
> They may be a mix of technical and/or non-technical. Perhaps the SRv6 Ops
> forum will produce some deployment and operational guidelines for the
> technical aspects. It is not in the scope of this document to serve as a
> deployment or design guide.

At lease please include that ("There are likely to various other
considerations besides the C-SID lengths. They may be a mix of
technical and/or non-technical.") somewhere.

I seem to be the only person asking for additional information, so I
may be in the rough.  However, I don't consider waiting for a future
document a good solution.

Let's move on.



...
> > > > 1094 The segment list that the SR source node pushes onto the packet MUST
> > > > 1095 comply with the rules in Section 6.3 and Section 6.4 and result in a
> > > > 1096 path equivalent to the original segment list.
> > > >
> > > > [major] "MUST...result in a path equivalent to the original segment
> > > > list"
> > > >
> > > > How is a "path equivalent to the original" defined? The next
> > > > paragraph mentions "a compressed segment list of equal or shorter
> > > > length than the uncompressed segment list". What does the length
> > > > refer to -- the number of Segment Lists in the SRH, the size of the
> > > > SRH, or something else?
> > >
> > > We clarified in revision -13 that this is "the same forwarding path".
> > >
> > > The length of a segment list is the number of elements that it contains.
> > >
> > > > 1098 If an SR source node chooses to compress the segment list, one method
> > > > 1099 is described below for illustrative purposes. Any other method
> > > > 1100 producing a compressed segment list of equal or shorter length than
> > > > 1101 the uncompressed segment list is compliant.
> >
> > The requirement is: "MUST...result in the same forwarding path as the
> > original segment list." BUT a method that produces "a compressed
> > segment list of equal or shorter length than the uncompressed segment
> > list is compliant".
> >
> > I understand the intent, but given that it is a requirement, how can
> > "the same forwarding path" be enforced? If the path is loose, how can
> > "the same forwarding path" be guaranteed?
> >
> > Suggestion>
> >
> > The segment list that the SR source node pushes onto the packet MUST
> > comply with the rules in Section 6.3 and Section 6.4 and should result
> > in the same forwarding path as the original segment list.
>
> That's a good point. However, "should result in the same forwarding path" may
> be too loose.
>
> How about "MUST [...] result in the same *set of possible forwarding paths*
> as the original segment list"?

I've been reading this sentence over and over...let's take a step
back.  This is how the text has evolved: "The segment list that the SR
source node pushes onto the packet MUST...result in "

-11: "a path equivalent to the original segment list."

-13: "the same forwarding path as the original segment list."

-14: "the same set of possible forwarding paths as the original segment list."


I was getting stuck on the question of "how can the MUST be enforced
as the packets are forwarded through a *path*?"  But that's the wrong
question.

The "original segment list" includes the SR Policy that represent the
path (in the form of SIDs = segment endpoints) that must be followed.
The compressed segment list must result in a path with the same
segments/segment endpoints (as the "original segment list").  Is that
the correct interpretation?

The requirement (a path with the same segments/segment endpoints) can
only be enforced at the SR Source Node -- it can't be enforced in
transit (in the forwarding path) or at the last segment router.

Suggestion>

   The segment list that the SR source node pushes onto the packet
   MUST...result in the same SR Policy as the original segment list.

Thoughts?



...
> > 1242 6.3. Rules for segment lists containing NEXT-C-SID flavor SIDs
...
> > 1262 6.4. Rules for segment lists containing REPLACE-C-SID flavor SIDs
...
> > [major] Are these requirements validated at any point? For example,
> > if rule #3 is not implemented and the next Segment List is not "a
> > REPLACE-C-SID container in packed format". Which node enforces the
> > fact that the specification is not followed? It seems to me that the
> > only node in that position would be the one represented by the that
> > last SID. Can any action be taken? What is the impact?
>
> These requirements are a part of how the SR source node builds the compressed
> segment list and the SR source node is sole responsible for enforcing them.
>
> As goes with any SRv6 segment list, the other nodes along the path can only
> validate that the next SID matches a local FIB entry.
>
> The impact if these rules are not followed are the same as any other
> incorrect value in an SRv6 segment list: the packet may get dropped or
> misrouted.

Right, that's what I wanted to get to.

Please consider adding that conclusion to the text:

   If these rules are not followed, the packets may get dropped or
   misrouted.



...
> > 1458 Signaling the SRv6 SID Structure is REQUIRED for all the SIDs
> > 1459 introduced in this document. It is used by an SR source node to
> > 1460 compress a segment list as described in Section 6. The node
> > 1461 initiating the SID advertisement MUST set the length values in the
> > 1462 SRv6 SID Structure to match the format of the SID on the SR segment
> > 1463 endpoint node. For example, for a SID of this document instantiated
> > 1464 from a /48 SRv6 SID block and a /64 Locator, and having a 16-bit
> > 1465 Function, the SRv6 SID Structure advertisement carries the following
> > 1466 values.
> >
> > [major] "Signaling the SRv6 SID Structure is REQUIRED..."
> >
> > The SRv6 SID Structure TLVs are optional in rfc9352, rfc9513, rfc9514,
> > I-D.ietf-pce-segment-routing-ipv6, and
> > I-D.ietf-idr-segment-routing-te-policy. Even if this document
> > requires the information to be advertised, the control protocols
> > don't. What should the SR Source Node do if the SRv6 SID Structure is
> > not present?
> >
> > Given that the SRv6 SID Structure TLVs are optional, a rogue node can
> > decide to not advertise the information -- the result would probably
> > be that SIDs would not be available to construct all the paths that
> > may be required, which may result in suboptimal routing, or even the
> > inability to construct paths to specific destinations. Please include
> > something about this threat in the Security Considerations.
>
> This is covered in section 6.1. In particular:
>
> | When compressing a segment list, the SR source node MUST treat an
> | invalid SID structure as unknown, and treats the SID as
> | incompressible.

An invalid SID structure is not the same as a missing one, even if the
result is.  Please indicate that the above also applies to the case
where it is missing.

BTW, the first sentence in §6.1 says this:

   As part of the compression process or as a preliminary step, the SR
   source node MUST validate the SID structure, if known, of each SID of
   this document in the segment list.

The combination "MUST validate the SID structure, if known" seems to
imply that the structure doesn't need to be validated if not known...
 s/, if known, /


> Not sure how that can be a security threat, though.

It's a falsification attack: a rogue router (either the originator or
one in transit) can delete the SID Structure Sub-TLV, or change it so
that it is not valid.  But you're right, the only issue would be that
the SID cannot be compressed.

https://datatracker.ietf.org/doc/html/rfc4593#autoid-17




> > [major] "...the SRv6 SID Structure is REQUIRED for all the SIDs
> > introduced in this document."
> >
> > This document defines, for example, the End.T behavior for both C-SID
> > flavors. However, rfc9352, rfc9513, and rfc9514 don't define the
> > advertisement of End.T. To illustrate, rfc9352 says this:
> >
> > 9. SRv6 SID Structure Sub-Sub-TLV
> >
> > The SRv6 SID Structure sub-sub-TLV is an optional sub-sub-TLV of:
> >
> > * SRv6 End SID sub-TLV (Section 7.2)
> >
> > * SRv6 End.X SID sub-TLV (Section 8.1)
> >
> > * SRv6 LAN End.X SID sub-TLV (Section 8.2)
> > ...
> >
> > No mention of End.T, or other behaviors mentioned in this document.
> >
> > Also, from §7.2:
> >
> > Supported behavior values, together with parent TLVs in which they
> > are advertised, are specified in Section 10 of this document. Please
> > note that not all behaviors defined in [RFC8986] are defined in this
> > document, e.g., End.T is not.
> >
> >
> > The above means that the requirement to advertise the SRv6 SID
> > Structure "for all the SIDs introduced in this document" can't be met
> > because the control plane protocols don't currently have the ability
> > to signal all the behaviors or because the SRv6 SID Structure is not a
> > valid option for them.
> >
> > While I don't think this issue is a showstopper for this document, I'm
> > curious about the plan to extend/update the existing specifications.
> > Note that the implementations in §10 give the impression that no
> > exceptions exist -- of course, it is possible that other mechanisms
> > (manual configuration, for example) are used. I am also curious about
> > any manageability-related plans to enhance YANG models.
>
> The SID structure requirement only applies when those SIDs are advertised in a control plane protocol.
>
> While it is desirable to extend the existing control and management plane
> mechanisms for those remaining SIDs, it really falls outside the scope of
> this document.

For completeness, can you please add that to the document?  I see how
it can't be required to *signal* the SID structure if the control
plane doesn't support it.  However, it is required if the SIDs are
intended/expected to be compressed, so it would be nice to say
something about it in the text.

Suggestion>

   The SRv6 SID Structure may also be learned through configuration or
   other management protocols.  The details of such mechanisms are
   outside the scope of this document.