RADEXT
WG Minutes
IETF
77
Anaheim,
California USA
Working
Group Home Page
Jabber
room: radext at jabber.ietf.org
Chairs
Bernard Aboba <bernard_aboba at hotmail.com>
David Nelson <d.b.nelson at Comcast.net>
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
l In IETF Last Call
l Status-Server
Comments so far: An editorial NIT (http://www.mail-archive.com/ietf@ietf.org/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
AD review comments:
l Completed RADEXT WG last call: Waiting for PROTO Writeup
l New Tunnel Type Values
l In RADEXT WG Last Call
l IPv6 RADIUS attributes
l RADIUS over TLS
l RADEXT WG Work Items
l NAI-based Peer Discovery
l RADIUS Crypto-agility Requirements
l Extended RADIUS Attributes
l Under Review as a RADEXT WG Work Item
l RADIUS Attributes for IEEE 802 Networks
l RADIUS over 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
Stefan Winter: We have incorporated proposed resolutions for all open issues in the tracker within the latest version (-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
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
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
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
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
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.
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)