Monday, November 06, 2006 3:20pm Note: All consensus calls taken in the meeting will be verified on the WG Mailing List. WG Status, MIBs, IPR, Milestones Pat Calhoun: WGLC before next meeting? Yes, before IEEE review. IPR reminder to re-declare any potential IPR against the current capwap spec. Any declarations on the previous pieces that went into the current CAPWAP spec need to be declared against current spec. Pat Calhoun: Issues comes up with patent applications. We can't tell IETF specifics until the patent is approved. New Milestones presented, no objections. MIBs: Now that we have the capwap base protocol and 802.11 bindings, we should have 2 MIBs. No objections from the WG. Consensus on 2 MIBs Volunteers? See chairs and send mail. Are there any example MIBs (on this protocol a proprietary one in this space) that could be shared with the IETF Pat Calhoun: 802.11 binding MIB should be the 802.11 MIB. We should utilize the IEEE MIB. Dan Romascanu: If we try to re-use the 802.11 MIB modules, WG needs to make an assessment on the quality of the IEEE MIB, and how well its maps to IETF CAPWAP Scott Kelly: CAPWAP Threat Analysis. No one in the WG read the CAPWAP threat analysis 00 draft. Dan Romenescu: What is the state of the Security Consideration section? Need to move quickly since this document need to go to IESG as part of the same package as the protocol specification. Charles Clancy: This is an informative document. There is still normative text in the security considerations section. Pat Calhoun: Informational? Yes. Secuirty consideration section should reference this new document. Dorothy Stanley: CAPWAP specifications Editors Report Authors section is TBD. www.capwap.org for iisues and descriptions 04: Clean up the trakker issues and the 7 issues identified in this WG meeting. Pat Calhoun: How does WGLC work with IEEE review? the Intent is to do the WGLC in parallel with the IEEE Review? Pat: Calhoun: Open Issues: 227: No way to differentiate DTLS packet from the Discovery packet Proposal: include a pre-header that dictates what follows. Puneet Agarwal: Why 2 session IDs? Because the MAC address field is optional, so you can't distinguish 2 WTPs behind a NAT if they both send you control and data packets at the same time. Davd Perkins: 1) None of the proposals solve the re-try problems. Pat asked to explain the retry problem. 2) Not sure session ID is needed in every message: Pat: we shouldn't go inside DTLS to figure out what an ID is. Margaret agrees, and wants to use DTLS as a black box. Bob: O'hara: DTLS is not always available, so is absent from the data packets. David Harrington: Proposal Pat preference reminds him of SNMP V3,(bits outside the DTLS header) Put inside the secure transport. Scott responds that handling fragmentiation inside of CAPWAP but these frames are not protected. That is what happens if we put DTLS inside CAPWAP, need to resolve other problems. CharlesClancy: Problem with Session ID binding. Concerned if we separate CAPWAP and DTLS too much. What prevents you from putting a different session id for another WTP? Not secure enough. Want to see a unique ID coming out of DLTS to prevent spoofing of the session id. Pat proposes Charles to send some text' Joe Salowey: TLS to bind tunnel to authentication protocol. Not necessarily a session id between 2 differnet layers, one way to bind them is to bind the identies. Removing the session ids would make it difficult to handle NATS Client Nonces? No you have to start extracting out of DTLS, not a good idea. David Perkins: Why the current retry doesn't work. Sent mail on June 23rd. you misunderstand the F bit. David and Pat will take this up on the list. Davd Harrington: Concern that having the DTLS inside capwap makes it more complex. Security Inside the SNMP message became a problem. Pat: Problems with IANA. David: More problems with operators than IANA. Margaret: Ignore now the issues of Session ID and if it needs to be coupled with DTLS, can we agree on Proposal 3. Consensus, only one objection. Puneet: Doesn't understand Tunnel ID. This is a later issue. Removal of Timestamp: Any objextions to timestamp? No Objections. Related issues will be closed in tracker, the specifics that were raised, will be made new issues. Version Field issue: (proposal #1) 1 version or 2 version: No consensus. David H: Sees it both ways. Version outside, if DTLS version changes, you may need that, supports 2 versions. DTLS Policy issues (221): Scott Kelley says this is a for all WTPs,may wants to have a different policy on certain WTPs. thinks we need to take this offline. Issues 217: Should adopt addition of padding. Puneet thinks we should not. Not sure why we need padding at the AC to send to the WTP, when encryption is done by WTP. Will take this on the list. If adds something, can do that over the padding, no extra work for the WTp. Bob OHara: IIf it does fragmentiation its still more efficient to for WTP to have the padding. Dorothy Stanley: Key RSC issue Syncing of keyRSC value between WTP and AC. Consensus on Proposal 4. Pat Calhoun: DTLS issue Proposal to create a Black blox DTLS and only define the interfaces between DTLS and CAPWAP. Charles Clancy: Genreally he agrees. Don't get rid of too much information. It may be important to understand why it failed. Margaret disagrees, says DTLS should log why it fails. Dorothy Stanley: Retlunctant to start pulling things out, Scott Kelly agrees. Worried we would take out too much. Actioni item for Pat to get with security advisors to see what can be pulled out. Have DTLS Rehandshake: Charles Clancy: rekey state, if we can configure DTLS with a rekey policy that would be enough. Scott Agress. Mani Agrees, there was a policy change, may need to re-key. Joe Salaway: Good to specifiy re-key policy and understand If it failed. Take to the list. Proposal for an interim meeting. Action to set up the meeting. Take this back to the list