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

[Ketan Talaulikar <[e-mail]>]

Thanks John for your inputs and suggestions.

Thanks,
Ketan


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

> 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 <[e-mail]>
> 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$>
>
> Please let us know if this addresses your concerns.
>
> Thanks,
> Ketan
>
>
> On Tue, Mar 22, 2022 at 11:20 PM John Scudder <[e-mail]> wrote:
>
>> Hi Ketan,
>>
>> Thanks as always for your quick reply.
>>
>> > On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar <[e-mail]>
>> 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
>> <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8231.html*section-7.3.2__;Iw!!NEt6yMaO-gk!TPdw7ZdqeCRS2htB1JCtU9oqzfUS0akoP3b2FGoZfrye6NBL-A_Cpxzu_nJ4ug$>
>> >
>> > 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
>>
>> > Thanks,
>> > Ketan
>> >
>> > On Tue, Mar 22, 2022 at 2:54 AM John Scudder <[e-mail]> 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:
>> >>
>> >> > On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=
>> [e-mail]> wrote:
>> >> >
>> >> >> 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.
>> >>
>> >> 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
>> >
>>
>
>