Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
> Hi Ketan,
> 
> > On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar <[e-mail]> 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