Re: [spring] Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Barry, 

Many thanks for the confirmation of those three points.
We have posted an updated version of the I-D with all the changes discussed below.

Regards,
Pablo.

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-20
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-20

-----Original Message-----
From: Barry Leiba <[e-mail]> 
Sent: martes, 22 de septiembre de 2020 23:05
To: Pablo Camarillo (pcamaril) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Bruno Decraene <[e-mail]>; Joel Halpern <[e-mail]>
Subject: Re: Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

Thanks for the reply, Pablo (and thanks also to Joel for his reply).
All good here.  And just confirming three items in particular:

>> It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, 
>> because one reads these as “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof.
>
> [PC] Agreed for RIR. For the other ones I’ve seen some disagreement on 
> this regard in between native English speakers. I’m not a native 
> English speaker, hence I would prefer to leave the decision up to RFC Editor.

As Joel said also, and I agree.

>> I can’t figure this out.  It looks like it should be “required to 
>> terminate”, but I don’t know what it means
> to “terminate less bytes”.  Can you reword this?
>
> [PC] I propose the following diff:
> <OLD>
> as part of the decapsulation process the egress PE is required to terminates less bytes from the packet.
> </OLD>
> <NEW>
> as part of the decapsulation process the egress PE is required to parse and remove fewer bytes from the packet.
> </NEW>

A very fine change; thanks.

>>    This document introduces SRv6 Endpoint and SR Policy Headend
>>    behaviors for implementation on SRv6 capable nodes in the network.
>>    As such, this document does not introduce any new security
>>    considerations.
>>
>> I’m not convinced of this.  It seems that misuse (such as injection 
>> or alteration) of some of these Behaviors could, for example, result 
>> in packets being forwarded to nodes they were not intended to go to.  Is it not important to discuss issues such as that: how these Behaviors might be attacked?  Is that really fully covered in 8754 and 8402?
>
> [PC] You mention injection alteration or misuse of these behaviors, 
> the paragraph preceding the one you quote in revision 19 states:
>   “Additionally, [RFC8754] defines an HMAC TLV permitting SR
>    Endpoint Nodes in the SR domain to verify that the SRH applied to a
>    packet was selected by an authorized party and to ensure that the
>    segment list is not modified after generation, regardless of the
>    number of segments in the segment list.”
>
> This text was added to revision 19 as part of the SECDIR review, and I 
> think this provides a reminder of how misuse or alteration within the 
> SR domain of trust can be handled based on RFC8754. Can you please check if this addresses your comment?

It does, and thanks for pointing it out.  I think I must have had that comment left over from an earlier start on reviewing, and hadn't double-checked it with the latest version.

Barry