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 <j...@juniper.net> 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= > 40juniper....@dmarc.ietf.org> 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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
