Minutes of the IEEE 802.11/IETF Conference Call

8 AM PST, 12/15/03

Attendees:

IESG: Bert Wijnen, Russ Housley, Thomas Narten, Margaret Wasserman (partial)
IAB: Bernard Aboba (scribe), James Kempf
IEEE 802.11 liason: Dorothy Stanley
WG/BOF chairs: Jari Arkko (EAP WG), David Nelson (RADEXT BOF)

Proposed Agenda

Document Status update

IEEE 802.11i
IEEE 801.aa
RFC 2284bis
EAP State Machine draft

Status of outstanding IEEE 802 liason requests

Peer-to-peer issues (802.11aaD7.1 comment 15, EAP Issue 204)
EAP Key Framework request
EAP method requirements

New liason issues

EAP WG: Network Selection/discovery (pending request from 3GPP)
CAPWAP BOF: IEEE 802.11 review
RADEXT BOF: LAN extensions

Face-to-Face liason meeting?

Action items

1. Bert to send email to Stuart Kerry and Tony Jeffree requesting review of the proposed charter of the IETF CAPWAP WG, cc’ing Dorothy Stanley.
2. Bernard and Jari to write up an EAP network selection problem statement, and circulate it for comment on the 3GPP, IEEE 802.11 and IEEE 802.1 mailing lists.
3. Dorothy Stanley to follow up with IEEE 802.11i relating to RFC 2284 reference change to RFC 2284bis.
4. Dorothy Stanley to bring up the “IEEE 802.11i Requirements” Internet-Draft at the Vancouver interim meeting of IEEE 802.11i, for revision and request for publication as an RFC.
5. Bernard and Jari to revise EAP key framework document to address the consistency in key naming/PSK mode issues brought up in the email from Dave Halasz.
6. Bernard and Bert to follow up with Paul Nickolich, Tony Jeffree, Stuart Kerry and Mick Seaman as to their availability for a meeting on Sunday afternoon, or another suitable time.
7. Bernard and David to send a copy of the strawman RADEXT WG Charter to the IEEE 802.1 and IEEE 802.11 mailing lists for review.

CAPWAP

The meeting started out by discussing CAPWAP. In discussing the proposed CAPWAP Charter within the IESG, questions had arisen that are in some ways reminiscent of the split between L2VPNs (IETF) and Provider Bridging (IEEE 802.1), namely: what work does the IEEE do? what work does IETF do?

Currently we have liasons from specific IEEE 802 groups to and from the IETF; most of the time we focus on liason between specific IEEE 802 task groups and IETF WGs. But in this case there may be some architecture work in IEEE 802.11, some in IETF; there may be work relating to network discovery in IEEE 802.1 or perhaps in IETF. So this is not just between IEEE 802.11 and IETF CAPWAP. Questions relating to the split of work between IEEE 802 and IETF that involve multiple IEEE 802 groups require a somewhat higher level discussion, probably between the IEEE 802 ExComm and the IESG.

One “theory” put forward is that the IETF should appoint a “default liaison” to IEEE 802 (Bernard Aboba), and that IEEE 802 should have a “default liaison” to IETF. These defaults would be used when there is no more specific liaison to handle a particular issue. The default could then communicate the message, and track status of the response.

Bert Wijnen noted that he had sent a recent CAPWAP charter revision, based on input from Bernard Aboba and James Kempf, to the CAPWAP mailing list, and so far there had been some tweaks but no major changes were suggested. This revision focusses CAPWAP on describing currently deployed architectures, rather than just focussing on the architecture of the “split AP”.

Dorothy commented that the new charter would get us to much the same place as the previous charter, but it was more practical in that it would focus on architectures that vendors found useful. Bert noted that the next step was to send a message to the New Work mailing list requesting review of the proposed charter. Dorothy asked if this was the normal procedure for WG charter proposals; Bert noted that it was.

The question arose as to how the IESG might best ensure that the proposed charter was reviewed by IEEE 802. Dorothy noted that Bob O’Hara was serving as the “Technical Advisor” to CAPWAP so as to ensure that documents get appropriate technical review. However, in this role, Bob is wearing an IETF hat, not an IEEE hat. So there is still a need for review by IEEE 802.11.

Although it is not clear that the IEEE 802 ExComm is subscribed to the New Work list, in practice, there are enough IEEE 802 participants on the list that a proposal relevant to IEEE 802 will typically be forwarded to the relevant IEEE 802 mailing list fairly rapidly.

