Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-07
"Susan Hares" <shares@ndzh.com> Thu, 17 December 2015 00:54 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1D01A8831; Wed, 16 Dec 2015 16:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.054
X-Spam-Level:
X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 ZK9s-dGidQQm; Wed, 16 Dec 2015 16:54:29 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1E81A87C9; Wed, 16 Dec 2015 16:53:11 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177;
From: Susan Hares <shares@ndzh.com>
To: 'Charlie Kaufman' <charliekaufman@outlook.com>, secdir@ietf.org
References: <COL401-EAS1272642F299281F38232C0DDF560@phx.gbl>
In-Reply-To: <COL401-EAS1272642F299281F38232C0DDF560@phx.gbl>
Date: Wed, 16 Dec 2015 19:49:06 -0500
Message-ID: <063801d13864$bbe90270$33bb0750$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0639_01D1383A.D31607B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEpOfrZTIkE5qJcJWMsTwMBawRKtqAazedA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/RzVYLv0wr_XCmXMvDrC1P2XL1HM>
Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org, iesg@ietf.org, "'BRUNGARD, DEBORAH A'" <db3546@att.com>, 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 00:54:46 -0000
Charlie: I'm hoping you will help us review the result of a year's work on security in the I2RS WG that relates to the i2rs architecture document. After your review, we decided to progress by defining the security requirements for the protocol requirements and for the environment. We also defined security requirements for the protocol. http://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requiremen ts/ In addition to our security requirements, we defined requirements for the protocol regarding publication of notification streams, ephemeral state, and logging/traceability. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ The I2RS WG thanks you for your excellent review and suggestions to make this protocol better. We hope that this combination of documents will provide you feedback on our work in the last year. Cheerily, Sue -----Original Message----- From: Charlie Kaufman [mailto:charliekaufman@outlook.com] Sent: Monday, December 22, 2014 3:05 AM To: secdir@ietf.org Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-i2rs-architecture-07 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. As an "architecture" document, this document does not specify the details that would allow one to review whether the security mechanisms were adequate. The Security Considerations section correctly notes that there is a need to transport this protocol over something that provides mutual authentication, confidentiality, and integrity to the data. It also notes that there needs to be some authorization mechanism that configures which authenticated clients are allowed to make what requests. There is no discussion of where this authorization comes from, and in particular whether the authorization data can be viewed or manipulated using this protocol, though my sense reading the document is that authorization data would be configured and manipulated by some other mechanism (as would the manipulation of client and server credentials). So I think we need to wait for the successor document with more meat to judge. Sue: Authorization comes from outside the protocol in a AAA or proprietary protocol. We hope the two security documents provide the detail on this protocol. That said, I would ask the designers some leading questions of the form "Have you considered.". Some relate to security and some don't. I'm not the best person to judge the answers, but I'm hoping the questions will kick off some discussion within the working group. It's likely that some of these issues have already been adequately discussed, in which case feel free to ignore them. This document goes out of its way *not* to specify any security mechanisms in order to provide flexibility to implementers. That makes sense for a requirements document, but I'm not sure it makes sense for an architecture document. You are clearly going to need some security mechanisms, and for clients and agents to interoperate, they need to be standardized. My guess is that you will end up using SSL with either client certificates or with some lesser client to agent authentication mechanism inside an SSL connection with only a server certificate. The mechanism you choose will determine the formats of the identity information you get and use to do lookups in your authorization tables. But section 7.1 says the protocol may need to run over TCP, SCTP, DCCP, and possibly other link types. Do you envision different security mechanisms for the different protocols? Sue: Yes, we will use different security mechanisms per protocol. We envision that we will be using secure encrypted exchanges over NETCONF/RESTCONF for all configuration data, and many pub/sub requirements. You will find we define these protocols. We may utilize other existing IETF but these exchanges will require secure encrypted sessions. There is one exception to this process. We may for a specific data model allow an insecure connection for some data. However, this data model and its protocol will be sent to the security directorate for specific review and approval. In the third paragraph of section 4 (and in some other places), you talk about the I2RS Client acting as a broker forwarding requests for some other entity, and forwarding some opaque identifier of that requesting entity to the I2RS Agent for logging. This presumes that the I2RS is configured with (or has access to) the authorization information that says which requestors are permitted to do which operations. A useful extension to the protocol would be to be able to forward a requestor-identity string that the Agent not only logs but also checks for proper authorization before performing the requested operation. The Agent would need to verify that both the Client and the client asserted identity of the requestor be authorized to perform the operation. This relatively simple change to the Agent and the protocol might permit a considerably simpler client (if this brokered-request behavior is actually common). Sue: On the broker, I believe the text in section 4 is the one below: If the I2RS Client is acting as a broker for multiple applications, managing the security, authentication and authorization for that communication is out of scope; nothing prevents I2RS and a separate authentication and authorization channel from being used. Regardless of mechanism, an I2RS Client that is acting as a broker is responsible for determining that applications using it are trusted and permitted to make the particular requests. We queried the WG on your idea. They felt the broker would not be the majority of work initially. The WG appreciated your suggestion, the WG suggested it was a feature for version 2. We will be starting the requirements for Version 2 in 2016. Section 1.1 says I2RS is described as an asynchronous programmatic interface. Asynchronous usually means that you can launch operations and then check back later whether they successfully completed. If you want to execute a second operation only if a first succeeds (or to guarantee the order in which they execute), you need to at some point wait for operations to complete. There is also substantial overhead in supporting asynchronous operation in that all transactions need labels so that they can be queried? Have you done that? A conceptually simpler strategy is to say that since a client can make multiple parallel connections to an agent that in cases where a client wants asynchronous operation he opens multiple connections and launches one asynchronous operation on each. The cost is that is has lower performance in cases where there are large numbers of parallel operations tying up lots of connection state. Sue: We have added to the models response in order to support transactions. In the RESTCONF version of the I2RS work, the client is launching one asynchronous operation on each. This matches your model. However, since NETCONF is widely deployed we are working to add enough in NETCONF configuration work and pub/sub. As to other protocol for pub/sub or reception of data streams, we will begin this in 2016. Given that information, do we have enough in version 11 of the architecture document? (see attached). Section 6.2: The restriction that this protocol injects only ephemeral state seems surprising, especially given that the circumstances under which the ephemeral state is lost are defined in terms of a network device reboot. Some network devices may not have a clear notion of a reboot, or might do it so rarely as to render such functionality useless. I was confused by the discussion of agent reboots vs. device reboots. Sue: Routing devices often have some parts of software running in one process. Some routing devices have the capability of handling a software module reboot (after failure or upgrade) rather than the whole process. A device reboot is considered the whole system reboot (hardware or software) rather than just the process. In the VM world, there is the software reboot of the process and the "pseudo hardware reboot" of the hosting system. Again, these are normative for routing in this environment (Google, Amazon, Linked-in) The first paragraph seems to say that ephemeral state is lost when the device reboots, but 6.2.1 seems to imply that state is lost when the agent reboots. The sentence "Just as routing state will usually be removed shortly after the failure is detected." seems to imply that ephemeral state might be lost when a client reboots. Have you considered what happens to state when a client disappears but the agent and server stay around forever. There is an option later in the document for some sort of timeout, but I would think there would be some sort of mechanism to guarantee that all ephemeral state disappears eventually unless the requestor is still around implicitly renewing it. Sue: The ephemeral state is lost when the agent reboots (software) or when the device reboots (hardware or software). The guarantee of the state being lost is a requirement for I2RS support. The I2RS architecture specifies two notification messages that are sent in the publication of notification (see the pub-sub requirement document) With that said, we are mandating In the ephemeral state requirements (http://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/) - that ephemeral state resets on a reboot. Any comments on the documents would be helpful. Also in 6.2.1, it appears that one piece of state is explicitly not ephemeral... the agent keeps a non-ephemeral list of clients to notify when ephemeral state is lost. If the client is not accessible, for how long does the agent continue to try to contact it? Forever? Sue: The agent timing on keeping the non-ephemeral list of clients to notify depends on the agent's implementation of the pub/sub requirements ( <http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/). The two notifications specified in 6.2.1 must be added any protocol handling notifications via the pub-sub. The notification requirements specify how the client specifies these publication actions. The I2RS protocol security requirements describe how notification impacts the protocol requirements. The security environment discussions should discuss how notification impacts the over-security requirements. Please let me know if you think these documents are sufficient. The protocol requires that agents be able to open connections to clients (in addition to clients being able to open connections to agents). This will introduce lots of challenges. It means the client needs an open port to accept connections, likely an SSL certificate, and will be in trouble if it is behind a NAT or is mobile and does not have a stable IP address. Other parts of the spec mention that two entities might have the same client identity. In such cases, it will be tricky for the agent to connect to "the right instance". It might be better to only allow clients to initiate connections to agents, possibly with some sort of unauthenticated notification from agent to client that initiating such a connection would be a good idea (to reduce the overhead of the polling that would otherwise be necessary). Yes: You are correct. The two proposals in the NETCONF are the pub/sub work https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ https://datatracker.ietf.org/doc/draft-voit-netconf-restconf-yang-push/ My first question when I started reading this document was why do we need a new protocol. Wouldn't SNMP or NETCONF do this just fine? And there are probably lots of others. Section 3.1 says "There have been many efforts over the years to improve the access to the information available to the routing and forwarding system." It would be good to understand why those efforts failed before inventing some new syntax (when it is unlikely the syntax is what killed previous efforts). Then section 7.1 says the protocol will be "based on" NETCONF and RESTCONF. What does "based on" mean in this context? Sue: The OPS/NM are utilizing NETCONF/RESTCONF for yang data models. The I2RS is data-model defined based on the yang data models. I2RS is a combination of configuration functions, notification publication, logging, and data analytics (e.g. IPFix or other data stream). The key security point is that with upgrades the NETCONF/RESTCONF may handle configuration, some level of notification, and some level of logging/tracing. It will not handle massive data analytics that IPFIX might handle. The setting of config, pub/sub parameters for notification streams, and logging/tracing will be initially done by NETCONF/RESTCONF. If speed becomes an issue, we will focus on this after getting some experience with the protocol. What killed SNMP was the MIB-II model is not supportable by human beings over the long run. This has been discussed and agreed upon in NETCONF/RESTCONF and Yang - so it is not the place of this document to state this point. Section 7.8 talks about "collisions", but it wasn't clear (at least to me) whether these were collisions in the time sense where two requests are made simultaneously by different clients vs. whether it is a case where once client tries to override the setting of another client. I also wonder whether there are cases where two changes would interact in some way other than one of them winning, as when two clients each want to increment the bandwidth of some virtual like over which they are both tunneling traffic (and where the correct result is to add the two increments). Sue: You are correct in your assessment. We have set a priority on each client, and a collision case for when two clients of the same priority interact. (First one wins and stays on until higher priority or client disconnects). Now, this part of the protocol was hotly debated and I expect additional changes in a second version of I2RS with more analytics. The first version is to get NETCONF/RESTCONF with configuration, pub/sub, logging, and a few analytic channels. The second version will focus more on this point. We need to see what type of implementations issue come up and get a security review of actual implementation issues. The last paragraph of 7.9 says "the protocol will include an explicit reply to modification or write operations even when they fully succeed". How does this relate to the asynchronous nature of the protocol? Sue: The data-models are being designed to explicitly reply to modification or write operations for key data elements. The notification (pub/sub) will be sent on the notification stream to notification clients if security and filters allow it. The logging will be sent on the logging stream to logging clients if security and filters allow it. These occasional points of synchronization focus on the key data elements per model. Good luck with this! --Charlie
- [secdir] Secdir review of draft-ietf-i2rs-archite… Charlie Kaufman
- Re: [secdir] Secdir review of draft-ietf-i2rs-arc… Joel Halpern
- Re: [secdir] Secdir review of draft-ietf-i2rs-arc… Susan Hares
- Re: [secdir] Secdir review of draft-ietf-i2rs-arc… Susan Hares
- Re: [secdir] Secdir review of draft-ietf-i2rs-arc… Susan Hares