Re: [Dots] AD review of draft-ietf-dots-data-channel-25

[Benjamin Kaduk <[e-mail]>]

On Wed, Feb 27, 2019 at 10:25:36AM +0000, [e-mail] wrote:
> Hi Ben, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:[e-mail]]
> > Envoyé : mercredi 27 février 2019 05:10
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : [e-mail]; [e-mail]
> > Objet : Re: AD review of draft-ietf-dots-data-channel-25
> > 
> > On Fri, Feb 15, 2019 at 09:36:26AM +0000, [e-mail] wrote:
> > > Hi Ben,
> > >
> > > Please see inline.
> > >
> > 
> > Thanks.  The -27 is in good enough shape that I've requested the IETF last
> > call; we can finish discussing the last few topics here in parallel.
> > 
> 
> [Med] Sure. 
> 
> > >
> > > > -----Message d'origine-----
> > > > De : Benjamin Kaduk [mailto:[e-mail]]
> > > > Envoyé : jeudi 14 février 2019 20:17
> > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > Cc : [e-mail]; [e-mail]
> > > > Objet : Re: AD review of draft-ietf-dots-data-channel-25
> > > >
> > > > Hi Med,
> > > >
> > > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, [e-mail]
> > wrote:
> > > > > Hi Ben,
> > > > >
> > > > > Thank you for the review.
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > -----Message d'origine-----
> > > > > > De : Benjamin Kaduk [mailto:[e-mail]]
> > > > > > Envoyé : mercredi 13 février 2019 17:46
> > > > > > À : [e-mail]
> > > > > > Cc : [e-mail]
> > > > > > Objet : AD review of draft-ietf-dots-data-channel-25
> > > > > >
> > > > > > This is my AD review of the -25
> > > > > >
> > > > > > I see that Med made a commit on github that preemptively addressed at
> > > > least
> > > > > > one of these comments, but will trust the authors to do to the right
> > > > thing
> > > > > > with anything in here that's stale.
> > > > > >
> > > > > > A handful of generic and/or high-level comments before the
> > > > > > section-by-section nitty-gritty stuff.
> > > > > >
> > > > > > The author count is large (7); RFC 7322 notes that the stream
> > approver
> > > > > > (i.e., the IESG) will ask questions if the count is more than five.
> > What
> > > > > > should I tell people when they ask?  (The authors are listed also in
> > the
> > > > > > YANG module itself, if changes are made.)
> > > > >
> > > > > [Med] Actually, the set of co-authors of the YANG module is not exactly
> > the
> > > > same.
> > > >
> > > > Whoops, my bad for not checking.
> > > >
> > > > > Anyway, in order to comply with the rules and avoid spending extra
> > cycles
> > > > on this, we added a new section called "Contributing Authors".
> > Nevertheless,
> > > > the set of authors is not modified in the YANG module.
> > > >
> > > > Thanks.  (To be clear, I'm happy to go to bat for everyone with the IESG
> > > > for this sort of thing, I just need an argument to present that's not me
> > > > making things up.)
> > > >
> > > > I don't know of a specific policy for YANG module authorship, so that
> > part
> > > > should be okay as far as I know.
> > > >
> > > > > >
> > > > > > Can someone (the shepherd?) confirm that an automated syntax checker
> > has
> > > > > > run over the JSON in examples?
> > > > > >
> > > > > > The concept of "DOTS client domain" is being used for actual protocol
> > > > > > purposes here (most notably as a bound on the prefix(es) that a
> > client
> > > > can
> > > > > > request mitigation for, but I don't remember seeing a formal
> > definition
> > > > for
> > > > > > how any DOTS actor would know the specific bounds of such a client
> > > > domain.
> > > > > > Is there text somewhere that I missed that we can point to, or will
> > we
> > > > need
> > > > > > to add some?
> > > > >
> > > > > [Med] Both "DOTS client domain" and "DOTS server domain" are used in
> > the
> > > > architecture draft. "DOTS client's domain" and "DOTS server's domain" are
> > > > also used in the architecture and requirements I-D.
> > > > >
> > > > > If a formal definition is needed, I prefer this to be done in the
> > > > architecture or the requirements I-D.
> > > >
> > > > I think it would be a somewhat better fit in the architecture document,
> > > > just to note that the "domain" is something that can concretely be
> > > > demarcated by IP addresses/prefixes (as opposed to a more nebulous
> > concept
> > > > to aid conceptual understanding).
> > > >
> > >
> > > [Med] Let's add that text into the architecture I-D.
> > 
> > Okay.  Tiru had a follow-up about how servers can identify DOTS client's
> > domains, which is okay but not quite what I was aiming for.  In the text
> > Tiru quoted, we note that
> > 
> >    The DOTS server enforces authorization of DOTS clients' signals for
> >    mitigation.  The mechanism of enforcement is not in scope for this
> >    document, but is expected to restrict requested mitigation scope to
> >    addresses, prefixes, and/or services owned by the DOTS client's
> >    administrative domain, such that a DOTS client from one domain is not
> >    able to influence the network path to another domain.
> > 
> > I was hoping to see something like "For a given client (administrative)
> > domain, the DOTS server needs to be able to determine whether a given
> > resource is in that domain.  This could take the form of associating a set
> > of IP Prefixes per domain, for example."  But I'm open to being persuaded
> > that the existing text conveys the same meaning.
> > 
> 
> [Med] Your proposed wording can be added to the architecture I-D, IMHO.
> 
> FWIW, we do have this text in the protocol spec: 
> 
>    DOTS servers MUST verify that requesting DOTS clients are entitled to
>    enforce filtering rules on a given IP prefix.  That is, only
>    filtering rules on IP resources that belong to the DOTS client's
>    domain can be authorized by a DOTS server.  The exact mechanism for
>    the DOTS servers to validate that the target prefixes are within the
>    scope of the DOTS client's domain is deployment-specific.

To me that text is just reading that it mandates authorization checks,
whereas the text in the data-channel document that prompted this comment
has me thinking that the DOTS server needs an explicit mapping between
"DOTS client domain" and "this set of IP addresses and/or other
identifiers", which is a slightly different thing.

> > > > > >
> > > > > > We don't say much about what validation the server does on input
> > data,
> > > > and
> > > > > > we probably should.  For example, does the server need to validate
> > 'cuid'
> > > > >
> > > > > [Med] We avoided to be redundant here. This is covered by this text:
> > > > >
> > > > > "This attribute has the same
> > > > >       meaning, syntax, and processing rules as the 'cuid' attribute
> > > > >       defined in [I-D.ietf-dots-signal-channel]."
> > > > >
> > > > > > and/or 'cdid' in dots-client-creation requests?
> > > > >
> > > > > [Med] This is covered by this text:
> > > > >
> > > > > "This attribute has the same meaning, syntax, and processing
> > > > >       rules as the 'cdid' attribute defined in
> > > > >       [I-D.ietf-dots-signal-channel]"
> > > >
> > > > I guess I'm mostly just concerned about if there's anything that doesn't
> > > > translate directly, since the CoAP and HTTP constructs would have to
> > > > describe the formal validation in somewhat different terms (i.e., for
> > > > consistency between URL paths and message bodies).  But in general I'm
> > > > happy to avoid redundancy as you desire.
> > > >
> > > > > And other parts in the text such as:
> > > > >
> > > > >    If the request is received via a server-domain DOTS gateway, but the
> > > > >    DOTS server does not maintain a 'cdid' for this 'cuid' while a
> > 'cdid'
> > > > >    is expected to be supplied, the DOTS server MUST reply with "403
> > > > >    Forbidden" status-line and the error-tag "access-denied".  Upon
> > > > >    receipt of this message, the DOTS client MUST register (Section 5).
> > > > >
> > > > >
> > > > >   What about validating that
> > > > > > the (e.g.) ACL name in the PUT URL matching the name in the body of
> > the
> > > > > > request?
> > > > >
> > > > > [Med] Those are supposed to be covered following RESTCONF base spec.
> > > >
> > > > Is this supposed to be RFC 8040 Section 3.5.3?  I am not sure that I'm
> > > > reading that as covering the property I want (and will double-check if
> > you
> > > > confirm that's what you have in mind).
> > > >
> > >
> > > [Med] In addition to 3.5.3, Section 4.5 specifies the rules for PUT.
> > >
> > > The main point is that the validation you mentioned is not specific to DOTS
> > but are governed by RESTCONF procedures.
> > 
> > I only see 3.5.3 as talking about how to construct a request URI for a
> > given data node in the YANG tree.
> > 
> > What I'm wondering about for the data-channel document is if there are
> > cases where a given path component of the YANG module appears both in the
> > request URI and in the data in the request body.  If so, it seems that the
> > server will need to verify that the redundant data agree, and I still don't
> > see where this is mandated by RFC 8040.  (Sorry if I am being dense.)
> > 
> 
> [Med] I hear you. As mentioned in my previous answer, this is covered in Section 4.5 of RFC8040:
> 
>    If the target resource represents a YANG leaf-list, then the PUT
>    method MUST NOT change the value of the leaf-list instance.
> 
>    If the target resource represents a YANG list instance, then the key
>    leaf values, in message-body representation, MUST be the same as the
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    key leaf values in the request URI.  The PUT method MUST NOT be used
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    to change the key leaf values for a data resource instance.

This quoted statement is predicated on the target resource being a list
instance.  Thinking about this a little bit, I suppose that could be the
only case in which the redundant encoding arises.  So, I will drop this
topic, and thank you for your patience explaining the situation to me.

-Ben