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
