Skip to main content

Last Call Review of draft-ietf-softwire-6rd-radius-attrib-07
review-ietf-softwire-6rd-radius-attrib-07-secdir-lc-salowey-2012-11-29-00

Request Review of draft-ietf-softwire-6rd-radius-attrib
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-11-27
Requested 2012-11-18
Authors Dayong Guo , Sheng Jiang , Rémi Després , Roberta Maglione
I-D last updated 2012-11-29
Completed reviews Secdir Last Call review of -07 by Joseph A. Salowey (diff)
Assignment Reviewer Joseph A. Salowey
State Completed
Request Last Call review on draft-ietf-softwire-6rd-radius-attrib by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 11)
Result Has nits
Completed 2012-11-29
review-ietf-softwire-6rd-radius-attrib-07-secdir-lc-salowey-2012-11-29-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I believe the document is almost ready for publication.

The following are significant issues that need to be addressed:

1.  A RADIUS message used for call-check does not contain any information that
would authenticate the request.  Therefore RADIUS messages using the 6rd
attribute MUST include a message-authenticator attribute or another attribute
that is capable of authenticating the RAIDUS packet.

2.   I'm not so familiar with the deployment scenario here so I have a
question.  Is it possible that the BNG was involved in a previous transaction
with the AAA server to authenticate a user?   If this is the case then the BNG
may have received a state attribute in the access-accept message.   Returning
this state attribute to the AAA server allows the AAA server to link the 6rd
request with the original authentication transaction.    If this is a possible
scenario the document should specify this since state attributes are not
typically used with the call-check service.  Also if its the case that there
could have been a related previous authentication session it seems that it
should be possible to include this attribute in an access-request as part of
the authentication exchange.

3.  It was not clear in the specification what is sent in the access-request
message is the BNG is looking to get a IPv6-6rd-configuration attribute in the
access accept.  It seems that you would need to send this attribute in the
request if you expected it in the response or else the AAA server would not be
able to un ambiguously be able to service the request; there are other uses for
the call-check service.   I think you should specify that the 6rd attribute
must be in the request if you want to see it in the response.

Cheers,

Joe