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

[Ketan Talaulikar <[e-mail]>]

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