Minutes of the NETCONF WG Session July 25, 2011, 13:00-15:00 ============================================================ Many thanks to the minute takers Juergen Schoenwaelder, Lada Lhotka and jabber scribe Bill Fenner. The session started at 13:00, blue sheets were circulated. Co-chairs: Bert Wijnen, Mehmet Ersue AD in the room: Dan Romascanu After agenda bashing Mehmet gave the WG status: - The documents With-defaults capability, 4741bis and 4742bis have been published as RFC 6243, RFC 6241 and RFC 6242. - Following documents are in WG LC till August 1st: - Network Configuration Protocol Access Control Model (draft-ietf-netconf-access-control-04) - NETCONF System Notifications (draft-ietf-netconf-system-notifications-04) **** Andy Bierman - Netconf Access Control Tim Polk is the new security advisor but he has not yet reviewed the latest version of the document. Andy reviewed the changes since the last version. - slide 6 Sending a request and writing the same data - noop or access denied? SNMP does not take the value that is written into account for taking an access control decision. Andy explains a number of corner cases where access control may only be applied to leafs where the value changes or where access control is not applied during confirmed commits. Andy: it should be access denied - The only criterion is the contents of the edit, not the contents of repository. Bert: sounds logical to fail. - slide 8 Martin: If two users change candidate in sequence and the second committing, rules for the second user must apply. Proposed solution is to apply access control on those leafs that actually got added/updated/deleted. However, this allows to guess values. - slide 11 Lada brought up the situation where user A makes changes in candidate he is allowed to do and user B makes other changes in candidate he is allowed to do but neither A and B have the rights to commit the combined changes. Andy has implemented anybody is allowed to do discard-changes. Martin: We should mention that must not check access because otherwise uncommitted changes by a user may prevent other users from acquiring a lock. David Harrington: Why is session B allowed to change session A's candidate? Andy: Candidate is a shared scratchpad. Bert asks whether there should be text recommending the use of locks on candidate? Andy: A setup in which everybody has a private candidate would work better. Andy: Perhaps a stricter policy is required to reply with access denied. A write should be a write even if doesn't change anything. Martin mentions the situation where a user has the rights to change his password but nothing else. Such a user can use edit-config in trial and error mode to guess the content of other leafs. Bert: Is there any feedback from reviews? Andy: Juergen's review - useful terminology changes and other improvements, better handling of notifications Bert: Is it that ony the figure needs an update? Andy: I will talk to Juergen offline AI: Andy and Martin to propose text on the mailing list how to handle these corner cases. Andy promises a new version two weeks after the IETF. **** Andy - NETCONF System Notifications Andy reviewed the changes since the last version. - slide 4 Martin: Does non-NC session mean any sessions? Non-zero session ID may also be used for non-NETCONF sessions. Andy: I have to look in the text whether it is OK to report a nonzero session number if it's not a NC session. We need a standardized solution. Martin says that his implementation assigns session ids to other sessions, e.g. a cli session. The current text is to restrictive but this can be easily fixed. Bert: Did you address server- vs. user-initiated changes? Andy: Text must make it clear the server can also make changes. Kent: In JUNOS, server itself encrypts password if the user passes it unencrypted. Is it a server initiated change? Juergen: In general, if the server generates configuration, does access control apply? Andy: That would be difficult, my code doesn't apply any access control to server-initiated changes. Martin says that 6241 handles reverting but what happens if there is a lock and the server likes to make changes? Andy: It is important to list all these cases in security considerations. Bert: Plugging a card is a config change. Martin states that the server should not modify configuration if that is not related to a client transaction. Andy: Consider RPC with side effects, e. g. "make-network" which results in generating configuration by the server Andy says if I have a high-level primitive create-network that causes config to be generated which access control is applied? Martin answers that this is already handled - you need to have access to create-network to succeed. Martin: This is already covered in NACM, in fact it is the user that initiates the changes. Martin: Detecting session-start with session ID=0 makes no sense. AI: Andy promises a new version within two weeks. **** Juergen - NETCONF Lite - slide 5 Andy: One use case is small devices have no notion of modifying config on the fly and keep running. Non-XML format would make it more attractive, JSON is an obvious choice. Kent Watsen: If we acquire a new company, their boxes typically know nothing about NETCONF. We can quickly implement NETCONF support, but without filters etc. Bert (to Juergen): What's your motivation for this I-D? Juergen: I wanted to see if there is interest in NETCONF Lite. Dan Romascanu: I'd support an informational I-D explaining how constrained devices could advertize their capabilities. Mehmet: I also have interest in this topic. We should keep it alive. Andy: I'd be interested in seeing how this can be implemented in comparison to CoAP. **** Kent: reverse ssh - slide 6 (Out-of band reversal) Juergen: How does the TCP passive open decide which SSH user identity to use for the SSH client? Kent: Admin has to prepare the NMS for the moment when the device calls home. A message is send of the TCP connection before SSH starts (in cleartext) which includes a pre-provisioned device id that maps to a user identity. - slide 11 (Questions) Andy: Experience from OpenStack - a standard without code is of no use, are you interested in making your code open source? Kent: We'll be happy to make our sources available, modulo company policies. Dan: We need to go out with just one of the four options, #1 is probably the easiest. Kent: My interest is in low-cost ones - #1 and #4. But #4 requires bidirectional authentication. Juergen: Bidirectional authentication is a good thing. Dan: Would you prefer to go for NC-specific or a more general solution? Bert: Could it be useful for SNMP? Juergen: We are three years late. Bert: Then we probably wnat to have it NC-specific. Wes Hardaker: It would be nice to have it more generic. The biggest issues were political - how to decide the identity of incoming connections. But IMO the right way is to do it in the protocol. Bert: Can we have more success than we had 4 years ago? Bert: Should we do it in NETCONF WG? Andy: I need a solution that works and don't care whether SSH community likes it. Bert: So we can also base the standardization on running code. The discussion concluded with a possible way forward to push for an Experimental RFC documenting the Juniper solution and if that receives implementation support to last ask for standardization.