Subject: Re: [AAA-DOCTORS] New Version Notification - draft-ietf-softwire-6rd-radius-attrib-09.txt

From: Benoit Claise <[email-masked]>
Date: Wed, 19 Dec 2012 08:57:35 +0100

AAA doctors,

A new version has been posted.
Let me know if your concerns are addressed?

Regards, Benoit
> A new version (-09) has been submitted for draft-ietf-softwire-6rd-radius-attrib:
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-09.txt
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/
>
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-6rd-radius-attrib-09
>
> IETF Secretariat.
>
>
>

---

From: Glen Zorn <[email-masked]>
Date: Thu, 20 Dec 2012 15:13:55 +0700

On 12/19/2012 02:57 PM, Benoit Claise wrote:

> AAA doctors,
 >
 > A new version has been posted. Let me know if your concerns are
 > addressed?

I still have some questions & comments:

   * The format for the IPv6-6rd-Configuration Attribute appears to owe 
a great deal to the discussions in draft-ietf-radext-radius-extensions; 
shouldn't there be a reference to that document in this one?

   * It would seem that there are some security concerns with using a 
single "canned" password for all the clients but there is no mention of 
such.

   * Since there is basically no authentication of the DHCP clients done 
and MAC addresses are notoriously easy to spoof, it seems quite possible 
that the same MAC address could be used to request 6rd service from 
multiple different hosts and succeed.   Is that a problem?  If not, why 
not?  If so, how can the problem be ameliorated?

   * Section 3 says:

            After receiving the IPv6-6rd-Configuration Attribute in the 
initial
            Access-Accept, the BNG MUST store the received 6rd configuration
            parameters locally. When the 6rd CE sends a DHCP Request 
message to
            request an extension of the lifetime for the assigned 
address, the
            BNG does not have to initiate a new Access-Request towards 
the AAA
            server to request the 6rd configuration parameters. The BNG 
retrieves
            the previously stored 6rd configuration parameters and uses 
them in
            its reply.

     If this is the case, what is the purpose of Scenario 2?  Under what 
circumstances would an "Authorize-Only" message be sent?

   * There are still a number of English language usage and grammar 
problems.

...

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 20 Dec 2012 08:43:50 +0000

Hi, Glen,

Thanks for your comments. Please see my replies in lines.

>shouldn't there be a reference to that document in this one?

This document will be added as an Informational reference.

>single "canned" password for all the clients but there is no mention of

Some consideration can be added if you have any proposed text. For my understanding, this likes a normal communication between a Radius client (the DHCPv6 server) and a Radius server.

>not?  If so, how can the problem be ameliorated?

The MAC address spoofing is possible. But I guess it is out of scope. This draft is mainly about 6rd configuration provision.

>   * Section 3 says:
>
>    After receiving the IPv6-6rd-Configuration Attribute in the initial
>    parameters locally. When the 6rd CE sends a DHCP Request message to
>    request an extension of the lifetime for the assigned address, the
>    BNG does not have to initiate a new Access-Request towards the AAA
>    server to request the 6rd configuration parameters. The BNG retrieves
>    the previously stored 6rd configuration parameters and uses them in
>    its reply.
>

The scenario 2 only happens when there is a previous authentication process which did not request 6rd configuration.

>   * There are still a number of English language usage and grammar

I had asked a native English speaker to check. If you still think some English are problem, could you drop me an email for details? We are love to follow. Your help is appreciated.

Best regards,

Sheng

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Dec 2012 07:47:21 -0500

Glen Zorn wrote:
>   * The format for the IPv6-6rd-Configuration Attribute appears to owe a
> great deal to the discussions in draft-ietf-radext-radius-extensions;

  I'm not sure that's necessary (though I don't object to it).  The TLV
format used in this document has been used in various vendor
dictionaries for a decade, and in other informational RFCs, IIRC.

> single "canned" password for all the clients but there is no mention of

  I agree.  I'm unsure what else to say here.

  Many implementations of MAC address authentication in RADIUS use the
MAC address as both the User-Name and User-Password.  While not
standardized, it is wide-spread.

  This use of MAC address for User-Name conflicts with this.  The only
way to tell the two uses apart is the presence of the 6rd attribute.

  By the way... what is the recommended format of the MAC address in the
User-Name?  This document doesn't say.  I'd suggest the format specified
for use in Calling-Station-Id (RFC 3580 Section 3.20), but without the
SSID portion.

> not?  If so, how can the problem be ameliorated?

  I agree.  I'd suggest a secdir review.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Dec 2012 07:51:02 -0500

> Some consideration can be added if you have any proposed text. For my understanding, this likes a normal communication between a Radius client (the DHCPv6 server) and a Radius server.

  Normal communications can still have security issues.

> The MAC address spoofing is possible. But I guess it is out of scope. This draft is mainly about 6rd configuration provision.

  Security considerations for a document are ALWAYS in scope.

  Alan DeKok.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 21 Dec 2012 00:23:49 +0000

>From: Alan DeKok [mailto:[email-masked]]
>
>Glen Zorn wrote:

Thanks, Alan. This will be added.

Sheng