RADIUS Option for the DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-radius-opt-14

The author has updated the document to address all comments and discusses, and the document shepherd has verified that this was done.  The document is now ready for the publication process.

[Ballot comment]

Thanks for handling my discuss points.
I didn't check if the comments below still applied so
I'll leave them there just in case it helps someone
sometime:-)

--- old comments:

abstract: this is very unclear to me, having read it
the spec could be about three or four different
things, but I'm none the wiser. It should say that
this is for when the RADIUS client is the DHCP relay
and wants to tell the DHCP server about RADIUS stuff.

section 1: This bit needs a rewrite. "In that case the
NAS directly responds the DHCPv6 messages as per the
indication conveyed by the attributes in the
Access-Accept message from the RADIUS server."

[Ballot discuss]
(1) cleared

(2) cleared

(3) rfc3588-bis has text saying that if you ever send
Diameter attributes in Diameter that require security
(e.g. keying material) over Diameter then you MUST run
over IPSec, TLS or better.  An analogous statement
seems required here. The last para of section 8 needs
to be stregthened to tell the IANA expert(s) not to
mess about with that. (Or add equivalent text
elsewhere.)

[Ballot comment]
abstract: this is very unclear to me, having read it
the spec could be about three or four different
things, but I'm none the wiser. It should say that
this is for when the RADIUS client is the DHCP relay
and wants to tell the DHCP server about RADIUS stuff.

section 1: This bit needs a rewrite. "In that case the
NAS directly responds the DHCPv6 messages as per the
indication conveyed by the attributes in the
Access-Accept message from the RADIUS server."

[Ballot comment]
I guess the answer is yes, but let me make sure...
Does this mechanism support the RADIUS protocol extensions (RFC 6929)?

Regards, Benoit

[Ballot discuss]
So this might be a little related to Stpehen's but I'm trying to figure out the authentication requirements here.  The following in s8 made me wonder whether we need to be explicit about what happens when the NAS isn't a trusted network component:

However, in the network scenarios described in the
section 3, NAS could always be regarded as a trusted network
component in the real deployment.

In other words, doesn't there need to be a statement that says the NAS and DHCP server MUST have a trust relationship to allow them to mutually authenticate?

[Ballot discuss]

(1) This is a discuss-discuss: Why (other than because
of wg charter) is this v6 specific or even RADIUS and
not Diameter specific?  shouldn't something like this,
if its needed, work just as well for v4 and v6 and for
RADIUS and Diameter?  Are we just making work for
standards professionals by splitting the v4 and v6 and
RADIUS/Diameter DHCP work this way? (This may be down
to the charter, but I wanted to ask.)

(2) 4.1: Why expert review if vendor specific is there
too? Doesn't that mean that the expert(s) can just be
bypassed if they ever say "no"? That type also seems
not to be v6-specific and so is maybe out of charter?
Also, such attributes might be sensitive and so
unsuited for sending in DHCP (see discuss point 3
below).

(3) rfc3588-bis has text saying that if you ever send
Diameter attributes in Diameter that require security
(e.g. keying material) over Diameter then you MUST run
over IPSec, TLS or better.  An analogous statement
seems required here. The last para of section 8 needs
to be stregthened to tell the IANA expert(s) not to
mess about with that. (Or add equivalent text
elsewhere.)

[Ballot comment]

abstract: this is very unclear to me, having read it
the spec could be about three or four different
things, but I'm none the wiser. It should say that
this is for when the RADIUS client is the DHCP relay
and wants to tell the DHCP server about RADIUS stuff.

section 1: This bit needs a rewrite. "In that case the
NAS directly responds the DHCPv6 messages as per the
indication conveyed by the attributes in the
Access-Accept message from the RADIUS server."

[Ballot comment]
This is a useful document - thank you for writing it.

