Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT)

[Maglione Roberta <[e-mail]>]

Hello,
   Please see answers inline [RM]
Thanks,
Regards,
Roberta

-----Original Message-----
From: Dan Romascanu [mailto:[e-mail]]
Sent: giovedì 11 agosto 2011 11.16
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT)

Dan Romascanu has entered the following ballot position for
draft-ietf-softwire-dslite-radius-ext-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Slightly edited version. Please use this one.

The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring.

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
   Access-Request packets that contain a Service-Type attribute with the
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.  This last requirement often means that an Access-
   Accept needs to contain a State attribute, which can then be used in
   a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

[RM] Adding the following text after figure 2 would address this comment?

"In the scenario described in figure 2 the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17), thus according to RFC 5080 the Access-Request packet MUST contain a State attribute.

2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
   (Note 1) Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request packets, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g., within CoA-Request packets
   to request authorization changes).

[RM] No, the DSLITE-Tunnel-Name Attribute cannot be classified as a session identification attribute, because the same AFTR device (hence identified by the same DSLITE-Tunnel-Name)  can be used to terminate different IPv4 over IPv6 tunnels coming from different IPv6 user's sessions. The session identification in this case could be an IPv6 attribute (like for example the Framed-IPv6-Prefix) or the Accounting-Session-ID of the IPv6 session.


3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.   Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:
   This attribute MAY be used in Access-Accept packets as a hint to the
   RADIUS server; for example if the NAS is pre-configured with a
   default tunnel name, this name MAY be inserted in the attribute.  The
   RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
   different AFTR tunnel name.

[RM] it's a typo, sorry I have fixed it in version -05


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. The use of kewords in section 3 seems inconsistent. Why are the 'may' and 'shall' in the second paragraph of the section non-capitalized, while in the rest of the section the keywords are capitalized.

[RM] I'm going to change them in this paragraph.

> This list may also contain the AFTR Tunnel Name.  When
   the NAS receives a DHCPv6 client request containing the DS-Lite
   tunnel Option, the NAS shall use the name returned in the RADIUS DS-
   Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME
   option in the DHCPv6 reply message.

2. I support item #2 in David's DISCUSS about the need to document the operational considerations of the NAS configuration and device configuration changes.

[RM] I tried to clarify this point in one of my previous emails, please let me know if the explanation addresses your comment.

3. Two of the AAA-Doctors made in early reviews the comment that it was not clear why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here. One of them even proposed an alternative based on RFC2868 but authors argued that their approach was better. that may be true, but it would have been good to document the decision and explain why the alternative was rejected.

[RM] When we first presented this draft in the RADEXT WG last year, the document contained two different attributes one for the DS-Lite-Tunnel-Name and another for the DS-Lite-Tunnel-Address, in order to match exactly the two different DHCPv6 options proposed for the same purpose. The idea to have a new AVP instead of re-using the one from RFC2868 came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6 options. The reason behind this choice was to avoid having an extra logic implemented on the NAS required to decide in which DHCPv6 option inserting the value received from RADIUS AVP.
After a long discussion based on DHC WG feedback, the DHCPv6 option related to AFTR address was removed from that document and only the AFTR name DHCPv6 option was kept, thus we updated this draft according to that decision.

Thanks,
Regards,
Roberta

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.