17:40 Monday July 23rd, 2007 Margaret Wasserman - Welcome to attendees, agenda bashing Agenda: 1. Administrivia and agenda bashing 2. CAPWAP Threat analysis update 3. Transport Issues with CAPWAP Base Spec 4. CAPWAP AC DHCP Option 5. CAPWPA Base and Binding Specs Update/Editors update 6. MIB removal from charter Agenda item 1: Administrivia and agenda bashing - no changes to the agenda Agenda Item 2: CAPWAP Threat analysis update Charles Clancy - No comments received on the threat analysis document since last meeting. Document is in last call. Joe Saloway is reviewer. We encourage people to review and give comments. Pat: What is the purpose of the document? Informational? Change protocol? Charles: Document is informational, describes deployment scenarios and security properties. Intent is to cover topics in more detain than the security considerations. Tom Taylor: Who is intended audience? Scott: Document is intended to be used by implementers, and those who would extend the protocol in the future, to understand the implications of changes they would make. Margaret: If get feedback from security directorate review, would result in changes to the base document. Don't expect this though. Agenda item 3: Transport Issues with CAPWAP Base Spec David Borman - Advisor from the transport area for CAPWAP. Bringing issues forward from Lars and Magnus. UDP Checksum - Doc currently avoids uses UDP checksum. Performance shouldn't be a reason for not using the checksum. Redundancy is a plausible reason. But for IPv6, UDP- Lite has potential for middle box traversal issues, could let packets through if boxes don't know about UDP-lite. PMTU Discovery - Avoiding IP fragmentation is good. Some middle boxes drop IP fragments. Could limit to 576-headers, but don't take advantage of max possible. Have a PMTU mechanism such as a solution based on RFC 4821 could be built using existing protocol elements. Congestion Control - All new protocols need to consider congestion control - for fairness and avoiding congestion collapse. Concerned about the data channel. IP will deal with congestion, but if there is other non-IP traffic, need to further investigate congestion issues. If IP, state that additional consideratipn not needed. NAT Traversal - Current solution does not describe all cases, Doesn't describe the cases that don't work. Concern that clarification is needed - cases supported and cases not supported. Could be a clarification, but could turn up issues Performance of Lock-Step - Make sure that the WG considered performance aspects. Margaret: Are there any questions? Pat: Have looked at checksum issue. Doing checksum at high data plane speeds -10GBps, is difficult to do. Margaret: Node that has to check is the one that receives the packet. Done in an ASIC, which doesn't have checksum capability. Comment: Why is the checksum being done? Pat: Need to be familiar with the CAPWAP application Describes the CAPWAP application. Comment: Using DTLS? Pat: Can run DTLS over the data channel, but only required on control channel. Scenario at home: AP at home, might want to use DTLS on the data traffic. Margaret: Use 802.11 encryption over the wireless link. Comment: Addresses the checksum, not NAT traversal. Won't go through middle boxes. Margaret: Treat as separable issues. Comment: If using IPv6, need to use checksum. Pat: Will there be NATs in IPv6? Comment: Also firewalls. Recommend that firewalls be put in place. Not completely hypothetical. Most uncontroversial of the list items. David - Bringing these issues up now, so that the documents will proceed further, faster. Margaret: Appreciate that Lars and Magnus have brought this up now vs later in IESG. Lars: Appreciate that you're open to receiving comments. Initial e-mail went only between the authors and chairs. Pat: PMTU Discovery - agree that there is a way to use the discovery mechanisms, need guidance on how to use existing mechanisms to meet requirements of RFC 4821. Lars: Document doesn't say how you get the initial value. Dorothy G: Need to review for the WG what 4821 requires. Commenters: RFC 4821 describes PMTU discovery requirements. PMTU discovery is a way to discover the size of the largest packet that can be sent without fragmentation. Need this in a protocol, else just send packets, multiple packets are retransmitted when congestion. Could use minimum MTU - don't want to restrict, or have way to detect the PMTU. Lars & Magnus have pointed out the need to meet 4821 requirements for this. Margaret: Congestion Control only an issue for the data channel only; have lock step protocol on the control channel. Link between the WTP and the AC. Concerned about congestion in that tunnel. Tunnel could be running over links with non-CAPWAP traffic. Need to resolve for CAPWAP data link. Pat: As long as the tunneled traffic is IP, then leverage IP capabilities. Do we want to put advisory statements in the document - not use other protocols. Margaret: Limit applicability of CAPWAP to IP networks, e.g. not X.25. Pat: Not enforceable in 802.11 networks. Lars: Content of the tunnel matters. Margaret: Self delusional that all IP has congestion control. This is now being enforced for new IP protocols. Lars: Concern when have other protocols, get more than fair share of time when other protocols back off. Could claim to get by this by limiting to IP types, but something better is desired. Margaret: Could number the packets, and identify drops. Lars: Want something that behaves like TCP in same timeframes. Shape traffic to meet TFRC. Different schemes are better. Under congestion, shouldn't use additional bandwidth over what TCP would use. Pat: Easier to digest than other things that would need to be done in hardware. Commenter: Pseudo wires has the same issues. Tunneling protocols - needed for new ones. New BCP. Pseudo wires RFCs are out. Lars: problem is that products shipped before RFCs were finished. Mechanism doesn't exist today, draft being written. All deployments running over provisioned capacity. Not a good solution. Comment: TFRC will give the tunnel the approximate value of one TCP flow. Readily available for use - a quick fit, if want something better, will be a longer process. 2914- have to show meet requirements. David: When have congestion, need to back-off, if CAPWAP doesn't back-off, will cause more congestion, then have a fairness issue; other back off to zero, and CAPWAP is still congested, no remedy. Margaret: CAPWAP extends the 802.11 link. Are we required to back-off? I'm confused about the right behavior of the system. David: If have congestion, packets will be lost. If WTP drops packets before injected in, then allow other traffic to be fairly used, build a queue, slow-down, send at a lower rate, fewer drops. Margaret: Concerned that the switch is the arbiter of congestion on the link. What are the upstream implications? Lars: WTP sends data at unlimited rates. Having such a flow on a general link with internet traffic is a problem. Uncontrolled link layer traffic is a problem. Margaret: If theoretically allow other traffic, will be small. If WTP or AC are congestion controlled, don't understand, do we have experience with this? Comments: Don't want the middle box to be doing congestion control. Need to make sure that you're only doing that for traffic that isn't otherwise dealing with congestion. Comment: Encapsulating a link layer, which will incorporate traffic types, some of which will be IP. Pat: Could say we monitor the traffic - at .11n speeds, can't do buffering. Policy - when IP traffic is present. David: If rate coming in at the AC, is higher that this link, will have to drop. What happens today? Pat: Drop traffic. David: Could have policy to detect when frames are being dropped, and be more aggressive in that regard. Pat: If gets dropped in the network, don't know. Endpoints will invoke congestion control in the endpoints. Comment: Could say filter on Ethertype or implement congestion control. Read the Rosen document on problems and issues with congestion control for education. Comment: If central encryption, don't see the ethertype. Margaret: Then congestion control comes from the AC knowledge. Pat: Be pragmatic: have .11 equipment out there, there is non-IP traffic out there, but most is IP. Non-IP is in retail, applications don't run over the internet. Margaret: If more than one hop, turn on Congestion control. Low cost simple solution needs to remain simple. Pat: Point to TFRC, do congestion control on an application that is already doing congestion control. Traffic inside the tunnel is already congestion controlled. Margaret: Need to know how bad the congestion control problem really is. Lars: Point of the presentation is that don't know what is in the tunnel. Margaret: Need to understand more about the issue, and what the tradeoffs are. Answer may not be the same for different scenarios. David: Want to clarify: TCP Congestion Control (CC) does reliable delivery, with retransmissions. CC here is different, is NOT reliable delivery. Main focus here, drop packets faster, so that there is a greater probability that the other traffic will get through. As long as underlying guy isn't trying to retransmit. Margaret: There is no acknowledgement of lost traffic. Pat: WTP doesn't need to know. If packet gets lost, endpoints will react. What happens when getting non IP? Margaret: Same congestion if IP routing the same way. Lars: Similar to pseudo wires. If traffic is being dropped, is an issue. Still fairness issue. People are sending TDM, CBR over IP, all kinds of things. Similar issues. Comment: If CAPWAP is extended to other wireless protocols, e.g.Wimax, might have issues. Comment: Nat Traversal question. Pat: IF AC behind a NAT, need rules on the NAT. Comment: One side public and other not, have issue. When AC behind a NAT, solution is not fully baked. Server behind the NAT is an issue. Pat: NAT on both sides, translate to same address. Think that no NAT is present. Comment: Management action to put the rule in, no standard way to do this. Use ICE, but more state machines. Likely that AC is behind a NAT? If not, then out of scope. Margaret: Could be behind a firewall. Not behind a NAT, issue when translating the addresses. Comment: Firewalls do what they are configured for. Declare NATs out of scope. Pat: Administratively configured NAT. Do we care about the AC behind a NAT. Keep- alives is an issue, have on both channels. UDP guidelines have 2 minute timer recommendation. Need to be realistic, use 30 seconds. Comment: Timer value up for discussion. Margaret: Straw poll on "Is AC behind a NAT an issue" No clear opinion Comment: If end system is on a battery, have issues. WTP not on battery, having it send more frequently not a problem. Margaret: Need to take to the list. Comment: What about performance of lock-step. Lock-step is slow. Margaret: We'll do the math, probably ok. Pat: Only for firmware download, can keep operating. Comment: Just run the math, make sure the WG has thought about the issue. Comment: UDP-lite: What was the decision on firewalls? Margaret: Need to decide on how to treat this. Comment; NATs could handle UDP-lite like UDP, but they don't. Margaret: UDP-lite & NAT interaction not clear. Is using UDP-lite vs using UDP checksums in IPv6 for performance reasons, but tradeoffs, does that change the opinion of using UDP-list? If there are no concerns on the list, there is no reason to change consensus. Pat: We discussed this in the past. There are no UDP V6 NATS, so it was viewed as less of an issue. Margaret: Need agreement on a change to change from where we are. David: From transport side - need to make sure that the issue was considered. Either answer is fine, just so that the issue was considered. Dan: Could be that there is a need for better documentation in the specs. Agenda item 4: CAPWAP AC DHCP Option Discussion: Pat: Reviewed slides. Background discussion between DHCP chairs and CAPWAP chairs on how to handle this. Feedback was that new method was used. Add CAPWAP AC DHCPv4 Option to DHCP. RFC didn't meet the cutoff date. Comment: Will this cause NAT traversal issues? Comment: No Pat: Similar for IPv6. Will resubmit as a WG work item once the window opens. Should there be a WG last call? Margaret: Need to have this. Does anyone object to adding this as a WG work item? Comment: Haven't seen the document, hard to approve what I haven't seen. Pat: Has been posted. Dan: No rule that you can't WGLC the document? Margaret: Also give DHCP WG a chance to review. Commenter: Objection withdrawn. Margaret: See no objection to WG work item. Agenda item 5: CAPWAP Document status, editor's report Pat: reviews resolved issues, see slides. Reviews selected changes to 06/03 and 07/04. Issue 244 - preamble header optimization 2 issues for 08/05: Issue 15, DataChannel KeepAlive timer not defined, Issue 16:MAC Address Length, length field was incorrect. Next steps: submit the updated document 08 CAPWAP protocol spec - agreement from the chairs. Need to resolve the transport issues before WGLC. Any need for an additional IEEE 802.11 review? Comments: none needed. Agenda item 6: MIB Status/Removal from Charter Margaret: We should put off killing the MIB work item, Richard Young has put together some MIB documents. He has some MIBs that we should review, before deciding how to move forward. Pat: Had a concern with previous approach, should not just extract the contents of the messages. Comment: Had a quick look at them to verify that they would pass syntactic checks. Richard wrote a document to describe what should be in the MIBs. Technically it is a viable MIB, CAPWAP needs to decide if the contents are appropriate. Dorothy G; Asks for volunteers to review the MIBS: Pat. Richard was unclear regarding the publication process, apologize for that. Will get the documents and the summary of what is included to the list. Chairs: Please review when the documents come out on the list, especially the objects that are included - managed. Comment: and that they don't include info that is not needed. Margaret: Any other business? None. Meeting completed.