Minutes of the NETCONF WG session, 22 March 2010 ======================================= Minutes based on notes taken by Lada Lhotka and Larry Biggs (thanks) The session started at 9:03, blue sheets were circulated. Note Well, need to accept rules etc IP issues, patent or related issues, should disclose anything pertinent Agenda bashing - no objections/additions. WG Status (Mehmet Ersue) ------------------------ 4741bis first up 4742bis next non chartered items robust config access-control Walk up item - wasnt able to get the topic Status since Hiroshima - Partial lock published as RFC 5717. - Monitoring schema draft is at AD review, needs better security section for YANG module for discussion - 4741bis issue discussion ongoing - With-defaults capability ready AD review? - Using NETCONF over SSH: rfc4742bis, new WG item addressing 4742 errata near tió final Unchartered items: - Robust Configuration Management within NETCONF new version with updated text - Netconf Access Control Model A first and useful start 4741bis (Andy Bierman) ---------------------- Slide 1 Andy: bases 1.1 capability - proposing need a base 1.1 capability , to distinnguish between existing rfc and the new version, currently no way to tell the a new server is following what spec by introducing a new capability as part of the "hello" allows to put new things in the protocol when a new server is talking to a new client. doesn't want to try to change 4741, a server con forming to that can stay that way, can't try and fix it in the protocol, dont want to break old clients proposal - clients will adverstise what they can use, whatever the best match is will be used, old server will be supported by new client, negotiate a version and then go from there slide 3 Phil Shafer: Does it mean that RFC 4741 doesn't get deprecated? Andy: No, it's gonna be obsoleted Phil: original version was an implicit exchange, WG wanted an explicit exchange. Are we going back to the old idea of negotiating capabilities between the client and server and selecting their intersection? Andy: Not in general, but this base 1.1 capability is essential, so it should be announced by the client. Old client sends just base, new client sends both. Currently server isn't required to send the base capability, a new client would have new requirements and send updated data. Phil: Trying to nail down that it sounds like an implicit change is something that was discarded previously by the WG, this isnt an explicit change. So the hello protocol is implicitly changed. Andy: Yes, I guess we change the protocol. By putting 1.1 in hello, the client asks for the new behavior. Wes Hardaker: What does it break? If it is an implicit change vs explicit change Phil: Let's move the discussion to the mailing list. Kent Watsen: Client may want an old version of one capability and new version of another one. Something that might break - if we have capabilities with multiple versions, what if a client wanted to mix versions of the procotol. Andy:"buffet" wont be allowed- the old protocol will be deprecated Phil:there needs to be a deprecation policy otherwise older clients will break - agreed. Andy: Server needn't support the old version nor advertise it. Wes: I can envision vendors who will want to work with the old version- 1.1, 1.2, 1.3 - do you have to have a matrix of what is compatibile with what? could make life interesting. Andy: may have to look at the client hello - currently there isnt a way to ask for a down rev version of the protocol, we really need to look at this and see what we need if the old way was buggy, Andy: do we insist that servers support something old that is known broken? So the server will have to support something that is broken indefinitly? Had an error in the namespace. need to fix, Martin may need to explain this next one, has an issue with the namespace - namespace module Andy: namespace stays the same and looking at the base 1.1 module, do we need to specify the order? no advertise the 1.0 and the 1.1, need to take into account all the yang stuff existing implementations already expecting certain things, dont want to break things slide4 Martin Björklund: Either continue using capabilities or start using YANG features. Andy: This will be discussed later. 004-error severity Andy: need to be able to tell the versions apart, to fix them we need to break old clients without standard warnings, not needed to add warnings - complete oversite in 4741 - should we add warnings now? nothing 006 - multiple namespaces Andy: legacy text - in 7.1 different namespaces can have different formats, not a protocol thing is a data model thing, not a netconf thing, removing that text 008- subtree filtering Andy: enable spellchecking? lol? subtree filtering issues, some of it written before xml was fully understood properly. The text implies attributes need to be in a certain place but that isnt the case instance matches? Martin: if you have a leaf list with a coupld values and get a couple matchesone instance may match another may not? Andy: need to find the text to change it - should't look like and "and" should be cleaned up 009- partial operation error Andy: no one cares, no one is gonna mind or use it - rreturns a flat list of keys - gonna remove it, never went anywhere 010- filter namepspace wildcard Andy: new addition - ok to use the null namespace to match all names - support in various propietary ways - although a 1.1 server could say I dont have anything in the null namepsace, are no errores in the filter, it either matches or doesnt return anything could use it on a 1.1 server but would nt work 012 - copy config Andy: currently doesnt have a top level - should be the netconf base config element - has to start with that topical element - any issues? nothing 013 - configmred commit Andy: weakness, same user session that started the procedure has to finsih it, we agree we dont like that restriction - if the config gets changed you cant do anything about it - martin thinking to add new parms to support 1.1 what about notifications? system group later 014 - capability change Andy: biggest change - new error, configuration change, when the configuration changes, everyone needs to resync via resending the again to get alignment - only on the 1.1 server, wouldn't impact the 1.0 server - some discussion- assorted special cases or reasons why not to do this or to do this - can resync allow an existing exchange to keep going with ackowledgement - this is a big change to keep the clients up to date slide18 David Partain: Although I'd be in favor of using YANG features, I don't have a good feeling about the ripple effect. Andy: It would also be quite a burden to work both with capability and feature notation. 019 - clarify copy-config Andy: esoteric text that needs to be changed - why do we need discard changes but what about copy from candidate to to running isnt the same thing thorny issue with access control - does a get config, gonna put that config back, restore from my copy, access control has changed the config - server says wait a sec, i'm rejecting the entire operation. need to add text to clarify it, possible point of confusion 020- changes during commit Andy: are you allowed to change things in the running config or? text may not be clear enoug unless you reread it, if you add new things in the second commit, the server may to expect another third change etc - is a "feature" unprotected feature, if the confirm change times out, your changes get clobbered, and you deal with it 021 - default data Andy: how much do we need to say in the protocol spec on handling defaults - dont want to introduce a normative reference here one issue - the server knows how its supposed to save things in nvram - "should it be done in the basic mode" or other formats, not sure what to say.. common thing to do is to use explicit mode, only the commands the operator wants? 022- capabilites text Andy: last open issue, YANG features new issue the intent is the YANG module is the new issue, 4741 has things about new stuff - Yang wants you to define a module and partition it with features - what do we want to do? convert features to ? its just a different string for the server to parse, that isnt a big deal, it does change the mindset though Dan: this would only work in 1.1? Andy: woudnlt be compatible with 1.0 inclined to not do it? for new functionality the Yang module is the new feature with tags in the URI? Authors like the Yang features but will there be too much work David: nonauthors like it as well, however what is the ripple factor, how dramatic are the changes? Andy: Sometimes you want the old version of a capability - do we want to support that, something the code changes keep piling in and becomes a burden to support everything issue of the client sedning the hello - they currently dont send all the requirements of what they might need to be able to know what the server is gonna do - would require two hello's to actually get through it all Bert: what I see is more discussion on base 1.1 this week hopefully, get it to the mailing list, this new issue needs some hallway discssions this week then mailing list, new changes- didnt see much comment that the changes are acceptable? polling the room - response? all of them? WG chair wants consensus on things- did the hmm test running out of time - sounds like on the right track anyway, will get it out to the mailing list, two issues to discuss in more detail, Andy: last cycle we had open issues and they didnt get discussed on the mailing list - WG chair - people didnt react and we need to do a last call on the issues so we can be done with it examine converting capabilites to Yang - maybe we discuss this week and decide if we move forward Bert Wijnen (as WG chair): Summarizing - more discussion in the ML needed about base 1.1. There was a rough humming consensus on Andy's proposals for resolving the issues, but each one has to be confirmed in ML. with-defaults (Andy) -------------------- Andy: changes from -04 to -05 - changed the boilerplate and may need to do it again 20 times with defaults feature had a Yang feature that didnt do anything, removed it - not sure why it was in there changed the definition of explicit to match the Yang mode - has a huge impact on createand delete - client needs to pay atention to how a server is going to treat defaults, emails with Phil - for create, the server must treat it if it isnt there - client can set a value 3 - if a different client changes it "it isnt there" - thinks its best that the Yang definition aligns with industry removed xsd and made it normative updated uri module - ever netconf server SHOULD any questions? Its time to use Yang now, lets use our Yang hats now big change that Yang is normative and not trying to push this ahead without a Yang module WG chair - are we ready for last call on this one? Phil are we? yes just listed the changes that were made, not that need to be made, think so - take a look and let us know Bert: Should the document go to WGLC? Martin: I and Lada sent comments, so we need an updated revision before WGLC. Bert: Will issue a last call and move forward 4742bis (Margaret Wasserman) --------------------------- rfc 4742 status update the point to the update was to merge in several errata and changes, get them in quick and get them out Martin had comments, Juergen had comments Client/Server, Agent/manager, instead refer to the SSH client, the SSH server, the NETCONF client and the NETCONF server throughout slide 4 David P.: Terminology SSH client/server and NETCONF client/server makes a good sense. Andy: Would this terminology fail for SSH callback? would this make it harder to add "call home" capability to netconf - server might ahve to intiate the call, doc says the client will always initiate. Margret: more call home - tcp client tcp server, on top of the accepted client, ssh on top of that? Kent: With the callback, the NETCONF server will only become TCP client, SSH client will always be the NETCONF client as before. So the new terminology is fine for the callback, too. Margaret says is this out of scope? Question is this is a good suggestion because its not specific enough the affect the "call home" discussion Operations vs Commands, doc as now, referrred to xml commands etc, change "commands" to operations - any objections - this would make this more alignment with parent doc slide 5 Kent: RPC message is not an operation. Martin: Yes, we have to keep the difference between RPC message and operation. Margaret - heard kent agree with Martin - ok to proceed? confused - rpc messages and - sounds like we are going to change it too much? Phil: But the draft wants to change both to "operation". Margaret: OK, we should keep the term "message" if we speak about the entire RPC message. Going forward with Margaret's clarification Notifications- likes the idea of any message without having to rev the doc - where examples "any message" can be sent slide 6 Margaret: I personally support Juergen's suggestion. Wording change not intended fucntional change, try to make it clear that its not just rpc commands received, its all messages received would not be handled after the session is closed. Martin: Yes, it's better to talk about generic messages. Margret: Next Steps - make all the changes, then go to last call slide 7 Kent: But there is no session after . Language on the last slide - close session - sounds like current ssh channel is more the wording desired. Margaret: the spec should read once the session close is received, server responds and thats it, Martin agrees. Margaret: need to work on the wording to be clear on the ssh side since you need that to finsih the close - "must not process any netconf messages recevied after the close session operation" Martin: We should rather say that the server MUST NOT process any messages on the same SSH channel after . The server should actually close the channel, otherwise we have to invent a way for opening a new session in the same channel. Bert (as WG chair): Can the document proceeds to WGLC? Humming consensus on YES. Bert: It should go together with RFC 4741bis. It's better if the reference is to the new NETCONF protocol spec. reference the 4741bis - hopefully send them both together to get successive numbers, we can ask for consecutive numbers. Robust Configuration Management (Bob Cole) ---------------------------------------- Bob: talk about the 3rd version of the robust netconf draft, thinking about changing the name - defining verification capability validation is checking against rules, verification is measureing against running code changes from 01 to 02 version 2 defines verify-yang definitions, operations, notiications, requirements verify.yang module pushed testing to the server - can do cros verification, multistage operation, 9going over the slide) can cancel the verifiy verification test suite can be composed of multiple test sets with multiple parms, time allowed etc, verboseness of the client reporting back etc verify example - refer to the slide going over the example cancel-verify example - follow the slide example ping.yang refer to the slide (nature of the reporting and the nature of the pass fail and consistent- leaf list index passed , can pull raw results etc Discussion after the presentation: Kent: Is this complentely independent of candidate configuration? Bob:Should be independent, set of tests you run agains the running config, can fix that for clarity. Bob: I assume it is. tried to minimize the verbiage in the main body and put the rest in the appendix Dan Romascanu (as contributor): We have plans to add other types of tests like OEM. activating stuff like oem testing at a low layer etc as an example of what can be done Bob: use cases etc need clarification Kent: Would session termination influence the verification? Any value to adding language to closing sessions re ssh and netconf and confim commit - does it makes sense to follow that discussion Bob:this is independent from confirm-commit - needs to be thought about - could cases where you are running a test against a different server it might drop but there could be good data still there to be looking at Bob: Good question, will look at it. thanks for the opportunity Martin: Is ping.yang just an example, or is it going to be a standardized test. Bob: I think both. Thinks there needs to be modules related to a test.yang module, could go on forever, Bob says start small with ping and build it up - also where do test modules fit in Bert: ping.yang can be just an example, but it should still be specified in a separate document. This work needs at least some test modules to work with. Bob - how do you make a test module that is extensible and complete etc - talking about MIB modules and rmon wg tie in Mehmet: hands on who has read the doc - some hands (martin etc) Mehmet (as WG chair): Are there any prospective implementors? (Two hands raised). Phil: What's the point of automating it in the device? Why can't the client drive the tests? if this is a client driven change, shouldnt the client be drving the change? Bob -thought the quyestion was why can we do ssh requests Bob: Sometimes the server is (temporarily) invisible. Phil:client should be driving the test - Bob- that's what verify.yang does - coordinate the tests etc in an interoperable base Phil: if there is a real ping.yang - rpc to a device - there is more value here then the new idea Dan (as contributor): That's how OEM works, there is a level of test automation among servers. oem in mpls or so on, is a layer 2 2.5 that works between routers and switches - can retrieve or do special things that has a level of autom ation that is there. Phil: But you can still expose these tests as RPCs. When writing, e.g., a BGP module, I also have to write test operations. anything you can expose throught this verification method ios really raw rpc, if you have that would does this get? Bob: Defining an RPC signature is different from specifying test semantics. Bob: gets you an interoperable method between clients and servers, Phil: if you define a module you will define operations within the module, so any server should have standard operations Bob - calling an rpc operation standard is different than having certain leaf objects called out or defined - Bob - hoping for commonality Andy: This is providing a framework where you can define a set of tests in an interopearble way. using the MIB analogy, there are propietary modules and the n why have a standard one Andy:discussing it is all about the module or the framework, nasty module, you fix it, but if you have 5 ping.yang from different vendors that are different then what - this provides a framework for testing but doesnt preclude you have testing on your own again if there is a standard yang module what does this add? Bob: iof there is a module built one way etc - all manner of protocols, it gets complicated and there isnt a common standard to interact with, maybe thats what you want Dan: We need to go beyond - or better explain - the term "framework". We are trying to standardize how the tests are activated. Bob: -02 revision goes deeper into differences between test signature and test procedure. WG chair as contributor: That may have answered the question, what this is doing is to provide a framework for different modules/protocols (bgp, ospf, whatever) - does this make sense Phil: if we standardize on it, do we require it - if you want it to work with the verify.yang module Bert: But it makes life more difficult to module writers since there are new rules to observe. Phil: you dont get away from it, you are saving rpc's with particular sets of arguments, "run 57, 21, 42" etc Bob: As a user I dont want a collection of indepentantly deveoped yang modules, really want some kind of conformity, some day have a "network verify" - its coordinated etc Bob: Yes, but I don't want to have a random set of individually developed tests - there is a risk of conflicts. (sounds like it boils down to framework vs the rpc calls) WG chair: Can we take this to the list - agreed Mehmet: Who is interested in having this work as WG item? (Weak hum). Martin: I am interested, but we should resolve the discussion first. Bob: Agreed. Mehmet: Can you bring the issues discussed here to the mailing list? Bob: Yes. Dan (as AD): The hum was timid, more discussion in ML is needed. Need to flesh out what is charter vs needs to worked out and confirmed on the main list Access Control Model (Andy) --------------------------- considers access control a must have not a nice to have - currently there isnt any way to control access at this point, every user is a root user, if you can get in, you got it all no one uses a run as root model slide 5 Phil: I don't agree that without ACM every user has to be root. Martin: Neither do I. Wes: I believe the NETCONF spec says that ACM is needed but no standard exists. Wes:doc says everything should have an access control model, and dont hold up everything to debate the "root" diuscussion Andy - gonna go with memory since slides dont line up Conceptual model diagram - jumping through slides need for access controls is there since access is unbounded netconf introduces differeing layers of access where snmp didnt need threats could DoS attack the server and reinject crap, need access control slide 8 Andy: Do we need a standard ACM? (Strong humming consensus.) Bert: This is an important point. The consensus means that WG should work on it and we have to decide what to do. NACM requirements 1, 2, 3 from the slides noncontrol point, if you can get the request, you get the reply - the server isn't required to parse the results for anything special WG chair - would like the group to be aware this is a big deal, Andy did the initial work but it needs to go before the group Andy brings up that we dont want to make it too complex but it needs slide 9 Kent: What happens to get-config if you don't have access to all nodes? Andy: That's an extra issue, will be discussed later. Andy we have to be able to specify what is allowed - yang calls it a data node, that is control- slide10 Kent: So is access control for notification based only on eventType. Andy: The server just does simple filtering based on eventType and then doesn't care about the contents of the notifications. Andy - dont want everyone to see the conf change notification or access control break in or intrusion detection, maybe you dont want to tell the hacker he's hacking slide is saying this is a simple filter on the event type - this is a significant difference from snmp simplicity - trying to be simple enough to be used VACM ignored localized costs stake in the ground for read, right , exec - any comments on this? create and delete are part of write? slide 11 Kent: Is create permission provided by write permission? Andy: Yes. Martin: The concept of being able to change something but not delete it is strange. concept of changing something but not deleting is important. Bert: Is lock permission included? Andy: Yes, locking permission should be added. you could have an access rule that prevents lock, but not sure if that's a good idea. Wes: I agree that ACM is needed, this is a good start. Question: Is the default policy to allow or disallow? Andy: Default is read and exec, not write. But it is configurable, need to debate the model/requirments. Wes: We need to separate requirements from solutions. Bert: We'll get to that. We are discussing requirements, but it's helpful to illustrate them with tentative solutions. David Perkins: The explanation of SNMP access control problems is not sufficient. People understand access control at the task level into the pain of figuring out or too expensive to implement Andy: I didn't intend to dicuss it in any detail. localized cost is an issue, sorry he brough up snmp David Perkins: It is unacceptable to be faced to a more complicated taskwithout being able to map it to access control. sure there is a way to wrap sensitive data in an opaque way to return special data Andy: requirement - accessing the database needs to apply to candidate etc - refer to the slide slide 12 Kent: What about access control of other methods of changing configurations (CLI etc.)? Andy: This is out of scope. Andy - lock is independent of access method Andy - concept of users and groups , etc Andy - concept of a superuser for access control bypass due to lost passwords etc slide 14 Phil: We sometimes don't have the superuser. SOX caused certain things to not have a superuser, may not be able to do that in some cases Wes: Some customers never enable a protocol that assumes a user that can do everything. Initial access control has to be set out of band. Andy: It doesn't seem like a good idea. Problem with OOB is that it precludes automation. Andy - says this is out of band? or if you dont have a superuser (if that is your case) then ignore this section Andy - talking about superuser access and first one in wins, Wes - saying that since the superuser is the bootstrap, that is an issue Andy - thinks this is a bootstrap issue Wes - there needs to be an initial setup layed out Andy - doesnt like that there must be an out of band propiertary method within the standard, why cant we have netconf due it Wes - we are choosing automation over security - there is the battle Phil: So you trade security for automation. I don't agree superuser should be required. Dan: It is a dejà vu. We led the same discussions 15 years ago and the conclusion was that superuser was needed. Andy: on/off switch on the access control, Separate default modes - read-default, write-default, exec-default, indentifying security holes- slide - right now it seems that we need to tag the data within the module for what is scnsitive vs forcing the operator doing work arounds or security to prevent it, we shouldn't have holes to begin with, suggesting that the sensitive data be tagged within the module slide16 Bob: Can the default permissions be set by an operator? Andy: No, only by module writers. tagging would apply when there aren't explicit rules slide19 Wes: [Mentions paranoid customers, I missed the point] data shadowing and leakage - the protocol leaks information, leaf ref, history counter etc from a security perspective we might have issues if we try and lock it down, no one else does this if you have leaf ref's that are referencing each other, you still need access all the way down we need practices how we do data models etc - WG chair: comments? nothing monitoring and errors - Andy thinks should keep track of write or exec denied is good enough, not that we should track reads etc Andy: snmp get next barf/ Wes - has customers very sensitive about data leakage, talking generically , Andy brings up MIB walking, Bert: Consensus call - do you agree with the gist of the requirements? Mehmet: This doesn't preclude other potential requirements, right? Bert: No, but we should have a broad idea what the set of requirements is. Bert echoing Wes's comments about requirements and solutions in the same doc, also concerned about waiting until we have a complete requirements, wants to know if the group has some agreement on the main points, noted that the superuser idea is contentious are we agreed that this is the set of requirements to pursue, some agreement Wes disagrees. Wes: I'd like to see the authors of different implementations to come together and discuss the right thing to do. I believe there are other things that are needed. Wes - doesnt want a 1 year effort either, wants the netconf folks to work together Wes - we should undertake the effort WG chair - would like another author to work on these with him for both testing as well implementation other chair - should there be a security commitee? Bert: Andy is so far the only author. We need at least another one as a co-editor. [Martin volunteers.] Dan (as AD): Some talks with the security community might be needed. Andy: We are trying to come up with something implementable, it my not be perfect. somthing implicit in the draft - something acheivable that may not be perfect, there isnt any ability to control a user "to set the knob up but not down" Bert: We probably don't need to change the charter, the WG chairs will check. We also need to focus on the requirements. sounds like we have consensus to proceed have andy and martin to work on the doc, can we take this document as a base doc? when we start off do the requirements, we have some implementation (could be an appendix) or remove it for now, work this out in milestones Wes: A competing proposals shouldn't be precluded. Bert: We'll ask in the ML. Other proposals are certainly possible but I don't see the need for them. Wes: Give one week for alternative proposals. doesnt like the "draft by the IETF" has more power , suggests asking is there any other work that is needed WG chair - concerned that the time lost for someone to do a opposing view might take too long Wes - is concerned Bert: Do you support this document as a starting point for the ACM work? (Humming consensus.) asking for proposed time for yang modules etc on wednesday Dan (as AD) offers time in OPS area meeting for presenting the NETCONF implementation written by Ray Atarashi. Session closed at 11:30.