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

[Ketan Talaulikar <[e-mail]>]

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
>
>