IETF 67, ANCP WG Meeting minutes. THURSDAY, November 9th, 2006: 13:00 - 15:00 CHAIRS: Wojciech Dec & Matthew Bocci AGENDA: ---------------- 15 mins - Administrivia, WG Status and WG Docs Update - Chairs 5 mins DSL Forum Liaison - Wojciech Dec (wdec@cisco.com) https://datatracker.ietf.org/documents/LIAISON/file375.doc https://datatracker.ietf.org/documents/LIAISON/file376.doc 10 mins - ANCP Requirements / Framework - Stefaan de Cnodder (stefaan.de_cnodder@alcatel.be) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-00.txt 15 mins - ANCP Acess Node MIBs - Stefaan de Cnodder (stefaan.de_cnodder@alcatel.be) http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an-00.txt 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-moustafa-ancp-security-threats-00.txt 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration- 02.txt 15 mins - Control Plane Graceful Restart extensions for ANCP - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-wadhwa-ancp-graceful-restart-00.txt MEETING MINUTES: ---------------- Chairs: Remove "Control Plane Graceful Restart" agenda item. Matthew - milestones. Will need to add some for Graceful Restart and other new work items. brief review of where we're at with charter items. DSL forum liaison. two docs on datatracker. Woj - DSL forum basically saying that they're following the WG, and have also passed over the WT-147 and L2CP use case. Their docs are much like our reqs/framework but have more in terms of reqs on DSLAM. Next DSL forum meet is Atlanta Dec 11-14. DSL Forum members should feel themselves invited to attend. Dave Allen - feedback on WT-147 form IETF WG is solicited. Seems to be deviating from what's going on here and it could be improved. Matthew - please post comments to ANCP list and we'll do a liaison back to DSL Forum. Could you please comment in next 2 weeks (given short timeframe before DSLF meeting). Stefaan - ANCP Framework & Requirements --------------------------------------- history from L2CP BoF/first ANCP WG. Became WG draft at Montreal so resubmitted as WG doc with some terminology changes etc. (though some sections still incorrect - so will be fixed in next version). definitions added for Net Data Rate (excludes physical layer overhead) and Line Rate (includes overhead), Access Node Control Mechanism (were using term without using it), Control Channel (different name before but also wasn't defined). changes to Access Node requirements - key one is identification of AN and access port (must be same in ANCP, PPPoE and DHCP). Also now say that must be routed encaps if running over ATM. NAS requirements - new section. wholesale model supports NAS acting as a LAC. need to finalise multicast use case, fill in the empty security considerations section (another draft has info so may just reference). comments from Woj, but would like more comments from WG. Woj (with chair hat off) - seems like most reqs should be related to protocol, but with threat analysis etc. would be good to provide some framework as to what is the expected use of the devices, location, etc. (so have boundary/intended use picture). not sure how much value there is in describing node functionality rather than the ANCP protocol (e.g. currently says should send SNMP traps following adjacency change). Woj (as chair) - would like feedback on how much we should identify requirements for devices vs requirements for protocol. Hassnaa - LAC sends QoS info etc. to LNS. Is there any interaction between ANCP and L2TP? Is that in or out of scope? Stefaan - should be in scope. whether done via ANCP or something else it ought to be added to docs. Mark Townsley - could work with L2TP mailing list. L2TP doesn't meet any more but mail-list is active and chairs are good.. Woj - a number of vendors have got together to draft a doc but not sent it to L2TP mailing list yet. Thomas (T-Systems) - regarding reqs for elements need to be clear e.g. what scalability requirements are (100s, or 1000s of nodes?). Need to consider this in the framework as to which environment the protocol should be implemented in. e.g. what works with 100s of nodes won't necessarily work for a large network. Woj - yes we need a picture as to where ANCP should be deployed, but stop short of requiring things such as "send an SNMP trap" Sanjay - one clarification. this is framework doc. But where has details of reqs are we thinking of doing a new doc, or is this one going to be comprehensive. Woj - I asked myself the same questions when read it (commented as if was protocol requirements but title says framework). Sanjay - do we want to separate? If is reqs then some things make sense. Sanjay - also requirements seem to come straight from WT-147 so should have reference Stefaan - yes. Michael Ramalho (Cisco) - seems like the ends you're trying to achieve are well communicated via policy language. So what you need for a particular app (e.g. DSL aggregation) can be defined in terms of policy language. E.g. satellite cases where if you use too much bandwidth consistently then you get throttled. That can be expressed in the schema that is used for that access topology. When I read this doc I see an apparent attempt to characterize reqs given a certain framework the authors came from in the DSL world and trying to put that into the requirements doc. Not sure that should put the abilities you want to signal there. They should be expressed in a policy language. Is the output of this work input to a set of schema for a policy language, or are you not thinking of a common information model. Stefaan - the framework doc says that the NAC can interact with a policy server but doesn't give many details. The NAS can get policy info from server and then use ANCP to enforce that in the DSLAM. So there is interaction but don't see ANCP as being input to policy work. Michael - if you look at other access arrangements than those in the doc you don't have them covered - probably don't have people participating. Confused as to whether this doc is for all access networks? Matthew - initial scope is DSL access networks. but not to say that we can't expand it. original WG scope was DSL. Toerless - do you see any problem in making this applicable to other tech areas by using a form of extensible/flexible presentation layer Michael - yeah, the policy language people don't use those kind of words. The things you want to signal (shaping, multicast, time of day routing etc) get embodies in the schema of the language and not in the requirements doc for a signaling protocol. If you signaled those things with a policy language then these things would be requirements for the schema. Toerless - do we want to define a protocol that is just a carrier for policies that we don't want to specify, or do we want to nail down a service and the protocol is part of that. of course there is a problem in terms of how far it should go. But just defining protocol without mandating what has to happen in BRAS and DSLAMs won't get us where we want to go. Michael - I think that actually the goals you're aiming at could be embodied in a schema if you'd adopt a given policy language to communicate these things... Stefaan - any language in mind? Michael - CIM would work (IETF defined) Woj - we started ANCP from a set of use cases. It depends where you want to cut the definition of policy, but yes, the use cases are policy. So use of protocol does fit into the schema of a policy language. But protocol definition is pretty much extracts elements of schema Sanjay - the protocol being defined sort of embodies policy schema and provides set of extensible TLVs. Suresh Krishnan - reqs say a NAS should be able to communicate with multiple access nodes. Is WG open to the reverse (one access node communicating with multiple NASes)? Woj - up to now has been one to many, but we're debating that. Stefaan - also means that one access node can go to multiple NASes Suresh - says ANCP must be mapped on top of IP. Does that mean can be on top of TCP? Stefaan - sure there can be a transport protocol in between... Woj - extensibility to other access types. Initially we're aiming at DSL but have made charter open so can look at other access technologies. If somebody feels strongly about including another access technology then please come forward and contribute. Michael - another good reason for a policy language is you can't count on every box at every layer to have same functionality. So e.g. if first box can't do policing then may happen a layer or two into the network. The policy server will know the topology and the capabilities of each box and can send policing info to the box that can do it. The endpoint doesn't need to know it to signal it. So don't have to assume that each box in the access network has to have all the capabilities that you may need. Just send generic request to access network and it'll happen where it needs to. Even within one technology it could happen at different layers of aggregation. So far don't see anything here you couldn't do with a policy language and where the reqs couldn't be part of the schema Sanjay - just to be clear we're defining a protocol between two network elements. Policy is complementary to this. Yet another way to do it. ANCP is a protocol between the network elements themselves... Matthew - take debate to list. Stefaan - access node ANCP MIB ------------------------------ draft started at IETF66 where discussed requirement for a MIB. scope of MIB is ANCP for access node (not NAS) MIB manages the access node control sessions, but not other things (e.g. control channels). session config table - NAS is identified by IP Address plus type (v4/v6). other attributes configure properties (e.g. version of ANCP). current session table. outstanding question on NAS MIB. Stefaan thinks too early to start NAS MIB, but maybe need to think about it. AN and NAS have different roles so probably best to have two MIBs rather than one. please read doc and post comments to WG mailing list. Woj - how much does MIB inherit from GSMP MIB? Stefaan - just textual conventions (e.g. version). Woj - is this fully standalone MIB? Stefaan - yes, no need to implement GSMP MIB. Woj - not seen any debate on mailing list so do please comment on it. Hassnaa - security threats/requirements for ANCP ------------------------------------------------ the main object is to investigate threats at ANCP nodes and develop model so can define security requirements for ANCP. communication with policy server needs to be secure, but not in scope here. mainly distinguish between two types of attack: 1) in path where attacker is in path from AN to NAS 2) out of path either attack could be active (take action) or passive (eavesdropping - later on may use info for unauthorised access). main security issues are prevention of DoS, impersonation and reading users' info. first use case. (dynamic access loop attributes). second use case. mainly active on-path attacks. one risk is replay - so illegitimate adversary could get privileged access. on-path is a mix of active/passive. third use case. main attacks are related to network functionality. fourth use case. mainly active on-path attacks. e.g. multicast group info could be changed by a man in the middle. Woj - multicast use case not really defined yet. what were your assumptions? Hassnaa - assumed that multicast is replicated and that there is some information regarding the group that is transferred from the policy server to the AN and which may be modified in order to disrupt the client's communication. Is abstract for the moment. Also consider damaging proxy functionality as being an attack. Based on threat model developed security requirements for ANCP. Hannes - you mentioned that the multicast use case isn't outlined in detail in framework. So is that something for the framework to provide mode detail on. Woj - fully agree. hole in framework remains to be filled. Hannes - threats doc has to move along, but the more work we do on the protocol the more specific the threat analysis can be, but also helps to have threat info in order to design protocol so we have to balance the two. want comments and will progress it as a separate draft at least for the moment to complement the framework. Sanjay - one quick comment on security requirements slide. Some of the reqs seem a bit strong given that protocol runs in a trusted domain. We could use SHOULD for some of those MUSTs. Hassnaa - we wanted this to work in untrusted domains as well Woj - I'll add here that following IETF best practice we should optimise for intended use but understand that may be used in unintended cases (e.g. over the Internet) as per BCP61 doc. Sanjay - the requirements outline what the protocol should provide in terms of capabilities. for deployment there is question of whether you want to turn on everything. e.g. may want to turn security on intra-domain even though they aren't "needed" so protocol should make it possible to turn them on. Make distinction between protocol requirements and usage. Suresh - two comments. No bootstrapping procedure defined so can't have this without knowing who the other end is. So you need a way to know that the guy the far end is the NAS. Hassnaa - that's why we have mutual authentication. Suresh - but need some kind of discovery procedure. Zero knowledge. Hassnaa - there's discovery in the protocol itself Hannes - the discovery of the nodes is a secondary issue. Authorisation as to whether it's a legitimate node can be done by walking the table. If people are excited by discovery (not seen in framework) then we need to address it. Stefaan - to respond to Suresh's comments you configure the IP address of the NAS in the AN. No discovery mechanism for the moment. Suresh - given that the AN knows the NAS are we missing a requirement that says we need to assure the initial exchange. Hassnaa - this draft is not trying to provide solutions. Hannes - mutual auth prevents man in middle between communicating entities Suresh - we have two MUSTs and a SHOULD right now. Hannes - the mutual authentication is already covered by AN and NAS (first two requirements) Haasnaa - trying to cover whole protocol and all communicating entities Hannes - but what are the other entities than AN and NAS? So if remove the mutual auth req it will be OK. Suresh - if that's what we do I'm OK Haasnaa - is it better to have two reqs (one each way) or a two way one? Suresh - has to be a MUST either way. Suresh - also says about privacy. Privacy for who? Hannes - confidentiality Suresh - but that's already covered. Woj - seems many comments. Suresh - not showstoppers. Suresh - for DoS might be better to be more specific and say e.g. "don't keep state until you know who you're talking to". Haasnaa - these are general requirements, that's a solution Hannes - requirement as stated is more generic. Murugaraj - is it really a security requirement to distinguish control from data? Haasnaa - yes, to prevent signalling reply attacks. And it's a SHOULD, not a MUST. Hannes - (Q to chairs). Should this doc become a WG item? Matthew - charter includes threat analysis. So certainly need to add requirements based on that. Lots of discussion/interest today. So ask Q to WG. We do have to do threat analysis, but maybe too early to become WG doc before we've had more discussion Hannes - just because is WG draft doesn't mean is over. Work usually starts then. Woj - hum vote for being WG doc at this stage. Sanjay - it does cover threat analysis and is comprehensive but think we need to wait for protocol draft to become WG doc first (as may need changes). Hannes - all WG docs will need changes. Sanjay - is just a matter of ordering. hum vote. Woj - seems like plenty of hums Dave Allen - you should put this to the list, that's what needs to happen anyway. Woj - want to make sure that points from discussion have been taken down. Hassnaa. will have some in minutes, but if need details can people please post on mailing list. Sanjay - ANCP protocol draft updates ------------------------------------- draft been around for a while. This is second rev. So will outline changes since rev 01. Assumes reader is familiar with 01. extension block allows us to add TLVs to existing messages if we come up with new info that needs to be exchanged from new use cases or extensions to existing cases. v1 had a bug where two TLVs collided - so now fixes. Also Qs on mailing list on ACI format - so now made clear is TR-101 syntax/format. Reason is that typically get ACI info in PPP or DHCP messages and NAS needs to correlate (so therefore need same format to correlate). Woj - ACI is same as used in option 82. are there any drafts defining it other than DSL Forum's TR-101 Sanjay - only seen in TR-101, which specifies it very well/extensively. Mark Townsley - I'm worried about having a normative ref to a DSLF doc as they aren't generally available. Woj - TR-101 is public. Once docs reach TR status they're public (available at http://www.dslforum.org/techwork/tr/TR-101.pdf) Mark - that's OK then. Sanjay - since draft out for a while and there are several interoperable NAS and AN implementations out there we'd like to request that it becomes WG doc. Stefaan - at last IETF meet we decided to separate framework and protocols, but this draft still has lots of framework in it. Sanjay - has some context for use cases Stefaan - sections 2 and 3 are mostly framework. Sanjay - that's because this was written before framework Stefaan - will it be removed? we agreed that at the last IETF. Sanjay - I'll try to take it out. Doesn't do any harm. Stefaan - not always in line with framework. If we have that then we'll have two framework docs. Sanjay - just has context on use cases. Maybe should shorten description. Stefaan - but on use cases you have more text than framework doc sometimes. So remove it and just focus on protocol. Matthew - not wrong to summarise framework, but don't want two different docs. Problem if one goes to RFC first and want to update the other. I suggest removing it. Sanjay - will just be context for use cases. show of hands on who's read it (fair number raised) consensus on becoming WG ID? only four hands raised. inverse question? nobody doesn't want it to be WG doc? none. Matthew - so lots of people have read it and are totally undecided! will ask Q on list again. Woj - overview of main gaps in framework and open Qs ---------------------------------------------------- list of bullet points. have had some discussion on partitioning. Any more input welcomed - otherwise will proceed on hard partitioning case. controller redundancy - lines up with earlier question on 1:N of controller/ANs or M:N (or whatever). Very little discussion on mailer. My takeaway so far is that priority is for 1+1. again if any more input then please come forward. Sanjay - one to one makes sense if doing the same kind of thing as for subscriber sessions. if we don't do something similar for PPP and sessions go down and come up again then doing same for DHCP isn't so bad. So for providers do we think inter-chassis redundancy in general is important. Stefaan - comment I have is that PPP session can go down and be re-established but DSL stays up. Sanjay - line info you're taking all that trouble to replicate won't be used when session comes up again. Stefaan - messages sent when DSL goes up and down independent of PPP state. Woj - have session ordering problem here. if a PPP session comes up from redundant BRAS before ANCP established then you're in the dark without the knowledge that ANCP gives you. Sanjay - that can happen without a failover. Woj - not sure if we can do anything at protocol level to address it (rather than box level). In essence one controller and many access nodes appears to be the main use case (followed by 1+1). Any other views from those who voiced Q earlier on 1:N vs M:N? ???? - to have more reliability we should consider controller redundancy. goes along with router failover etc. we also have multicast which is more downstream orientated. so should consider this... Woj: Need to initiate discussion on transport considerations. This should start by describing the overall problem; what is it? Haasnaa shown progress on security. multicast control refers to section in framework defining multicast control use case. Don't think we have progressed much (no update to use case) so need discussion on mailer as to what people have in mind. access line configuration. Attractive use case. not much detail in section as to what it'll be used for. Had discussion before on SNMP vs ANCP etc. Can people please re-read and see if we can clarify what is intended by this use case. previous notions typically inferred some kind of dynamic config based on subscriber profile. will be good to make sure we're still aligned on this... END.