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 <ketant.i...@gmail.com> 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 <ketant.i...@gmail.com> > 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. > > 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 <j...@juniper.net> wrote: > Hi Ketan, > > > On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar <ketant.i...@gmail.com> 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
