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
