Interface to the Routing System (I2RS) Security-Related Requirements
draft-ietf-i2rs-protocol-security-requirements-17

[Ballot comment]

Thanks for adding REQ-16. Comments below are unchanged
from my previous discuss ballot.

- The topic of marking things as allowing insecure read
access has been discussed a lot so I won't get into it
again.

- section 4: "Data passed over the insecure transport
channel MUST NOT contain any data which identifies a person
or any "write" transactions." I don't get what identifying a
write transaction might mean?

- 4.1: "AAA protocols MAY be used to distribute these
identifiers, but other mechanism can be used." If I'm doing
TLS with mutual-auth, then I need a private key and
certificate. I don't think AAA protocols can transport those
(and they probably ought not) so I'm not sure what's meant
here.

- 4.2: What do "valid identity" and "valid identifier" mean?
If the same then use the same terms. But I think you need to
define "validity" or else say that work needs to be done
later.

- 4.3: I think you're saying here that the i2rs client is
trusted to simply assert the secondary identifier. If so,
then saying that would be good. If not, then I don't know
what you mean.

- 4.4: I still don't see why it'd not be better to use a
different protocol for the non-secure stuff and avoid all
the potential discussion and pitfalls of trying to do all
this in one protocol.

- 4.4: "It is mandatory to use (MTU) on any I2RS client's
Write transaction or the configuration of an Event Scope
transaction." Which "it" do you mean?

- 4.4: The BCP107 stuff is still not useful.

- 4.5: "detect when the data integrity is questionable" -
I've no idea what that means. Nor what it could mean.  Can
you explain?

[Ballot discuss]

Thanks for the major revision, this is a lot better.  I have
one discuss point and a bunch of comments.

The discuss is: I think it's an error to mix the secure and
insecure transports in one set of protocol requirements. And
I would definitely put a DISCUSS on any protocol solution
that aims to weaken the security of e.g. port 443 or
equivalent. In other words, I think you need to rule out any
protocol solutions that weaken the secure transports that
you are re-using. I therefore suggest adding a new
requirement along these lines:

"SEC-REQ-NN: While I2RS might need to make use of both
secure and insecure transports, this MUST NOT be done in any
way that weakens the secure transport protocol, either as
used in I2RS, or especially not as used in other contexts
that do not have this requirement for mixing secure and
insecure modes of operation and that depend on security
being as good as we can provide."

So I'd like to discuss adding the above or similar.

[Ballot comment]


- The topic of marking things as allowing insecure read
access has been discussed a lot so I won't get into it
again.

- section 4: "Data passed over the insecure transport
channel MUST NOT contain any data which identifies a person
or any "write" transactions." I don't get what identifying a
write transaction might mean?

- 4.1: "AAA protocols MAY be used to distribute these
identifiers, but other mechanism can be used." If I'm doing
TLS with mutual-auth, then I need a private key and
certificate. I don't think AAA protocols can transport those
(and they probably ought not) so I'm not sure what's meant
here.

- 4.2: What do "valid identity" and "valid identifier" mean?
If the same then use the same terms. But I think you need to
define "validity" or else say that work needs to be done
later.

- 4.3: I think you're saying here that the i2rs client is
trusted to simply assert the secondary identifier. If so,
then saying that would be good. If not, then I don't know
what you mean.

- 4.4: I still don't see why it'd not be better to use a
different protocol for the non-secure stuff and avoid all
the potential discussion and pitfalls of trying to do all
this in one protocol.

- 4.4: "It is mandatory to use (MTU) on any I2RS client's
Write transaction or the configuration of an Event Scope
transaction." Which "it" do you mean?

- 4.4: The BCP107 stuff is still not useful.

- 4.5: "detect when the data integrity is questionable" -
I've no idea what that means. Nor what it could mean.  Can
you explain?

[Ballot discuss]
Thanks for resolving my previous DISCUSS point. I have just one further point that hopefully will be easy to fix: Section 3.2 trails off in mid-sentence.

[Ballot comment]
= Section 1 =

The abstract talks about multi-headed writes but Section 1 talks about multi-headed reads -- I'm assuming these are supposed to be aligned.

= Section 3.1 =

"I2RS also requires a secure transport protocol and key distribution
  protocols."

