Re: [Gen-art] Gen-ART review of draft-ietf-i2rs-problem-statement-04

[Alia Atlas <[e-mail]>]

Hi Russ,

Thanks for the review.  Responses in-line.

On Fri, Dec 12, 2014 at 9:53 AM, Russ Housley <[e-mail]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> This review is in response to a request for early Gen-ART review.
>
> Document: draft-ietf-i2rs-problem-statement-04
> Reviewer: Russ Housley
> Review Date: 2014-12-11
> IETF LC End Date: unknown
> IESG Telechat date: unknown
>
> Summary: Almost Ready.
>
> Major Concerns:
>
> Section 5 says, "Data written can be owned by different I2RS clients."
> The intended consequences are unclear.  I assume that the data written
> by one client cannot be rewritten by another client.  However, I can
> imagine some situations where the same data object might be written by
> more than one client at different times.  Please add some language to
> say whether this situation is within scope or not.
>

It is possible for the same data object to be written by more than one
client
at different times; conflicts are resolved by priority.   The details of
how this
are handled are described in draft-ietf-i2rs-architecture, which, quite
reasonably,
you many not have read.

I have changed the text to read:


" Data written can be owned by different I2RS clients at different times;
data
may even be overwritten by a different I2RS client.  The details of how this
should be handled are described in [draft-ietf-i2rs-architecture]."


Section 5 includes a requirement for multi-channel.  I would expect
> policy to dictate that some requests, especially ones that impact the
> whole router, come from a specific source.  This might require that
> the request arrive on a particular port or that it be authenticated in
> a particular manner.  Can more be said about the policy controls here?
>

In the problem statement?  We do have "Secure Control: Any ability to
manipulate routing state must be subject to authentication and
authorization.
Such communications must also have its integrity protected"

It's important for most writable state.  I could add a reference to the
architecture
again, but I'm not convinced that it is needed.  These are different
aspects that
need to pull together into a single protocol - and the secure control with
associated
policy is definitely part of that.


> Section 8 seems very thin to me.  There are some lessons from MIBs
> documented here: www.ops.ietf.org/mib-security.html.  I think that
> some of this extrapolates to this document, but I do not think that
> a pointer to those guidelines is the best way forward.
>

You are right.  I will add a reference to draft-ietf-i2rs-architecture,
which has an
extensive section discussing security.  I've pulled a couple key concepts
from there
as well - since I think they are worth highlighting.

"Security is a key aspect of any protocol that allows state
      installation and extracting of detailed router state.  The
      security considerations are discussed in
[draft-ietf-i2rs-architecture].
      Briefly, the I2RS Agent
      is assumed to have a separate authentication and authorization
      channel by which it can validate both the identity and the
      permissions associated with an I2RS Client.  Mutual
      authentication between the I2RS Agent and I2RS Client is
      required.  Different levels of integrity, confidentiality, and
      replay protection are relevant for different aspects of I2RS."

Minor Concerns:
>
> The document talks about the IESG statement issued on 2 March 2014.
> Please add a reference, which is probably best done with a URL.
>

Done


> Section 5 says that the ability to manipulate routing controls is
> "subject to authentication and authorization."  This is highly desirable.
> Can we go a little bit further?  Is it like root on a Unix box, or is
> the authorization more granular?  Are there known roles that must be
> supported?
>

It is intended to be more granular and the expectation is that there are
multiple roles - but the details of those roles aren't defined in the
problem-statement
or even the architecture.  Given the updated security considerations
section,
I'd rather not specify too much here.


> Other Comments:
>
> Section 5 says: "Such communications must also have its integrity
> protected."  I do not know how to do authentication without also
> providing integrity, so this is really implied by the previous
> sentence.  That said, I suggest the following wording: "Such
> communications must be integrity protected."
>

Sure - change made.

I'll publish an updated version very soon (today/tomorrow) after I've dealt
with
outstanding comments.

Thanks again for your review!
Alia