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

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 7 Mar 2022 11:50:32 +0530

Hi John,

We've just posted an update to the draft for the Color-Only steering modes
and the allocation of bits from the BGP Color Extended community.

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

This is along the lines of your suggestions and the ongoing discussions on
the IDR list for the draft-ietf-idr-segment-routing-te-policy :
https://mailarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fFh5F9wlQA/

Looking forward to your response on your discuss & comments on this
document. Please let know of any outstanding discuss or comments that
remain to be addressed in the document.

Thanks,
Ketan

On Thu, Feb 17, 2022 at 1:12 AM John Scudder <[email-masked]> wrote:

> Hi Ketan,
>
> > On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar <[email-masked]>
> wrote:
> >
> > Hi John,
> >
> > Thanks for your review and please check inline below for responses.
>
> Thanks for your reply. For this response I’m confining myself to points 3
> and 4.
>
> [snip]
>
> > 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.
> >
> > 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.
>
> > 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…)
> >
> > 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

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Mar 2022 22:44:05 +0530

Hi John,

Please let us know your feedback on whether the responses and draft updates
address your concerns.

The latest version is

Thanks,
Ketan

On Mon, Mar 7, 2022 at 11:50 AM Ketan Talaulikar <[email-masked]>
wrote:

>> > example its use in §2.4 seems like it may rise to the "normative"
>> level, §2.5
>> 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
>> 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
>> > 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

---

From: John Scudder <[email-masked]>
Date: Thu, 17 Mar 2022 18:52:43 +0000

Noted and I’ll get back to you on this as soon as I can.

—John

