RADEXT WG Minutes for IETF60 Monday session

"Nelson, David" <dnelson@enterasys.com> Fri, 03 September 2004 19:26 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 03 Sep 2004 19:27:22 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RADEXT WG Minutes for IETF60 Monday session
Date: Fri, 03 Sep 2004 15:26:09 -0400
Message-ID: <A675D99D53706742B50619249A8EBF04FE2962@MAANDMBX2.ets.enterasys.com>
Thread-Topic: RADEXT WG Minutes for IETF60 Monday session
Thread-Index: AcSR69xue5w1rktlQhqCacMOAMbW4g==
From: "Nelson, David" <dnelson@enterasys.com>
To: radiusext@ops.ietf.org

IETF 60
RADIUS Extensions (RADEXT) WG 
Monday August 2, 2004 Session Minutes

The agenda is listed at:
http://www.drizzle.com/~aboba/RADEXT/ietf60_radext_agenda.ppt

Agenda bashing - no changes.

Liason requests - from other SDOs: 802.11, 802.1, GSMA SLAN
 WFA 3GPP2 3GPP  (See http://www.drizzle.com/~aboba/RADEXT/liasons/ )

Liason Plan - In the short term, we will address SDO requests in a
timely way.
In the long term, the IETF wishes to focus on protocol changes and
extensions with widespread appeal.  Other SDOs should be prepared to
work on extensions particular to their own requirements.  RADEXT WG
should assist SDOs in doing their own work (ala SNMP).

WG milestones -  See web page
http://www.ietf.org/html.charters/radext-charter.html

WG last call is currently being held on drafts:
2486bis (NAI), draft-arkko-roamops-rfc2486bis-02.txt
RADIUS Extension for Digest Authentication, draft-sterman-aaa-sip-03.txt

Presentations -

Bert Wijnen - RADIUS MIB Changes for IPv6
	- Should go fast with MIB doctor participation
- Could augment existing documents, but could deprecate old modules so
that implementations would be more straightforward.  
	- Needed to do IPv6 
	- Create 5 new objects
       - Propose WG augment existing modules - agreement from floor
       - MIBs needing be to be recycled are RFC 2618-21
    - WG prefers to modify existing MIBs rather than create new 
    docs

Mutaza Chiba - MIB for RFC3576, Dynamic RADIUS
       - Create a MIB similar to existing  RADIUS MIBs
       - Need two MIBS, one for client one for server
       - Currently only for IPv6
- Question of who is interested in this work - got no response	

David Nelson - Extended Management attributes
	- Existing two attributes are service types for CLI
	- Need other attributes for SNMP, HTTP, etc.
 	- Also need security levels 
	- Need attributes to specify roles or privilege levels
	- See draft-nelson-radius-management-authorization-00.txt
	- SNMP usage in conjunction with service type of "Framed-
Management"
       - Bert W. points out that SNMPv1 and v2c are now historical
	- Suggestion that community based SNMP not be supported 
       - Enterasys is working in this area using vendor-specific
attributes
	- Idea is that this might be more generally useful and if 
	others are interested it could be standardized
	- Two hands indicating interest from the audience
	- Send comments and suggestions to the RADEXT list

Wolfgang Beck - SIP authentication  - draft-sterman-aaa-sip-03.txt
	- RADIUS server generates nonces
       - Required for AKS
       - Draft version 03 emulates an access-challenge sequence
       - Proposal - use Access-Challenge RADIUS packet type
       - Draft in last call - please send comments to list soon !!
       
Jari Arkko - RFC2486bis
	- Status - rewrote to fix errors in draft version 00
	- Clarified the ! syntax
	- Added privacy discussion
	- Changed the examples
	- Discussion on list about feature interaction between 
	User-Name rewrite and the ! syntax
	- could note this in some guideline document
      - or could require a reverse ! conversion for Access-Accept
processing
	- Jari won't talk about it in this draft
	- Question from Paul Funk about why not just convert to what is
required for other apps when needed
       - Jari points out a problem with sending NAI to DNS if the two
are 	not the same
       - Question is whether NAI and email (DNS) will internationalize
the 	same way
      - Internationalization will take time
	- This might be a problem in time?  Probably will not need to
mail 	using NAI address, (so not a problem) but not completely clear.
       - Draft in last call - please send comments to list soon !! :)

Jari Arkko for David Mariblanca - Lower Layer EAP Issues
	- Provides information about the lower layer that EAP runs over
	- AAA server with EAP services both AP and VPN gateway
	- Desire to understand the EAP transport protocol, via an
attribute
	- Is it related to NAS port type
	- What is the port type
       - Could it be handled by sub-type of port type
       - Idea is to tell server what is going on in the access  point, 
       what are the attributes  that are important
       - Focuses on EAP carrier between the user and client - not the
port,
        although not clear what the difference is
       - Topic will be brought up more on the RADEXT list
       
Paul Congdon - LAN Attributes for 802.1
	- Collected stuff from various groups
	- Other attributes will be discussed Thursday
       - Possible overlap and alignment with LAN tunnel attributes
	- How should the attributes be bundled?
	- Attempt is to bundle to solve IEEE 802 issues
	- Will anyone implement this in RADIUS servers (is it
interesting)?
	- Implementer comments?

Avi Lior - RADIUS Redirection
       - Sometimes an operator would like to be able to control a user
session
	- Limit what user can do (e.g. "walled garden")
	- Notifying the user (e.g. with  SMS)
	- Notification scheme not covered in the draft
	- Draft includes NAS-Filter-Rule attribute
	- Feature to redirect HTTP traffic to support Web Authentication
	- Discussion of difference between RADIUS and Diameter
	- Question: why not do redirection inside a filter, because
ordering 	is important
	- Answer: wanted to be compatible with Diameter
	- Talk about this issue some more on the RADEXT list

Bandwidth 
	
On the bandwidth draft, there was some discussion around what can we
actually specify, or do we simply have to punt the problem and identify
a filter-id that must be pre-configured?   That is really how the
filter-ID scheme came up in the first place. No-one could agree on a
standard set of controls, so to wash your hands of the problem, they
simply send down an identifier.  This isn't really driving us towards
good interoperable implementations.

	- Allow an end-user organization to specify bandwidth
       - Advertisement of bandwidth capabilities is optional
	- Selection of allowed bandwidth by AAA server
	- Followed by confirmation message
	- Re-authentication with either push or pull model
	- Issue: single attribute or separate attributes for four
parameters?
	- Issue: include burst size, profile ID or algorithm ID?
	- Issue: what hardware will be able to support this?
	- Devices may have rich QoS capabilities
	- Can use vendor specific attributes, but then how to
standardize.
  	- Is there a standard way to specify QoS?

Avi for ? - prepaid
	- Presented prepaid model, i.e. carrying prepaid service /
credit 	info over RADIUS
	- Multi-services - differentiate between flow types
	- Service may be different IP-flows 
	- Access service is default or initial service
	- 3GPP2 uses it as the "main" service instance
	- Quota - complicated buckets to manage variety of applications
	- Next steps - traffic to date vs. delta
	
Avi for Hannes - prepaid
	- Extensions for event based charging
	- Service is not access service
	- How does RADIUS specify service and actions?
	
Volunteers requested for 
	Issues doc
	


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>