Thanks John for your inputs and suggestions. Thanks, Ketan
On Tue, 22 Mar, 2022, 11:51 pm John Scudder, <j...@juniper.net> 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 <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> wrote: > >> Hi Ketan, >> >> Thanks as always for your quick reply. >> >> > On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar <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> 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
