Draft minutes of IETF 77 RADEXT WG meeting

["Bernard Aboba" <[e-mail]>]

RADEXT WG Minutes

IETF 77

Anaheim, California USA

Working <http://tools.ietf.org/wg/radext/>  Group Home Page

Jabber room:  radext at jabber.ietf.org

Chairs
        Bernard Aboba <bernard_aboba at hotmail.com
<mailto:bernard_aboba%20at%20hotmail.com> > 
        David Nelson <d.b.nelson at Comcast.net
<mailto:[e-mail]> >

Agenda
March 22, 2010
 
17:40 - 17:50 PT: Preliminaries 
 
     Bluesheets
     Attendance
     Note takers
     Agenda bash
     Document Status
 
RADEXT WG Agenda Slides
 
Document Status:
 
l  Completed IETF Last Call: Waiting for Revision
l  Design Guidelines <http://tools.ietf.org/html/draft-ietf-radext-design>  
l  In IETF Last Call
l  Status-Server
<http://tools.ietf.org/html/draft-ietf-radext-status-server>  
Comments so far:  An editorial NIT
(http://www.mail-archive.com/[e-mail]/msg45725.html ), and a Gen-Art
review (http://www.ietf.org/mail-archive/web/radext/current/msg01590.html )
l   AD Review: Waiting for Revision 
l  RADIUS over TCP
<http://tools.ietf.org/html/draft-ietf-radext-tcp-transport> 
AD review comments: 
l  Completed RADEXT WG last call: Waiting for PROTO Writeup 
l  New Tunnel Type Values
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type>  
l  In RADEXT WG Last Call
l  IPv6 RADIUS attributes
<http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00>  
l  RADIUS over TLS <http://tools.ietf.org/html/draft-ietf-radext-radsec>  
l  RADEXT WG Work Items
l  NAI-based Peer Discovery
<http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery>  
l  RADIUS Crypto-agility Requirements
<http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements>  
l  Extended RADIUS Attributes
<http://tools.ietf.org/html/draft-ietf-radext-extended-attributes>  
l  Under Review as a RADEXT WG Work Item
l  RADIUS Attributes for IEEE 802 Networks
<http://tools.ietf.org/html/draft-aboba-radext-wlan>  
l  RADIUS over DTLS <http://tools.ietf.org/html/draft-dekok-radext-dtls> 
 
 
SECURE RADIUS TRANSPORT (30 minutes)
 
1750 - 1800 AM PT  RTLS, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
 
 
RADIUS over TLS Presentation
<http://www.ietf.org/proceedings/10mar/slides/radext-2.pdf> 
 
Stefan Winter: We have incorporated proposed resolutions for all open issues
in the tracker within the latest version (-06
<http://tools.ietf.org/html/draft-ietf-radext-radsec-06> ). The document is
ready for another WG last call.
Bernard Aboba: We have started another WG last call (see
http://www.ietf.org/mail-archive/web/radext/current/msg01578.html ).  This
will go until April 19, 2010.  Please read the document and send your review
to the list. 
 
1800 AM - 1810 PT NAI-Based Peer Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery
 
 
RADIUS NAI Discovery Presentation
<http://www.ietf.org/proceedings/10mar/slides/radext-4.pdf> 
 
Stefan Winter:  Several open issues:
.         S-NAPTR. 
.         Include Diameter?
.         Reference RFC 4282?
.         Guidance on connection attempts (IPv4 vs. IPv6)
 
Alan DeKok:  RFC 4282 is badly broken.  
Bernard Aboba:  Agreed. My advice is to avoid referencing it.  Instead, you
can just reference IDNAbis and tell people to convert U-labels to A-labels
prior to sending DNS queries.  
Hannes Tschofenig: Why are you using S-NAPTR?  Wouldn't it be easier to use
U-NAPTR and a AAA URI?
Stefan Winter:  U-NAPTR might be simpler, if we could utilize the AAA URI
scheme. 
Bernard Aboba: Was Diameter peer discovery ever implemented?
Hannes Tschofenig:  No. 
Bernard Aboba:  Might make sense to explore whether we can come up with a
single solution for Diameter and RADIUS.  Perhaps this should be brought up
in DIME. 
Stefan Winter:  Recommend we stay out of the IPv4 vs. IPv6 issue. 
Bernard Aboba: Big issue so far has been IPv6 blackholing.  Typical causes
are broken tunnels, problems in IPv6 routing, or lack of connectivity
between Teredo/6to4 and native IPv6 Internet.  These problems are more
likely to show up in consumer deployments than in AAA infrastructure.  So it
seems less likely that AAA will need things like DNS IPv6 whitelisting and
perhaps it doesn't matter.  
 
1810 - 1820 PT RADIUS over DTLS, Alan DeKok     (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls
 
 
RADIUS over DTLS Presentation
<http://www.ietf.org/proceedings/10mar/slides/radext-3.ppt> 
 
Alan DeKok:  Major new content in -02. One of the major differences between
RADIUS over TLS and RADIUS over DTLS is that DTLS uses the existing RADIUS
ports.  So you have DTLS and conventional RADIUS being sent to the same port
and the RADIUS implementation has to distinguish DTLS from regular RADIUS
packets.  This is done by looking at the first byte of the RADIUS packet.
If the first byte is 22, then the packet is DTLS, not RADIUS.  For a given 5
tuple (IP Destination address, IP source address, destination port, source
port, UDP), there can only be one choice (DTLS or conventional RADIUS).
This can be implemented on the server in multiple ways.  The server can keep
state in memory relating to whether DTLS or conventional RADIUS was received
on a given 5 tuple.  Or it can keep state in stable storage.  Once DTLS is
received from a given NAS, it can be assumed that the NAS has been upgraded,
and after that, DTLS will always be assumed/required.  The stable storage
approach prevents downgrade attacks after a reboot.
Alan DeKok:  The RADIUS over DTLS document references the RTLS specification
were appropriate, and provides deltas to it.  So the RDTLS document has a
dependency on the RTLS document, but not the other way around.  This makes
since, RADIUS over DTLS implementations are behind RADIUS over TLS by a few
years. 
Stefan Winter: We looked at combining the RADIUS over TLS and RADIUS over
DTLS documents.  However, the documents were at varying levels of maturity
(RTLS has been out for a while, there are multiple interoperable
implementations, DTLS is not yet there), so we didn't think it made sense.
Bernard Aboba: Have there been bakeoffs yet to demonstrate RADIUS over DTLS
interoperability?
Alan DeKok:  Not yet. 
 
 
IPv6 (20 minutes)
 
1820 - 1830  RADIUS Attributes for IPv6 Networks, W. Dec (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access
 
RADIUS Attributes for IPv6 Access Networks Presentation
<http://www.ietf.org/proceedings/10mar/slides/radext-6.ppt> 
 
Bernard Aboba:  This document is currently in RADEXT WG last call (see
announcement:
http://www.ietf.org/mail-archive/web/radext/current/msg01547.html  ).  Last
call ended yesterday (March 21, 2010).  However, we only received a few
comments, so will extend last call for a few weeks after IETF 77 to allow
for additional reviews.  Please read the document and send your reviews to
the list, even if it's only to say that the document is fine.  It's not very
long. 
W. Dec:  With early versions of the document, there were concerns about
whether we were trying to create a protocol to handle generic support of
DHCP within RADIUS with no authentication involved.  That is not the
purpose;  we added Section 2 to describe the scenarios. 
 Bernard Aboba:  The protocol exchanges described in the Virtual Interim
(e.g. use of DHCPv6 for configuration and address assignment over PPP
instead of IPv6CP and RA) aren't in Section 2. It would help to refer to
them so that it is clear that authentication is always expected to occur, as
required in RFC 2865.  
W. Dec:  We have received comments in WG last call from Peter Deacon,
relating to existing practices (e.g. how existing implementations use a
combination of Framed-IPv6-Prefix and Framed-Interface-Id to denote an IPv6
address).  The draft describes how a single attribute IPv6-Framed-Address,
can be used in an Accounting-Request, but it doesn't update RFC 3162, so
that attributes allowed in Accounting-Request messages are still legal.  
Alan DeKok:  Shouldn't IPv6-Framed-Address be Framed-IPv6-Address?
 
1830 - 1840  Accounting Extensions for IPv6, R. Maglione (10 minutes)
http://tools.ietf.org/html/draft-maglione-radext-ipv6-acct-extensions
 
RADIUS Accounting for IPv6 Presentation
<http://www.ietf.org/proceedings/10mar/slides/radext-5.ppt> 
 
There have been a number of review comments on the list. 
>From Avi Lior: http://ops.ietf.org/lists/radiusext/2010/msg00193.html
(Existing attributes are not just for IPv4, they count both IPv4 and IPv6).

Alan DeKok: http://ops.ietf.org/lists/radiusext/2010/msg00220.html (suggest
sending two Accounting-Requests, one for IPv4 and another for IPv6 (using
existing attributes).  Distinguish the accounting streams based on use of
NAS-IP-Address/NAS-IPv6-Address attributes.  Use Acct-Multi-Session-Id used
to link the two streams together.  This approach  seems operationally too
heavy for both the BRAS and the RADIUS system.  Defining new attributes
appears a simpler solution, and doesn't require changing the meaning of
existing attributes (which appear to apply to both IPv4 and IPv6).  
Bernard Aboba:  Changing the meaning of existing accounting attributes based
on the presence of another attribute (NAS-IP-Address/NAS-IPv6-Address) would
represent a "polymorphic attribute" approach, which is discouraged in Design
Guidelines.  The approach of defining new attributes avoid this problem.  
 
Design Guidelines (50 minutes)
 
1840  - 1930  Design Guidelines, Alan DeKok     (50 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-guidelines
 
RADIUS Design Guidelines Presentation
<http://www.ietf.org/proceedings/10mar/slides/radext-1.ppt> 
 
Alan DeKok:  People have commented on the background of the slides.
Bernard Aboba:  About the flames? 
Alan DeKok:  Yes. 
Bernard Aboba:  Here is where we are on Design Guidelines. With respect to
the Last Look, a summary was sent to the RADEXT WG list on January 28, 2010:
http://www.ietf.org/mail-archive/web/radext/current/msg01472.html
 
As described in the summary, the chairs believe that there is WG consensus
against publication of the Design Guidelines document in its current form.
Therefore, the document cannot be advanced until the issues are addressed. 
 
Three issues were opened against the document as a result of the "Last
Look".  One issue was opened by Hannes Tschofenig, relating to the
organization of the document (see
http://www.ietf.org/mail-archive/web/radext/current/msg01515.html ).  
Alan DeKok:  I believe that this issue is resolved in -12
<http://tools.ietf.org/html/draft-ietf-radext-design> . 
 
Another is Issue 325 (opened by Joe Salowey), which relates to the text on
complex attributes.  The issues relates to problems with both the statements
of fact (relating to whether code changes are required in certain
situations) as well as the recommendations.   Changes were made in -11 and
-12 to resolve this issue. Joe has indicated that the suggested changes were
helpful (see
http://www.ietf.org/mail-archive/web/radext/current/msg01434.html), so I am
going to close the issue. 
 
Since other "Last Look" comments appear to indicate that the changes are
insufficient, it is possible that there are additional changes required, but
we don't have specific comments or text changes on the table. How do we move
forward? 
Alan DeKok: I will solicit feedback on the list (done, see
http://www.ietf.org/mail-archive/web/radext/current/msg01588.html ). 
Bernard Aboba:  If you have concerns relating to the text on complex
attributes, please submit specific changes to the list.  The time for
general comments is past. This document has completed WG last call and IETF
last call and IESG DISCUSS comments have been resolved.  We need text to
move forward.  
 
On Issue 327 (opened as a result of postings by Avi Lior), a proposal for
resolution was made and discussed at the Virtual Interim (see
http://www.ietf.org/mail-archive/web/radext/current/msg01496.html )  Avi
accepted the resolution, but the suggested resolution has not yet been
reflected in the document. 
Alan DeKok:  In -12 I focused on improving document readability.  Since
there were so many editorial changes to the document, the proposal no longer
applied.
Bernard Aboba:  I will take an action item to resubmit the proposed
resolution, based on the -12 organization.  However, I do not believe that
Issue 327 has been resolved, so I will not close it. 
 
Wrap-up (10 minutes)
 
1930 - 1940  Discussion and Next Steps:  WG Chairs & ADs (10 minutes)