Dorothy noted that Stuart Kerry had agreed to locate reviewers within IEEE 802.11 for documents produced by CAPWAP. Bernard asked whether the IETF might ask for a review of the CAPWAP charter from IEEE 802.11 as a first step. Bert agreed to sent email to Stuart Kerry requesting review of the CAPWAP charter, and cc:’ing Dorothy. The question arose as to whether there might also be a review by IEEE 802.1. Bert agreed to also send a copy of the CAPWAP charter to Tony Jeffree for comment.

There was discussion of whether the review might complete soon enough that Bert could get feedback from Stuart and Tony relating to the charter before or at the Vancouver IEEE 802 interim. Dorothy noted that the feedback process was independent of whether there was a face to face meeting; it might come by email just as well.

Dependency Status

Discussion then moved on to a discussion of IEEE 802 dependencies on IETF documents.

Dorothy noted that IEEE 802.11i had recently gone to Sponsor Ballot. This could result in IEEE 802.11i being done as soon as March 2004, but perhaps more realistically by June 2004.

Dorothy noted that IEEE 802.11i depends on IEEE 802.1aa, which in turn depends on RFC 2284bis. This implies that IEEE 802.1aa will need an RFC # for RFC 2284bis in order to resolve the dependency. IEEE 802.1X-REV D8 is currently in recirculation ballot, and planning to go to sponsor ballot after the January 2004 IEEE 802.1 interim meeting in Vancouver. As a result, it is on much the same schedule as IEEE 802.11i — possibly done as early as March, but more likely by June 2004. Thus publication of RFC 2284bis as an RFC by March 2004 is a good goal, so as not to delay publication of the IEEE 802.1aa and IEEE 802.11i standards.

Bernard Aboba provided an update on the status of IEEE 802.1X-REV D8. There is currently an issue being resolved between the IEEE 802.1X-REV state machine and the EAP state machine document. Paul Congdon, Jim Burns and Nick Petroni are converging on a proposed solution, though they are not completely there yet.

Russ Housley asked if this affects RFC 2284bis. Bernard Aboba noted that IEEE 802.1 had reviewed the relevant sections of RFC 2284bis and no issues were found. The discussion that is going on now is about changes to the IEEE 802.1X and EAP state machines, as well as possibly to Section 6.7. However, it was noted that IEEE 802.1X-REV D8 does not depend on the EAP State Machine document, which has completed its first EAP WG last call. Bernard expects the EAP SM to go to EAP WG last call again by late January.

Dorothy also noted that IEEE 802.11i also references RFC 2284 directly. Bernard noted that this reference should probably be changed to RFC 2284bis. Since IEEE 802.1aa depends on RFC 2284bis, a reference to RFC 2284 in IEEE 802.11i could create confusion about the expected state machine behavior of the EAP implementation within IEEE 802.11i. This could affect conformance testing efforts. Dorothy took an action item on this.

Bernard discussed the status of the IETF response to the March 2003 IEEE 802.11 liaison request (see references). That liaison letter requested replacement of the RFC 2284bis mandatory-to-implement EAP method with one meeting IEEE 802.11i’s requirements, which were listed.

Erik Nordmark replied to the request with a recommendation that IEEE 802.11i publish their requirements as an RFC. He also asked that IEEE 802.11i be specific about whether the purpose of the requirements was to serve as a set of requirements for selection of a single method (beauty contest for the mandatory-to-implement method) or just as requirements for any method that was to be used with IEEE 802.11i.

Bernard has gone ahead and put together a strawman IETF draft based on the IEEE 802.11i liaison letter. As with any translation, there is no guarantee that the orginal meaning was maintained. For example the term “required” was translated to MUST and “desirable” to SHOULD. There were also some requirements that were ommitted, such as replay and integrity protection. Bernard asked that IEEE 802.11i consider revising the document in any way they see fit, and submitting it for publication as an Informational RFC. It would be useful if this was published concurrently with RFC 2284bis, for example. Dorothy agreed to bring this up at the January IEEE 802.11i interim.

Bernard also noted that EAP WG had received an inquiry from Dave Halasz relating to a comment by Russ Housley on EAP key naming. Bernard noted that the EAP Key Framework did have a key naming section, but that this only applied to use of keys derived by EAP methods. It does not apply to IEEE 802.11i PSK mode, which does not use EAP. IEEE 802.11i PSK mode exists in part because IEEE 802.11 does not have a mandatory to implement EAP method. That in turn came out of the IETF response to the IEEE 802.11i March 2003 liaison letter. So in effect, the IETF’s response on mandatory-to-implement lead to IEEE 802.11i workarounds that subsequently resulted in a dictionary attack vulnerability in PSK mode as well as a situation in which IEEE 802.11i is unable to make use of the IETF’s work on EAP key naming. Bernard and Russ agreed that this was not a good situation, but it was one which has no obvious near-term solution. Russ requested that the EAP Key framework document discuss the implications of this issue, and in particular the potential vulnerabilities that result from lack of consistent key naming.

Jari noted that while the IETF would probably not change the mandatory-to-implement method from EAP MD5-Challenge that based on the requirements from 3GPP and IEEE 802.11i, IETF could publish EAP methods that conformed to those requirements. At some future time, this could enable IEEE 802.11 and 3GPP to select mandatory-to-implement methods for their applications. That seems like the best we can hope to achieve at this point.

New Issues

Aside from CAPWAP, two other new liaison issues were discussed: EAP-based network selection, and RADIUS LAN attributes.

EAP-based Network Selection

Jari summarized the EAP network selection issue. This includes several problems:

1. Selection of the access point as part of roaming.
2. Selection of the appropriate identity to use in authentication.
3. Selection of the network to connect to.
4. Routing of the authentication to the home server.

Bernard noted that at IETF 58, 3GPP liaison Stephen Hayes had indicated that 3GPP would be sending a liaison letter to EAP WG asking for work on EAP network selection. Jari indicated that the letter, if it was sent at all, might not request work on each of the problems above. For example, discussion in 3GPP seemed to be focussing less on the access point selection problem now, and more on the other problems. At this point it is therefore not entirely clear whether 3GPP would be sending a liaison letter to IETF or not, or what it would say if it was sent. Jari asked whether it would make sense to invite 3GPP liaison Stephen Hayes to the liason meeting in Vancouver. Bernard was not clear that this would be a good use of Stephen’s time.

Bernard outlined some of the issues with access point selection via EAP. If the station is not connected to an AP, it is necessary for it to associate with each access point, obtain the information via the EAP-Request/Identity and then select an AP to roam to. This is a very cumbersome roaming procedure, to say the least, even if Class 1 Data Frame support is added to IEEE 802.11, and if all the APs support pre-authentication (which is optional in IEEE 802.11i).

At IETF 58, concerns were raised about this, and the question was asked why conventional IEEE 802.11 Beacon and Probe Response isn’t used instead. The answer was that simulations show that when an AP has 10 virtual APs advertising different capabilities with IEEE 802.11b, that 35% of the transmission bandwidth will be used up by Beacons. So if there are dozens of networks to advertise, the IEEE 802.11 Beacon/Probe mechanism does not scale.

Dorothy noted that there had been some presentations on this issue within the IEEE 802.11 WLANNG group, but that there was no vote to form a study group since it seemed clear that such a vote if held, would lose. Jari noted that EAP WG was now considering the network selection problem and that he had sent mail to EAP WG asking for a problem statement by 12-15-03 (today). Bernard asked whether it might make sense for Jari and Bernard to put together a problem statement and then request review from IEEE 802.11 by sending mail to Stuart Kerry. There was also a question about whether review by IEEE 802.1 might be appropriate, since they are also working on discovery (IEEE 802.1ab and IEEE 802.1af).

Dorothy noted that she thought she knew what Stuart would say: that the issue was being considered by IEEE 802.11 WLANNG. Bernard noted that there had been proposals to handle “interworking” in WLANNG as well, and that those proposals included work on AAA which overlapped with the RADEXT BOF proposals on LAN authentication and WLAN roaming. So there was an unresolved question of how IETF and IEEE 802.11 should cooperate in this area.

In terms of the partioning of work on EAP network selection, there are some areas that have previously been worked on by the IETF, such as AAA routing, Network Access Identifier (NAI) definition, and Identity Selection (there is a PKIX draft on this subject, for example). However, the EAP WG does not feel comfortable taking on work relating to network device advertisement without an understanding of why this functionality belongs in EAP. Since the arguments are based on assertions relating to IEEE 802.11 Beacon/Probe scaling, review of those claims by IEEE 802.11 seems appropriate. There has already been IETF work in the area of alternative AP advertisement mechanisms (e.g. SEAMOBY CARD protocol) which has not been deployed; there is also IEEE 802.1 work in this area as well (IEEE 802.1ab, IEEE 802.1af). There was even a BOF at IETF 57 which was cancelled (IDP). Adding EAP based network selection to this list may not be helpful. Is there some way for IETF, IEEE 802.1, and IEEE 802.11 to have a conversation so as to straighten this out?