I have one comment that is indeed a comment only, not a blocking issue. It relates to how the attribute is designed. It is my belief additional interoperability could perhaps been achieved, if you had used the Diameter attribute format. This would have allowed carrying both RADIUS and Diameter attributes (see http://tools.ietf.org/html/rfc6733#section-4.1), at the cost of only a few bytes. (It is of course also possible to define a separate DHCP option for carrying Diameter attributes, perhaps in a separate document.) Did the authors or the working group consider this design choice, or work out what the implications would have been? Or are there existing specifications or other reasons (such as practices on the DHCPv4 side) that dictate the particular design chosen in the draft?

[Ballot comment]
I support Spencer's DISCUSS points on the use of SHOULDs vs/ MUSTs.  One way to clarify why SHOULDs are appropriate would be to add an example exception case where the options are not included.

[Ballot discuss]
This document was very well-done. I expect this DISCUSS and COMMENT will be easy to resolve, because I basically had a question about every SHOULD (NOT) in the document, so maybe I just need help understanding.

That wasn't intentional, it just worked out that way :-)

In 3.  Network Scenarios

  After receiving RENEW (5) message from the DHCPv6 client, the NAS
  SHOULD NOT initiate a new Access-Request/Access-Accept message
  exchange with the RADIUS server; but after receiving REBIND (6)
  message from the DHCPv6 client, the NAS SHOULD initiate a new Access-
  Request/Access-Accept message exchange with the RADIUS server.

could you help me understand why these are SHOULD NOT/SHOULD, and especially why the second SHOULD is not a MUST? Is there an alternative scenario that can also result in a user being allowed access?

In 4.  DHCPv6 RADIUS option

  According to the network scenarios described in section 3, the
  OPTION_RADIUS SHOULD appear in the RELAY-FORW (12) message relaying
  SOLICIT (1), REQUEST (3) and REBIND (6) from the DHCPv6 client, and
  MAY appear in the RELAY-FORW (12) relaying any other message from the
  DHCPv6 client.

I'm not sure I understand why this is a SHOULD, and not a MUST. If I was trying to explain this without 2119 language, I'd say "the OPTION_RADIUS will probably be in RELAY-FORW relaying some kinds of messages, but it might not be, and it might be in RELAY-FORW relaying any other message". Is that a fair summary? If so, is it also correct to say that it might not be present at all? (and, if not, what's supposed to happen next?)

[Ballot comment]
In 5.  DHCPv6 Relay Agent Behavior

  The DHCPv6 relay agent MAY include OPTION_RADIUS in the RELAY-FORW
  (12) message.  When the value in the attributes, for example,
  Delegated-IPv6-Prefix-Pool (171), Stateful-IPv6-Address-Pool (172),
  Delegated-IPv6-Prefix (123) or Framed-IPv6-Address (168) in the
  Access-Accept message replied from RADIUS server are valid, the relay
  agent that supports OPTION_RADIUS SHOULD include these RADIUS
  attributes into the OPTION_RADIUS one by one.

is this SHOULD just saying relay agents that support OPTION_RADIUS ought to do something with OPTION_RADIUS?

In 6.  DHCPv6 Server Behavior

  Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a
  relay agent, the DHCPv6 server that supports OPTION_RADIUS SHOULD
  extract and interpret the RADIUS attributes in the OPTION_RADIUS, and
  use that information in selecting configuration parameters for the
  requesting client.  If the DHCPv6 server does not support
  OPTION_RADIUS, the DHCPv6 server MUST silently discard this option.

I have pretty much the same question, about DHCPv6 servers.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RADIUS Option for DHCPv6 Relay Agent) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'RADIUS Option for DHCPv6 Relay Agent'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The DHCPv6 RADIUS option provides a mechanism to exchange
  authorization and identification information between the DHCPv6 relay
  agent and the DHCPv6 server.  This mechanism is meant for the
  centralized DHCPv6 server to select the right configuration for the
  requesting DHCPv6 client based on the authorization information
  received from the RADIUS server, which is not co-located with the
  DHCPv6 server.  The Network Access Server (NAS) acts as DHCPv6 relay
  agent and RADIUS client simultaneously in this document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2052/

Document Writeup, template from IESG area on ietf.org, dated 24 February 2012.

draft-ietf-dhc-dhcpv6-radius-opt-10 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

Proposed standard. This document defines an extension to the DHCPv6 protocol
(and defines new DHCPv6 option), which requires standards track. The intended
type is indicated in the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

  This document defines RADIUS DHCPv6 option that is similar to its DHCPv4
  counter-part that was defined in RFC4014. The DHCPv6 RADIUS option provides a
  mechanism to exchange authorization and identification information between the
  DHCPv6 relay agent and the DHCPv6 server.  This mechanism is meant for the
  centralized DHCPv6 server to select the right configuration for the requesting
  DHCPv6 client based on the authorization information received from the RADIUS
  server, which is not co-located with the DHCPv6 server.  The Network Access
  Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in
  this document.

Working Group Summary:

  This document was called draft-yeh-dhc-dhcpv6-authorization-opt prior to its
  adoption. There was unanimous support for it (9 people in favor of adoption
  and none against), so this document was adopted in May 2012. There was quite
  high interest in this work - 55 posts since its adoption. There was never any
  opposition for this work.

Document Quality:

  I'm not aware of any existing implementations, but the level of support from
  both DHCP vendors (Nominum, Weird Solutions, Cisco, ISC), hardware vendors
  (Huawei, Cisco) and operators (Orange, Telecom Italia) suggests that this will
  be implemented and deployed shortly after option code is assigned by IANA.
  There was no single lead reviewer and many people contributed to the draft (55
  posts during its WG life). This document went through rapid updates (10
  revisions 10 months), because its lead author - Leaf Yeh - was eager to
  address any comments as soon as they appeared.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Tomek Mrugalski is the document shepherd. Ted Lemon is the responsible AD.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I thoroughly reviewed this document twice (and have other minor
  comments in between):
  my -09 comments: http://www.ietf.org/mail-archive/web/dhcwg/current/msg13979.html
  my -05 comments: http://www.ietf.org/mail-archive/web/dhcwg/current/msg13529.html

  The issues raised in my last review were promptly addressed by authors
  in -10. This document is ready for publication in my opinion.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  Yes. This document is between area of expertise of 2 WGs: DHC and RADEXT. It
  was very well reviewed (detailed discussions and reviews with 55 posts total)
  in DHC. There was only one post about it in RADEXT wg.
  http://www.ietf.org/mail-archive/web/radext/current/msg07717.html
  RADEXT chairs were requested to ask for a review on RADEXT ML.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  This document has had a great deal of careful DHCP review. It did not
  get enough RADIUS review. RADEXT chairs were requested to ask for a
  review on RADEXT ML.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues from the DHCP perspective.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes, the authors, Leaf Yeh and Mohamed Boucadair, did confirm in writing that
  they are not aware of any IPR.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was very broad support for adopting this document. It was later reviewed
  couple times by 6 active WG participants. All changes were mostly minor and
  did not change the basic mechanism (that was operationally proven to work in
  DHCPv4).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  All outstanding issues were resolved in -10 version. This document is
  now ID nits clean.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document. This document did not go through AAA Doctors review. If such
  a step is needed, please advise how can I request such a review.

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  I-D.ietf-radext-ipv6-access (RFC Ed queue, AUTH48) is a normative reference.
  All other normative references are to RFC documents.

(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. It was discussed with co-chair and responsible AD that this
  document extends, but do not update RFC3315 (DHCPv6).

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  This document requests assignment of a new DHCPv6 option code. The IANA registry
  for this code is clearly identified. This document also requests creation of a
  new registry that will hold RADIUS attributes that are permitted in the RADIUS
  option. This will be a sub-set of existing RADIUS attibute types registry
  that is clearly identified (with a name and URL to IANA website). The
  initial content of the newly created registry is clearly listed in
  section 4.1. There is a clear pointer to section 4.1 in IANA
  considerations section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  This document calls for creation of a 'RADIUS Attributes Permitted in the
  DHCPv6 RADIUS option' registry. Its name, location, process of adding new
  values is clearly defined. -09 version did not clearly mention initial content
  of the new registry in IANA considerations section. This was fixed
  in -10.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.