Minutes from the Basic User Registration Protocol (BURP) BoF meetings held in Minneapolis, MN.
Thanks to Behcet Sarikaya for capturing the notes.
Tuesday, March 20 at 1700-1800
==============================
1. Problem Statement: Basavaraj Patil
Basavaraj discussed the problem scope. Network and operators require a user to register in order to provide access to the network or access to value added service. He emphasized that current registration mechanisms are built into the lower layers and thereby make them access specific. Two I-Ds (draft-das-burp-requirements-00.txt) and (draft-soliman-burp-require ments -00.txt) discuss the requirements. The I-Ds will be merged into a single document after the IETF.
Draft authors felt the need for an upper layer protocol which will enable the usage of a common registration mechanism for multiple access types. Presently, AAA protocols (such as RADIUS or Diameter) reside within the network and use information about the user obtained via mechanisms such as PPP to authenticate and authorize as well as charge (accounting). Basic User Registration Protocol (BURP) should be the mechanism that exists between the user and the network to carry user information used by AAA entities. Although configuration is an important aspect to network access, it is out of scope for the BURP BoF.
2. Pros and Cons of Upper Layer Network Access: Bernard Aboba
(www.drizzle.com/~aboba/IEEE/)
Before describing the pros and cons of upper layer authentication, Bernard discussed few issues such as, how do we measure if a protocol has been a success, what do we do today , who standardizes what and what we have learned from the past? He also described static vs. extensible authentication and why we do authentication at link layer. He presented pros and cons of network access authentication that has already been implemented at every layer. For example, today network access authentication is done at link layer. Network Access Server (NAS) and client use PPP links. Then NAS and AAA server use IP based AAA protocol. IP layer is used in hotel to access Web Server based on ICMP re-direct method. At UDP/TCP layer propriety token card protocols are used. Finally, he raised five important questions and concluded with a summary saying that layer-3 authentication makes sense for a wireless WAN.
A discussion ensued regarding the increasing speeds of routers and switches to gigabit and beyond and some of the issues associated with doing access control and filtering at higher layers for networks that operate at such high speeds.
3. Requirements for High-speed Internet Access in Public Places
Anand Balachandran
Anand discussed the current trend in ubiquitous internet access and the related security issues. Current schemes are: MAC level filtering, WEP key security, IEEE 802.1x port based access control etc. although the latter requires changes to existing APs. He described their vision on network access protocol. It should be based on IPv6/v4, support multiple authentication schemes. AAA E-cash system of VISA, Masters cards etc. Service models: Model 1: free access to local resources in the Intranet and no authentication is required. Model 2: Authenticate and pay. It allows access to the Internet, and thereby differentiated charging. Scope is: user-network interaction; Protocol is decoupled from routing and location updates for mobile hosts. Fallout is: a user registration and authentication protocol has been implemented and working in malls for 7 months. He has not described the encryption protocol since it is beyond scope.
Discussion cut short because of time limitations.
4. Applicability of a user registration protocol: Yoshihiro Ohba
Ohba described L2 access control as "all or nothing" which is simple but more flexible access control would be useful in public areas. Multihoming is another issue: a host may associate with many access routers (ARs). A host may have multiple interfaces that belong to the same or different AAA domains. If all ARs belong to same AAA domain, performing AAA per AR may not be good idea. The same is true for multiple interfaces. He also discussed AAA application protocols issues such as MIP and SIP. It is always good to have protocols to be AAA ready without any modification to AAA base specification. According to him BURP should be a light weight client-server protocol for user registration to the visiting AAA domain.
5. Why BURP is required in wireless nets: Pat Calhoun
Pat explained the need for BURP. Currently PPP is used because it is an IETF protocol. However, in cellular world LCP of PPP is no longer used to negotiate link parameters. Authentication phase is also not used, instead Mobile IP authentication is used. IPCP is used only to negotiate a NULL address. He has given several reasons why PPP is bad. According to him a light weight registration protocol is needed which should include authentication, re-authentication, disconnect message, contains minimal state and compression negotiation. Moreover, since Mobile IPv6 does not have access control at the edge, BURP would allow the first hop router to perform this function.
6. Discussion of related I-Ds
draft-ietf-dhc-aaa-ra-00.txt -- George Tsirtsis
George mentioned that he presented this draft in dhc WG as his own contribution. The main idea is to extend DHCP as an Internet access model in which AAA procedures are invoked from a DHCP relay agent. He thinks the protocol should support full AAA functionality not only registration. For example, policing and accounting are provided by AAA apart from registration. However, he indicated that it is not necessary to have it always with DHCP but the registration agent should be in the AR since it is simpler to do access control at AR. He also discussed why not DHCP? Some BoF members think it is not a good idea to tie the registration with a configuration protocol such as DHCP.
7. draft-perkins-aaav6-03.txt -- Charlie Perkins
This is also an individual contribution with his colleagues at Nokia. Charlie started with general philosophy, have access control at AR and should coexist with ipv6 stateless autoconf. He suggested to have a generic method. Enable integration with other access methods such as mipv4 extension for AAA and try to make it for mipv6. The generic framework should support different mechanisms such as stateless autoconf, DHCPv6, mipv6 etc.
Presenation cut short because of time limitations.
Discussion of problem statement and charter
-------------------------------------------
A. Basavaraj asked for comments on problem statement.
Suggestions: DHCPv6 may add new requirements. We should concentrate on authentication schemes, kerberos, etc. It should be decoupled from address acquisition mechanisms. Authentication in the core is complicated, the route can change etc.
Chairs mentioned that they will consider these suggestions and also look into Bernard's comments.
B. Consensus
Question 1: Do people agree that there is a problem as stated by this BOF exists and that it needs to be addressed?
Response +ve : Overwhelming Yes
-ve : A very few No's
Question 2: Does a WG need to be created out of this BOF to address this problem?
Response +ve : Overwhelming Yes (again)
-ve : A very few No's
Next Steps: An updated problem statement/charter will be sent to the Internet ADs for approval and request to create a WG.