Subject: [Capwap] CAPWAP Minutes from IETF72 Dublin

From: Margaret Wasserman <[email-masked]>
Date: Fri, 12 Sep 2008 16:53:58 -0400

Hi All,

Here are the minutes from the CAPWAP session at IETF72 in Dublin.   
Thanks to Dorothy Stanley for preparing them.

I'm sorry for the late circulation.  I had attempted to circulate them  
earlier, but they don't seem to have gone out.

Margaret

---

Notes from CAPWAP session: July 29th, 2007 1740-1840, Dublin

Margaret Wasserman opened the meeting and reviewed the agenda:

Agenda is to
-          - Review status of documents
-          - Present MIB status
-          - Discuss issues raised on list

Margaret: I’m sending around the blue sheets – please sign them.

Margaret: Is there a volunteer for scribe? Dorothy Stanley volunteers.

Margaret: Status: We have 6 documents in progress, see the website:
-CAPWAP base specification – currently in IETF last call, closing week  
after next
-.11 binding document – also in IETF last call, closing week after next
-Security threat analysis- – finished IETF last call, minor changes  
required
-DHCP – finished IETF last call, minor changes required
And 2 MIB documents that are not yet completed.

We’ll wait to send the Security threat analysis and DHCP document to  
the IESG
until the protocol and binding documents are completed, for context.

Base document – we knew there would be comments and a new revision.  
Have received comments from Pasi, which will
require text changes. Review period ends in over a week, may get more  
last call documents.

However, we are most actively working on the MIB documents.

After we finish the MIB document update, we can review comments that  
have come in from Pasi.

Is anyone following jabber? No

Any comments on the document status summary? None

Presentation - Chris Elliot (Cisco) – CAPWAP WG MIB Drafts Report
-          He has been working with Shi Yang (Richard), who has done  
most of the work on this

Current status – both documents published as working group documents
Current version number of drafts is 00.
David Harrington has offered MIB doctor services.
Most issues involve description errors, smlint complaints and  
inconsistent name rules.

Dan Romascanu comment: the protocol has changed, but is not yet  
synchronized with the MIB.
Since the protocolis now stable, should be able to do this.
Next version is planned to be published in August
-          Fix bugs found by Dan and other experts
-          Keep synchronization
-          Clean up language
-          Verify compliance with latest IETF MIB guidelines
-          Request more comments form CAPWAP working group members.

Questions or comments?

Margaret: you should update the author list – include currently active  
folks, and acknowledge others as contributors.
Also, want to finish this work soon.

Dan R – Took me two days to review the document. Also lots work to  
check consistency.

Chris: Aiming for sometime in August.

Dorothy Gellert: – Puneet is no longer able to work on the mIB, we are  
looking for additional volunteers, if anyone is interested.

Margaret – Need to make sure that the MIB issues are in tracker, to  
document resolutions.

Margaret – Issue of MD5 used for hash of checksum, does the  
application make a difference?

Pasi Eronen– does make a difference. There are some environments where  
it is difficult to use MD5 for any purpose – e.g.
government applications. Tim Polk may have more info, I haven’t had a  
chance to check with him on this.
Are there shipping implementations?

Margaret – Depends on what you mean by “shipping implementations”. Am  
aware of 2 interoperable implementations.

Margaret – DTLS retries – view it as good that retries can go on  
forever. We saw this as a decision for the application.
Pasi – Doesn’t really matter where the timer is, should be clear.

Margaret – Does matter, if we specify that timer is in DTLS,  
application can’t go longer. In this type of application, right thing  
might
be to not time out – it’s a brick if it can’t connect.

Pasi – In most applications, doesn’t make sense to transmit forever.

Margaret – Another issue – start-up might be overcomplicated, session  
resumption. Give us more advice on how this can work.

Pasi – Sent e-mail on this to the list. Complexity comes from fact  
that full handshake not needed for the data channel.
Don’t see a gain from requirement to “not implement”. TLS has  
renegotiation capability – need to figure out how this works with  
“must not”.

Charles Clancy: What would happen if you resume when first session is  
still active?

Pasi – Web browsing uses multiple connections
Charles: Seems reasonable to simplify. Possible to open a data channel  
without having an established control channel.

Dorothy G: Is that a new comment/issue?
Charles:  No, part of the “must not” question.

