Authentication, Authorization and Accounting (aaa)

Bernard Aboba | 1 Jun 2005 01:08

Re: : Re: authors 48 hours: RFC 4005

This looks fine to me.  Any objections?

On Mon, 30 May 2005, David Mitton wrote:

> Suggested changes
> Dave.
>
> ------
> Text changes for RFC 4005 <draft-ietf-aaa-diameter-nasreq-17.txt>
>
> Section 9.6.  RADIUS Vendor Specific Attributes
>
> para 1:  s/recommended/example/
>
> after para 1: <add >
>     A system communicating between Diameter and RADIUS MAY have specific
>     knowledge of vendor formats, and MAY be able translate between the
>     two formats. However, given the deployment of many RADIUS vendor
>     formats that do not follow the example format in RFC 2865 [RADIUS],
>     (e.g. those that use a longer vendor type code) the translations in
>     the next two sections, will not work in general for those VSAs.  RFC
>     2865 states that a robust implementation SHOULD support the field as
>     undistinguished octets.
>
>     Systems that don't have vendor format knowledge, MAY discard such
>     attributes not knowing a suitable translation. An alternative format is
>     under consideration [VSAdraft] that proposes encodings that would
>     preserve the native information and not require vendor knowledge in
>     the gateway system.
>

(Continue reading)

Glen Zorn (gwz | 1 Jun 2005 20:04

Picon

RE: : Re: authors 48 hours: RFC 4005

Bernard Aboba <> supposedly scribbled:

> This looks fine to me.  Any objections?

I give up.  In the message containing my non-suggestions
(non-suggestions because they didn't begin with the word "Issue" --
talk about quibbling!) I listed 3 options for (partially) fixing
this problem: a flag in the Diameter header signifying that the
packet had been translated from RADIUS, the creation of a new AVP
signifying the same, or the artificial limitation of the length of
Diameter AVPs w/codes <= 255.  Of these, the last was clearly (to
me, anyway) the worst possible choice, included only for
completeness.  I suppose that I shouldn't be surprised that that was
the route taken...

> 
> On Mon, 30 May 2005, David Mitton wrote:
> 
>> Suggested changes
>> Dave.
>> 
>> ------
>> Text changes for RFC 4005 <draft-ietf-aaa-diameter-nasreq-17.txt>
>> 
>> Section 9.6.  RADIUS Vendor Specific Attributes
>> 
>> para 1:  s/recommended/example/
>> 
>> after para 1: <add >
>>     A system communicating between Diameter and RADIUS MAY have

(Continue reading)

Bernard Aboba | 2 Jun 2005 20:42

Re: : Re: authors 48 hours: RFC 4005

To be clear, if we do not hear any objections to these changes by Friday,
we will go ahead and publish the document.

On Tue, 31 May 2005, Bernard Aboba wrote:

> This looks fine to me.  Any objections?
>
> On Mon, 30 May 2005, David Mitton wrote:
>
> > Suggested changes
> > Dave.
> >
> > ------
> > Text changes for RFC 4005 <draft-ietf-aaa-diameter-nasreq-17.txt>
> >
> > Section 9.6.  RADIUS Vendor Specific Attributes
> >
> > para 1:  s/recommended/example/
> >
> > after para 1: <add >
> >     A system communicating between Diameter and RADIUS MAY have specific
> >     knowledge of vendor formats, and MAY be able translate between the
> >     two formats. However, given the deployment of many RADIUS vendor
> >     formats that do not follow the example format in RFC 2865 [RADIUS],
> >     (e.g. those that use a longer vendor type code) the translations in
> >     the next two sections, will not work in general for those VSAs.  RFC
> >     2865 states that a robust implementation SHOULD support the field as
> >     undistinguished octets.
> >
> >     Systems that don't have vendor format knowledge, MAY discard such

(Continue reading)

David Mitton | 3 Jun 2005 07:42

RE: : Re: authors 48 hours: RFC 4005

On 6/1/2005 02:04 PM, Glen Zorn (gwz) wrote:
>Bernard Aboba <> supposedly scribbled:
>
> > This looks fine to me.  Any objections?
>
>I give up.  In the message containing my non-suggestions
>(non-suggestions because they didn't begin with the word "Issue" --
>talk about quibbling!) I listed 3 options for (partially) fixing
>this problem: a flag in the Diameter header signifying that the
>packet had been translated from RADIUS, the creation of a new AVP
>signifying the same, or the artificial limitation of the length of
>Diameter AVPs w/codes <= 255.  Of these, the last was clearly (to
>me, anyway) the worst possible choice, included only for
>completeness.  I suppose that I shouldn't be surprised that that was
>the route taken...

Well, before I sent my message, I went back and re-read the list, and your 
email of 4/19/05.
Let's look at it again....

>From: "Glen Zorn (gwz)" <gwz <at> cisco.com>
>To: "'Bernard Aboba'" <aboba <at> internaut.com>
>Cc: "'David Mitton'" <david <at> mitton.com>, <john.loughney <at> nokia.com>,
>         "'Pat Calhoun'" <pcalhoun <at> cisco.com>,
>         "'Bert Wijnen'" <bwijnen <at> lucent.com>,
>         "'Kessens, David'" <david.kessens <at> nokia.com>, <aaa-wg <at> merit.edu>
>Subject: RE: [AAA-WG]: Re: authors 48 hours: RFC 
>4005  <draft-ietf-aaa-diameter-nasreq-17.txt>
>Date: Tue, 19 Apr 2005 20:01:36 -0700
>

(Continue reading)

German Blanco (ML/EEM | 3 Jun 2005 14:57

Picon

: Diameter SIP Application AVP and command codes

Hi all,

in the set of AVPs and commands used in the draft there are some that have been already reserved in 3GPP for the
same purpose, with the same type and in some cases with the same name as in the draft.
Are there any plans of reusing the AVP and command codes of the Cx Application?

This is the list of similar AVPs:
+ 3GPP Vendor AVP           + in the draft
Server-Name                 SIP-Server-URI
Server-Capabilities         SIP-Server-Capabilities
Mandatory-Capability	    SIP-Mandatory-Capability
Optional-Capability	    SIP-Optional-Capability
SIP-Number-Auth-Items	    SIP-Number-Auth-Items
SIP-Authentication-Context  SIP-Authentication-Context
SIP-Item-Number	          SIP-Item-Number
SIP-Auth-Data-Item	    SIP-Auth-Data-Item
Server-Assignment-Type	    SIP-Server-Assignment-Type
Deregistration-Reason	    SIP-Deregistration-Reason
Reason-Code	                SIP-Reason-Code
Reason-Info	                SIP-Reason-Info
User-Authorization-Type	    SIP-User-Authorization-Type
User-Data-Already-Available SIP-User-Data-Already-Available

The command values could all be reused as far as I can see.

Cheers,

German Blanco.

(Continue reading)

john.loughney | 3 Jun 2005 14:57

Picon

RE: : Re: authors 48 hours: RFC 4005

David,

> >  we could use one of the unused flags in the
> >Diameter packet header and set it when a Diameter message passes
> >through a RADIUS->Diameter gateway; this would require special
> >purpose logic in the Diameter "server", however it would ensure that
> >the RADIUS rules were followed (if possible).
> 
> Well, I'm not convinced that the server MUST know the origin of the request.
> Operationally that would depends on whether the response would violate RADIUS rules.
> I'm not sure what service the server would return to a NAS that wouldn't work, but there is
> a possibility, so lets say there's something we want here.
> 
> Some RADIUS systems solve this (in particular for VSAs) by having the 
> network admin configure a NAS model table along with the IP address.  They 
> could add a RADIUS/Diameter protocol type.  But that's out of protocol.
> 
> But I've actually always liked identifying information in 
> requests.  Instead of a flag, I would think an Origin-Host-Protocol AVP 
> would be useful.  (personally, I'd love to see Make, Model, and version 
> number too)  With a protocol enumeration, heck someone could build a TACACS 
> to Diameter gateway.
> 
> I think this is a good idea.  It should probably be re-fitted into the 
> Base, and included in all Diameter requests.  Likewise, a RADIUS equivalent attribute 
> could be created.

I think that this might be a good way to solve this, going forward. Could we document
this behavior in a new draft; this could potentially update Diameter Base, if
the wg agrees.

(Continue reading)

mikko.aittola | 3 Jun 2005 15:45

Picon

RE: : Re: authors 48 hours: RFC 4005

Hi,

> Instead of a flag, I would think an Origin-Host-Protocol AVP 
> would be useful.

I agree.

> It should probably be re-fitted into the Base, and included in all
> Diameter requests.

I think it must not be mandatory in all Diameter requests.
There is no need for it if the Origin-Host-Protocol id
is Diameter.

BR,
Mikko

> -----Original Message-----
> From: owner-aaa-wg <at> merit.edu 
> [mailto:owner-aaa-wg <at> merit.edu]On Behalf Of
> ext David Mitton
> Sent: 03 June, 2005 08:43
> To: gwz <at> cisco.com; 'Bernard Aboba'
> Cc: aaa-wg <at> merit.edu
> Subject: RE: [AAA-WG]: Re: authors 48 hours: RFC 4005
> 
> 
> On 6/1/2005 02:04 PM, Glen Zorn (gwz) wrote:
> >Bernard Aboba <> supposedly scribbled:
> >

(Continue reading)

mikko.aittola | 3 Jun 2005 15:52

Picon

RE: : Diameter SIP Application AVP and command codes

Hi,

I agree the best solution would be to use the same AVP-
and command-codes where possible.

I think the application-id must be different, though.

BR,
Mikko

> -----Original Message-----
> From: owner-aaa-wg <at> merit.edu 
> [mailto:owner-aaa-wg <at> merit.edu]On Behalf Of
> ext German Blanco (ML/EEM)
> Sent: 03 June, 2005 15:57
> To: 'aaa-wg <at> merit.edu'
> Subject: [AAA-WG]: Diameter SIP Application AVP and command codes
> 
> 
> Hi all,
> 
> in the set of AVPs and commands used in the draft there are 
> some that have been already reserved in 3GPP for the same 
> purpose, with the same type and in some cases with the same 
> name as in the draft.
> Are there any plans of reusing the AVP and command codes of 
> the Cx Application?
> 
> This is the list of similar AVPs:
> + 3GPP Vendor AVP           + in the draft

(Continue reading)

john.loughney | 3 Jun 2005 19:51

Picon

RE: : 3588 issue with Vendor-Specific-Application-Id

Avi,

I looked over the thread on this, and I don'te quite get your point, could you
supply a little more text, esp. on what you reason you think that this should
be changed (other than it doesn't make sense)?

thanks,
John

> -----Original Message-----
> From: owner-aaa-wg <at> merit.edu 
> [mailto:owner-aaa-wg <at> merit.edu]On Behalf Of
> ext Avi Lior
> Sent: 10 May, 2005 18:57
> To: 'aaa-wg <at> merit.edu'
> Subject: [AAA-WG]: 3588 issue with Vendor-Specific-Application-Id
> 
> 
> Description of issue
> 
> Submitter name: Avi Lior	
> Submitter email address: avi <at> bridgewatersystems.com
> Date first submitted: May 10, 2005
> Reference: 
> Document: 3%88
> Comment type: T
> Priority: S
> Section: 6.11
> Rationale/Explanation of issue:
>

(Continue reading)

Miguel Garcia | 21 Jun 2005 13:21

Picon

Re: : Diameter SIP Application AVP and command codes

German:

I have concerns with your proposal.

Starting with, it is not a good idea to do a double specification, and 
this is exactly what you are proposing. 3GPP has defined a number of 
AVPs in the Diameter Cx application. These AVPs are allocated AVP codes 
600 and upwards (see 3GPP TS 29.229 Section 6.3).

If we now allocate the same AVP codes to a number of AVPs, and we 
publish the Diameter SIP application as an RFC, what we get is that the 
same AVP is specified twice, one in the future RFC and the other in 
29.229. If both specifications specify the same thing, so far so good. 
But if one specification indicates something slightly different from the 
other (imagine, because of an oversight, or because a change request 
approved by 3GPP), which one will win?

In this situation, if you receive one of those double-specified AVPs, 
you will need then to check the Application-ID, which is different for 
DSA and Cx applications. So if you need to look at the application ID to 
understand the syntax or semantics of a given AVP, then your main goal 
falls apart and we have failed.

In order to avoid these sorts of things, I would highly recommend not to 
even try to share any code. These are two applications (quite similar, 
yes), with different AVPs and different AVP codes. This grants some 
independendance of the two documents.

On the other hand, I haven't found what will be the benefit on doing 
your proposal. If it is to save programming code, then you won't at the

(Continue reading)

Group

gmane.ietf.aaa.

Search Archive

Page

1 | 2

Articles in period: 12

June 2005

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Call For Participation to IMAGINE 2008 in Iceland (30 Apr 2008)
: Naveen has Tagged you! :) (28 Mar 2007)
WG Action: Conclusion of Authentication, Authorization and Accounting (30 Jan 2007)
IPTComm 2007 Second Call for Papers (8 Jan 2007)
RFC 4740 on Diameter Session Initiation Protocol (SIP) Application (29 Nov 2006)
: [AAA-WG] Two-factor authentication support (6 Nov 2006)
: FW: RFC 3588 "aaas" Scheme: Feedback Needed! (31 Oct 2006)
FW: : Fwd: Failover processing (7 Aug 2006)
: Session Management APIs (7 Aug 2006)
: Fwd: Failover processing (26 Jul 2006)
: Diameter - Failover Implementation (24 Jul 2006)
: Realm expiration timer (24 Jul 2006)
: Diameter redirect (21 Jul 2006)
: Request Forwarding (20 Jul 2006)
: Realm table updation in Diameter (20 Jul 2006)
: Diameter redirect (20 Jul 2006)
: RFC 4590 on RADIUS Extension for Digest Authentication (fwd) (12 Jul 2006)
: Session state machine in DBP (26 Jun 2006)
: RE: [Dime] RE: Diameter base protocol messages used by DCCA (26 Jun 2006)
AW: : RE: Conclusions on the draft "Resource Management Extensions" (21 Jun 2006)
: RE: Conclusions on the draft "Resource Management Extensions" (21 Jun 2006)

Archives

1	April 2008
1	March 2007
2	January 2007
2	November 2006
1	October 2006
3	August 2006
12	July 2006
28	June 2006
11	May 2006
7	April 2006
9	March 2006
5	February 2006
23	January 2006
21	December 2005
22	November 2005
118	October 2005
24	September 2005
32	August 2005
15	July 2005
12	June 2005
30	May 2005
74	April 2005
8	March 2005
19	February 2005
7	January 2005
25	December 2004
43	November 2004
20	October 2004
46	September 2004
64	August 2004
94	July 2004
75	June 2004
167	May 2004
104	April 2004
110	March 2004
110	February 2004
103	January 2004
68	December 2003
38	November 2003
74	October 2003
41	September 2003
30	August 2003
40	July 2003
52	June 2003
65	May 2003
40	April 2003
40	March 2003
29	February 2003
23	January 2003
83	December 2002
47	November 2002
130	October 2002
138	September 2002
16	August 2002
79	July 2002
185	June 2002
76	May 2002
277	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template