Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)
Susan Hares <shares@ndzh.com> Sun, 21 August 2016 21:16 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A6912B043; Sun, 21 Aug 2016 14:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxiXG4MUMVbd; Sun, 21 Aug 2016 14:16:40 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0783E12B01F; Sun, 21 Aug 2016 14:16:39 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.56.220;
Date: Sun, 21 Aug 2016 17:16:32 -0400
Message-ID: <m2ewte6wu54rkdo6q10qdklj.1471809750749@email.android.com>
Importance: normal
From: Susan Hares <shares@ndzh.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_176427079500470"
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/C3d7tUag3Xgh6izFVpdGSdotKCI>
Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Aug 2016 21:16:44 -0000
Stephen: This email begins the discussion on the DISCUSS criteria. For ease of process it goes through DISCUSS 1 to 5 Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone -------- Original message --------From: Stephen Farrell <stephen.farrell@cs.tcd.ie> Date: 8/21/16 8:37 AM (GMT-05:00) To: The IESG <iesg@ietf.org> Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-09: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- 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. Can you suggest what kernel of information you would deem useful in the abstract? > 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 row TBH. Same for the last sentence. That para makes <the intro pretty unclear for me. Thank you for that input. I will fix that in version 10. > 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. The reason this is introduced here is to link to statements in the architecture document. The initial protocols may be netconf and restconf, but other protocols will follow. I will provide an improved text in version 10. > 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. Stephen: We are working on a re-use protocol for NETCONF, RESTCONF, IPFIX, Forces and other protocols. It is technically possible to define an operation which spans multiple messages. And we are limiting the first version of this protocol to one message. Please clarify what you wish added. >- 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. Sue's responds: The language was chosen carefully. An overloaded I2RS agent has the option not to reapond. Therfore, the phrase "the I2RS Agent responding to the read request" is a more appropriate phrase. >(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. Sue's reaponse: We need to go to a meta level first to answer this question. I2RS is a re-use protocol. For each protocol these messages which encode specific transactions that are a sequence of read, write, rpc, or event actions. We are defining the higher level protocol that will be translated into each language via extensions. So.. what precisely fits the discuss criteria here? Are you looking for transactions and actions to be defined? How does this impact the review of the I2RS protocol security - 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? Sue response: In order to be precise in my answer, I will need you to define IMEI. These non-I2RS entities are attached to a valid i2rs client with a mutually authenticated identity signales by the identifier (client or agent). The connection of the application to the i2rs client is outside the scope of the I2RS protocol. The secondary identifiers are use for tracking of the application in the traceability mechanism. So.. again I am unclear regarding what you are concerned about and what makes this a DISCUSS based on the DISCUSS criteria. -> 3, 1st para: s/The security for the/The/ - there isn't a thing called the security for the i2rs protocol. Sue: Why not? Please explain. We are defining a re-use protocol with extensions to other protocols. Why does the composite protocol not have a level of security or security considerations? Please explain what you desire here. >(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. Sue: Just to be clear, you are not objecting to the text you indicate -but your understanding from the email. An I2RS agent has MTU secure transport of TLS or SSH. Any I2RS client accessing any data model which has mixture of secure and non-secure data has an MTU of a secure transport (TLS or ssh). Any i2rs client accessing an i2rs agent in an environment that where the network info might be linked to a person' identity has a MTU of secure transport. The only time the I2RS client is allowed to have a non-secure transport is if the only thing it is accessing is non-secure data. We currently have no i2rs data models which have non-secure data. > 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 a idea - it's clearer IMO to separate the 2119 language from introductory text in documents like this. Stephen: The language was specified by a few implementers doing I2RS work. I believe you do not understand I2RS transactions versus messages. Transactions can be setting a value, rpc to add a set of values, and starting an event stream. Each transaction must either work or not work as an independent unit. This is not the same as sending this messages with a set of commands and being able to rollback to the beginning of those 5 commands. Some protocol I2RS may support this level of checkpoints- but it is not a requirement. - 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. Sue: Thank you for the input. > (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. Sue: The conditional sentence above has a compound noun.- "confidentiality and integrity" - can you have both without authentication? Please confirm. -> 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). Sue: Thank you for this editorial correction. Version 10 will address this >(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. Sue: Things wander out of a data center into the Internet. Management protocols have wandered out in the past. The safest mechanism is to be utterly unique. if deployments choose less that that, the security network designer must do risk/reward choice. Or people may decide to connect 2 data centers due to an emergency and forget the Management system identifiers overlap. And then the network systems start interacting. OopsAnything less than complete uniqueness can go bad. ======= response ends here======== (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. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
- [i2rs] Stephen Farrell's Abstain on draft-ietf-i2… Stephen Farrell
- Re: [i2rs] Stephen Farrell's Abstain on draft-iet… Susan Hares
- Re: [i2rs] Stephen Farrell's Abstain on draft-iet… Stephen Farrell
- Re: [i2rs] Stephen Farrell's Abstain on draft-iet… Susan Hares
- Re: [i2rs] Stephen Farrell's Abstain on draft-iet… Susan Hares
- Re: [i2rs] Stephen Farrell's Abstain on draft-iet… Stephen Farrell
- Re: [i2rs] Stephen Farrell's Abstain on draft-iet… Susan Hares