This is the first sentence of the section -- what does the "also" refer to?

"The following protocols will need to be extended to provide
  confidentiality, data integrity, peer authentication, and key
  distribution protocols: SSH, SCTP, or the ForCES TML layer over SCTP."

I'm a little confused by the implications of "will need to be extended." Is this document proposing that they be extended? Or is the idea that if any of these protocols is chosen as a transport for I2RS, they would need to be extended to meet the I2RS security requirements? Also, note the existence of draft-ietf-tsvwg-sctp-dtls-encaps-09.

= Section 3.2 =

"The last new security feature is the ability to allow non-
  confidential data to be transfered over a non-secure transport."

How is this a security feature?

= Section 3.3 =

I'm not sure what "options described above" is referring to.

= Section 4 =

"Data passed over the insecure
  transport channel MUST not contain any data which identifies a person
  or any "write" transactions."

Assuming this should say "MUST NOT".

[Ballot comment]
Thank you very much for your re-write of this draft.  It reads much better and as such, should be a more helpful document for the WG.  The requirements are more clearly listed and the new section breaks with explanations are also a positive improvement. 

I do appreciate the new language in section 3.2.  I still don't agree with the model, but I wouldn't block on the scope and method with the way this is currently written.  I favor marking when data is confidential, but you've been careful in how you have scoped this requirement.

[Ballot comment]

First, apologies for not getting my review done for
this when it was scheduled due to my vacation and
thanks for being willing to defer the document.

Second, having now properly reviewed this, I am
balloting abstain as I think it's unlikely that this
document can be fixed in a way that results in
something useful happening. I think that the likely
outcome is that this document will be used later when
people are arguing and will not much help in resolving
those arguments, or else this will be ignored and
arguments will be held afresh, as needed. That latter
outcome is what I'd guess is most likely and therefore
it seems that spending all of our cycles on DISCUSS
ballot processing for this would not be wise. That
said, I am willing to change to a DISCUSS ballot if the
responsible AD prefers that, but I suspect I'll end up
with an abstain in any case, after some discussion. The
only plan I can think of that'd lead to me ending up
with a yes or no-objection ballot would be if this was
returned to the WG for fixing and possibly major
surgery, which is what I actually think would be the
best plan. (I realise this has had a somewhat tortured
history, so folks may not be willing to take it back to
the WG, but honestly, I think the failings visible in
this document do indicate that this is not ready for
approval and ought be returned to the WG.)

Third, I think the overall set of requirements posed
here might (with some unknown probability) lead to
later specifications that are considered too hard to
deploy, with the result that non-secure variants of
I2RS become the norm. That seems like it would be a
really bad outcome. I would suggest that might be
partly mitigated if a requirement were added to the
effect that deployment issues and specifically ease of
deployment MUST be considered as a first order
requirement when developing I2RS protocol solutions.

Fourth, the (19!) comments below that are preceded by
"(discuss" would have been DISCUSS ballot points had I
not decided to abstain. I am happy to chat about any of
my comments below, but if the authors/WG do want to
chat, it might be more efficient to concentrate on
those that would otherwise have been DISCUSS points.
(But that's your call, I don't mind.) I think the 19
would-have-been-discuss points is another clue that
this ought really be sent back to the WG.

And with that, and with apologies for this being such
an overall negative review, here're my detailed
comments:

- general: The writing here is generally poor, for
example the opener is "This presents..." whereas it
ought be "This document presents..." (or
s/document/whatever you prefer/). Such issues are
repeatedly seen and all that makes this a much harder
read than ought be the case. I'd strongly recommend an
editorial pass from someone who hasn't been down in the
weeds with this text for a while (which could be one of
the authors, if one of them has been less active
recently.) Note that this is not only (but is
primarily) an editorial issue - there are some cases
(hopefully called out below) where the writing does
create real ambiguity that might lead to re-opening old
arguments later.

- abstract: "mutual authentication, transport
protocols, data transfer and transactions" don't seem
to me to be commensurate things, so the abstract, as
written is very uninformative for me.

- intro 3rd para: I'm really not sure what you're
telling me about [I-D.ietf-i2rs-ephemeral-state].  "The
draft [RFC7922]" is odd, that being no longer a draft.
I'd have expected such nits would have been fixed by
now TBH. Same for the last sentence.  That para makes
the intro pretty unclear for me.

- 2.2: The definition of higher level protocol seems
like an odd place to introduce the fact that i2rs ==
netconf + restconf.  That'd be more usefully said in
the abstract/intro if that's solidly agreed by the WG.

- 2.2: This is wrong: "While it is possible to have an
I2RS operation which is contained in multiple I2RS
(E.g.  write in multiple messages), this is not
supported in order to simplify the first version of
I2RS." The reason this is wrong, is that it is here
that you are defining that it is not possible to have
an operation in multiple messages. s/it is/it could
have been/ would work maybe.

- 2.2: " *  The I2RS client issues a read request to a
I2RS agent, and the I2RS Agent responding to the read
request" Shouldn't that use respond and not responding?
Given that you seem to be trying to define the scope of
what is and is not a transaction, I think being precise
with the language is something well worth doing.  The
2nd bullet could also do with a re-write.

(discuss1) 2.2: you sort-of define messages,
operations, transactions and actions. None of the
definitions are that precise, e.g. are those the only
operations or examples? And transaction and action
aren't really defined at all. I'm not sure if that's
likely to be a problem or not. I suspect it will later,
e.g. when you get to figuring out the scope within
which replay needs to be detectable.

- 2.2: s/transation/transaction/

(discuss2) - 2.2: "defines a secondary identity as the
entity of some non-I2RS entity " That could be abused
for tracking of various kinds I would guess, e.g. if an
IMEI were used. I think you need to note that and
should impose some requirements that such secondary
identifiers are not used thusly for tracking.  Also,
should the first occurrence of entity there be
identity?

- 3, 1st para: s/The security for the/The/ - there
isn't a thing called the security for the i2rs
protocol.

(discuss3) - section 3 says "the I2RS protocol requires
mutually authenticated I2RS clients and I2RS agents
communicating over a secure transport." To me that
implies that something like TLS or SSH is MTU which
seems to contradict recent emails.

- section 3 says: "The I2RS protocol MUST be able to
provide atomicity of an I2RS transaction, but it is not
required to have multi-message atomicity and roll-back
mechanism transactions.  Multiple messages transactions
may be impacted by the interdependency of data."  I
don't believe that that's easily enough understood to
be useful. Also, wouldn't s/Multiple messages
transactions/Multiple-message transactions/ be much
clearer if that's what's meant? And finally, I think
the MUST embedded in the above is not that great an
idea - it's clearer IMO to separate the 2119 language
from introductory text in documents like this.

- 3: "There are dependencies in some of the
requirements below" would be better as "There are
inter-dependencies between some of the requirements
below" unless you mean dependencies on some external
things, which is not clear from the text as-is.

(discuss4) " For confidentiality (section 3.3) and
integrity (section 3.4) to be achieved, the
client-agent must have mutual authentication (section
3.1) and secure transport (section 3.2).  " This is
incorrect. One can have confidentiality without
authentication (see RFC7435) so the text is not
accurate.

- capitalisation needs fixing in various places, e.g.
around the end of p5, we get "secure Transport" and
then "I2RS client" and "I2RS Agent" in the title of 3.1
Is any of that capitalisation supposed to be
significant? Either way, fixing it now would be good as
you'll need to get the RFC editor to do it later if you
don't (which takes longer).

(discuss5) SEC-REQ-01: what is the scope of uniqueness
required here? I see no reason why two different data
centres cannot re-use a client or agent identifier, if
they so wish. I'd be fine if you say that's for later
decision, but being silent on the matter could lead to
trouble later if different folks decide differently.

(discuss6) SEC-REQ-02: the "MUST utilize" there means
MTU, which wasn't what you wanted I think

(discuss7) - SEC-REQ-03: how is "upon receiving... MUST
confirm" a good choice? As stated that'd be hugely
onerous, implying e.g.  OCSP checks for each packet
received. Same point applies to SEC-REQ-04.

(discuss8) - SEC-REQ-05: this either means nothing at
all (being a tautology) or else something I don't get.
I think it's the former, but am not sure.

- 3.1: s/One mechanism such mechanism/One such
mechanism/ I guess. And it's not at all clear to me
"AAA protocols" is the right idea there, and nor is it
clear what's meant, with the text as-is.

- SEC-REQ-06: where is a "priority" defined?

- SEC-REQ-07: here you say read/write is a transaction,
but earlier you said it was an operation, which is it?

(discuss9) 3.2: As with others, I don't think the idea
of annotating parts of yang modules with "can be
insecure" is a good one. There's a separate thread
discussing that though, so maybe better to not fork
that.

(discuss10) - SEC-REQ-O9: I hate to do this to ya, but
BCP107 is IMO a fairly clear failure when it comes to
routing. And yet again the exceptions clauses here are
so broad as to be meaningless (e.g. considered low
value by whom?). What is the real goal here? (other
than an attempt to keep the sec ADs from being annoying
and trying to insist on BCP107? ;-)

(discuss11) - SEC-REQ-09: Separately, to my other
would-be-discuss point on this requirement, "can
guarantee" is well beyond the state of the art in key
management. I'd just drop that sentence maybe, but
can't make a concrete suggestion until I understand
where you want to be wrt BCP107.

- SEC-REQ-10: the last sentence here is also involved
in the "may do stuff insecurely" thing, and so will
likely need fixing when that is fully resolved.

- How is SEC-REQ-11 useful? What protocol artefacts do
you have in mind here? Perhaps a requirement that DDoS
attacks be specifically considered in I2RS would be
more useful.

- SEC-REQ-12: This seems to me to have too many words,
e.g. the current text could be read to imply that
outside of critical infrastructure there is less or no
need for confidentiality, so those added words
(presumably there to motivate) might be
counter-productive.

(discuss12) SEC-REQ-12: I don't get the meaning of the
SHOULD here - combined with "certain data" that SHOULD
seems to end up meaning MAY, as in, it seems to mean
the same as "Read/write operations MAY have to be
protected using a confidentiality service."

- 3.4, bullet (2) here means that we're not talking
about data integrity but data origin authentication
as well.

(discuss13) 3.4, (3): Within what scope must replay be
detected? The text implies for ever, which can be very
onerous. SEC-REQ-14 doesn't quite go so far, but is
ambiguous on this aspect. I'd say best is to note that
the scope within which replay needs to be detectable is
for future study.

(discuss14) SEC-REQ-15: Sorry, I don't understand
what's required here (having read this >1 time). Can
you explain?  I'm not sure if any substantive change is
needed, but there are certainly editorial changes
needed for sure as there are multiple wording problems
with the text as-is.

- 3.5, 1st para: the text here is not as good as
the actual definition of "role" in RFC7921, and in
fact I found the text here confusing. Better to
just delete that and say that 7921 defines roles.

(discuss15) SEC-REQ-16: I don't see any content in this
text as it seems to just say "some role based access
control and some level of transport protection need to
be provided" which is always true, as you are allowing
"no transport security" and (I assume) "fully public
access" so any protocol/system will always meet this
requirement.

- SEC-REQ-16: "privacy requirements" here is wrong,
you mean confidentiality I think.

(discuss16) SEC-REQ-17: "MUST work" is far too vague.
That could for example hide a major debate about push
v. pull of role information. If the WG haven't
considered that, I think you could ack that again by
saying that more work is needed to define how RBAC is
consistent across multiple transport layer connections.

(discuss17) SEC-REQ-18: again this seems to have no
content, other than perhaps imposing an odd requirement
on implementations - I don't see a protocol requirement
here at all. It is reasonable to note that libraries
for clients ought not assume a single client identity
but even that's very specific to library
implementations and since it's just a MAY that's
entirely obvious, I'd leave it out.

(discuss18) SEC-REQ-19: I fully agree with the
motivation here but I think the stated requirement is
broken.  For example, I don't know how a piece of s/w
will determine whether or not it is correlated with a
person. I also don't think a SHOULD works here, as
again something would need to be stated about the
situations when the feature is not needed, and I can't
figure out a sensible statement for that. The last
sentence also seems likely not useful. All in all, I
think this is likely to be ignored or even worse
treated like a piece of fig-leaf specification text to
pretend that we're caring about privacy.

(discuss19) - 3.6: I have no idea whether this other
draft is supposed to be considered as setting
requirements or not. I assume that the answer is "not"
as you've made it an informative reference, but in that
case you really should say that.  The alternative would
be that 3.6 is essentially specifying an applicability
statement for the environments in which it is, and is
not, ok to run i2rs. If the latter were intended, then
you'd need to say it and make the draft a normative
reference.

[Ballot comment]
Version 8 resolved my discuss point for section 3.4. Thanks!

I don't think it resolved my discuss point for 3.2. I'm clearing anyway, because I think my point has been made. I would prefer the language to say that anything not explicitly marked as non-confidential in the relevant data model MUST be sent over a protected transport. But I will leave it to the authors to do the right thing.

I will leave my non-discuss comments below for reference. I think version 8 resolves at least some of them. Any remaining are up to you; none of them are show stoppers.

-2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

-3.1,:
I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they  grant permission?)

[Ballot comment]
I have the same concerns as others around the secure transport, but I'm not putting in a DISCUSS because the concerns are already well represented.  Just one additional comment on the topic:

I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport") and this text from Section 3. (Security-Related Requirements): "…MUST be able to exchange data over a secure transport, but some functions may operate on a non-secure transport."  The latter text talks bout "some functions" using a non-secure transport, while SEC-REQ-09 implies that everything may use it.


Other comments from Section 3.1. (Mutual authentication of an I2RS client and an I2RS Agent)

-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements".  I'm not sure what you mean my "sets", as there are no requirements (labeled as such) in the architecture document.  If there are, then this section doesn't seem to be needed (as others have mentioned).  Maybe "these requirements are derived from the architecture", or something similar may be more appropriate.

-- What is a "valid identifier"?  A couple of requirements where a "valid identifier" "MUST" be confirmed are listed, but no indication as to what that may be in this document or the architecture one.  The definition of identifier doesn't help…

-- SEC-REQ-05 and SEC-REQ-06 sound the same to me.  What is the difference?  BTW, if there is a difference, instead of "IETF" I think that "standardized" may be better.

[Ballot discuss]
Thanks for your work on this draft.  There may be some overlap in points, I tried to minimize them...
----
Section 3.1:

I don't see any actual requirements for mutual authentication in this section, just requirements for identifiers.  Did I miss something?

Are all mutual auth schemes in scope?  Are there any considerations for mutual authentication (passwords, keys, etc.)?
----
I share the same concern as others for secure transport, but since there are already discusses on that, I have one comment to add to the existing discusses below.

[Ballot comment]
Section 3:
Can you clarify the second to last sentence?  Do you mean there are sections that indicate an insecure transport should be used?

  I2RS allows the use of an
  insecure transport for portions of data models that clearly indicate
  insecure transport.

Perhaps:
  I2RS allows the use of an
  insecure transport for portions of data models that clearly indicate the use of an
  insecure transport.
----
Section 3.2
I agree with Alissa's discuss point on the following sentence (that could also be reworded a bit):
  A non-secure transport can be can be used for publishing telemetry
  data or other operational state that was specifically indicated to
  non-confidential in the data model in the Yang syntax.
----
Section 3.4: In the following text:
  SEC-REQ-15: The integrity that the message data is not repeated means
  that I2RS client to I2RS agent transport SHOULD protect against
  replay attack

I'm not sure why this just doesn't say:
  SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect against
  replay attack

The additional text doesn't add anything and sounds a bit confusing.
----
Nit:

I'm not sure these definitions add any value as they seem to restate the term defined:

  I2RS protocol data integrity

      The transfer of data via the I2RS protocol has the property of
      data integrity described in [RFC4949].

  I2RS component protocols

      Protocols which are combined to create the I2RS protocol.
-----

I also agree that the definitions from 4949 should be removed.

Thank you in advance.

[Ballot comment]
-2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

-3.1,:
I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they  grant permission?)

[Ballot discuss]
In section 3.4, the text says that the requirements that the integrity protection mechanisms can actually provide integrity protection are SHOULD because some communication may occur over non-secure channels. That does not follow, since the rationale is about use, while the actual requirement is about capability.  As currently written, it leaves it possible for people to select a protocol that cannot provide integrity protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS.

In the third paragaph of 3.2, Isn't the point to say that ephemeral data MUST be sent over a secure transport unless the data model explicitly labels it as safe for insecure transports? As written, it seems to leave room to send data that is not labeled as safe to also be sent over insecure transports.

[Ballot comment]
-2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

-3.1,:
I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like a statements of fact. (That is, do they simply recognize reality, or to they  grant permission?)

[Ballot discuss]
== Section 3.2 ==

"A non-secure transport can be can be used for publishing telemetry
  data or other operational state that was specifically indicated to
  non-confidential in the data model in the Yang syntax."

What kind of telemetry data is it that is of no potential interest to any eavesdropper? This is not my area of expertise so I'm having a hard time conceiving of what that could be. I'm also wondering, since I2RS agents and clients will have to support secure transports anyway (and RESTCONF can only be used over a secure transport), why can't they be used for all transfers, instead of allowing this loophole in the name of telemetry, which undoubtedly will end up being used or exploited for other data transfers?

If the argument was that this loophole is needed for backwards compatibility with insecure deployments of NETCONF or something like that I think it would make more sense, but my impression from the text is that those will have to be updated anyway to conform to the requirements in this document.

[Ballot comment]
In general I agree with Mirja that where other documents already provide definitions, they should be referenced, not copied or summarized, in this document.

== Section 2.1 ==

Using "privacy" as a synonym for "confidentiality" is outmoded, I think, given current understanding of the many other facets of privacy (see, e.g., RFC 6793). I would suggest dropping the definition of data privacy and just using the word confidentiality when that is what you mean.

== Section 2.2 ==

"The I2RS protocol exists as a higher-level protocol which may
      combine other protocols (NETCONF, RESTCONF, IPFIX and others)
      within a specific I2RS client-agent relationship with a specific
      trust for ephemeral configurations, event, tracing, actions, and
      data flow interactions."

Reading the provided definition of "trust," I'm not sure what "with a specific trust for" means in the sentence above.

"The I2RS architecture document [I-D.ietf-i2rs-architecture]
      defines a secondary identity as the entity of some non-I2RS entity
      (e.g. application) which has requested a particular I2RS client
      perform an operation."
   
Per my comment above, I would suggest just referencing the definition from the architecture document. The text above is circular ("the entity of some ... entity") and conflates an identity with an identifier.

== Section 3.1 ==

Agree with Mirja that this section is superfluous.

== Section 3.3 ==

Since the normative recommendation here isn't to be enforced by the protocol, why is it SHOULD rather than MUST? Same question applies to SEC-REQ-17.

== Section 3.5 ==

Is the omission of normative language from Sec-REQ-20 purposeful?

[Ballot comment]
A few comments:

1) I don't think copy&paste from RFC4949 is necessary. I would recommend to remove this part and just name the definitions that are needed.

2) The following sentence seems to indicate that the refernce to RFC4949 should be normative.
"The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]."
As I don't think this is needed, I would recommend to rather spell out the properties here in this sentence. Also, to be honstest I not sure what this sentence tells me at all. So maybe stating clearing what you mean (instead of just having the reference) would help anyway.

3) To me it's not really clear why there are several requirments docs (that also are connected and refer each other; see e.g. section 3.6 and SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). Couldn't those docs be combined to one requiremnet doc?

4) Section 3.1 says:
"The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements:"
Why is this needed is RFC7921 already sets these requirements?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-i2rs-protocol-security-requirements-06.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: i2rs@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, "Jeffrey Haas" , jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (I2RS Security Related Requirements) to Informational RFC


The IESG has received a request from the Interface to the Routing System
WG (i2rs) to consider the following document:
- 'I2RS Security Related Requirements'
  as
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This presents security-related requirements for the I2RS protocol for
  mutual authentication, transport protocols, data transfer and
  transactions.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ballot/


No IPR declarations have been submitted directly on this I-D.

Template date: 2/24/2012
Date of Shepherd report: 12/31/2015
Next update expected on: 1/6/2016
Reviews pending:  QA-Routing, QA-Security Directorate
Shepherd:  Jeff Haas

Type of RFC:  Standards document
This document is part of a series of documents that specify requirements for an I2RS protocol.
If possible, the I2RS protocol is to be created as an amalgamation of existing protocols that
can be combined to create the architecture described in the I2RS architecture document.
(https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/). 

For example, the I2RS protocol could be be compromised of configuration and notification
from NETCONF/RESTConf) and an analytical protocol (e.g. IPFix).

The requirements for the first version of I2RS are:
1) model driven ephemeral state - that is data models that do not survive
    a software or hardware reboot. 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

2) a secure protocol -
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

3) traceability - ability to record interactions between I2RS elements
(Client, Agent, Routing system)
https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

4) notification publication via subscription
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

5) Protocol to pass Data for Analytical applications 
The first version of these requirements does not include a
separate analytical protocol requirements as the simple use cases may
pass information via query/poll or the notifications.

The I2RS protocol exists in an secure environment described by:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/

(2) The IESG approval announcement includes a Document Announcement
Write-Up. 

Technical Summary
  This presents security-related requirements for the I2RS protocol for
  mutual authentication, transport protocols, data transfer and
  transactions.

Working Group Summary
Working consensus for requirements was honed over 6 months (May -Nov 2015).
WG LC done with All of requirement drafts 10/6/2015 to 10/20/2015

Document Quality

This draft comes out of discussion with the I2RS WG and
various security experts, and security directorate reviewers.
The last SEC-DIR messages on this topic was:
http://www.ietf.org/mail-archive/web/secdir/current/msg05942.html
last message:
http://www.ietf.org/mail-archive/web/secdir/current/msg05964.html

NETCONF:
It has been reviewed by the NETCONF WG (July 2015, Nov 2015), and
all issues were declared resolved as of November 2015.

Routing QA review has been requested, but not assigned.

A significant number of vendors have indicated their plan to
expand existing protocols to create an IRS amalgamate protocol.
A list includes the following: Cisco, Juniper, Huawei, Ericsson,
Google, Packetdesign (Client software) and others.

ID-NITS: none

Personnel

Document shepherd:  Jeff Haas
WG Chairs: Susan Hares and Jeff Haas
Authors: Susan Hares, Daniel Migault, and Joel Halpern
AD: Alia Atlas
Sec-DIR QA-Reviewer: Russ Housley
RTG-DIR QA-Reviewer: TBD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

3-a: Shepherd's report:
(Put in Mail list for review send to list)

3-b: Routing-QA Review:
(Put in Mail list pointer for QA-Review)

3-c: Sec-DIR QA Review
http://www.ietf.org/mail-archive/web/secdir/current/msg05942.html


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

Shepherd is satisfied with depth of reviews

Final reviews from Security Directorate and OPS-DIR should be done on all
5 documents in the requirements suite.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Early SEC-DIR and OPS-DIR reviews were done on the I2RS architecture and
problem statement that form the basis for the 5 requirement documents.
Early SEC-DIR reviewers were done on draft-ietf-i2rs-protocol-security-requirements-00.txt

Final reviews from Security Directorate and OPS-DIR should be done on all
5 documents in the requirements suite.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No specific concerns or issues on this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR reference for three authors:
Susan Hares (shares@ndzh.com)
https://mailarchive.ietf.org/arch/search/?email_list=i2rs&q=protocol-security-requirements

Daniel Migault (daniel.migault@ericsson.com)
https://mailarchive.ietf.org/arch/msg/i2rs/pDiHwgLYIllh8cNU08uL_mtHbTw

Joel Halpern
https://mailarchive.ietf.org/arch/msg/i2rs/5XhX1lKhJ0PNF-XViFIh-wG0pM0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure

(9) How solid is the WG consensus behind this document? 

Solid full WG agreement and discussion for 5 months (June to November 2015).

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? 

No Appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No NITS Are indicated.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Requirements document does not require MIB, Yang validation or URI reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes.  All references are appropriate.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are coming as part of the
bundle with problem statement, architecture, and
protocol requirements. 

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Architecture is a downref, but it is part of the cluster of drafts
that includes: problem statement, architecture, and requirements.

(16) Will publication of this document change the status of any
existing RFCs? 
No RFC changed.  This is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 

No requests of IANA are made since this is a requirements document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No registries are created or referenced.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ID-NITS done.  No XML, BNF, MIB or Yang so no validation required.