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 <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> 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 <j...@juniper.net<mailto:j...@juniper.net>> wrote: Hi Ketan, Thanks as always for your quick reply. > On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> 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 > <j...@juniper.net<mailto: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<mailto: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
