Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Prasad,

Thanks a lot for your comments. Please see inline ("..FB").

> -----Original Message-----
> From: sfc <[e-mail]> On Behalf Of Vengada Prasad Govindan
> (venggovi)
> Sent: Donnerstag, 25. Juni 2020 13:02
> To: [e-mail]
> Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
> 
> Hello all,
> 
> I support progressing this draft to an Experimental RFC. Please consider the
> following comments (mostly editorial):
> 
> 1)
> Not sure what is implied by the sentence below (Sec 1):
> > A particular set of nodes "to be verified" is either described by a set of shares
> of a single secret.
...FB: Good catch. We'll remove the word "either". This is an editorial left-over from the time when the draft had two methods mentioned (SSSS and nested crypto).

> 
> 2)
> The following sentence (Sec 1) describes about controller nodes and verifier
> nodes. While the former's role could be easily understood, I am not sure the
> latter node role is clearly defined. If it does not limit the scope, we may use only
> one terminology or clarify the difference, if we need to refer about two roles.
> > The complete secret set is only known to  the controller and a verifier node,
> which is typically the ultimate node on a path that performs verification.

...FB: A network element that compares the iteratively (by all nodes that participate in POT on the path) computed result which is carried along in the packet with the secret and concludes whether the computed result matches the secret. If the two match, the packet transit is proven. The role of the verifier naturally assumes that the packets had a chance to traverse the nodes subject to POT before arriving at the verifier.

We can add a short paragraph with such an explanation to the document to ensure the role of the verifier is properly explained.

> 
> 3)
> Sec 7.9.1
> OLD
>  Since these schemes introduce at least additional control requirements, the
> selection of order verification SHOULD be configurable the Controller
> management interface NEW Since these schemes introduce at least additional
> control requirements, the selection of order verification SHOULD be
> configurable BY the Controller management interface

...FB: Thanks. We'll update the sentence accordingly.

> 
> 4)
> Sec 3.2 has the words Solution Approach duplicated

...FB: Thanks. Good catch. 
> 
> 5)
> Not sure if there is a missing reference here (Sec: 3.3.1.3):
> > For a general way to compute the modular multiplicative inverse, see   e.g.,
> the Euclidean algorithm.

...FB: We'll add a reference to http://en.wikipedia.org/wiki/Modular_multiplicative_inverse#Computation

> 
> 6)
> General comment: It may be helpful to either have a diagram or a pointer to a
> diagram pointing out the different roles like Controller, ingress node. Also I am
> not sure if there is text (other than the section in Security Considerations) that
> explains that POT should be deployed in a set of nodes under a single
> administrative domain.

...FB: The scope of this draft is the definition of methods for proof-of-transit. Like I mentioned in an earlier discussion on the SFC mailing list:
An implementor of POT for SFC with NSH would need to rely on several documents:
    - draft-ietf-sfc-proof-of-transit: for the POT concept and mechanism
    - draft-ietf-ippm-ioam-data: for the definition of POT related data fields in IOAM
    - draft-ietf-sfc-ioam-nsh: for the definition of the encapsulation of POT related data fields in IOAM into NSH
What you seem to be missing is an architecture-level discussion of how the mix of POT+IOAM+NSH apply to the SFC architecture. IMHO this would best be addressed by an architecture-level document, because all of the above mentioned documents are focused on a specific subject and neither of the documents would be a good fit for an architecture level definition. IMHO the best place for that would be a "RFC 7665bis" document - i.e. we'd extend the SFC architecture with a discussion how POT applies.

That said - and this is along the lines of your comment wrt/ the verifier: What is feasible within the scope of the document is to have an explanation of the different roles in POT in the document (e.g. we can do this in section 3), where we discuss the role of nodes which participate in POT, the verifier and the controller role, i.e.

* Node: A network element through which packet transit has to be proven.
* Controller: The Controller that creates secrets and secrets shares and configures the nodes for POT operations.
* Verifier: A network element that compares the iteratively (by all nodes that participate in POT on the path) computed result which is carried along in the packet with the secret and concludes whether the computed result matches the secret. If the two match, the packet transit is proven. The role of the verifier naturally assumes that the packets had a chance to traverse the nodes subject to POT before arriving at the verifier.

Thanks again, Frank

> 
> Thanks
> Prasad
> 
> > > -----Original Message-----
> > > From: sfc <[e-mail]> On Behalf Of Joel M. Halpern
> > > Sent: Dienstag, 16. Juni 2020 15:42
> > > To: [e-mail]
> > > Subject: Re: [sfc] IETF WG state changed for
> > > draft-ietf-sfc-proof-of-transit
> > >
> > > The chairs are starting the WG last call for
> > > draft-ietf-sfc-proof-of-transit.  Please reply explicitly whether
> > > you think this is ready to go to the IETF for publication as a Experimental
> RFC.
> > > As noted below, the call runs through June 30.
> > >
> > > Note that silence does not imply consent, so please speak up.
> > >
> > > Yours,
> > > Joel (& Jim)
> > >
> > > On 6/16/2020 9:32 AM, IETF Secretariat wrote:
> > > >
> > > > The IETF WG state of draft-ietf-sfc-proof-of-transit has been
> > > > changed to "In WG Last Call" from "WG Document" by Joel Halpern:
> > > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/
> > > >
> > > > Comment:
> > > > This starts WG last call for this document, ending June 30.
> > > >
> > >
> > > _______________________________________________
> > > sfc mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc