headers
Pasi.Eronen | 1 Sep 2003 11:00
Picon

: Route-Record AVP in responses

Route-Record AVP in responses
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen <at> nokia.com
Date first submitted: September 1, 2003
Reference: 
Document: base and nasreq
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issue:

Oops, I know it's kinda late to notice this... but there 
seems to be some inconsistencies about the Route-Record AVP
in some of the following: Base, NASREQ, my head.

Route-Record AVP use in requests seems to be ok, but
it is not clear if responses should have Route-Record AVPs.

- The AVP occurrence tables (in both Base and NASREQ) show 
  that Accounting-Answers MAY have Route-Record AVPs, but 
  all other responses MUST NOT have them.
- There's no text saying when or if agents or servers 
  should add Route-Record AVP(s) to responses.
- Base (Section 2.10) says that "...the local Diameter agent, 
  on receiving a Diameter response authorizing a session, 
  MUST check the Route-Record AVPs...". 
- NASREQ (Section 9.2) says that RADIUS translation should
  add Route-Record AVPs to AA-Answers. (Route-Record is 
  mentioned several times in Section 9, but all the other 
  cases apply only to requests, so they're probably ok).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pasi.Eronen | 1 Sep 2003 11:06
Picon

: Misspelled AVP in NASREQ

Misspelled AVP in NASREQ
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen <at> nokia.com
Date first submitted: September 1, 2003
Reference: 
Document: nasreq
Comment type: E
Priority: 2
Section: 9.3
Rationale/Explanation of issue:

I also noticed that "Route-Record" is misspelled as "Record-Route" 
several times in NASREQ. All of the cases apply only to requests,
so this is purely editorial (and independent of the other
issue related to this AVP).

Proposed change: search and replace.
Permalink | Reply | 0 comments |
headers
David Mitton | 1 Sep 2003 19:10

Re: : Misspelled AVP in NASREQ

On 9/1/2003 12:06 PM +0300, Pasi.Eronen <at> nokia.com wrote:
>Misspelled AVP in NASREQ
>Submitter name: Pasi Eronen
>Submitter email address: pasi.eronen <at> nokia.com
>Date first submitted: September 1, 2003
>Reference:
>Document: nasreq
>Comment type: E
>Priority: 2
>Section: 9.3
>Rationale/Explanation of issue:
>
>I also noticed that "Route-Record" is misspelled as "Record-Route"
>several times in NASREQ. All of the cases apply only to requests,
>so this is purely editorial (and independent of the other
>issue related to this AVP).
>
>Proposed change: search and replace.

I will fix that.  Thanks.
Dave.
Permalink | Reply | 0 comments |
headers
David Mitton | 1 Sep 2003 19:20

Re: : Authorization-Lifetime/Session-Timeout confusion

I like this suggestion.
Bernard had complained about a similar issue in #404 wrt to 802.1x, but I 
had problems working out all the details.

If there are no further comments, I'll incorporate this approach in NASREQ 
making sure it works with IEEE 802.1x or 802.1aa or whatever it is this week.

Dave.

On 8/15/2003 04:13 PM +0300, Pasi.Eronen <at> nokia.com wrote:

>Submitter name: Pasi Eronen
>Submitter email address: pasi.eronen <at> nokia.com
>Date first submitted: August 15, 2003
>Reference:
>Document: NASREQ
>Comment type: T
>Priority: 1
>Section: various
>Rationale/Explanation of issue:
>
>There seems to be some confusion about Authorization-Lifetime
>and Session-Timeout AVPs between Base and NASREQ.
>
>More specifically, the state machine in Base (Section 8.1)
>specifies that when Session-Timeout expires, the access
>device MUST send a STR and move to state Discon.
>
>This is inconsistent with with NASREQ description for
>Termination-Action AVP, which allows other behavior as well.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Mitton | 1 Sep 2003 19:29

Re: : Authentication method AVP?

On 8/12/2003 01:07 PM +0300, Jari Arkko wrote:
>Pasi.Eronen <at> nokia.com wrote:
>>Authentication method AVP?
>>Submitter name: Pasi Eronen
>>Submitter email address: pasi.eronen <at> nokia.com
>>Date first submitted: August 12, 2003
>>Reference: Document: NASREQ-12/EAP
>>Comment type: T
>>Priority: 2
>>Section: -
>>Rationale/Explanation of issue:
>>Diameter EAP application has Accounting-EAP-Auth-Method AVP that 
>>corresponds to the MS-Acct-EAP-Type RADIUS attribute from RFC 2548.  In 
>>RADIUS, this attribute is used together with MS-Acct-Auth-Type attribute 
>>(which has values for PAP, CHAP, EAP, MS-CHAP-1, etc.).
>>Should NASREQ have a corresponding AVP, named perhaps
>>Accounting-Auth-Method? (Note that this is different from
>
>Yes.
>
>>Acct-Authentic AVP, which has values for local, RADIUS and Diameter)
>>I guess we could define this AVP in Diameter EAP document if adding this 
>>to NASREQ this late would be a problem.
>
>I think we should put it in NASREQ.
>
>--Jari

Okay, can we elaborate more on the intended semantics?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 1 Sep 2003 20:11

: [Issue] Diameter/DynAuth RADIUS translation

Submitter name: Bernard Aboba
Submitter email address: aboba <at> internaut.com
Date first submitted: September 1, 2003
Reference:
Document: nasreq-12
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Update the references:

[RADDynAuth]  M. Chiba, M Dommety, M. Eklund, D. Mitton, B. Aboba,
              "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)",
              RFC 3576, August 2003.

[RADIUSIANA]  B. Aboba, "IANA Considerations for RADIUS", RFC 3575,
              August 2003.

[RAD802.1X]   P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines",
              RFC 3580, September 2003.

Update Section 6.1 to include the new Service-Type value:

    17  Authorize Only  [RFC3576]

Delete the following text from Section 9.1:

"   If the Diameter translation system receives a message as specified in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pasi.Eronen | 2 Sep 2003 10:39
Picon

RE: : Authentication method AVP? (issue 417)

David Mitton wrote:
> Okay, can we elaborate more on the intended semantics?
> 
> Is this an informational readout for Accounting as to what auth 
> method was actually used?
> 
> Which end originates it? (if accounting only, then client 
> to Acct server) Which way does it flow? Can we enumerate all the 
> desired values?
>
> How does this relate to the RADIUS attributes and MS VSAs at a 
> protocol gateway?
> 
> We have a day to get this in.

Like I said earlier, not delaying NASREQ is more important than
getting this AVP in (and it could be defined somewhere else,
like Diameter EAP, if necessary).

The AVP would be informational, from the client to the accounting
server. RFC2548 defines the following values for MS-Acct-Auth-Type: 
PAP (1), CHAP (2), MS-CHAP-1 (3), MS-CHAP-2 (4), and EAP (5). 
I guess we need a new IANA-managed namespace for these; 
the initial values could be these for easier translation.

Proposed text:

- New section (possibly after 8.6)

  8.TBD Accounting-Auth-Method AVP
(Continue reading)

Permalink | Reply | 501 comments |
headers
john.loughney | 2 Sep 2003 14:59
Picon

: Diameter Credit Control: Failover procedures updated

Hi all,

After some discussion, we are proposing the following changes to the Credit Control 
Failover procedure.  I believe Avi raised this point in his review.  We'd appreciate
comments on this, we plan on incorporating this into the next version of the draft.

thanks,
John

1) Change the second and third paragraphs in section 4.1.4 Failure Procedures

