Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-07
"Susan Hares" <shares@ndzh.com> Mon, 02 March 2015 23:39 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 669C21A8AB7; Mon, 2 Mar 2015 15:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.354
X-Spam-Level:
X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SakssEEHlmdz; Mon, 2 Mar 2015 15:38:56 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E20181A8AB2; Mon, 2 Mar 2015 15:38:55 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92;
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: Mon, 02 Mar 2015 18:38:49 -0500
Message-ID: <01fd01d05542$097e0280$1c7a0780$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01D05518.20AED850"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEpOfrZTIkE5qJcJWMsTwMBawRKtp5ObSiA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/SV6YV9dFJf9Gl5fDY-9bp9RADsw>
Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org, iesg@ietf.org
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: <http://www.ietf.org/mail-archive/web/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: Mon, 02 Mar 2015 23:39:06 -0000
Charlie: Thank you for your wonderful review. I have worked on getting more defined response for December 22nd through February28th. I have reached a point of diminishing returns on the work - with what you may consider substantially the same comments. Please review the comments below. After you see these comments, if you would suggest what sections I should still fix in the architecture draft. I only found one section I could provide good additional text (which I included below). 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's Response: You are correct, the I2RS architecture does not provide the necessary detail to clearly define a security protocol. I2RS is an architecture designed to re-use other protocols. After a great deal of discussion in a few interims, Please take a look at the text below as an addition to section 4. This I2RS architecture describes interfaces that clearly require serious consideration of security. As an architecture, I2RS has been designed to re-utilize existing protocols that carry network management information. Two of existing protocol which the I2RS WG has select to re-use are NETCONF [RFC6541] and RESTCONF [draft-ietf-netconf-restconf]. The I2RS protocol design process is to specify additional requirements for these existing protocols in order to support the I2RS architecture. After the existing protocol (E.g. NETCONF or RESTCONF), has been alter to fit the I2RS requirements, the I2RS protocol will be evaluated against the I2RS requirements. Due to the re-use strategy of the I2RS architecture, this security section describes the assumed security environment for I2RS with additional detail on: a) identity and authentication, b) authorization, and c) client redundancy. Each protocol proposed for inclusions as an I2RS protocol will need to be evaluated for the security constraints of the 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. Sue's Response: I appreciate your careful thought on these questions. We have considered these questions. Item #1 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. Sue's response: If you examine NETCONF running over SSH (RFC4272) or over TLS, or RESTCONF running over HTTP over TLS, I believe you will see the type of SSL with certificates. Item #2 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's item#2 response: Our first focus is the security sessions found in NETCONF (SSH/TLS), or RESTCONF. However, a vocal subset of the WG suggests there is a small subset of I2RS users that may have no security requirements because it is a "read-only" set of public data. The difficulty is while the proponents in the WG are vocal, they have not provided a description of the solution. This response was delayed for 3 months while I as the WG chair attempted to get a clean description of this "read-only" case. Therefore, the architecture has an open window for this "light" weight protocol to run over TCP, SCTP, or DCCP in case something clever gets developed. If another 18 months pass, we will revise the architecture to remove this section. Item #3: 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. Item #3 response Secondary identity is just opaque string which is passed without verification for purposes of trouble shooting and logging changes. The WG likes your description below, but decided to take this is as a second pass protocol change as it does not appear to be as simply as you suggest. We will include this extensions as a potential optional feature in our requirements document. Your text below: 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). Item #4 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? Item #4: We believe the asynchronous operation works without the transaction label. However, I have queried the WG regarding your question regarding the netconf/restconf protocols with the pub/sub requirement ( <http://datatracker.ietf.org/doc/draft-voit-i2rs-pub-sub-requirements/> draft-voit-i2rs-pub-sub-requirements-00). Item #5 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. Item #5 response: I2RS use of RESTCONF for I2RS actions provides this mechanism. Item #6 Ephemeral statea: 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. 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. Item #6 Response: I worked through these use cases in January for netconf/restconf. I awaited the "read-only" proposal or a mini-proposal to see if there were any differences. We agree there are three types of loss: a) I2RS client - the loss of the I2RS client will be timed out on the I2RS agent. The recovery of data on the I2RS client is outside the scope of the I2RS protocol. b) Routing device crashes without losing the I2RS agent. This can be handled as an internal issue or a graceful termination. The I2RS agent has two potential situations: a) the I2RS agent can recover the all device state or b) the I2RS agent cannot recover all device state. If case A, then the reboot has been buffered by the High-Availability of the routing system. It is as though the reboot never happened. If case b, all ephemeral state must be flushed via a graceful termination. The graceful termination causes a disconnect, reboot, and restart. The I2RS agent needs to have a time-out period so the I2RS client knows when to consider the I2RS Agent as DOA after the reboot. c) I2rs Agent fails - and all ephemeral state is flushed because the I2RS fails. This recovery is an unexpected failure so the I2RS agent upon reboot must send the NOTIFICATION_I2RS_AGENT_STARTING to all cached nodes. These types of processes are fairly common in routing protocols. I would appreciate any comments on how I might clarify the text. Item #7: 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? Item #7 Response: The I2RS agent has a time-out feature that indicates this point. See the above 3 cases. Item #8 pub/sub requirments: 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). Item #8 response: Could you review the requirements described for publication/subscription feature described in: draft-voit-i2rs-pub-sub-requirements-00? The key requirement is the following: "Put simply, periodic fetching of data is not an adequate solution for applications requiring frequent or prompt updates of remote object state. Trying to impose a polling based solution to this problem imposes load on networks, devices, and applications. Additionally, polling solutions are brittle in the face of communication glitches, and they have limitations in their ability to synchronize and calibrate retrieval intervals across a network. I2RS WG documents have expressed a need for more robust YANG object subscriptions. Similar discussions are underway in NETMOD and NETCONF. With the support of standards bodies such as OMG (DDS) , XMPP.org standard, generic Pub/Sub mechanisms to communicate data updates have been defined and proven themselves in a wide variety of deployments" We thought this set of features matched the description in the architecture text. If not, could you give me some insight on where you see a disconnect. #item 9: 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? Item 9 response: SNMP MIB modules are problematic for routing. NETCONF and RESTCONF have been adopted by the working group as the initial protocols that the I2RS WG suggests are modified shortly. Based on means that "I2RS" does not find all of its features to exist inside of NETCONF or RESTCONF. However, NETCONF and RESTCONF provide 80% of the properties needed. The I2RS requirements are to specify these additional features. Item 10: 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). Item 10 response: The I2RS debated this issue at length. Please note the collisions occur only if two clients with the same priority seek to write something in the agent. In the overwrite case, if the client has a higher priority the overwrite is accepted. If the client has a lesser priority, the overwrite is denied. Only in the case where the priority is identical does the agent detection a collision. In the simultaneous write by two different clients or the over-write, the assumption is that the collision is an administrative error. If the two clients want to both increment bandwidth at the same priority Item 11: 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? Item 11 response: If you use a netconf mechanism, you could use an RPC that would have a later acknowledgment. If you use a restconf mechanism, the restconf could contain a positive response per request. You can also use the RPC feature. 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