Subject: [AAA-WG]: Issue 395: NASREQ-10 comments

From: David Mitton <[email-masked]>
Date: Fri, 31 Jan 2003 13:14:25 -0500

Changes relative to comments, as below

On 12/28/2002 02:53 PM -0600, Kuntal Chowdhury wrote:

>Hello,
>Here is a list of comments on nasreq-10 draft. The draft seems to be quite 
>stable. Did not find any major issue.
>
>Regards,
>Kuntal
>
>------------------------------------------------------------------------
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: E
>Priority: 1
>Section: 4.1.3
>Rationale/Explanation of issue:
>...This AVP SHOULD be present if the NAS uses the same NAS-Port
>    number ranges for different services types concurrently.
>Proposal:
>
>...This AVP SHOULD be present if the NAS uses the same NAS-Port
>    number ranges for different service types concurrently.

 >> accepted - change plural service

>----------------------------------------------------------------
>
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: T
>Priority: 1
>Section: 4.2.6
>Rationale/Explanation of issue:
>
>       CHAP with MD5       5
>          The CHAP response is computed using the procedure described in
>          [PPPCHAP].  The CHAP-Response AVP MUST be present in the CHAP-
>          Auth AVP.
>
>Comment: We should not talk about CHAP-Response AVP in the CHAP-Algorithm
>AVP section. Also according to the ABNF grammar, the CHAP-Response AVP is
>not mandatory in CHAP-Auth AVP.
>
>Proposal: Delete the paragraph below CHAP with MD5      5.

 >> declined - The CHAP-Auth grouping was designed to allow a number of 
different CHAP algorithms, each with seperate AVP constraints.  Because 
only one has been defined, it looks a little odd.  The CHAP-Response AVP is 
grammarically optional, but required by the specification of CHAP with MD5.
Other algorithms may require other AVPs and not CHAP-Response.

>-----------------------------------------------------------------
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: T
>Priority: 2
>Section: 4.4
>Rationale/Explanation of issue:
>Tunneling AVP is of type Grouped but MAY NOT be encrypted. Whereas CHAP-Auth
>AVP MAY be encrypted, but it is of type Grouped as well. In the entire spec
>Tunneling AVP is the only one that has "N" in MAY Encr column. Is this an 
>error
>or is there a reason for it? Since almost all of the AVPs have MAY Encr = Y
>this column can be replaced by a global declaration ( e.g. may encrypt all 
>AVPs).

 >> This confuses me a little too.  I'll have to look into it further and 
consult "those that understand our security representation".

>-------------------------------------------------------------------
>
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: T
>Priority: 1
>Section: 5.8
>Rationale/Explanation of issue:
>
>        Acct-Multi-                   Accounting-     Acct-
>       Session-Id     Session-Id     Record-Type     Link-Count
>       --------------------------------------------------------
>         "...10"        "...10"      START_RECORD        1
>         "...10"        "...11"      START_RECORD        2
>         "...10"        "...11"      STOP_RECORD         2
>         "...10"        "...12"      START_RECORD        3
>         "...10"        "...13"      START_RECORD        4
>         "...10"        "...12"      STOP_RECORD         4
>         "...10"        "...13"      STOP_RECORD         4
>         "...10"        "...10"      STOP_RECORD         4
>
>At the fourth step, the Acct-Link-Count should be 2, because at the third
>step the link with session-Id ...11 was closed, thus leaving only session-Id
>...10 open.

 >> This example is lifted directly from RFC 2866, Section 5.12.
The description is slightly different, but the intended semantics are the 
same.  The value indicates the "total" number of links _seen_ over time on 
this session by the time the record is sent.  Active or not. It never 
decreases.

RFC 2866 said:
contains the number of links seen so far in this Multilink Session.

I edit this text to clarify further:

indicates the total number of links that have been active (current or closed)
in a given multilink session, at the time the accounting record is generated.

>----------------------------------------------------------------
>
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: T
>Priority: 1
>Section: 6.1.1
>Rationale/Explanation of issue:
>
>       - If a Proxy-Info AVP is present, extract the encoded information,
>         otherwise retrieve the information from the local state table.
>
>       - If a Proxy-Info AVP was present in the request, the same AVP
>         MUST be added to the response.
>
>The Proxy-Info AVP is not supported in RADIUS. Should it be Proxy-State AVP
>instead?

 >> You're right, in the first bullet, it should read:
if a Proxy-State attribute is present, ...

This is following our recommendation in the prior section to encode 
Proxy-Info information in a Proxy-State attribute.

The second bullet is correct as is.  It is talking about this situation, 
where Proxy-Info was in the Diameter Request that caused this gateway's 
RADIUS translation.

>-----------------------------------------------------------------
>
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: E
>Priority: 1
>Section: 6.2
>Rationale/Explanation of issue:
>
>    The AVPs defined in this section SHOULD only used for backwards
>    compatibility when a Diameter/RADIUS translation function is invoked,
>    and are not typically originated by Diameter systems.
>
>Proposal:
>    The AVPs defined in this section SHOULD only be used for backward
>    compatibility when a Diameter/RADIUS translation function is invoked,
>    and are not typically originated by Diameter systems during normal
>    operation.

 >> accepted

>----------------------------------------------------------------
>
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: E/T
>Priority: 1
>Section: 7.2.1 and 7.2.2
>Rationale/Explanation of issue:
>The AVPs that are MUST not be present in a command Request/Answer are still
>shown in the table.
>
>Proposal:
>Section 7.2.1
>State AVP MUST not be present in both ACR and ACA. There is no need to show
>it in the table. Delete this entry.

 >> Okay.   This appears to be a carryover from RFC2866 sect 5.13
The State attribute is explictly called out to be not-allowed.

>Section 7.2.2:
>Same as above: delete Accounting-Input-Packets, Accounting-Output-Packets,
>NAS-Filter-Rule, State entries from the AVP table for these types of
>accounting messages.

 >> I guess so.  Their presence serves as a comparator from the other 
accounting table.  I might take a crack at combining these two tables.

>-----------------------------------------------------------------
>
>Description of issue
>Submitter name: Kuntal Chowdhury
>Submitter email address: [email-masked]
>Date first submitted: 12/28/02
>Reference:
>Document:  nasreq
>Comment type: E
>Priority: 1
>Section: 10
>Rationale/Explanation of issue:
>
>Update reference for CDMA2000 with the latest release of the standard.
>
>[CDMA2000]    3GPP2 "P.S0001-A v3.0", Wireless IP Network Standard, July
>               2001.
> 
><http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.pdf>http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.pdf 
>
>Proposal:
>
>[CDMA2000]    3GPP2 "P.S0001-B", Wireless IP Network Standard, October
>               2002.
> 
><http://www.3gpp2.com/Public_html/specs/P.S0001-B_v1.0.pdf>http://www.3gpp2.com/Public_html/specs/P.S0001-B_v1.0.pdf 
>

 >> Thanks, will do.

Dave.