FROM

If a communication failure occurs during an ongoing credit-control session the credit-control client
can move the credit control message stream to an alternative server if the value of the
CC-Session-Failover AVP is set to FAILOVER SUPPORTED. A secondary Credit control server name received
for instance from the AAA server, can be used as an address of the backup server. If the
CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the credit control message stream MUST NOT be
moved to backup server and the credit control client will terminate or continue the service depending on
the value set in the Credit-Control-Failure-Handling AVP. The Credit-Control-Failure-Handling AVP
MAY be sent from the authorization server and in the Credit-Control-Answer from the credit-control
server. For new credit-control sessions, failover to an alternate credit-control server SHOULD be
performed, if possible.

The timer, Tx (as defined in section 10), is used in the credit-control client to supervise the
communication with the credit-control server.

TO

If a failure occurs during an ongoing credit-control session the credit-control client may move the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Arkko | 2 Sep 2003 16:32
Picon
Picon

Re: : [Issue] Diameter/DynAuth RADIUS translation

Bernard Aboba wrote:
> Submitter name: Bernard Aboba
> Submitter email address: aboba <at> internaut.com
> Date first submitted: September 1, 2003
> Reference:
> Document: nasreq-12
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> 
> Update the references:

Ok.

> Update Section 6.1 to include the new Service-Type value:
> 
>     17  Authorize Only  [RFC3576]

Ok.

> Add the following to Section 9.1:
...
> Add the following to Section 9.2:

The text sounds right. But I wonder if my head hurts because
I'm tired, or because a sequence diagram would make the issue
easier. The particular piece of text I had trouble with was
where STA, ASR, and RADIUS Access Request were mentioned in
the same sentence. Which direction are these messages sent?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jari Arkko | 2 Sep 2003 16:34
Picon
Picon

Re: : Route-Record AVP in responses

Auth48 is on for the base spec, so in theory we can still
fix things. Assuming the fixes are simple, and don't get
us into additional trouble...

--Jari
Permalink | Reply | 0 comments |

Gmane