Subject: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 08:59:53 -0800

John Scudder has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: 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-spring-segment-routing-policy/

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

I’ve done an initial review of this document and have several concerns I’d like
to discuss. I apologize for not also providing a full review as comments in
this ballot, I judged it more important to begin the discussion about these
points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and
indicated in the title page header. This is appropriate for a specification of
packet steering into an SR policy needing interoperability between the
ingress/source of the policy instantiation and the egress/destination of the
policy termination.”

I realize it’s unusual to ask to discuss a shepherd writeup rather than the
spec itself, but I think this one rises to the level. My concern is that this
description (needing interoperability between the ingress and the egress)
doesn’t comport with my understanding of the Segment Routing architecture.
Surely, one of the key value propositions of SR is that it’s stateless
everywhere other than the headend? Indeed, that’s stated in the abstract. SR
doesn’t require the egress to even understand that it IS an egress of a SR
Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be wrong.
:-( And that in turn leads me to ask, whether the track really is right. It
seems to me that in most respects this is more an Informational document than a
standards track one. That’s not a value judgement in any respect, just a
statement of fact — for the most part, it doesn’t seem as though the
information found in this document is needed in order to interoperate with
another system. (Section 8.8 is an exception, I discuss that separately.)

Anyway, not to get too far ahead of myself, let’s start by working on this
question: is the shepherd writeup correct in saying that interoperability
between headend and tailend is required? If so, can someone please characterize
the nature of that interoperability, and put it in the context of SR’s
stateless nature?

2. It seems to me an unusual practice for this document to be defining
semantics and even reserving values in a field allocated by a different
document, by a different WG. I’m referring here to the so-called “‘Color-Only’
bits” discussed in Section 8.8.

- I would be more comfortable if the work were all done in one place, to the
extent possible.

- Given the fact this document is reaching in to a registry normally managed by
IDR, was there any discussion with the IDR group? I don't see any evidence of a
courtesy notification of the last call when I look at the IDR mailing list
archive.

I’ve also emailed the IDR list about this in connection with
draft-ietf-idr-segment-routing-te-policy, see
https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/

Relating this back to my previous question, it’s evident that if this document
is going to define semantics for the Color Extended Community Flags, then that
makes it Standards Track because there is an interoperability factor to take
into account (that's been imported from IDR). A more ideal solution would be to
take care of that in the IDR document rather than putting it in this
“architecture” document, though. Surely, this kind of detail is implementation,
not architecture?  Indeed, Ketan said in his reply to Matthew Bocci's RTG
review, "Given that this is an architecture document, it describes the
architecture and not really the protocol mechanisms"... but this section seems
to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational
clearly has to be normative with the document as it stands.
draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for
example its use in §2.4 seems like it may rise to the "normative" level, §2.5
almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake
because this document defines semantics for a field that isn’t even allocated
until and unless draft-ietf-idr-segment-routing-te-policy is published.

4. In §2.1 you talk about the signaling of symbolic names for candidate paths.
Although you are careful to say that such symbolic names are only used for
presentation purposes, it seems to me they still could be considered a new
potential source of vulnerability, since a string that has no sanity-checking
whatsoever applied by the protocol can display literally anything to an
operator viewing it. Shouldn’t this be addressed in your Security
Considerations? (For an example of a related Security Considerations, see RFC
9003. It’s probably not the best example, but it’s the one I had at my
fingertips…)

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

As noted in my DISCUSS, these comments are unfinished but I thought I’d give
you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I’d like
to talk about it a little more: why have you chosen to restrict symbolic names
to ASCII? UTF-8 is the more usual choice in this context; indeed
implementations may have to go to extra effort to scrub their input to insure
that only ASCII is present. BCP 18 doesn’t require you to internationalize your
strings, of course, it gives you two options, of which you have (sort of, you
don't have the "US-") followed the latter:

   This document does not mandate a policy on name internationalization,
   but requires that all protocols describe whether names are
   internationalized or US-ASCII.

But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough
to invite the question.

If you do stick with ASCII as currently written, might you add text mandating
that implementations scrub their input to prevent non-ASCII characters from
being accepted?

---

From: James Guichard <[email-masked]>
Date: Wed, 16 Feb 2022 17:04:21 +0000

Hi John,

This is timely as I actually made some changes to the shepherd writeup this morning to make it clearer (I hope). I changed the text you are referring to as follows:

Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the policy source / controller of the policy instantiation and the traffic head end as the destination of the policy termination.

Jim

-----Original Message-----
From: John Scudder via Datatracker <[email-masked]> 
Sent: Wednesday, February 16, 2022 12:00 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; James Guichard <[email-masked]>
Subject: John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1314e98385084ec229d608d9f16dc130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806275962576860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HFqlQmZekrMmTL216lgNlzrjPu4QcQ9o0htAl%2BzTPr0%3D&amp;reserved=0
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-segment-routing-policy%2F&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1314e98385084ec229d608d9f16dc130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806275962576860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XUC%2FNAZ63ADlW4ShT1fsrFrQDb1l3k2%2BiJisFKSBoiY%3D&amp;reserved=0

I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”

I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture.
Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be wrong.
:-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)

Anyway, not to get too far ahead of myself, let’s start by working on this
question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’
bits” discussed in Section 8.8.

- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don't see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.

I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FyCcZdStmTR-FLUYGHTsLLBv5aWo%2F&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1314e98385084ec229d608d9f16dc130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806275962576860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4NQebR3Fiyc6qt1IYAZU4IamNand%2Fh84yTqyNHSG4QM%3D&amp;reserved=0

Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands.
draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.

4. In §2.1 you talk about the signaling of symbolic names for candidate paths.
Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my
fingertips…)

As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I’d like to talk about it a little more: why have you chosen to restrict symbolic names to ASCII? UTF-8 is the more usual choice in this context; indeed implementations may have to go to extra effort to scrub their input to insure that only ASCII is present. BCP 18 doesn’t require you to internationalize your strings, of course, it gives you two options, of which you have (sort of, you don't have the "US-") followed the latter:

But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough to invite the question.

If you do stick with ASCII as currently written, might you add text mandating that implementations scrub their input to prevent non-ASCII characters from being accepted?

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 00:33:43 +0530

Hi John,

Thanks for your review and please check inline below for responses.

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

KT> I see that Jim (doc shepherd) has clarified. The document aims to
standardize the SR Policy constructs and related behaviors. It provides the
basis then for protocol extensions (e.g. PCEP and BGP) and the YANG model
to follow by a normative reference to it.

> https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/

KT> Thanks. I will work on addressing them as a co-author of that IDR
document.

> to be an exception to that aspiration.

KT> The resolution of BGP service routes over the underlying forwarding
constructs may be seen by some as more of a "system" or "forwarding" aspect
than a BGP protocol aspect. This is in the architecture because operators
who have deployed SR Policies expected the same consistent resolution
behavior across headed routers from different vendors.

> until and unless draft-ietf-idr-segment-routing-te-policy is published.

KT> It is the other way round. The SPRING document specifies
the information model and the constructs of the SR Policy. The IDR document
is primarily about signaling of the SR Policy from a controller to the
headend using the new SR Policy SAFI (73) - as such it does refer
normatively to the SPRING SR Policy.

> 9003. It’s probably not the best example, but it’s the one I had at my

KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As such, I
am not aware of security issues around printable ASCII - please do point me
to any references. Also note that this document does not specify protocol
encodings where some extra verbiage is normally required (e.g. that it is
signaled without NULL, handling truncation/overruns, etc.).

KT> As discussed in the WG, we are sticking to printable ASCII. When the
encoding is specified to be printable ASCII, it is expected that
implementations valid that.

Thanks,
Ketan

---

From: John Scudder <[email-masked]>
Date: Wed, 16 Feb 2022 19:42:00 +0000

Hi Ketan,

> On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar <[email-masked]> wrote:
> 
> Hi John,
> 

Thanks for your reply. For this response I’m confining myself to points 3 and 4.

[snip]

> KT> It is the other way round. The SPRING document specifies the information model and the constructs of the SR Policy. The IDR document is primarily about signaling of the SR Policy from a controller to the headend using the new SR Policy SAFI (73) - as such it does refer normatively to the SPRING SR Policy. 

Without getting too far into the details on this one, you just can’t write a spec about a field (or set of flags) that doesn’t (don’t) exist. The way you’ve structured these two documents, that field (I will call it a field) doesn’t formally exist until and unless draft-ietf-idr-segment-routing-te-policy is published. Therefore, draft-ietf-spring-segment-routing-policy has a hard dependency on it, and this is one thing that makes a reference “normative”. These would hardly be the first two documents to normatively reference one another, it’s what the RFC Editor uses clusters for (amongst other things).

You could also resolve this particular issue by restructuring the documents to make them more self-contained. If you do, then perhaps we would need to revisit the other references to draft-ietf-idr-segment-routing-te-policy in more detail — but until then it wouldn’t be time well spent, as the §8.8.1 reference is sufficient to cement the requirement.

> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As such, I am not aware of security issues around printable ASCII - please do point me to any references.

You’re thinking too much like a protocol designer. The kind of concern I’m thinking about has to do with using the string as a vector to put some words in front of an operator, as part of a larger social engineering attempt. I don’t have a detailed attack scenario to paint for you, but a quick sketch is along the lines of 

- Attacker manages to inject a candidate path with the name “Big_Bank_Low_Latency”
	- ProTip: the candidate path does not actually terminate at Big_Bank
- Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_Bank traffic onto that path

You get the idea, I hope.

> Also note that this document does not specify protocol encodings where some extra verbiage is normally required (e.g. that it is signaled without NULL, handling truncation/overruns, etc.).

But yet it does specify the precise character set to be used, and a near-obsolescent one at that. Why is that? I mean, I don’t hate ASCII, but I just find it odd and assume you actually have a reason for it, instead of taking either the option of leaving the character set unspecified (as you point out there are many such details you don’t concern yourself with in this document) or if specifying it, using UTF-8 or similar.

> KT> As discussed in the WG, we are sticking to printable ASCII. When the encoding is specified to be printable ASCII, it is expected that implementations valid that.

I admire your optimism.

—John