RADIUS LAN attributes

The next topic was RADIUS LAN and WLAN attributes. Bernard noted that RFC 3580 was developed as an Informative Appendix in the IEEE 802.1X-2001 specification, and subsequently published as an Internet-Draft and (later) RFC 3580. Bernard asked if there was a plan to incorporate RADIUS LAN or WLAN attributes within a future IEEE 802 standard. Dorothy did not know. Bernard noted that part of the push for WLAN attributes was coming from the Wifi Alliance (WFA) Public Access group. They were looking for IETF standard attributes that WFA could reference rather than pushing their own proprietary attributes as was done in WHISPR. RADIUS LAN attribute work is being lead by IEEE 802.1 Vice Chair Paul Congdon. The question arose as to how that work (or the WLAN attribute work) would be reviewed within IEEE 802. Jari Arkko has recently reviewed both drafts on the RADEXT mailing list and inquired as to whether this work should also include Diameter AVP definitions, so as to ensure compatibility between RADIUS and Diameter. This seems to make sense.

Russ asked whether this work would also apply to IEEE 802.16, which has a very different authentication model. Bernard noted that there had not been proposals for use of RADIUS with IEEE 802.16, but in principle if there was interest in IEEE 802.16 in such work, and people to do it, then it could be handled in RADEXT. Bernard took an action item to send a copy of the RADEXT Charter to the IEEE 802.11 and IEEE 802.1 mailing lists for review.

Liason meeting

The last topic of discussion was a potential liaison meeting between IETF and IEEE 802 on Sunday afternoon January 11 at the Vancouver Hyatt Regency.

One topic of discussion is overall IEEE 802 and IETF coordination — the issue of the “default” liason. Dorothy Stanley suggested that Paul Nickolich, chair of IEEE 802, would be the appropriate contact for such a discussion, along with other members of the IEEE 802 ExComm, such as Tony Jeffree and Mick Seaman. Bernard and Bert agreed to contact Paul, Tony and Mick to determine their availability.

Another topic of discussion was the review of the CAPWAP charter. Assuming that Bert got email to Stuart requesting charter review, Dorothy was not clear whether this required a face-to-face meeting or not. There was some discussion of whether it would be useful for Bert to meet with Stuart Kerry to discuss CAPWAP face-to-face.

Examining the IEEE 802.11 schedule, Stuart would appear to be in meetings from Sunday afternoon to evening, so that it might only be possible to catch him from noon to 2 PM perhaps. Bernard and Bert took an action item to determine Stuart’s availability.

It was noted that Bert will be in Vancouver most of the week, as will Bernard, James Kempf, Russ Housley, Dorothy, David Nelson, and others so that a breakfast meeting on some other day would work just as well.

Margaret Wasserman asked whether it was necessary for her to fly to Vancouver to attend the meeting, and there was agreement that this was not required. Thomas also noted that he could not make it.

9:15 AM PST Meeting adjourned.

References

IEEE 802.11 liason letters:
http://www.ietf.org/IESG/LIAISON/ieee802.11.txt
http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt

IETF response:
http://www.drizzle.com/~aboba/IETF56/EAP/ietf56-eap.pdf

RFC 2284bis:
http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-07.txt

IEEE 802.11 EAP method requirements:
http://www.drizzle.com/~aboba/IEEE/draft-walker-ieee802-req-00.txt

EAP State Machine:
http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf

EAP Key Framework:
http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt

Network selection:
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt
http://www.drizzle.com/~aboba/IETF58/network/

CAPWAP architecture:
http://www.ietf.org/internet-drafts/draft-mani-capwap-arch-00.txt

RADEXT LAN work:
http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt
http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roaming-01.txt
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-for-pwlan-00.txt
http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf”>http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf”>http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf

IETF/IEEE 802 Relationship history:
http://www.ietf.org/internet-drafts/draft-aboba-ieee802-rel-01.txt

Potential face-to-face liason meeting:
http://www.drizzle.com/~aboba/IEEE/liason.html