Subject: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 19:09:56 -0400

Based upon the WGLC comments, I have updated these two drafts.  Because I
believe that the changes are not particularly controversial (except for the
new reference to NETCONF and RESTCONF), I've published the updated versions
so that the WG can verify the changes at the same time as my co-authors.

The differences for the architecture draft can be found at:
http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-architecture-03&difftype=--html&submit=Go%21&url2=draft-ietf-i2rs-architecture-04

and for the problem-statement at:
http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-problem-statement-03&difftype=--html&submit=Go%21&url2=draft-ietf-i2rs-problem-statement-04

Thanks,
Alia

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Jun 2014 09:50:24 -0400

I believe we had sufficient review during the last round of WGLC to advance
these documents *if* the concerns previously raised have been sufficiently
covered.  The one significant detail where that work is unclear is whether
the security considerations under current discussion in
draft-hares-i2rs-security warrant specific additional detail in the
architecture draft.

If you've previously raised concerns on these drafts, please note to the
list whether you believe they've been addressed.

If you were paying specific attention to the security issues, please also
review the security draft.

The week is yet young.  Hopefully the group can be convinced to complete
this work by Friday. :-)

-- Jeff

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2014 15:51:22 +0200

> review the security draft.

I have been trying to read draft-hares-i2rs-security-01.txt and to
match it against draft-ietf-i2rs-architecture-04.txt and I have come
to the solution that we should 

- stop work draft-hares-i2rs-security-01.txt and 

- merge all statements from this I-D that are worth keeping and that
  are not yet part of draft-ietf-i2rs-architecture-04.txt into
  draft-ietf-i2rs-architecture-04.txt.

There are numerous places where I the documents are inconsistent and
this should be avoided if all possible and one way of doing this is
make sure there is only one document talking about I2RS security
'architecture'. And I do not see a convincing point why the I2RS
security 'architecture' should not be sufficiently defined in the I2RS
architecture - in fact I see many good reasons why the whole I2RS
architecture should be in one document.

To substantiate my position, I will list several examples that make
me concerned. But note that this list is not complete.

* I am concerned about MUST statements in the security document that I
  do not find in the architecture document. Or, if these MUST
  statements are already in the architecture document, then there is
  no point in repeating them in the security document.

* I am concerned about definitions such as Role in the security
  document that I do not find in the same meaning in the architecture
  document. Furthermore, I am worried about terms like 'routing tree'
  that are not well defined in the security document and do not exist
  in the architecture document. I note that the definition of Role is
  actually inconsistent even within the security document (e.g.,
  3.3. and 3.1).

* There are concepts in the security document like I2RS identity
  repositories that I do not find in the I2RS architecture.

* The section 3.2 of the security document gives guidelines that on
  things like that with symmetric keys, "sequence numbers which
  increase monotonically could be useful to help distinguishing
  replayed messages". I believe this goes way beyond _architectural_
  concerns and worse it kind of implies that I2RS may invent their
  security protocol instead of using one of the already available and
  well understood security protocols we have.

* Section 3.3. is messing up the separation of communication security
  and access control. Furthermore, the advice given that data model
  writers should consider whether a client / agent is valid is IMHO
  wrong. It is wrong to encode authorization policies into data
  models.  The security policy must be configurable at runtime by a
  security administrator. There needs to be a separation of policy
  from mechanism.

* Similar as above, the advice in section 3.4. that IM/DM writers
  "must discuss determine" whether encryption is a recommendation or
  requirement is wrong. It is the job of the security administrator
  deploying I2RS to answer those questions. All the IM/DM writer can
  reasonably do is to provide guidelines what in particular may need
  protection (this is what we are doing for ~20 years for MIB
  modules).

* My understanding is that so called "stacked I2RS agent-clients in
  broker topologies" are left out of scope in the architecture. Why do
  such things pop up in the security architecture? What is the point
  of having an I2RS architecture with a certain scope and then an I2RS
  security architecture with a bigger scope?

Bottom line is that I strongly prefer if all the security aspects of
the I2RS architecture are covered in the document that defines the
I2RS architecture.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2014 15:57:13 +0200

> so that the WG can verify the changes at the same time as my co-authors.

I suggest to take this out again:

  Additionally, on March 2, 2014, the IESG issued a statement about
  Writeable MIB Modules which is expected to limit creation of future
  writeable MIB modules.

This is what the statement really says (despite its unfortunate
title, http://www.ietf.org/iesg/statement/writable-mib-module.html):

  SNMP MIB modules creating and modifying configuration state should
  only be produced by working groups in cases of clear utility and
  consensus to use SNMP write operations for configuration, and in
  consultation with the OPS ADs/MIB doctors.

My understanding is that configuration here is meant in the OPS sense
and my understanding is that I2RS is about changing operations state
as understood in the OPS community.

/js

---

From: Alia Atlas <[email-masked]>
Date: Thu, 26 Jun 2014 17:13:46 -0400

Hi Juergen,

> as understood in the OPS community.

I've also heard support for having it in.  I think that what it says is
accurate -
that WGs will be asked to think about whether write operations are needed
in MIBs going forward.

Can you suggest a rewording that you'd be comfortable with?

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 26 Jun 2014 17:16:53 -0400

Given the level of maturity of the security draft, that we put into the
architecture draft
what we think is good guidance without selecting existing mechanisms, and
that we
are trying to finish the architecture draft, do you really see aspects
missing and if so,
precisely what, around the security section?

I don't want to confuse cherry-picking the parts that are needed from an
immature draft
with information that is missing from the architecture.

IMHO, we will need a draft that talks about what protocols can meet the
requirements,
whether there is a mandatory-to-implement, and so on.  That draft may or
may not be
what the efforts at the security draft matures into.

Regards,
Alia

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2014 09:09:12 +0200

> Can you suggest a rewording that you'd be comfortable with?

The edit is to simply remove the sentence.

And I disagree that the statement says that "WGs will be asked to
think about whether write operations are needed in MIBs going
forward".

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2014 09:15:37 +0200

Alia,

the security draft claims that it is "an expansion of the security
architecture found in the i2rs architecture." Note that it says
_architecture_.

I believe all _architectural_ security aspects have to be part of the
I2RS architecture and there should not be a need for a second I-D to
refine them.

I personally do not believe anything is missing security wise in the
I2RS architecture but apparently several people do. They should make
concrete proposals to add missing things to the I2RS architecture
instead of pushing a separate I-D.

/js

---

From: "George, Wes" <[email-masked]>
Date: Fri, 27 Jun 2014 09:12:39 -0400

>think about whether write operations are needed in MIBs going

WG] well, the observation is accurate, whether the statement actually says
that or not, because people will ask. Alia, since I'm the one that
suggested that we address this, I suggest that you simply make an
informative reference to the statement without a lot of editorializing,
possibly just quoting the relevant part that Juergen included in his
response.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.