From:
owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf
Of Bernard Aboba
Sent: Wednesday, October 14, 2009 2:35 AM
To: radiusext@ops.ietf.org
Subject: Draft RADEXT Virtual Interim Minutes
Here is a draft of the RADEXT WG Virtual Interim Minutes.
Please take a look at these minutes and add/edit/correct as necessary.
===============================================
Minutes of the RADEXT WG Virtual Interim
October 13, 2009
Design Guidelines
Alan: -09 has been submitted. This includes a number of
clarifications
with respect to tags, VSA formats, simple versus complex types.
There are no MUSTs or MUST NOTs in the document. Guidelines try to
encourage good practice, but should not be followed slavishly.
Dan: Jari has cleared his discuss. So the document could be sent to the
RFC Editor for publication immediately.
Bernard: Not clear that the document is ready.
There are still two open issues from IETF last call: Issues 313 and 314.
Issue 313 concerns the "security exemption". Does this apply to
any attribute
relating to security or authentication? There was confusion on this point
during the review of the PKMv1 document.
For user authentication or RADIUS security attributes there is computation
involved: the client has to compute something and the server has to
verify,
or vice-versa. If an attribute relates to security (e.g. sending a
certificate)
but there is no computation, does the exemption still apply?
In that case, it might have been possible to use the String
type, but a complex attribute would require new code on both the client and
server.
Issue 314 was filed by Hannes. It was to be followed by specific text to
address the
concerns, but this wasn't provided.
Hannes: The state of the art has advanced. In some designs addition
of code is
no longer a big issue, scripts can be plugged in. Also, parsers have
improved,
and could enable complex attributes to be supported automatically.
So are we locking ourselves into the past?
David Nelson: Many RADIUS server implementations utilize a data
dictionary. This
allows administrators to add the definition of a new attribute without having
to
upgrade the server. If an attribute doesn't have to require a server
upgrade, that
is probably a good thing.
Bernard: There are a lot of legacy RADIUS servers out there that
implement
the data dictionary model described in RFC 2865. For those implementations,
the data dictionary provides benefits. It can save administrators time
and money, allowing them to support a new attribute immediately without waiting
for
a RADIUS server upgrade.
David Nelson: It is also possible to use opaque attributes, where the
data
is not parsed by RADIUS but by some other component. Those attributes
are sent to and from a plugin.
Dan Romascanu: There is also the question of whether normative language
is being used
in the same way as described in RFC 2119.
Do we need to update the draft?
Bernard Aboba: How about an RFC Editor note?
Dan: That would be easier.
David Nelson: I think it would be best to get the document published and
then see how
well it works in the real world.
Bernard: So far, we've used it in reviewing two documents, the PKMv1
document, and the
IPv6 access document. In both cases, there was confusion about how the
guidelines applied
that required clarifications in the text. So the "real world"
experience is not so good.
That's why the document has taken so long to finish.
Bernard: Alan -- can you take the action item to work with Dan on addressing
the RFC 2119 issue
as well as proposing an RFC Editor note to address issue 313?
Status Server
Alan: This draft was revised. An applicability subsection was
added. There were some
terminology changes.
David Nelson: Does this document just describe what has been deployed, or
does it also
describe how Status-Server is used in RADSEC?
Alan: It is focused on what has been implemented. The RADSEC
document uses Status-Server
as an RFC 3539 Watchdog, but that is covered in the RADSEC document.
Bernard: Status-Server was originally implemented by Ascend in their
concentrators.
Alan: It was subsequently implemented in RADIATOR and FreeRADIUS.
Bernard: It would be good if we could get some additional reviewers to
look at whether
the document accurately describes their implementations. This isn't a
standards-track
document; its job is just to describe what has been implemented. Do
we have any
volunteers:
David Nelson: I will take a look at it.
RADIUS over TCP
Alan: We added text to the applicability section. We're now using
the term "RADIUS over TLS" instead
of a vendor's product name (RADSEC). We also added text on the head-of-line
blocking issue.
Bernard: As I recall, Magnus (Transport AD) raised this issue initially.
What can be done to address this
issue other than opening multiple TCP connections?
Alan: Nothing.
Dan: What is the issue specifically?
Alan: If a packet is lost, then all traffic that was intended to travel
on the TCP connection has to
wait until the data at the head-of-the-line is acknowledged. This isn't
an issue with UDP.
Hannes: One of the reasons we created the SCTP transport for Diameter was
to address the head-of-line
blocking issue. But SCTP has not been widely implemented.
Alan: For those that are interested, FreeRADIUS now supports RADIUS over TCP,
so you can play with it.
Bernard: Does the latest revision address Issues 315 and 316?
Alan: Yes.
Bernard: OK. If there are no open issues, then we could do another WG
last call.
RADIUS over DTLS
Alan: RDTLS has been implemented in Stefan's RADSEC Proxy. I am
implementing it as well.
This draft was not revised.
David Nelson: Isn't this draft expired? What is the status?
Alan: It is not expired.
Bernard: We issued a call for interest. Only one or two people
responded. There are no
open issues at the moment. We need more reviews.
IEEE 802 Attributes
Dan Romascanu: Is this document only about WLAN attributes or wired IEEE
802 attributes as well? Are
the attributes usable on multiple technologies?
Bernard: A number of the attributes are specific to a technology. For
example, there are attributes
that relate to IEEE 802.11r specifically. There are also attributes that
relate to IEEE 802.1X-REV.
Joe Salowey: IEEE 802.1X-REV does apply to wireless, but there are
aspects (such as announcements)
that were only meant to be implemented on wired networks.
Bernard: At one point we had attributes specific to IEEE 802.11s, but the
security model changed, so
we removed them.
David Nelson: What is the status of the document?
Bernard Aboba: IEEE 802.1X-REV has completed Sponsor Ballot. We
were waiting until the resolution of
Sponsor Ballot comments to align the document with IEEE 802.1X-REV.
Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot. So
it is a good time to look at
it again.
Bernard Aboba: The document is referenced in Appendix E of IEEE
802.1X-REV. But it is not a normative
dependency.
Joe Salowey: Now that IEEE 802.1X-REV has settled down, I will review the
document again, to see what
changes may be needed.
Bernard Aboba: After Joe is done with his review, what are the next
steps?
Dan Romascanu: For a standards track document, it can either be a WG work
item, or an AD sponsored
document. I would prefer a WG work item.
Bernard: There was a call for interest in November 2007, but it never
completed. So the document has
been in limbo for almost two years now.
David Nelson: Did anyone respond to the call?
Bernard Aboba: Some people responded, yes.
David Nelson: I was waiting for IEEE 802.1 to send their requirements.
Bernard Aboba: IEEE 802.1 provided their review of -08 in July
2008. That is now up on the liaison archive.
David Nelson: We can either send the document to the RFC Editor or run a quick
WG last call on it, once
it is aligned with IEEE 802.1X-REV.
IPv6 Attribute Design Considerations
Hannes: This document initially did not have much interest, then there
was a lot of discussion on the
list due to interest from the Broadband Forum. There are a number of ways
to address the review from
Alan. The document utilizes a tagging scheme similar to, but not exactly
the same as RFC 2868. The
authors did not want to depend on Extended Attributes since it has not been
progressing (and is now
expired).
Bernard: It seems like many of the attributes that are tagged relate to a
router advertisement, correct?
Hannes: That is my understanding.
Bernard: One of the objections to the current scheme is that it creates
multiple new tagged data types.
A new attribute is needed for each element of the RA that needs to be
expressed. It occurred to me that
it might actually be easier to define an opaque blob that carries much of (or
the entire) RA.
David Nelson: It seems like the lack of progress on Extended Attributes is
creating a problem. Design
Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic
use. But it doesn't make
a recommendation. If we don't get Extended Attributes done, then we will
be creating a problem.
After finishing Design Guidelines, it seems like this needs to be our #2
priority.
Bernard: Agreed. To be clear though, this document does not
currently depend on Extended Attributes.
Question: If Extended Attributes were further along, would this document
use it?
David Miles: I don't think so.
David Nelson: It seems like there are a number of use cases here, and
they are not clearly described.
Bernard: Previous documents have had very well defined uses cases.
RFC 3162 supports address auto-
configuration. RFC 4818 supports DHCPv6 Prefix Delegation. This
document supports multiple modes,
and that is confusing.
David Miles: In looking at the attribute list, there are a set of
attributes relating to router advertisements
that require tagging, but another set of attributes like IPv6-Address and
IPv6-DNS-Server-Address that do not.
Would it make sense to split the document into two parts, one focusing on
DHCPv6, and
the other one on router advertisements?
Bernard Aboba: Yes, I think this would help.
David Nelson: Which attributes are you interested in?
David Miles: For the Broadband Forum, IPv6-Address is of the most immediate
interest. IPv6-DNS-Server-Address
is relevant but isn't as important since in most cases name resolution is being
handled over IPv4.
Bernard Aboba: If that is what you need, then focusing on that would
enable things to go forward much more
quickly. Can you put a document together that focuses on that?
David Miles: There is already a document that does that.
David Nelson: Which one?
David Miles:
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00
Bernard Aboba: Yes, that document just handles the attributes you are
interested in. However, it confused
the WG because it only talked about DHCPv6 and RADIUS, but did not talk about
authentication. RADIUS is
spoken between a RADIUS client and server. So if the RADIUS client is
also a DHCPv6 server, then it makes
sense. But if the DHCPv6 server is separate, then it's not clear how it
works. Does the NAS pass the
RADIUS attributes to the DHCPv6 server, and if so, how? Is there
authentication going on between the
DHCPv6 server and the RADIUS server? If there are no authentication
attributes is this a Call Check,
or is it changing the RADIUS protocol in some way?
David Miles: I can include material on the Broadband Forum
scenarios. If I work with Benoit to create
an -01 with that additional material would that help?
Bernard Aboba: Yes, it would help a great deal.
Summary/Wrapup
Bernard: At the last virtual interim, the feedback on DimDim was not very
positive. So we tried LiveMeeting this time. How did it work for
people?
Dan Romascanu: The conference bridge was fine.
Alan DeKok: I could not use the web conferencing software, it was only
available on Windows.
Dan Romascanu: It required me to install additional software (Outlook
addin). That is a big deal.
Bernard Aboba: DimDim also required a software install. Though it
supported more platforms.
David Nelson: Having a teleconference bridge, Jabber and slides is fine.
David Miles: As long as the slides don't get too long or there are
too many people in the meeting. Otherwise it's easy to lose your place.
Bernard Aboba: They had a session on WebEx at IETF 75, in the Working
Group Chairs meeting. I asked the Secretariat if we could get access, but
didn't get a response. So it was
either DimDim or LiveMeeting.
Dan Romascanu: I will inquire about the availability of WebEx.
Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not currently
scheduled to meet at IETF 76. We have just completed the Virtual Interim,
and
IETF 76 is in just a few weeks.
Dan Romascanu: Who is attending?
David Nelson: I will not attend.
Bernard: No
Alan DeKok: No
Hannes: Yes
Dan Romascanu: There are disadvantages to not holding a meeting at IETF
76. You will miss the opportunity to interact with the community,
particularly participants from Asia.
It would be good to have a representative at IETF 76. Hannes is very
busy, but perhaps you can find someone to represent RADEXT.
Bernard: If there is WebEx available, we could participate remotely.
Dan Romascanu: I will look into supporting WebEx at the OPS Area
Meeting. There are cost concerns.