> On Mar 17, 2022, at 1:14 PM, Ketan Talaulikar <[email-masked]> wrote:
> 
> 
> Hi John,
> 
> Please let us know your feedback on whether the responses and draft updates address your concerns.
> 
> The latest version is https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-20
> 
> Thanks,
> Ketan
> 
> 
> 
> On Mon, Mar 7, 2022 at 11:50 AM Ketan Talaulikar <[email-masked]> wrote:
> Hi John,
> 
> We've just posted an update to the draft for the Color-Only steering modes and the allocation of bits from the BGP Color Extended community.
> 
> This is along the lines of your suggestions and the ongoing discussions on the IDR list for the draft-ietf-idr-segment-routing-te-policy : https://mailarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fFh5F9wlQA/ 
> 
> Looking forward to your response on your discuss & comments on this document. Please let know of any outstanding discuss or comments that remain to be addressed in the document.
> 
> Thanks,
> 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]
> 
> > 3. Related to the above, at least one of the references listed as informational
> > example its use in §2.4 seems like it may rise to the "normative" level, §2.5
> > because this document defines semantics for a field that isn’t even allocated
> > 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.
> 
> > 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
> > Considerations? (For an example of a related Security Considerations, see RFC
> > 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
> 
> > 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

---

From: John Scudder <[email-masked]>
Date: Mon, 21 Mar 2022 21:24:32 +0000

Hi Ketan,

You asked "whether the responses and draft updates address [my] concerns”. I’d say that while I’m not completely happy about certain things (e.g., I remain unconvinced that the companion IDR doc shouldn’t be a normative reference) I don’t need to continue holding a DISCUSS on them: we’ve had a discussion, we don’t completely agree, these things happen. On point 4 however, I don’t think our discussion has concluded. At least, if you replied to this, I missed it:

> On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=[email-masked]> wrote:
> 

More snipped, but this is the meat of it. In case you haven’t looked at RFC 9003’s security section, here’s a snip from it:

   As BGP Shutdown Communications are likely to appear in syslog output,
   there is a risk that carefully constructed Shutdown Communication
   might be formatted by receiving systems in a way to make them appear
   as additional syslog messages. 

(FWIW, I didn’t contribute that text.)

Please don’t obsess about “syslog” in the example above, it’s not central to the point, just like UTF-8 vs ASCII isn’t central. The point, again, is that by introducing a way for an attacker to cause a target system to display arbitrary strings, it would seem reasonable to wonder if that creates an opportunity for mischief that doesn’t ordinarily exist in our protocols, involving misleading people looking at the displayed string in a user interface.

There are various ways this concern could be mitigated (if we were to come to agreement that it’s even a concern). One would be to remove the “signal arbitrary strings” idea; this is clearly the solidest way to do it. Another would be to mandate (or strongly suggest) that symbolic names gleaned from something other than configuration be displayed in such a way as to make the operator aware of their status. At a minimum, one might add a paragraph or two identifying the concern. I’m sure there are other things that could be contemplated.

Regards,

—John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Mar 2022 00:14:52 +0100

Hi John,

The point, again, is that by introducing a way for an attacker to cause a
> target system to display arbitrary strings, it would seem reasonable to
> wonder if that creates an opportunity for mischief that doesn’t ordinarily
> exist in our protocols, involving misleading people looking at the
> displayed string in a user interface.
>

Hmmm while I am not clear what "our protocols" mean in this context I do
see a number of cases where protocols have the ability to carry free form
text.

For example, how about RFC8203 ?

There are few other works in progress to also add such ability. So above
all I am trying to sense if your above comment is a specific
to draft-ietf-spring-segment-routing-policy (which is by design *strongly*
limited to the same administration so it would be pretty weird to be
concerned about it) or is it more general in nature ?

Thx,
Robert

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 22 Mar 2022 14:24:44 +0530

Hi John,

I dug into my emails and you are right that while we had a discussion on
point 4 (i.e. security considerations associated with the use of symbolic
names), it was not concluded. My apologies for the same.

It might be helpful to place a context on why the draft uses symbolic names
in the first place. The closest analogies that come to my mind are tunnels
(different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These
constructs have had symbolic names associated with them for a long time now
- both for local use on routers (some implementation-specific - others
specified by IETF) and also signaled via routing protocols. Operators are
therefore quite familiar with their usage and hence their introduction in
the SR Policy construct. I don't believe the WG would want to take the
option of their removal (it was a suggested option).

Then we get to option of adding specific text to the draft (in the security
considerations?) that would discuss your concerns. Such text may be
addressed to implementators and/or operators. As mentioned above, the use
of symbolic names for constructs similar to SR Policy name and SR Policy
Candidate Path name is not "new" for both sets of readers. Therefore, I am
not sure if we need to cover or add anything new in this document and I
could not find text that I could borrow from other RFCs or point to other
RFCs. e.g., https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2

I did look at RFC9003 but its context is very different. From your DISCUSS
comment, I see that your concern is that a string does not have any sanity
checking - the operator is free to use any text. I agree. Do we want
implementations to restrict something? Do we want to give some naming
guidelines or precautions to the operators?

In a previous response, your suggestions for the text for operators were
(somewhat?) of the nature - "beware the name of the SR Policy may not
actually be correct or may be misleading because someone might have hacked
into the network". I am not sure if something of that nature helps. If the
names stop being meaningful then they are no more relevant? Isn't the
security aspect to be taken care of here is to prevent hacking? Something
beyond the scope of this draft?

I'll admit that I am running out of ideas on what would be a meaningful
text to add to address your concerns. Would appreciate some text suggestion
that is relevant to this specific context.

Thanks,
Ketan

On Tue, Mar 22, 2022 at 2:54 AM John Scudder <[email-masked]> wrote:

> Hi Ketan,
>
> You asked "whether the responses and draft updates address [my] concerns”.
> I’d say that while I’m not completely happy about certain things (e.g., I
> remain unconvinced that the companion IDR doc shouldn’t be a normative
> reference) I don’t need to continue holding a DISCUSS on them: we’ve had a
> discussion, we don’t completely agree, these things happen. On point 4
> however, I don’t think our discussion has concluded. At least, if you
> replied to this, I missed it:
>
> More snipped, but this is the meat of it. In case you haven’t looked at
> RFC 9003’s security section, here’s a snip from it:
>
> Please don’t obsess about “syslog” in the example above, it’s not central
> to the point, just like UTF-8 vs ASCII isn’t central. The point, again, is
> that by introducing a way for an attacker to cause a target system to
> display arbitrary strings, it would seem reasonable to wonder if that
> creates an opportunity for mischief that doesn’t ordinarily exist in our
> protocols, involving misleading people looking at the displayed string in a
> user interface.
>
> There are various ways this concern could be mitigated (if we were to come
> to agreement that it’s even a concern). One would be to remove the “signal
> arbitrary strings” idea; this is clearly the solidest way to do it. Another
> would be to mandate (or strongly suggest) that symbolic names gleaned from
> something other than configuration be displayed in such a way as to make
> the operator aware of their status. At a minimum, one might add a paragraph
> or two identifying the concern. I’m sure there are other things that could
> be contemplated.
>
> Regards,
>
> —John

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 17:50:29 +0000

Hi Ketan,

Thanks as always for your quick reply.

> On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar <[email-masked]> wrote:
> 
> 
> Hi John,
> 
> I dug into my emails and you are right that while we had a discussion on point 4 (i.e. security considerations associated with the use of symbolic names), it was not concluded. My apologies for the same.
> 
> It might be helpful to place a context on why the draft uses symbolic names in the first place. The closest analogies that come to my mind are tunnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These constructs have had symbolic names associated with them for a long time now - both for local use on routers (some implementation-specific - others specified by IETF)

Sure. Anything local to the router isn’t related to my concern, which is specific to the opportunity for a remote attacker to mislead someone on the local router. I hope it’s clear by now that I have no issue with associating a symbolic name with a SR Policy (or any other thing), as such.

> and also signaled via routing protocols.

Now that you point it out, I do see a few such, e.g. the SYMBOLIC-PATH-NAME in RFC 8231. That particular example has arguably different threat properties since the relationship between a PCE and its clients isn’t mediated through other routers; the trust relationship is clearer and the “remote attacker” is not so very remote. But I imagine there are other examples to be found, and I don’t want to split hairs on this detail.

> Operators are therefore quite familiar with their usage and hence their introduction in the SR Policy construct. I don't believe the WG would want to take the option of their removal (it was a suggested option).

I didn’t really expect you to; I was just laying out some points in the solution space.

> Then we get to option of adding specific text to the draft (in the security considerations?) that would discuss your concerns. Such text may be addressed to implementators and/or operators. As mentioned above, the use of symbolic names for constructs similar to SR Policy name and SR Policy Candidate Path name is not "new" for both sets of readers. Therefore, I am not sure if we need to cover or add anything new in this document and I could not find text that I could borrow from other RFCs or point to other RFCs. e.g., https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2
> 
> I did look at RFC9003 but its context is very different. From your DISCUSS comment, I see that your concern is that a string does not have any sanity checking - the operator is free to use any text.

Correct. As long as you assume good will on the part of “the operator” it’s all good. If you start thinking in terms of an attacker in some distant part of the network injecting a policy, it becomes potentially concerning. 

> I agree. Do we want implementations to restrict something? Do we want to give some naming guidelines or precautions to the operators?

I don’t think the concern is addressable on the origination side, since it assumes a bad actor to begin with, and they’re not going to be bothered by what we write in an RFC. That was why in my suggestion I was thinking in terms of display conventions. I’m not super excited by my own idea, though, because it reminds me uncomfortably much of the disclaimer my IT department slaps on every incoming email, “[External Email. Be cautious of content]”. It’s not particularly actionable, and it’s annoying. :-(

> In a previous response, your suggestions for the text for operators were (somewhat?) of the nature - "beware the name of the SR Policy may not actually be correct or may be misleading because someone might have hacked into the network". I am not sure if something of that nature helps. If the names stop being meaningful then they are no more relevant? Isn't the security aspect to be taken care of here is to prevent hacking? Something beyond the scope of this draft?

“Security is everyone’s responsiblity.” 

> I'll admit that I am running out of ideas on what would be a meaningful text to add to address your concerns. Would appreciate some text suggestion that is relevant to this specific context.

In the end, maybe it’s true that there’s not much to be done, which sucks, but that’s life. But even if we throw our hands in the air and say “nothing to be done”, which is I think where we’re getting to, I don’t think there would be any harm in putting a sentence or two in the Security Considerations such as you mention just above. Something along the lines of,

“In Section 2.1 we mention that a symbolic name MAY be signaled along with a candidate path. While the value of symbolic names for display clarity is indisputable, as with any unrestricted freeform text received from external parties, there can be no absolute assurance that the information the text purports to show is accurate or even truthful. For this reason, users of implementations that display such information would be well-advised not to rely on it without question. Furthermore, implementations that display such information might wish to display it in such a fashion as to differentiate it from known-good information. (Such display conventions are inherently implementation-specific; one example might be use of a distinguished text color or style for information that should be treated with caution.)”

Let’s be honest, the “oooh be careful” text provides about as much protection as wet tissue paper, and displaying the string in magenta not a whole lot more than that — but it’s still better to disclose the cocnern than not to.

Regards,

—John

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 22 Mar 2022 23:41:42 +0530

Hi John,

Thanks for your guidance with the text. Very much appreciated - especially
in the middle of the busy IETF week.

I've just posted an update to the draft with slight modifications to your
text (so as to cover both sec 2.1 and 2.6 and suggest the use of the
well-defined identifiers as a mitigation approach instead of relying solely
on the symbolic names.

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

Please let us know if this addresses your concerns.

Thanks,
Ketan

On Tue, Mar 22, 2022 at 11:20 PM John Scudder <[email-masked]> wrote:

> > It might be helpful to place a context on why the draft uses symbolic
> names in the first place. The closest analogies that come to my mind are
> tunnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths).
> These constructs have had symbolic names associated with them for a long
> time now - both for local use on routers (some implementation-specific -
> others specified by IETF)
>
> Sure. Anything local to the router isn’t related to my concern, which is
> specific to the opportunity for a remote attacker to mislead someone on the
> local router. I hope it’s clear by now that I have no issue with
> associating a symbolic name with a SR Policy (or any other thing), as such.
>
> Now that you point it out, I do see a few such, e.g. the
> SYMBOLIC-PATH-NAME in RFC 8231. That particular example has arguably
> different threat properties since the relationship between a PCE and its
> clients isn’t mediated through other routers; the trust relationship is
> clearer and the “remote attacker” is not so very remote. But I imagine
> there are other examples to be found, and I don’t want to split hairs on
> this detail.
>
> > Operators are therefore quite familiar with their usage and hence their
> introduction in the SR Policy construct. I don't believe the WG would want
> to take the option of their removal (it was a suggested option).
>
> > Then we get to option of adding specific text to the draft (in the
> security considerations?) that would discuss your concerns. Such text may
> be addressed to implementators and/or operators. As mentioned above, the
> use of symbolic names for constructs similar to SR Policy name and SR
> Policy Candidate Path name is not "new" for both sets of readers.
> Therefore, I am not sure if we need to cover or add anything new in this
> document and I could not find text that I could borrow from other RFCs or
> point to other RFCs. e.g.,
> https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2
> >
> > I did look at RFC9003 but its context is very different. From your
> DISCUSS comment, I see that your concern is that a string does not have any
> sanity checking - the operator is free to use any text.
>
> Correct. As long as you assume good will on the part of “the operator”
> it’s all good. If you start thinking in terms of an attacker in some
> distant part of the network injecting a policy, it becomes potentially
> concerning.
>
> > I agree. Do we want implementations to restrict something? Do we want to
> give some naming guidelines or precautions to the operators?
>
> I don’t think the concern is addressable on the origination side, since it
> assumes a bad actor to begin with, and they’re not going to be bothered by
> what we write in an RFC. That was why in my suggestion I was thinking in
> terms of display conventions. I’m not super excited by my own idea, though,
> because it reminds me uncomfortably much of the disclaimer my IT department
> slaps on every incoming email, “[External Email. Be cautious of content]”.
> It’s not particularly actionable, and it’s annoying. :-(
>
> In the end, maybe it’s true that there’s not much to be done, which sucks,
> but that’s life. But even if we throw our hands in the air and say “nothing
> to be done”, which is I think where we’re getting to, I don’t think there
> would be any harm in putting a sentence or two in the Security
> Considerations such as you mention just above. Something along the lines of,
>
> “In Section 2.1 we mention that a symbolic name MAY be signaled along with
> a candidate path. While the value of symbolic names for display clarity is
> indisputable, as with any unrestricted freeform text received from external
> parties, there can be no absolute assurance that the information the text
> purports to show is accurate or even truthful. For this reason, users of
> implementations that display such information would be well-advised not to
> rely on it without question. Furthermore, implementations that display such
> information might wish to display it in such a fashion as to differentiate
> it from known-good information. (Such display conventions are inherently
> implementation-specific; one example might be use of a distinguished text
> color or style for information that should be treated with caution.)”
>
> Let’s be honest, the “oooh be careful” text provides about as much
> protection as wet tissue paper, and displaying the string in magenta not a
> whole lot more than that — but it’s still better to disclose the cocnern
> than not to.
>
> Regards,
>
> —John
>
> > Thanks,
> > Ketan
> >
> >> You asked "whether the responses and draft updates address [my]
> concerns”. I’d say that while I’m not completely happy about certain things
> (e.g., I remain unconvinced that the companion IDR doc shouldn’t be a
> normative reference) I don’t need to continue holding a DISCUSS on them:
> we’ve had a discussion, we don’t completely agree, these things happen. On
> point 4 however, I don’t think our discussion has concluded. At least, if
> you replied to this, I missed it:
> >>
> >> > 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
> >> >
> >> Please don’t obsess about “syslog” in the example above, it’s not
> central to the point, just like UTF-8 vs ASCII isn’t central. The point,
> again, is that by introducing a way for an attacker to cause a target
> system to display arbitrary strings, it would seem reasonable to wonder if
> that creates an opportunity for mischief that doesn’t ordinarily exist in
> our protocols, involving misleading people looking at the displayed string
> in a user interface.
> >>
> >> There are various ways this concern could be mitigated (if we were to
> come to agreement that it’s even a concern). One would be to remove the
> “signal arbitrary strings” idea; this is clearly the solidest way to do it.
> Another would be to mandate (or strongly suggest) that symbolic names
> gleaned from something other than configuration be displayed in such a way
> as to make the operator aware of their status. At a minimum, one might add
> a paragraph or two identifying the concern. I’m sure there are other things
> that could be contemplated.
> >>
> >> Regards,
> >>
> >> —John
> >
>

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 18:20:57 +0000

Looks good, thanks. I’ve cleared my discuss, thanks for your work on this.

—John

On Mar 22, 2022, at 2:11 PM, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

Thanks for your guidance with the text. Very much appreciated - especially in the middle of the busy IETF week.

I've just posted an update to the draft with slight modifications to your text (so as to cover both sec 2.1 and 2.6 and suggest the use of the well-defined identifiers as a mitigation approach instead of relying solely on the symbolic names.

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22__;!!NEt6yMaO-gk!TPdw7ZdqeCRS2htB1JCtU9oqzfUS0akoP3b2FGoZfrye6NBL-A_CpxzRhVlz1g$>

Thanks,
Ketan

On Tue, Mar 22, 2022 at 11:20 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

> On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> Hi John,
>

> Then we get to option of adding specific text to the draft (in the security considerations?) that would discuss your concerns. Such text may be addressed to implementators and/or operators. As mentioned above, the use of symbolic names for constructs similar to SR Policy name and SR Policy Candidate Path name is not "new" for both sets of readers. Therefore, I am not sure if we need to cover or add anything new in this document and I could not find text that I could borrow from other RFCs or point to other RFCs. e.g., https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8231.html*section-7.3.2__;Iw!!NEt6yMaO-gk!TPdw7ZdqeCRS2htB1JCtU9oqzfUS0akoP3b2FGoZfrye6NBL-A_Cpxzu_nJ4ug$>
>

Regards,

—John

> Thanks,
> Ketan
>
> On Tue, Mar 22, 2022 at 2:54 AM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
>> Hi Ketan,
>>
>> > On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
>> >

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 00:00:37 +0530

Thanks John for your inputs and suggestions.

Thanks,
Ketan

On Tue, 22 Mar, 2022, 11:51 pm John Scudder, <[email-masked]> wrote:

> On Mar 22, 2022, at 2:11 PM, Ketan Talaulikar <[email-masked]>
> wrote:
>
>
>
> Hi John,
>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22__;!!NEt6yMaO-gk!TPdw7ZdqeCRS2htB1JCtU9oqzfUS0akoP3b2FGoZfrye6NBL-A_CpxzRhVlz1g$>
>
>> > I dug into my emails and you are right that while we had a discussion
>> on point 4 (i.e. security considerations associated with the use of
>> symbolic names), it was not concluded. My apologies for the same.
>> >
>> <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8231.html*section-7.3.2__;Iw!!NEt6yMaO-gk!TPdw7ZdqeCRS2htB1JCtU9oqzfUS0akoP3b2FGoZfrye6NBL-A_Cpxzu_nJ4ug$>
>> >
>> > I agree. Do we want implementations to restrict something? Do we want
>> to give some naming guidelines or precautions to the operators?
>>
>> I don’t think the concern is addressable on the origination side, since
>> it assumes a bad actor to begin with, and they’re not going to be bothered
>> by what we write in an RFC. That was why in my suggestion I was thinking in
>> > In a previous response, your suggestions for the text for operators
>> were (somewhat?) of the nature - "beware the name of the SR Policy may not
>> In the end, maybe it’s true that there’s not much to be done, which
>> sucks, but that’s life. But even if we throw our hands in the air and say
>> “nothing to be done”, which is I think where we’re getting to, I don’t
>> think there would be any harm in putting a sentence or two in the Security
>> “In Section 2.1 we mention that a symbolic name MAY be signaled along
>> with a candidate path. While the value of symbolic names for display
>> clarity is indisputable, as with any unrestricted freeform text received
>> from external parties, there can be no absolute assurance that the
>> information the text purports to show is accurate or even truthful. For
>> this reason, users of implementations that display such information would
>> be well-advised not to rely on it without question. Furthermore,
>> implementations that display such information might wish to display it in
>> such a fashion as to differentiate it from known-good information. (Such
>> display conventions are inherently implementation-specific; one example
>> might be use of a distinguished text color or style for information that
>> should be treated with caution.)”
>>
>> >> More snipped, but this is the meat of it. In case you haven’t looked
>> at RFC 9003’s security section, here’s a snip from it:
>> >>