[Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-binding-label-sid-12: 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/blog/handling-iesg-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-pce-binding-label-sid/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I don't think we're currently entirely accurate in our depection of
the properties of BT=3 TE-PATH-BINDING TLVs.  In particular, in
Section 5 we write:

   For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
   SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
   by setting the BT (Binding Type) to 3.  This enables the sender to
   have control of the SRv6 Endpoint Behavior and SID Structure.  A
   sender MAY choose to set the BT to 2, in which case the receiving
   implementation chooses how to interpret the SRv6 Endpoint Behavior
   and SID Structure according to local policy.

But this TLV can be sent in several different circumstances -- when the
PCC has allocated the BSID and is reporting it to the PCE, when the PCE is
requesting the PCC to allocate a specific value, when the PCE has already
allocated a specific value from a range controlled by the PCE, and when
the PCE is requesting the PCC to allocate some value of its own choosing
(at least).  I think that only in the "PCE is requesting a specific value"
and "PCE has already allocated a specific value" cases do these claimed
properties hold -- if the PCC is allocating the value then the
interpretation of its internal structure is local to the PCC and the PCE
does not need to know how to interpret the structure in order for the path
to function.

This also brings up a related topic (and gives me unease about
specifically recommending use of BT=3 as the quoted text does), which may
be familiar to those who participated in the processing of
draft-ietf-lsr-isis-srv6-extensions.

In particular, the relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered to
be logically local to the node advertising the SID and therefore not an
observable part of the protocol.  In that sense, the wire-visible use and
processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a TLV that specifically carries the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  While this document does seem to present
somewhat more of a concrete use case for this mechanism than
draft-ietf-lsr-isis-srv6-extensions did (i.e., if the PCE is requesting or
allocating a specific value as an agent for the PCC, then the PCC needs to
know the internal structure somehow), the current framing of the mechanism
in the document leaves me uncomfortable, and once my discuss point is
resolved, I intend to change my position to Abstain.  It is possible
(though I make no commitment to future action) that if we changed the
description of the mechanism to be one where the PCC and PCE are jointly
managing the allocation of IPv6 addresses belonging to the PCC and
collaborate to manage the internal structure of the allocated values,
without exposing that internal structure to external entities in the
network or having the internal structure used in data-plane forwarding
paths, my discomfort would be reduced to a level that I could ballot No
Objection.  (I also wouldn't object to making the registry procedures
something less stringent than Standards Action and allocating the
codepoint as currently specified via some mechanism that does not involve
IETF Consensus, which would avoid reopening the controversy in the IETF
about this topic.)

(2) We are allocating a bit for the 'P' flag in the LSP Object flags, but
I only see specification of its behavior/semantics for the case when a
TE-PATH-BINDING TLV is present in the LSP object.  Section 8 says:

   *  P (PCE-allocated binding label/SID): If the bit is set to 1, it
      indicates that the PCC requests PCE to make allocations for this
      LSP.  The TE-PATH-BINDING TLV in the LSP object identifies that
      the allocation is for a binding label/SID.  [...]

The first sentence seems to indicate that the P flag is useful outside of
the scope of BSID allocation, with the general semantics of "the PCE
requests PCE to make allocations for this LSP".  This seems to be rather
under-specified for how it applies to cases without the TE-PATH-BINDING
TLV (what exactly is to be allocated by the PCE?) -- is the P flag useful
in such other cases?  If so, where are the usage details (going to be)
specified?  We do limit the use of P=1 to cases where PCECC has been
negotiated per RFC 9050, but I don't see a limitation of its use to cases
where TE-PATH-BINDING is present.  (And if there was such a limitation,
why is it a flag in the LSP Object rather than in the TLV itself?)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Abstract

   In order to provide greater scalability, network confidentiality, and
   service independence, Segment Routing (SR) utilizes a Binding Segment
   Identifier (BSID).  [...]

I'd consider mentioning RFC 8402 in some manner here, e.g., "as described
in RFC 8402", to emphasize that BSID is a preexisting concept and not the
new innovation of this document.

Section 1.1

I spent a while being rather confused about the example in Figure 1.  The
prose helps with some of my confusion, but there may still be some gaps
that could be improved.  In particular (per the prose), the PCE is
computing SR-TE paths in the IP/MPLS WAN (and so the PCC at gateway node 1
is the headend of that path, as expected).  But the PCE in the figure is
not shown interacting with the IP/MPLS WAN at all, other than Gateway
Node-1.  On the contrary, the PCE is explictly shown interacting with the
access node in front of the MPLS DC network, where (per the prose) paths
are managed via BGP prefix SID advertisements, without PCEP at all!  The
prose says of this interaction only that "the PCE passes the SID stack
{Y, X} where Y is the prefix SID of the gateway node-1 to the access
node", but not what protocol or mechanism is used to effectuate that
passing.  Is that supposed to be part of the BCP prefix SID advertisement
otherwise used in the MPLS DC network?  Or perhaps some other interaction
where the PCE is functioning as a central controller?  I suggest
clarifying in both the figure and the prose.

Section 4

   Section 12.1.1 defines the IANA registry used to maintain all these
   binding types as well as any future ones.  Note that multiple TE-
   PATH-BINDING TLVs with different Binding Types MAY be present for the
   same LSP.

It seems that we have defined a couple pairs of binding types that contain
redundant information, e.g., the SRv6 SID of BT=2 might be expected to be
the same SRv6 SID contained in BT=3.  If such semantically "similar"
binding types appear together in the same LSP, is there any requirement
for them to be internally consistent (when not indicating removal, at
least)?  Is a recipient allowed/required to verify such consistency?  What
is the error handling behavior if inconsistency is detected?
If the intent is that a node might usefully desire to assign multiple
distinct BSID values of the same type that correspond to the same path, we
probably want to say so explicitly, including what a potential motivation
would be.  (Is there perhaps some privacy benefit to be had by avoiding
certain types of correlation?  I do not really see one, based on my
limited knowledge of the ways in which these paths will be distributed,
but could be missing something.)

Section 4.1

   *  Endpoint Behavior: 2 octets.  The Endpoint Behavior code point for
      this SRv6 SID as per the IANA subregistry called "SRv6 Endpoint
      Behaviors", created by [RFC8986].  When the field is set with the
      value 0, the endpoint behavior is considered unknown.

If the primary purpose of the Binding SID is bind to a policy, which is
then instantiated as (usually) a list of SIDs, it seems like we might need
to say a bit more about why there is additionally a single Endpoint
Behavior value associated with the BSID.  One might surmise that there is
a combined action of imposing the new list of SIDs and also having an
endpoint behavior, e.g., to send the outgoing packet over a tunnel or
cross-connect after having imposed the new SID list, but it's a fairly
weak inference and could stand to be made explicit.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    LB Length  |    LN Length  | Fun. Length   |  Arg. Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should we say something (whether here or in the security considerations)
about needing to check that the sum of these lengths is less than or equal
to 128?

Section 5

   The binding value is allocated by the PCC and reported to a PCE via a
   PCRpt message.  If a PCE does not recognize the TE-PATH-BINDING TLV,

Should we forward-reference §8 as an exception to this, where the PCE is
actually doing the allocation?

   Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
   LSP object.  This signifies the presence of multiple binding SIDs for
   the given LSP.  In the case of multiple TE-PATH-BINDING TLVs, the
   existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP
   object.  [...]
[...]
   R flag set to 1.  If a PCC wishes to modify a previously reported
   binding, it MUST withdraw the former binding value (with R flag set
   in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING
   TLV containing the new binding value.  Note that other instances of
   TE-PATH-BINDING TLVs that are unchanged MAY also be included.

This implies but does not state explicitly that if the unchanged instances
are not included, they still remain associated with the LSP in the state
on the PCE.  Should it be stated explicitly?

   of the TLV to 4).  A PCE can also request a PCC to allocate a binding
   value at the time of initiation by sending a PCInitiate message with
   an empty TE-PATH-BINDING TLV.  [...]

I wonder if "empty" is really the best term, as in other contexts one
might assume that an "empty" TLV has length zero, rather than the length
four that we mean here (with just the "binding value" field being empty).

                                  Only one such instance of empty TE-
   PATH-BINDING TLV SHOULD be included in the LSP object and others
   ignored on receipt.  [...]

Is this one instance total or one instance per BT?

Separately, is a TLV with empty binding value but the R flag set invalid?

Section 8

   A new P flag in the LSP object [RFC8231] is introduced to indicate
   that the allocation needs to be made by the PCE:

Is there a mnemonic for why this flag is named 'P' vs. some other letter?

      the PCC.  Further, a PCE MUST set this bit to 0 and include a TE-
      PATH-BINDING TLV in the LSP object if it wishes to indicate that
      the binding label/SID should be allocated by the PCC as described
      in Section 5.

In Section 5 we described how the use of a zero-length binding value
indicates that the PCE requests for the PCC to allocate the BSID value.
Why do we need two ways to do the same thing?  (Well, presumably "there's
nothing else to put in the field", at least for this flag bit, but we
could at least frame the discussion in the document more like "this one is
authoritative, but when we are doing PCC allocation [as indicated by the
authoritative setting], we have to also set this field accordingly in
order to remain self-consistent" or be careful to always mention both
together as a single unit.  I do note the later text that P=1 is only
valid when use of the RFC 9050 procedures has been negotiated.)

   It is assumed that the label range to be used by a PCE is known and
   set on both PCEP peers.  The exact mechanism is out of the scope of
   [RFC9050] or this document.  [...]

I note that RFC 9050 referenced draft-li-pce-controlled-id-space as a
potential future expansion that could allow advertising the range in-band
via a PCEP extension, but that draft seems to have expired in August 2021.
So maybe it's not something we should mention again here...

Section 10

   The security considerations described in [RFC5440], [RFC8231],
   [RFC8281] and [RFC8664] are applicable to this specification.  No

I think we need to add RFC 9050 to this list; the things that can go wrong
with PCE allocation definitely apply here (per §8).

   As described in [RFC8664], SR allows a network controller to
   instantiate and control paths in the network.  A rogue PCE can
   manipulate binding SID allocations to move traffic around for some
   other LSP that uses BSID in its SR-ERO.  Note that path {A, B, BSID}
   can be misdirected just by assigning the BSID value to a different
   LSP making it a lot easier to misdirect traffic (and harder to
   detect).

This could probably be made more crisp.  I propose
NEW:
% As described in [RFC9402] and [RFC8664], SR intrinsically involves an
% entity (whether head-end or a central network controller) controlling
% and instantiating paths in the network without the involvement of
% (other) nodes along those paths.  Binding SIDs are in effect shorthand
% aliases for longer path representations, and the alias expansion is in
% principle known only by the node that acts on it.  In this document,
% the expansion of the alias is shared between PCC and PCE, and rogue
% actions by either PCC or PCE could result in shifting or misdirecting
% traffic in ways that are hard for other nodes to detect.  In
% particular, when a PCE propagates paths of the form {A, B, BSID} to
% other entities, the BSID values are opaque, and a rogue PCE can
% substitute a BSID from a different LSP in such paths to move traffic
% without the recipient of the path knowing the ultimate destination.

   Note that in case of BT as 3, the manipulation of SID structure could
   be exploited by falsifying the various length values.

Similarly, I propose
NEW:
% The case of BT=3 provides additional opportunities for malfeasance, as
% it purports to convey information about internal SRv6 SID structure.
% There is no mechanism defined to validate this internal structure
% information, and mischaracterizing the division of bits into locator
% block, locator node, function, and argument can result in different
% interpretation of the bits by PCC and PCE.  Most notably, shifting bits
% into or out of the "argument" is a direct vector for affecting
% processing, but other attacks are also possible.

   and PCCs belonging to the same administrative authority, using
   Transport Layer Security (TLS) [RFC8253], as per the recommendations
   and best current practices in BCP195 [RFC7525] (unless explicitly set
   aside in [RFC8253]).

For information, the UTA WG is currently working on a "bis" of RFC 7525.
But I do not think you should make any change to this document at this
time; I just mention it for general awareness.

Section 12.2

Just to confirm my understanding: there are no unallocated flags left in
the LSP Object flag field?  Would we then be forced to either define a new
object or use sentinel (zero-length) TLVs for things that would otherwise
be treated as flags?
In particular (and related to discuss point (2)), why is a flag in the
TE-PATH-BINDING TLV flag field not suitable and a flag in the toplevel LSP
Object necessary?

NITS

Section 1

   This document specifies an extension to PCEP to manage of binding
   label/SID for both SR and non-SR paths.

I think s/manage of binding/manage the binding of/.

Section 1.2

   To implement the needed changes to PCEP, in this document, we
   introduce a new OPTIONAL TLV that a PCC can use in order to report
   the binding label/SID associated with a TE LSP, or a PCE to request a
   PCC to allocate a specific binding label/SID value.  This TLV is
   intended for TE LSPs established using RSVP-TE, SR, or any other
   future method.  [...]

This sentence reads oddly to me, in that there's some kind of "type
mismatch" between RSVP-TE and SR.  That is, RSVP-TE is a protocol that I
run and it "computes" paths for me.  But I see Segment Routing as a mode
of operation that lets me use a path I already know, without maintaining
per-path state on each node in the path.  It doesn't compute the path for
me, rather, it's something I can do once I know the desired path from some
out-of-band mechanism.  So while it may be okay to say that I have a TE
LSP "established using SR" in isolation (in that the headend just asserts
the path and thereby "establishes" an LSP), to put it right next to having
a TE LSP "established using RSVP-TE" seems to lack a certain parallelism
of structure that I'm expecting.

                   Also, in the case of SR-TE LSPs, the TLV can carry a
   binding label (for SR-TE path with MPLS data-plane) or a binding IPv6
   SID (e.g., IPv6 address for SR-TE paths with IPv6 data-plane).

I am not sure what role the word "also" is intended to play here, and
think that the paragraph would make sense if it was removed.

Section 4.1

Please make the SRv6 Binding SID field in Figure 4 taller in some fashion
to match its 16-byte nature.