Charles: If we change to a CRC – would that be better?
Pasi – Yes
Margaret – Need to check with Tim on the MD5 question first, before  
decision to change is made.

Margaret – MTU issue. Current text put in based on transport AD input.  
You’re saying that we should
say “we send a packet at a given size” All out packets are small until  
firmware download – find out then.

Pasi – have complexity – send probe, get response, interacts with how  
capwap protocol does implementation.
Do path MTU discovery in the discovery phase. If get too large packets  
at that time, need to look at how this is fragmented.
Order is maintained by lockstep requirement. What if one was larger  
than the max? Need more text.

Margaret – May be an issue if backoff due to no response.

Pasi – Don’t need to probe all the time, need to figure out what to do  
if you get an ICMP back. Seems possible that the 2 ends
could get out of synch, no offset to the end of the file.

Margaret – If have a block, and it doesn’t get through. If packet was  
received, but not acknowledged, would we send
the packet again? In a lossy network – send lots of packets.

Pasi– Look at text in an RFC – 45?? – Recommendation is to retransmit  
a couple of times, then decrease packet size.

Margaret – What about the interaction with DTLS?

Pasi – DTLS never retransmits anything. It doesn’t remember what it  
transmits.

Margaret – Are there any other comments to discuss?

Pasi – Some of the comments were questions, need more explanation.
How the WTP processes the information elements that it gets from the  
AC? Discuss on the list.

Pasi – Need more explanation of how the information elements are  
processed.

Dorothy Stanley: Processing of 802.11 information elements is  
specified in 802.11 document.

Pasi – Yes, but seems like in most cases the WTP receives elements to  
forward, and just sends the elements out,
for example in a Beacon or Probe Response. But it consumes some  
elements.

Dorothy S: Agree that the CAPWAP spec should clarify the cited  
different cases.

Margaret – Security analysis document

Pasi – I have sent comments to the list.

Charles: response to Pasi’s comments on threat analysis. One comment  
re: support of WEP.
not precluding support of WEP, support this, and also RSN.

Dorothy S: WEP is deprecated in the .11 standard, but implementations  
are not prevented from supporting it.

Pasi – An editorial change is needed to make it clear in the threats  
document that WEP is supported in the CAPWAP spec, but
Not advised to use, and not considered in the threat analysis document.

Pasi: Zero config WTP? How to make sure you’re talking to the right  
AC. List of ACs?

Margaret – Implemetations will attach to any AC in some cases.

Pasi – Should include a discussion of this in the security  
considerations.

Charles: Need to add this in the base spec security analysis. May rely  
on the Cert, cert has the right options set.
Will propose text, with Scott, see if Pasi’s comments are addressed.

Margaret – Thank you to Pasi for his thorough review

Pasi – I started reviewing now, due to schedule conflicts, and decided  
to send the comments early – rather than entering in the discuss tool  
later.

Dorothy G – Start talking about future work.

Margaret – There is a wish list for CAPWAP, Also could support other  
items added in 802.11 since the spec - .11k and .11r.
on the wish list – DTLS 1.2 (in final review), QOS. Do we want to go  
to draft 2.0 of CAPWAP?
Do these items warrant future work? Or should we quit while we’re ahead.

Puneet – We have done a lot, we should take a break, revive the group  
later if needed based on deployment experience.
Margaret – I agree.

Dorothy G – Spec updates, could be done in ops area, not require the  
WG to be restarted.
Margaret: If people deploy, then we will get feedback.
Dan R – Talking about new work, this is the time to discuss it.  
Individual submissions can be proposed.
A 2.0 – is this a major revision?

Margaret - Meant only the next revision, not necessarily a major  
revision.
Bug fixes – Implementation, deployment BCPs – do in the OPS area, if  
take to draft standard.

Margaret: Is there anyone who disagrees with closing the group after  
the current documents are published?

No objection.

Charles: IESG review – will we have issues re: hash agility re: DTLS  
1.0?
Pasi – No. The new DTLS draft is in -00, will take some time to  
complete. Don’t delay the capwap specs for this.
Should be an easy extension. Minor upgrade with Draft 1.2.

Abijit: Need to check that we change the text that currently requires  
use of block ciphers.

Pasi – Current version does not require this, it was incorporated  
already.

Margaret – Hope we have no reason to meet in Minneapolis.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap