From owner-aaa-wg@merit.edu Mon Aug 2 09:56:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07096 for ; Mon, 2 Aug 2004 09:43:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A90109123D; Mon, 2 Aug 2004 09:43:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C3719123E; Mon, 2 Aug 2004 09:43:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AA269123D for ; Mon, 2 Aug 2004 09:43:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D90C5A81A; Mon, 2 Aug 2004 09:43:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id C96FD5A780 for ; Mon, 2 Aug 2004 09:43:06 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i72Dh5HC027144 for ; Mon, 2 Aug 2004 15:43:05 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Aug 2004 15:43:01 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47896.A139BB06" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: [AAA-WG]: DCC: Service-Context-Id AVP definition and related updates Date: Mon, 2 Aug 2004 15:43:01 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906406A96@OMIMEXO06.omnitel.it> Thread-Topic: DCC: Service-Context-Id AVP definition and related updates Thread-Index: AcR4lqEAWwJOnFWJSLug70eKai9lRw== From: "STURA Marco Consultant" To: Cc: , , "Bernard Aboba (E-mail)" , , , "David Mitton (E-mail)" , "Mark Watson" , "Wijnen, Bert (Bert)" X-OriginalArrivalTime: 02 Aug 2004 13:43:01.0952 (UTC) FILETIME=[A1486400:01C47896] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C47896.A139BB06 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 the IESG commented a) to clean up the section 4.1 in order to give useful guidelines for interoperability and=20 b) to clarify the Service-Identifier meaning. =20 Since a) and b) are addressed by the Mark's amendments to my proposal and by the Leena's proposal, that=20 were accepted, it is time to update the draft accordingly. What is needed is to define the Service-Context-Id AVP and to update the Service-Identifier and Rating-Group AVPs. =20 Here is my proposal for the updates. =20 The Service-Context-Id AVP MUST be present in the CCR as per Mark's proposed amendment in http://www.merit.edu/mail.archives/aaa-wg/msg00802.html Therefore the CCR command will be updated with this AVP as follow =20 ::=3D < Diameter Header: xxx, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } { Service-Context-Id } { CC-Request-Type } { CC-Request-Number } [ Destination-Host ] [ User-Name ] [ CC-Sub-Session-Id ] ........... =20 Definition of the Service-Context-Id AVP. =20 8.xx Service-Context-Id AVP =20 The Service-Context-Id AVP is of type UTF8String (AVP Code XXX - IANA please fill in and remove this note - suggested value 458) and contains a unique identifier of the Diameter Credit Control service specific document that applies to the request (as defined in section 4.1.2). This is an identifier allocated by the service provider, by the service element manufacturer or by a standardization body and MUST uniquely identify a given Diameter Credit Control service specific document. The format of the service identifier is:=20 =20 "service-identifier" "@" "domain" =20 service-identifier =3D Token The Token is an arbitrary string of characters and digits. =20 domain =3D represents the entity that allocated the service-identifier. It can be ietf.org, 3gpp.org etc. if the identifier is allocated by a standardization body, or it can be the FQDN of the service provider (e.g. provider.example.com) or of the vendor (e.g. vendor.example.com) if the identifier is allocated by a private entity. =20 This AVP SHOULD be placed as closed to the Diameter header as possible. =20 Service specific documents that are for private use only, i.e. to one provider's own use, where no interoperability is deemed useful may define private identifiers without need of coordination. However, when interoperability is wanted, coordination of the identifiers via e.g. publication of informational RFC is RECOMMENDED to make Service-Context-Id globally available. =20 Updates to Service-Identifier and Rating-Group AVP =20 FROM =20 8.28 Service-Identifier AVP =20 The Service-Identifier AVP is of type UTF8String (AVP Code XXX - IANA please fill in and remove this note - suggested value 439) and contains a unique identifier of a service. This is an identifier allocated by the service provider, by the service element manufacturer or by a standardization body and MUST uniquely identify a given service. The format of the service identifier is:=20 =20 "service-identifier" "@" "domain" =20 service-identifier =3D Token The Token is an arbitrary string of characters and digits. =20 domain =3D represents the entity that allocated the service-identifier. It can be ietf.org, 3gpp.org etc. if the identifier is allocated by a standardization body, or it can be the FQDN of the service provider (e.g. provider.example.com) or of the vendor (e.g. vendor.example.com) if the identifier is allocated by a private entity. =20 Services that are for private use only, i.e. to one provider's own use, where no interoperability is deemed useful may define private identifiers without need of coordination. However, when interoperability is wanted, coordination of the identifiers via e.g. publication of informational RFC is RECOMMENDED to make Service-Identifier globally available. =20 A usage example of this AVP for multiple services in one user session is illustrated in Appendix A (Flow IX). =20 TO =20 8.28 Service-Identifier AVP =20 The Service-Identifier AVP is of type Unsigned32 (AVP Code XXX - IANA please fill in and remove this note - suggested value 439) and contains the identifier of a service. The specific service that the request relates to is uniquely identified by the combination of Service-Context-Identifier and Service-Identifier AVPs. =20 A usage example of this AVP is illustrated in Appendix A (Flow IX). =20 FROM =20 8.29 Rating-Group AVP =20 The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA please fill in and remove this note - suggested value 432) and contains the identifier of a rating group. All the services subject to the same rating type are part of the same rating group. This is an identifier allocated by the home service provider and MUST be unique within the home service provider domain. =20 A usage example of this AVP is illustrated in Appendix A (Flow IX). =20 TO =20 8.29 Rating-Group AVP =20 The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA please fill in and remove this note - suggested value 432) and contains the identifier of a rating group. All the services subject to the same rating type are part of the same rating group. The specific rating group that the request relates to is uniquely identified by the combination of Service-Context-Identifier and Rating-Group AVPs. =20 A usage example of this AVP is illustrated in Appendix A (Flow IX). =20 Moreover, there was an issue by Glen Zorn to include the Service-Identifier in the CER/CEA ( http://www.merit.edu/mail.archives/aaa-wg/msg00727.html ) The Service-Identifier intended by Glen is now the Service-Context-Id, therefore the draft 06 will reflect this. =20 Let me have your comments should you disagree on the above proposal. =20 Regards Marco =20 ------_=_NextPart_001_01C47896.A139BB06 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

the IESG commented a) to clean up the section 4.1 in = order to give useful guidelines for interoperability and =

b) to clarify the Service-Identifier = meaning.

 

Since a) and b) are addressed by the Mark’s = amendments to my proposal and by the Leena’s proposal, that =

were accepted, it is time to update the draft = accordingly. What is needed is to define the Service-Context-Id = AVP

and to update the Service-Identifier and Rating-Group = AVPs.

 

Here is my proposal for the = updates.

 

The Service-Context-Id AVP MUST be present in the CCR = as per Mark’s proposed amendment in http://w= ww.merit.edu/mail.archives/aaa-wg/msg00802.html

Therefore the CCR command will be updated with this = AVP as follow

 

<Credit-Control-Request> ::=3D < Diameter Header: xxx, REQ, PXY = >

       &nbs= p;            = ;            =   < Session-Id >

       &nbs= p;            = ;            =   { Origin-Host = }

       &nbs= p;            = ;            =   { Origin-Realm = }

       &nbs= p;            = ;            =   { Destination-Realm = }

       &nbs= p;            = ;            =   { Auth-Application-Id = }

       &nbs= p;            = ;            =   { Service-Context-Id = }

       &nbs= p;            = ;           &nbs= p;  { CC-Request-Type }

       &nbs= p;            = ;            =   { CC-Request-Number = }

       &nbs= p;            = ;            =   [ Destination-Host = ]

       &nbs= p;            = ;            =   [ User-Name = ]

       &nbs= p;            = ;            =   [ CC-Sub-Session-Id = ]

       &nbs= p;          &nbs= p;            = ;   ...........

 

Definition of the Service-Context-Id = AVP.

 

8.xx  Service-Context-Id = AVP

 

The Service-Context-Id AVP is of type UTF8String (AVP Code XXX - IANA please = fill in and remove this note - suggested value 458) and contains a unique = identifier of the Diameter Credit Control service specific document that applies to = the request (as defined in section 4.1.2). This is an identifier allocated = by the service provider, by the service element manufacturer or by a = standardization body and MUST uniquely identify a given Diameter Credit Control service specific document. The format of the service identifier is: =

 

"service-identifier" "@" "domain"

 

service-identifier =3D Token

The Token = is an arbitrary string of characters and digits.

 

domain =3D represents the entity that allocated the = service-identifier.

It can be = ietf.org, 3gpp.org etc. if the identifier is allocated by a standardization body, = or it can be the FQDN of the service provider (e.g. provider.example.com) or = of the vendor (e.g. vendor.example.com) if the identifier is allocated by a = private entity.

 

This AVP SHOULD be placed as closed to the = Diameter header as possible.

 

Service specific documents that are for private use only, i.e. to one provider's = own use, where no interoperability is deemed useful may define private = identifiers without need of coordination. However, when interoperability is wanted, coordination of the identifiers via e.g. publication of informational = RFC is RECOMMENDED to make Service-Context-Id globally = available.

 

Updates to Service-Identifier and Rating-Group = AVP

 

FROM

 

8.28           = ; Service-Identifier = AVP

 

The Service-Identifier AVP is of type UTF8String (AVP Code XXX - IANA please = fill in and remove this note - suggested value 439) and contains a unique = identifier of a service. This is an identifier allocated by the service provider, by = the service element manufacturer or by a standardization body and MUST = uniquely identify a given service. The format of the service identifier is: =

 

"service-identifier" "@" "domain"

 

service-identifier =3D Token

The Token = is an arbitrary string of characters and digits.

 

domain =3D represents the entity that allocated the = service-identifier.

It can be = ietf.org, 3gpp.org etc. if the identifier is allocated by a standardization body, = or it can be the FQDN of the service provider (e.g. provider.example.com) or = of the vendor (e.g. vendor.example.com) if the identifier is allocated by a = private entity.

 

Services that are for private use only, i.e. to one provider's own use, where no interoperability is deemed useful may define private identifiers without = need of coordination. However, when interoperability is wanted, coordination = of the identifiers via e.g. publication of informational RFC is RECOMMENDED to = make Service-Identifier globally available.

 

A usage example of this AVP for multiple services in one user session is illustrated in Appendix A (Flow IX).

 

TO

 

8.28 Service-Identifier AVP

 

The Service-Identifier AVP is of type Unsigned32 (AVP Code XXX - IANA please = fill in and remove this note - suggested value 439) and contains the = identifier of a service. The = specific service that the request relates to is uniquely identified by the = combination of Service-Context-Identifier and Service-Identifier = AVPs.

 

A usage example of this AVP is illustrated in Appendix A (Flow IX).

 

FROM<= /a>

 <= /span>

8.29           = ; Rating-Group AVP

 

The = Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA please fill in and remove = this note - suggested value 432) and contains the identifier of a rating group. All = the services subject to the same rating type are part of the same rating = group. This is an identifier allocated by the home service provider and MUST be = unique within the home service provider = domain.

 <= /span>

A usage = example of this AVP is illustrated in Appendix A (Flow = IX).

 <= /span>

TO

 <= /span>

8.29           = ; Rating-Group = AVP

 

The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA please fill = in and remove this note - suggested value 432) and contains the identifier of a = rating group. All the services subject to the same rating type are part of the = same rating group. The specific rating group that the request relates to is uniquely identified = by the combination of Service-Context-Identifier and Rating-Group = AVPs.

 

A usage example of this AVP is illustrated in Appendix A (Flow = IX).

 

Moreover, there was an issue by Glen Zorn to include = the Service-Identifier in the CER/CEA

( = http://w= ww.merit.edu/mail.archives/aaa-wg/msg00727.html )

The Service-Identifier intended by Glen is now the Service-Context-Id, therefore the draft 06 will reflect = this.

 

Let me have your comments should you disagree on the = above proposal.

 

Regards

Marco

 

------_=_NextPart_001_01C47896.A139BB06-- From owner-aaa-wg@merit.edu Mon Aug 2 22:51:23 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23953 for ; Mon, 2 Aug 2004 22:51:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97EBF91248; Mon, 2 Aug 2004 22:51:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F4389124A; Mon, 2 Aug 2004 22:51:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EEA391248 for ; Mon, 2 Aug 2004 22:51:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16E7F5A7D6; Mon, 2 Aug 2004 22:51:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 51A395A4C4 for ; Mon, 2 Aug 2004 22:51:07 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i732p6O00582 for ; Tue, 3 Aug 2004 05:51:06 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 05:48:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i732m92N002619 for ; Tue, 3 Aug 2004 05:48:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0032Z5UX; Tue, 03 Aug 2004 05:48:09 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i732m8n25061 for ; Tue, 3 Aug 2004 05:48:08 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 05:48:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 05:48:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: AAA WG Agendabashing Date: Tue, 3 Aug 2004 05:48:05 +0300 Message-ID: Thread-Topic: [AAA-WG]: AAA WG Agenda at IETF 60 Thread-Index: AcRzIjg1MOw7N8vdRfiVRjvhNlV5HABShTtAAAL/QgAALnlc4AD0faFg From: To: X-OriginalArrivalTime: 03 Aug 2004 02:48:06.0209 (UTC) FILETIME=[4D9B9B10:01C47904] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bashing the agenda before the meeting, I needed to re-arrange the = discussions: Diameter EAP, Pasi Eronen, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt EAP Key Management Issues, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 15 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Tea Break Diameter MIPv4, Pete McCann, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-19.t= xt Diameter NASREQ, David Mitton, 10 minutes http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-17.txt Diameter Credit Control, John Loughney, 10 min http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt Diameter URI, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt Diameter SIP, M. Garcia-Martin, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.tx= t Diameter QoS application, Hannes Tschofenig, 10 minutes http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt From owner-aaa-wg@merit.edu Tue Aug 3 10:17:41 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11298 for ; Tue, 3 Aug 2004 10:17:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9EBEF91251; Tue, 3 Aug 2004 10:16:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 661EB91254; Tue, 3 Aug 2004 10:16:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CC4D91251 for ; Tue, 3 Aug 2004 10:16:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68D3B5A7D4; Tue, 3 Aug 2004 10:16:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D6F485A7D2 for ; Tue, 3 Aug 2004 10:16:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i73EChN20930 for ; Tue, 3 Aug 2004 07:12:43 -0700 Date: Tue, 3 Aug 2004 07:12:43 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Slides for IETF 60 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you have slides to present at the AAA WG meeting today, please send them to the chairs ASAP. From owner-aaa-wg@merit.edu Tue Aug 3 12:53:17 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21015 for ; Tue, 3 Aug 2004 12:53:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F197D9125A; Tue, 3 Aug 2004 12:52:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71C6E91267; Tue, 3 Aug 2004 12:52:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 297A39125A for ; Tue, 3 Aug 2004 12:51:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EC495A342; Tue, 3 Aug 2004 12:51:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 7CA865A28B for ; Tue, 3 Aug 2004 12:51:38 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73GpbN05820 for ; Tue, 3 Aug 2004 19:51:37 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 19:48:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i73Gmp1Y016712 for ; Tue, 3 Aug 2004 19:48:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 001nrzek; Tue, 03 Aug 2004 19:48:47 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73Gmlu18190 for ; Tue, 3 Aug 2004 19:48:47 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 19:48:44 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C47979.BD5EAF09" Subject: [AAA-WG]: FW: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments Date: Tue, 3 Aug 2004 19:48:44 +0300 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments Thread-Index: AcR5ebvsZz5PP3hSSrGwaMDIgWSqPA== From: To: X-OriginalArrivalTime: 03 Aug 2004 16:48:44.0516 (UTC) FILETIME=[BD2E7A40:01C47979] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C47979.BD5EAF09 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Text sent to clear Ted's comments. Attached are the responses. John _____________________________________- Hello, thank you for your comments. We agree that the specification is not very = clear in some parts and some clarification is certainly useful to better = understand the message we wanted to give. Please see the answers and proposals for improved text below and let us know whether these corrections and clarifications will address your = concerns. Best Regards, Harri Hakala Leena Mattila Juha-Pekka Koskinen Marco Stura John Loughney -------------------------------------------------------------------------= - Ted Hardie: Discuss: I believe Section 4.1 needs some clean up to provide useful guidelines = for=20 interoperability. I read through it 3 or 4 times, and I believe I = eventually=20 got the steps into a reasonable set of steps, but it is still hard for = me to=20 be sure that it is the only reasonable reading. The document needs clear = advice on when to reuse AVPs, how and when to define new ones, and=20 when to use the service-parameter-info as a container. It may also need=20 to justify some choices based on other constraints (does a limit in the=20 AVP namespace suggest re-use of existing AVPs, for example?)=20 Answer: Agree. The section needs some re-structuring to give better guidance. Proposal for the text (replaces old section 4.1): 4.1 Service-Specific Rating Input and Interoperability=20 The Diameter Credit-Control Application defines the framework for=20 credit control; it provides generic credit control mechanisms=20 supporting multiple service applications. The Credit Control=20 Application, therefore, does not define AVPs that could be used as=20 input in the rating process. Listing the possible services that could = use this Diameter application is seen as out of scope for this=20 generic mechanism as well.=20 =20 Furthermore, it is not assumed that any arbitrary Diameter credit- control client will be able to communicate with any Diameter credit-control server, but the connections reflect the business relationships between the organizations hosting the Diameter peers. Therefore, it is reasonable to expect that there will exist a service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input, etc. 4.1.1 Specifying Rating Input AVPs There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principles for sending rating=20 parameters are: 1a. The service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing Diameter applications (e.g. NASREQ for network access services). Re-use of existing AVPs is strongly recommendated in [DIAMBASE]. For AVPs of type Enumerated the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2. 1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In such a case, the procedures=20 defined in [DIAMBASE] for creating new AVPs MUST be followed. 1c. For services specific only to one vendor's implementation where no interoperatbility is deemed useful, a Vendor-Specific = AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g.=20 ASN.1 BER). This method can be used to avoid unnecessary data=20 format conversions from an existing format to an AVP format. In=20 that case the rating input is embedded in the = Service-Parameter-Info=20 AVP as defined in section 8.42. New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability.=20 4.1.2 Application Support Since the Application-Id of the Diameter Credit Control Application = does not uniquely identify the service being monitored, an additional = mechanism is needed. The service application MUST be identified using the Service-Identifier AVP at command level. A server receiving a request = for=20 a service application it does not support will reject the request as=20 defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a = unique=20 identifier for a given service as defined in section 8.28.=20 Thus, the combination of the Diameter Credit Control Application-Id = and the Service-Identifier AVP in the Credit-Control-Request command = uniquely defines the service within the context of the Diameter Credit = Control,=20 and hence provides interoperability between Diameter credit control=20 clients and server.=20 Introducing new, non-rating related AVPs, that imply new credit = control mechanisms, require definition of a new version of the Diameter=20 Credit Control Application and corresponding Application Identifier.=20 4.1.3 Documentation of the Service-Specific Information =20 The service specific rating input AVPs, the contents of the Service- Parameter-Info AVP or Service-Identifier AVP are not within the scope = of this document. To facilitate interoperability, it is RECOMMENDED=20 that the rating input and the values of the service identifiers are=20 coordinated via an informational RFC or other permanent and readily=20 available reference such as the specification of another cooperative=20 standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used.=20 However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used.=20 =20 This specification, together with the above service specific = documents, governs the credit control message. The rule is that service specific documents only define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new=20 credit control applications), and thus need to be included in the=20 Credit-Control-Request command by a Diameter Credit Control Client=20 supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP. 4.1.4 Handling of Unsupported/Incorrect Rating Input=20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of=20 the services they support according to the 'M' bit rules in = [DIAMBASE].=20 =20 In case a rating input required for the rating process is incorrect=20 in the Credit control request, or the credit control server does not=20 support the requested service, the Credit control answer MUST contain = error code DIAMETER_RATING_FAILED. A CCR message with this error MUST = contain one or more Failed-AVP AVPs containing the missing and/or=20 unsupported AVPs that caused the failure. A Diameter credit control=20 client receiving error code DIAMETER_RATING_FAILED in answer to a=20 request MUST NOT send such similar requests in the future. 4.1.5 RADIUS Vendor-Specific Rating Attributes =20 When service specific documents include RADIUS vendor specific=20 attributes that could be used as input in the rating process, the=20 rules described in [NASREQ] for formatting the Diameter AVP MUST be=20 followed. For example, the AVP code used is the vendor attribute type = code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID=20 MUST be set to the IANA Vendor identification value. The Diameter AVP = data field contains only the attribute value of the RADIUS attribute. = ---------------------------------------------------------------------- It is not clear to me what the client requirements are for 5.5. If, for = example,=20 a client is using this mechanism to manage voice minutes on a mobile = phone,=20 does the potential for a Server-initiated RAR imply that the client must = have=20 data traffic and this service enabled at all times, in case it receives = such a request?=20 Note that the "graceful service termination" redirect to a top-up server = doesn't=20 obviate this requirement (at least in my reading), since it doesn't = imply that=20 the server won't send an RAR.=20 Is it legal to combine a Tariff change with a service initiated re-auth? = Answer: The client needs to support the RAR/RAA messages and needs to initiate a credit re-authorization by sending a CCR request upon reception of the RAR. This is explained in the third and subsequent paragraphs and it is visible in the client=20 state machine. This is the only requirement to the client,=20 and it is according to the base protocol. Concerning the voice minutes, this is handled by requesting credit authorization (or re-authorization) with the CCR request.=20 The server returns the time quota in the corresponding CCA message within the Granted-Service-Unit AVP, the time quota is monitored by the client. At any time the server may request credit re-authorization by issuing a RAR request. Performing tariff time changes with the server initiated=20 re-authorization is actually possible although cumbersome. Tariff changes typically occur at the same time for all the active sessions, therefore, the server would need to issue a RAR for all the active sessions at the same time. This abviously creates a huge storm of credit re-authorization that would potentially overload the system. In real networks, where million of users are active, this mechanism for tariff change is actually not gonna work. The DCCA defines a more effective tariff change mechanism where huge storm of credit re-authorization when tariff change occurs is avoided (see for instance sect. 5.1). ---------------------------------------------------------------------- Comment:=20 "credit fragmentation" is mentioned in this section:=20 To avoid credit fragmentation and unnecessary load on the credit=20 control server, it is possible for service units to be provided to=20 multiple services or rating groups as a pool. This is achieved by=20 providing the service units in the form of a quota for a particular=20 service or rating group in the Multiple-Services-Credit-Control AVP,=20 but also including a reference to a credit pool for that unit type.=20 Some definition of credit fragmentation might be useful.=20 Answer: We'd propose to modify the above paragraph as follows: To avoid a situation where several parallel, and typically also small, credit reservations must be made on the same account (i.e. credit fragmentation) and also to avoid unnecessary load on the = credit=20 control server, it is possible to provide service units as a pool=20 that applies to multiple services or rating groups. This is achieved by providing the service units in the form of a quota for a = particular=20 service or rating group in the Multiple-Services-Credit-Control AVP,=20 but also including a reference to a credit pool for that unit type.=20 ---------------------------------------------------------------------- ------_=_NextPart_001_01C47979.BD5EAF09 Content-Type: message/rfc822 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments Date: Tue, 29 Jun 2004 13:44:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: To: , Cc: , , , , , Content-Transfer-Encoding: quoted-printable Hello, thank you for your comments. We agree that the specification is not very = clear in some parts and some clarification is certainly useful to better = understand the message we wanted to give. Please see the answers and proposals for improved text below and let us know whether these corrections and clarifications will address your = concerns. Best Regards, Harri Hakala Leena Mattila Juha-Pekka Koskinen Marco Stura John Loughney -------------------------------------------------------------------------= - Ted Hardie: Discuss: I believe Section 4.1 needs some clean up to provide useful guidelines = for=20 interoperability. I read through it 3 or 4 times, and I believe I = eventually=20 got the steps into a reasonable set of steps, but it is still hard for = me to=20 be sure that it is the only reasonable reading. The document needs clear = advice on when to reuse AVPs, how and when to define new ones, and=20 when to use the service-parameter-info as a container. It may also need=20 to justify some choices based on other constraints (does a limit in the=20 AVP namespace suggest re-use of existing AVPs, for example?)=20 Answer: Agree. The section needs some re-structuring to give better guidance. Proposal for the text (replaces old section 4.1): 4.1 Service-Specific Rating Input and Interoperability=20 The Diameter Credit-Control Application defines the framework for=20 credit control; it provides generic credit control mechanisms=20 supporting multiple service applications. The Credit Control=20 Application, therefore, does not define AVPs that could be used as=20 input in the rating process. Listing the possible services that could = use this Diameter application is seen as out of scope for this=20 generic mechanism as well.=20 =20 Furthermore, it is not assumed that any arbitrary Diameter credit- control client will be able to communicate with any Diameter credit-control server, but the connections reflect the business relationships between the organizations hosting the Diameter peers. Therefore, it is reasonable to expect that there will exist a service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input, etc. 4.1.1 Specifying Rating Input AVPs There are two ways for providing rating input to the credit control=20 server, either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principles for sending rating=20 parameters are: 1a. The service SHOULD re-use existing AVPs, if the service can use AVPs defined in existing Diameter applications (e.g. NASREQ for network access services). Re-use of existing AVPs is strongly recommendated in [DIAMBASE]. For AVPs of type Enumerated the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2. 1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In such a case, the procedures=20 defined in [DIAMBASE] for creating new AVPs MUST be followed. 1c. For services specific only to one vendor's implementation where no interoperatbility is deemed useful, a Vendor-Specific = AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs are encouraged instead, refer to [DIAMBASE]. 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g.=20 ASN.1 BER). This method can be used to avoid unnecessary data=20 format conversions from an existing format to an AVP format. In=20 that case the rating input is embedded in the = Service-Parameter-Info=20 AVP as defined in section 8.42. New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability.=20 4.1.2 Application Support Since the Application-Id of the Diameter Credit Control Application = does not uniquely identify the service being monitored, an additional = mechanism is needed. The service application MUST be identified using the Service-Identifier AVP at command level. A server receiving a request = for=20 a service application it does not support will reject the request as=20 defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a = unique=20 identifier for a given service as defined in section 8.28.=20 Thus, the combination of the Diameter Credit Control Application-Id = and the Service-Identifier AVP in the Credit-Control-Request command = uniquely defines the service within the context of the Diameter Credit = Control,=20 and hence provides interoperability between Diameter credit control=20 clients and server.=20 Introducing new, non-rating related AVPs, that imply new credit = control mechanisms, require definition of a new version of the Diameter=20 Credit Control Application and corresponding Application Identifier.=20 4.1.3 Documentation of the Service-Specific Information =20 The service specific rating input AVPs, the contents of the Service- Parameter-Info AVP or Service-Identifier AVP are not within the scope = of this document. To facilitate interoperability, it is RECOMMENDED=20 that the rating input and the values of the service identifiers are=20 coordinated via an informational RFC or other permanent and readily=20 available reference such as the specification of another cooperative=20 standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used.=20 However, private services may be deployed that are subject to agreements between providers of the credit control server and client, in this case vendor specific AVPs can be used.=20 =20 This specification, together with the above service specific = documents, governs the credit control message. The rule is that service specific documents only define what existing AVPs or new AVPs are used as input to the rating process (i.e. they do not define new=20 credit control applications), and thus need to be included in the=20 Credit-Control-Request command by a Diameter Credit Control Client=20 supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP. 4.1.4 Handling of Unsupported/Incorrect Rating Input=20 Diameter credit control implementations are required to support the=20 Mandatory rating AVPs defined in service specific documentation of=20 the services they support according to the 'M' bit rules in = [DIAMBASE].=20 =20 In case a rating input required for the rating process is incorrect=20 in the Credit control request, or the credit control server does not=20 support the requested service, the Credit control answer MUST contain = error code DIAMETER_RATING_FAILED. A CCR message with this error MUST = contain one or more Failed-AVP AVPs containing the missing and/or=20 unsupported AVPs that caused the failure. A Diameter credit control=20 client receiving error code DIAMETER_RATING_FAILED in answer to a=20 request MUST NOT send such similar requests in the future. 4.1.5 RADIUS Vendor-Specific Rating Attributes =20 When service specific documents include RADIUS vendor specific=20 attributes that could be used as input in the rating process, the=20 rules described in [NASREQ] for formatting the Diameter AVP MUST be=20 followed. For example, the AVP code used is the vendor attribute type = code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID=20 MUST be set to the IANA Vendor identification value. The Diameter AVP = data field contains only the attribute value of the RADIUS attribute. = ---------------------------------------------------------------------- It is not clear to me what the client requirements are for 5.5. If, for = example,=20 a client is using this mechanism to manage voice minutes on a mobile = phone,=20 does the potential for a Server-initiated RAR imply that the client must = have=20 data traffic and this service enabled at all times, in case it receives = such a request?=20 Note that the "graceful service termination" redirect to a top-up server = doesn't=20 obviate this requirement (at least in my reading), since it doesn't = imply that=20 the server won't send an RAR.=20 Is it legal to combine a Tariff change with a service initiated re-auth? = Answer: The client needs to support the RAR/RAA messages and needs to initiate a credit re-authorization by sending a CCR request upon reception of the RAR. This is explained in the third and subsequent paragraphs and it is visible in the client=20 state machine. This is the only requirement to the client,=20 and it is according to the base protocol. Concerning the voice minutes, this is handled by requesting credit authorization (or re-authorization) with the CCR request.=20 The server returns the time quota in the corresponding CCA message within the Granted-Service-Unit AVP, the time quota is monitored by the client. At any time the server may request credit re-authorization by issuing a RAR request. Performing tariff time changes with the server initiated=20 re-authorization is actually possible although cumbersome. Tariff changes typically occur at the same time for all the active sessions, therefore, the server would need to issue a RAR for all the active sessions at the same time. This abviously creates a huge storm of credit re-authorization that would potentially overload the system. In real networks, where million of users are active, this mechanism for tariff change is actually not gonna work. The DCCA defines a more effective tariff change mechanism where huge storm of credit re-authorization when tariff change occurs is avoided (see for instance sect. 5.1). ---------------------------------------------------------------------- Comment:=20 "credit fragmentation" is mentioned in this section:=20 To avoid credit fragmentation and unnecessary load on the credit=20 control server, it is possible for service units to be provided to=20 multiple services or rating groups as a pool. This is achieved by=20 providing the service units in the form of a quota for a particular=20 service or rating group in the Multiple-Services-Credit-Control AVP,=20 but also including a reference to a credit pool for that unit type.=20 Some definition of credit fragmentation might be useful.=20 Answer: We'd propose to modify the above paragraph as follows: To avoid a situation where several parallel, and typically also small, credit reservations must be made on the same account (i.e. credit fragmentation) and also to avoid unnecessary load on the = credit=20 control server, it is possible to provide service units as a pool=20 that applies to multiple services or rating groups. This is achieved by providing the service units in the form of a quota for a = particular=20 service or rating group in the Multiple-Services-Credit-Control AVP,=20 but also including a reference to a credit pool for that unit type.=20 ---------------------------------------------------------------------- ------_=_NextPart_001_01C47979.BD5EAF09 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments Date: Wed, 30 Jun 2004 16:15:03 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: To: , Cc: , , , , , Content-Transfer-Encoding: quoted-printable Hi, Answers & clarifications to your follow up comments. Best regards, DCC authors. > > Furthermore, it is not assumed that any arbitrary=20 > Diameter credit- > > control client will be able to communicate with any Diameter > > credit-control server, but the connections reflect the business > > relationships between the organizations hosting the=20 > Diameter peers. >=20 > The sentence above concerns me, as I believe it could be read > over-broadly as "interoperability between clients and servers > is not a goal". Based on the text below, it seems that an > arbitrary client should be able to talk to an arbitrary server, > and that the parties should be able to exchange error messages > when one references a service the other does not understand (I'm > looking at 4.1.4, in particular). Is there some way to make clearer > that the business relationships that extend credit may affect > the availability of specific AVPs and the interchanges between > peers, without implying that the clients and servers may not > be interoperable? The intention of the above sentence was to indicate that it is not = assumed or preferred that one can plug in an arbitrary credit control client and start to interchange credit control messages with any credit control server, although it could be protocol wise possible. Meaning that an=20 arbitrary credit control client can send credit control messages to=20 any credit control server, but most probably these messages would be rejected, since they carry unsupported services/AVPs. But it is true that one can interpret that sentence in several ways.=20 Would this be better: Furthermore, it is reasonable to expect that there will exist a = service level agreement between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e. AVPs), etc. Therefore, it is assumed that a Diameter credit control server will provide service only for Diameter credit-control clients which have agreed beforehand the content of credit control messages. Protocol = wise,=20 it is naturally possible that any arbitrary Diameter credit-control client can interchange credit control messages with any Diameter=20 credit control server, but with a higher likelihood that unsupported = services/AVPs could be present in the credit-control message causing the server to reject the request with an appropriate result-code. > > 1c. For services specific only to one vendor's implementation > > where no interoperatbility is deemed useful, a=20 > Vendor-Specific AVP > > >=20 > interoperatbility-->interoperability >=20 > I also would suggest removing "where no interoperability is deemed > useful", as I believe "specific only to one vendor's implementation" > covers the ground without raising the question of what level of=20 > interoperability > is meant. OK > >Answer: > > The client needs to support the RAR/RAA messages and needs to > > initiate a credit re-authorization by sending a CCR request > > upon reception of the RAR. This is explained in the third > > and subsequent paragraphs and it is visible in the client > > state machine. This is the only requirement to the client, > > and it is according to the base protocol. >=20 > I guess what is confusing me is the Server MAY here. If a > client does not react at all to RAR (possibly because the > credit control application is attached to a data interface > that is not active and/or cannot be activated by the > network), I assume that Graceful Service Termination > proceeds. The question is, was the client's failure > to respond a protocol error? If so, is there any way for > the client to negotiate with the server the use of RAR/RAA > messages, so that it can decline their use in cases where > keeping the data channel open would be onerous? The client MUST support the server initiated re-authorization, the = server MAY use it or not. Therefore, the assumption is exactly what you are pointing out i.e. the client MUST immediately respond with RAA followed by CCR[Update]. Perhaps we could include the MUST keyword in the 3d paragraph as follow: If a credit re-authorization is not already ongoing (i.e. the credit=20 control session is in OPEN state), a credit control client that=20 receives such a RAR message with Session-Id equal to a currently=20 active credit control session MUST acknowledge the request by sending = the Re-Auth-Answer (RAA) message and MUST initiate the credit re- authorization towards the server by sending a Credit-Control-Request=20 message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. = In case the data interface is not active and/or cannot be activated by the network, it means that a transport connection failure will be detected by the client e.g. upon expiration of the validity-timer in case the GST is ongoing. The client will typically stop the GST and disconnect the user (I think this is visible in sect. 5.5 9th paragraph, here copied). If a communication failure occurs during the graceful service=20 termination procedure, the service element SHOULD always terminate=20 the ongoing service session. > Ah, I see the section now; thanks for the pointer. As an aside, > 5.1 is pretty long, and sections like this might be less obvious > to the reader as a result; you might consider giving 5.1.x > subheadings to break it up a bit. We will add subheadings 5.1.x >=20 ------_=_NextPart_001_01C47979.BD5EAF09 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Last Call: 'Diameter Credit-control Application' to Proposed Standard + IESG Evaluation, IANA comments Date: Tue, 29 Jun 2004 16:58:41 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: To: , , Cc: , , , , , Content-Transfer-Encoding: quoted-printable Hello, thank you for your comments regarding the IANA parts. Since we received similar comments during IETF Last Call from IANA and during = IESG Evaluation from Thomas Narten we'd like to answer both reviews in one = combined mail in order to keep all the involved parties in the loop. Please see the answers and proposals for improved text below and let us know whether these corrections and clarifications will address your = concerns. Best Regards, Harri Hakala Leena Mattila Juha-Pekka Koskinen Marco Stura John Loughney =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= ----Original Message----- From: Michelle S. Cotton [mailto:cotton@icann.org] Sent: 15. kes=E4kuuta 2004 20:37 To: iesg@ietf.org; iana@iana.org Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; marco.stura@nokia.com; John.Loughney@nokia.com; aboba@internaut.com; david@mitton.com Subject: RE: Last Call: 'Diameter Credit-control Application' to Proposed Standard IESG: The IANA has reviewed the following Internet-Draft which is=20 in Last Call: , and has=20 the following comments with regards to the publication of=20 this document: Section 12.1 The name of the application identifier to be assigned should be included in this section. Answer: The draft will be updated as follows: 12.1 Application Identifier=20 =20 This specification assigns the value XXX [IANA please fill in XXX=20 (suggested value 4) and remove this note], 'Diameter Credit Control', to the Application Identifier namespace defined in [DIAMBASE]. See section 1.3 for more information.=20 Additionally, the above suggested application id value 4 is mentioned = also in sections 1.3 and 5.5. Should IANA allocate another value than the proposed 4 = these sections must be updated accordingly. Therefore we also will add = IANA-notes in those sections as follows: 1.3 Advertising application support =20 =20 Diameter nodes conforming to this specification MUST advertise=20 support by including the value of XXX [IANA please fill in XXX=20 (suggested value 4 in section 12.1) and remove this note] in the Auth-Application-Id of the Capabilities-Exchange-Request and=20 Capabilities-Exchange-Answer command [DIAMBASE]. =20 5.5 Server-Initiated Credit Re-Authorization=20 The Diameter Credit Control Application supports server-initiated re- authorization. The credit control server MAY optionally initiate the=20 credit re-authorization by issuing a Re-Auth-Request (RAR) as defined = in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in=20 the RAR message is set to XXX [IANA please fill in XXX (suggested=20 value 4 in section 12.1) and remove this note] to indicate the = Diameter=20 Credit Control Application and the Re-Auth-Request-Type is set to=20 AUTHORIZE_ONLY.=20 -------------------------------------------------------------------------= - Sction 12.2 The name of the command code to be assigned should be included in this section. Answer: The draft will be updated as follows: 12.2 Command Codes =20 =20 This specification uses the value XXX [IANA please fill in XXX = (suggested=20 value 272) and remove this note] from the Command code namespace=20 defined in [DIAMBASE] for the Credit-Control Request (CCR) and = Credit- Control-Answer (CCA) commands. =20 -------------------------------------------------------------------------= - Section 12.3 We will use section 8 as the guide for assigning AVP Codes (total values =3D 50) Answer: OK. Section 12.4 We will use section 9 as the guide for assigning Result-Code AVP Values (total values =3D 5). Answer: OK. Sections 12.5-12.18 We will create sub-registries for AVP Specific Values Answer: OK. These sections will also be clarified as suggested by Thomas Narten = below. Michelle Cotton (on behalf of the IANA) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Thomas Narten wrote: > 12.1 Application Identifier=20 >=20 > This specification assigns the value XXX [IANA please fill in XXX=20 > (suggested value 4) and remove this note] to the Application=20 > Identifier namespace defined in [DIAMBASE]. See section 1.3 for more=20 > information.=20 Please provide the name of the application identifier. Answer: The text will be modified as proposed above (see comments from IANA). -------------------------------------------------------------------------= - > 12.3 AVP Codes=20 >=20 > This specification assigns the values XXX - YYY [IANA please fill in=20 > XXX, YYY (suggested values 411, 457) and remove this note] from the=20 > AVP code namespace defined in [DIAMBASE] See section 8 for the=20 > assignment of the namespace in this specification.=20 would be good to include a table with all the needed TBDs, refering to=20 the section where each is defined.=20 Answer: When reviewing the draft the IANA indicated that they will use section 8 = as the guide when allocating the AVP code values. In section 8 there is = a summary table listing all new AVP codes defined in this specification=20 including references to appropriate section. Thus, we assume that no=20 additional summary table is required by the IANA. -------------------------------------------------------------------------= - > 12.4 Result-Code AVP Values ditto.=20 ANSWER: When reviewing the draft the IANA indicated that they will use section 9 = as the guide for assiging the Result-Code AVP values. Therefore we assume = that no additional summary table is required by the IANA.=20 -------------------------------------------------------------------------= - > 12.5 CC-Request-Type AVP=20 >=20 > As defined in section 8.3, the CC-Request-Type AVP defines the values=20 > X1-X3 [IANA please fill in X1-X3 (suggested value 1, 3) and remove=20 > this note]. All remaining values are available for assignment via=20 > Designated Expert [IANA].=20 Better:=20 12.5 CC-Request-Type AVP=20 As defined in section 8.3, the CC-Request-Type AVP includes an = Enumerated=20 type value. IANA is to create and maintain a namespace for this=20 AVP. [IANA please fill in X1-X3 (suggested value 1, 3) and remove=20 this note]. All remaining values are available for assignment via=20 Designated Expert [IANA].=20 i.e., make it clear that this is a name space that IANA must create=20 and maintain.=20 Similar comments apply to other subsections.=20 Answer: We will update the specification according to the suggested text. -------------------------------------------------------------------------= - BTW, IANA seemed to have raised similar issues in mail on June 15.=20 Answer: Yes, and therefore we've combined the answer to keep the proposed = updates coordinated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= ------_=_NextPart_001_01C47979.BD5EAF09-- From owner-aaa-wg@merit.edu Tue Aug 3 12:53:42 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21088 for ; Tue, 3 Aug 2004 12:53:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCE6B91266; Tue, 3 Aug 2004 12:52:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F6C691269; Tue, 3 Aug 2004 12:52:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04A0C91266 for ; Tue, 3 Aug 2004 12:51:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E095A5A213; Tue, 3 Aug 2004 12:51:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id F10495A30E for ; Tue, 3 Aug 2004 12:51:57 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73GpvN06224 for ; Tue, 3 Aug 2004 19:51:57 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 19:49:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i73GndFC022874 for ; Tue, 3 Aug 2004 19:49:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00CXy9bZ; Tue, 03 Aug 2004 19:49:39 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73Gncn04510 for ; Tue, 3 Aug 2004 19:49:38 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 19:49:36 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: FW: Diameter Credit Control - IESG Evaluation, Allison Mankin's comments Date: Tue, 3 Aug 2004 19:49:36 +0300 Message-ID: Thread-Topic: Diameter Credit Control - IESG Evaluation, Allison Mankin's comments Thread-Index: AcR5edsWg4KB/vG+RGm1P9u0xXnEtA== From: To: X-OriginalArrivalTime: 03 Aug 2004 16:49:36.0429 (UTC) FILETIME=[DC1FC5D0:01C47979] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Text to clear Allison's DISCUSS, still waiting on response. -------------------------- Hello, thank you for your comments. Please see the answers and proposals for improved text below and let us know whether these corrections and clarifications will address your = concerns. Best Regards, Harri Hakala Leena Mattila Juha-Pekka Koskinen Marco Stura John Loughney ----------------------------------------------------------------- Allison Mankin Discuss: - The Subscription-Id-Type AVPs are a very limited set and do not appear = extensible: what about this application for interoperating pres: uri's or other identifiers in = future? Another case like this is the User-Equipment-Identifier, which allows only 3GPP mobiles and = wireless. This is inappropriate in a general AAA document. Answer: Actually the AVPs are extensible. Both the Subscriptio-Id-Type and the = User-Equipment-Info-Type AVPs are of type enumerated, it is sufficient to define and document new = values to extend the AVPs to cover other needs. Basically we have defined those AVPs also thinking to = extensibility since we cannot cover all the possible identifier that may pop-up in the future. Concerning the User-Equipment-Info AVP, we have defined MAC, EUI64 and = MODIFIED_EUI64 that should cover also a broad range of wired (non-3GPP) terminals. Overall we believe that the AVPs in question are not 3GPP mobiles and = wireless specific, rather generic enough to cover other environments as well. Discuss: - The WG needed to think more broadly about SIP. The SIP example works = as expected in the 3GPP-enforced environment because the proxy can measure the quota, = but in open=20 environments, the proxy at best will see the BYE (and possibly might not = see that). Flow II must state in a careful final paragraph that the degree of credit control = measuring of the media by the proxy depends on the business model design used in setting up the = end system and proxies=20 in the SIP network. Answer: The intention of the flows example is just to illustrate simple examples = for the usage of the DCCA. The purpose of those flows is not to define how SIP work in different = environments, it should perhaps stated that the SIP signaling is inacurate and the focus is on credit = control messages. If a service provider want to offer prepaid services for SIP sessions = based on time usage, it should=20 make sure that all requests within the dialog created by that INVITE = traverse the proxy that provide prepaid services. Otherwise no prepaid services (usage based) can be = offered at all. Here is a proposal for a new text, perhaps you could suggest even more = appropriate text should you disagree with our proposal. New text proposal to be added right after the diagram: This is an example of Diameter Credit Control for SIP sessions. While = the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate = and the diagram is not by any=20 means an attempt to define a service provider's SIP network. However, = for the sake of this example some assumption is made as discussed in the next paragraph. Typically, prepaid services based e.g. on time usage for SIP session = require an entity in the service=20 provider network to intercept all the requests within the SIP dialog in = order to detect events, such as=20 session establishment and session release, which are essential to = perform credit-control operations=20 with the credit control server. It is, therefore, assumed in this = example that the SIP Proxy record-route=20 since the initial INVITE to make sure that all the future requests in = the created dialog traverse through it. Finally, the degree of credit control measuring of the media by the = proxy depends on the business model design used in setting up the end system and proxies in the SIP = network. Discuss: - Flow V and VII need a bigger SIP picture. In V, the INVITE is to B, or = to a B2BUA that is meant to intercept a price inquiry? This is a new SIP service. Flow VII = describes use of a SIP controller, which is probably 3PCC, but that needs to be shown, the call = establishment would need to be shown.=20 Answer: Flow V The INVITE is sent to B. The term SIP controller was taken from the RFC = 3725, not sure whether this term is appropriate here. The intention in this example is that this "SIP controller" just buffer = the INVITE, just as it would do a proxy for an ordinary quota request, until the AoC transaction is = performed. When the user accept the=20 charges the original INVITE is sent forward toward the destination. Again, the intention of the flows example is just to illustrate simple = examples for the usage of the DCCA features. Perhaps similar text as proposed above is also suitable here? New text proposal to be added right after the diagram (Flow V): This is an example of Diameter Credit Control for SIP sessions. While = the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate = and the diagram is not by any=20 means an attempt to define a service provider's SIP network.=20 UA A sends an INVITE with SDP to B (1). Flow VII SIP controller is here 3PCC, again the term was taken from RFC 3725. = Perhaps we could refer to RFC 3725 and mention that best current practices for 3PCC are defined there. Also in this flow we choose to keep the SIP signaling at very high level = since we are not defining SIP in this document, we are just doing high level examples to illustrate = DCCA functionalities. What about this text proposal? Figure A.7 is an example of the graceful service termination for a SIP = call. It is assumed the call is set up=20 so that the controller is in the call as a B2BUA (Back to Back User = Agent) performing third party call control (3PCC). Note that the SIP signaling is inaccurate since the focus of = this flow is in the graceful service=20 termination and credit control authorization, best practices for 3PCC = are defined in [RFC 3725]. We could then add RFC 3725 in the informational references. Discuss: - Recommendation on flows V and VII: Jon and I should email you as to = whether to clean them up, remove them, or annotate them. Answer: OK with us. Please consider the above proposals while making your = decision. From owner-aaa-wg@merit.edu Tue Aug 3 13:00:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21806 for ; Tue, 3 Aug 2004 13:00:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 123AC9126A; Tue, 3 Aug 2004 12:58:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD82091267; Tue, 3 Aug 2004 12:58:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D0EA9125F for ; Tue, 3 Aug 2004 12:58:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 376C45A562; Tue, 3 Aug 2004 12:58:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 31CD55A4DA for ; Tue, 3 Aug 2004 12:58:26 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73GwPN13932 for ; Tue, 3 Aug 2004 19:58:25 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 19:55:47 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i73Gtl31006688 for ; Tue, 3 Aug 2004 19:55:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Teib14; Tue, 03 Aug 2004 19:55:46 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73Gtjn09105 for ; Tue, 3 Aug 2004 19:55:45 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 19:55:46 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: FW: IESG evaluation and IETF Last Calll - Diameter Credit Control - Thomas Narten's DISCUSS Date: Tue, 3 Aug 2004 19:55:46 +0300 Message-ID: Thread-Topic: IESG evaluation and IETF Last Calll - Diameter Credit Control (fwd) Thread-Index: AcRic9DT6im3aCMNR0acY5i5+RzhUQXBp0PA From: To: X-OriginalArrivalTime: 03 Aug 2004 16:55:46.0086 (UTC) FILETIME=[B874F460:01C4797A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable These are Thomas's comments - we will udpate the draft accordingly. Discuss: [2004-06-24] > 12.1 Application Identifier =20 > =20 > This specification assigns the value XXX [IANA please fill in XXX=20 > (suggested value 4) and remove this note] to the Application=20 > Identifier namespace defined in [DIAMBASE]. See section 1.3 for > more information. =20 Please provide the name of the application identifier. > 12.3 AVP Codes =20 > =20 > This specification assigns the values XXX - YYY [IANA please fill = in=20 > XXX, YYY (suggested values 411, 457) and remove this note] from the = > AVP code namespace defined in [DIAMBASE] See section 8 for the=20 > assignment of the namespace in this specification. =20 would be good to include a table with all the needed TBDs, refering to the section where each is defined. > 12.4 Result-Code AVP Values =20 ditto. > 12.5 CC-Request-Type AVP=20 > =20 > As defined in section 8.3, the CC-Request-Type AVP defines the = values=20 > X1-X3 [IANA please fill in X1-X3 (suggested value 1, 3) and remove=20 > this note]. All remaining values are available for assignment via=20 > Designated Expert [IANA].=20 Better: =20 =20 12.5 CC-Request-Type AVP=20 =20 As defined in section 8.3, the CC-Request-Type AVP includes an = Enumerated type value. IANA is to create and maintain a namespace for this AVP. [IANA please fill in X1-X3 (suggested value 1, 3) and remove=20 this note]. All remaining values are available for assignment via=20 Designated Expert [IANA].=20 =20 i.e., make it clear that this is a name space that IANA must create and maintain. Similar comments apply to other subsections. BTW, IANA seemed to have raised similar issues in mail on June 15. -------- From IANA: Date and Time: 2004-06-15, 14:8:59=20 Version: 05=20 Commented by: Michelle Cotton=20 State before Comment: In Last Call=20 State after Comment: In Last Call=20 Comment: IANA Last Call Comments: Section 12.1 The name of the application identifier to be assigned should be included in this section. Sction 12.2 The name of the command code to be assigned should be included in this section. Section 12.3 We will use section 8 as the guide for assigning AVP Codes (total values =3D 50) Section 12.4 We will use section 9 as the guide for assigning Result-Code AVP Values (total values =3D 5). Sections 12.5-12.18 We will create sub-registries for AVP Specific Values=20 From owner-aaa-wg@merit.edu Fri Aug 6 06:53:57 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18890 for ; Fri, 6 Aug 2004 06:53:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0286191227; Fri, 6 Aug 2004 06:53:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C097B91228; Fri, 6 Aug 2004 06:53:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E13D191227 for ; Fri, 6 Aug 2004 06:53:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF5605A83F; Fri, 6 Aug 2004 06:53:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 4B6EF5A6F9 for ; Fri, 6 Aug 2004 06:53:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i76AncG31317 for ; Fri, 6 Aug 2004 03:49:38 -0700 Date: Fri, 6 Aug 2004 03:49:38 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Presentations from IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk are available at: http://www.drizzle.com/~aboba/IETF60/aaa/ From owner-aaa-wg@merit.edu Fri Aug 6 10:47:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01953 for ; Fri, 6 Aug 2004 10:47:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B7389122F; Fri, 6 Aug 2004 10:47:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0515991231; Fri, 6 Aug 2004 10:47:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93DCD9122F for ; Fri, 6 Aug 2004 10:47:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 743A45A313; Fri, 6 Aug 2004 10:47:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 1B6865A2EA for ; Fri, 6 Aug 2004 10:47:17 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i76Eiv608716; Fri, 6 Aug 2004 17:44:57 +0300 (EET DST) X-Scanned: Fri, 6 Aug 2004 17:41:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i76EfwD5030637; Fri, 6 Aug 2004 17:41:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00qCs9sb; Fri, 06 Aug 2004 17:41:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i76Efuu18089; Fri, 6 Aug 2004 17:41:56 +0300 (EET DST) Received: from nokia.com ([10.162.15.128]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 Aug 2004 17:41:15 +0300 Message-ID: <41138A9A.2040903@nokia.com> Date: Fri, 06 Aug 2004 16:41:46 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: radiusext@ops.ietf.org, AAA mailing list , baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, "Beck01, Wolfgang" Cc: Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: [AAA-WG]: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-app-03 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2004 14:41:15.0411 (UTC) FILETIME=[6D32EE30:01C47BC3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: My apologies for the crossposting. I read draft-sterman-aaa-sip-03 and I have some comments to both the draft itself and the Diameter SIP application. The authors of both drafts are copied as well. First, I think that in general, both drafts are aligned. This is good news, since there is not need for a lot of rework. Here are some comments though: 1) Abstract: The abstract looks more like an introduction to me, providing a motivation for this work. I think the abstract should just indicate what this document provides, rather than a historical description of the capabilities of RADIUS, SIP and HTTP. I would suggest a text around this lines: "This document specifies an extension to RADIUS that allows a RADIUS client in a SIP/HTTP server, upon reception of a SIP/HTTP request, retrieve and compute Digest authentication information from a RADIUS server. Additionally, a scenario describing the authentication of a user emiting a SIP/HTTP request is provided." 2) Attributes/AVP: I am happy to see that we both drafts are aligned with the attributes/AVP names and semantics. But on reading draft-sterman I found suggestions for the Diameter SIP app. In Diameter SIP app we had a conflict with the duplication of information. For instance, we use the User-Name AVP as well as Digest-Username AVP. We don't have, though, a Digest-Method AVP, since we have a SIP-Method AVP that does the same. I think this is wrong, and I propose to add a Digest-Method AVP to the Diameter SIP app. The idea is: Digest-xxx AVPs are used to compute the Digest authentication, wherease SIP-Method or User-Name are used to authorize the user to proceed with a particular request. This adds a duplication of information, but on the other hand, it provides a clear split between Digest authentication and authorization of a request. If I found no objections, next version of Diameter SIP app will include a new Digest-Method AVP. 3) draft-sterman defines a Digest-Body attribute. But actually, the attribute will not contain a body, but the hash of a body. I would suggest to rename this attribute to Digest-Entity-Body-Hash. It happens that this is the name of the same AVP in Diamter SIP app. 4) I noticed that draft-sterman does not specified a Digest-Nextnonce attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. While the mechanism probably works, I would suggest to define a new Digest-Nextnonce attribute in draft-sterman, since the semantics of Nonce and Nextnonce are completely different, so they are sent in different parameters in the Digest header. Is this acceptable? 5) Similar to #4 above, I noticed that draft-sterman defines a Digest-Response that presumably is used to map it to both "response" and "rspauth" in Digest. As in #4, the semantics of both Digest parameters are different, so the attributes should be. In Diameter SIP app. we define Digest-Response and Digest-Response-Auth AVPs. I would suggest that draft-sterman splits Digest-Response similarly. Is this acceptable? 6) Question of documentation. I noticed that all the attribute descriptions in draft-sterman include a figure containing the position of Type, Length and String. I wonder if it is needed to repeat the figure in all the attribute descriptions or whether you can indicate in a general paragraph the commonality shared by all the attributes (among others, the structure represented in those figures). 7) Section 2.1 in draft-sterman. The definition of Type says: Type DIG-RES for Digest-Response. Early implementations have used the experimental type 206. I would suggest to remove the last sentence. It is not relevant for this document the value an early implementation has used or not. What is important is the value assigned by IANA. 8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter SIP app are not synchronized with the possible values of this attribute. Draft-sterman indicates that if Digest-Stale is present, its value will always be set to "1". This will be mapped to the stale="true" parameter in Digest. I understan that if Digest-Stale is not present, then the RADIUS client should assume that stale="false" or simple not present in Digest Diameter SIP app. maps strictly the contents of the "stale" parameter in Digest, meaning that the contents can be "true" or "false" (we actually refer to RFC 2617). I like more the approach taken by Diameter SIP app. There is no assumptions (as if the attribute is not present, it means stale="false"). And I found it more future proof, in case someone defines an extension with more values of stale (unlikely though, but this is not a justification). My proposal is that draft-sterman aligns with Diameter SIP app and the value of the Digest-Stale AVP includes a quoted string that is straight forward mapped to the stale parameter in Digest. Is this acceptable? 9) Section 4, migration path to Diameter: Digest-URI First a typo: s/DIAMETER/Diameter We should synchronize the name of Digest-URI AVP. Diameter SIP app calls it Digest-Digest-URI. The reason is that the first "Digest-" refers to the prefix used for all those Digest AVPs. The second "Digest" refers to the name of the Digest direction, which is called "digest-uri". It is not so important, so I am willing to change the name in Diameter SIP app to Digest-URI. Proposal: I will change the name of Digest-Digest-URI to Digest-URI. There is no action to draft-sterman. 10) Section 4: This section will need an update after the discussion in this e-mail. Some other typos I found: - Remove all the "AVP" instances - s/SIP-Entity-Body-Hash/Digest-Entity-Body-Hash You can also see how ugly is to overload an existing attribute when the semantics of the request difer from the semantics of the response. See the Digest-Response attribute The "Access-Request Digest-Response" attribute should be mapped to the "Digest-Response" in Diameter SIP app. The "Access-Accept Digest-Response" attribute should be mapped to the "Digest-Response-Auth" in Diameter SIP app. Note that table 2 will become obsolete when we add the proposed changes in this e-mail. However the contents of the table should move to table 1 with the appropriate values. In general, I found that this section 4 has to be rewritten once we agree on the proposals in this e-mail. It would become easier to map both documents now. 11) Section 5: I would expect that this section starts with the following sentence: "This document serves as IANA registration request for ..." Particularly, I would remove the dependency on becoming a working group (item) or IESG document. 12) Examples in Section 7: This one was a shock to me. It violates all the rules of writing RFCs. For instance, it does not use the IP address space suggested for examples, it does not use the example.com domain name. The SIP examples luck a few mandatory headers (e.g., Max-Forwards), contains the name of commertial products, contains undocumented extensions to SDP, misses recommendations of populating several SIP headers and SDP lines... If you want to continue in this path, I may suggest that an expert reviewer assigned by the transport AD should inspect this examples. I have a better suggestion: at the end of the day, this draft is about Digest and RADIUS. So why don't you focus on Digest and RADIUS in the examples? create some sort of abstract SIP/HTTP request, and just write down the Digest headers, but not the whole SIP message. This is all for the time being. Thanks a lot, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Aug 9 03:27:29 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10038 for ; Mon, 9 Aug 2004 03:27:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5813C91201; Mon, 9 Aug 2004 03:27:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BCC491203; Mon, 9 Aug 2004 03:27:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2C3591201 for ; Mon, 9 Aug 2004 03:27:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABAD35A859; Mon, 9 Aug 2004 03:27:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id E34D15A67B for ; Mon, 9 Aug 2004 03:27:11 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 9 Aug 2004 09:27:07 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Aug 2004 09:27:07 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD5F@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com, radiusext@ops.ietf.org, aaa-wg@merit.edu, baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com Cc: maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03 Date: Mon, 9 Aug 2004 09:27:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, > 1) Abstract: The abstract looks more like an introduction to me, > providing a motivation for this work. I think the abstract should just > indicate what this document provides, rather than a historical > description of the capabilities of RADIUS, SIP and HTTP. I would suggest > a text around this lines: > > "This document specifies an extension to RADIUS that allows a RADIUS > client in a SIP/HTTP server, upon reception of a SIP/HTTP request, > retrieve and compute Digest authentication information from a RADIUS > server. Additionally, a scenario describing the authentication of a > user emiting a SIP/HTTP request is provided." Thank you for this proposal. > 3) draft-sterman defines a Digest-Body attribute. But actually, the > attribute will not contain a body, but the hash of a body. I would > suggest to rename this attribute to Digest-Entity-Body-Hash. It happens > that this is the name of the same AVP in Diamter SIP app. Digest-Body-Digest looked a bit strange to me and Digest-Entity-Body-Hash a bit long. But I've no problem changing it. > 4) I noticed that draft-sterman does not specified a Digest-Nextnonce > attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It > seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. > While the mechanism probably works, I would suggest to define a new > Digest-Nextnonce attribute in draft-sterman, since the semantics of > Nonce and Nextnonce are completely different, so they are sent in > different parameters in the Digest header. Is this acceptable? > > 5) Similar to #4 above, I noticed that draft-sterman defines a > Digest-Response that presumably is used to map it to both "response" and > "rspauth" in Digest. As in #4, the semantics of both Digest parameters > are different, so the attributes should be. In Diameter SIP app. we > define Digest-Response and Digest-Response-Auth AVPs. I would suggest > that draft-sterman splits Digest-Response similarly. Is this acceptable? After converting the draft to flat attributes, I tried to save attribute space. It is a scarce resource in RADIUS. > 6) Question of documentation. I noticed that all the attribute > descriptions in draft-sterman include a figure containing the position > of Type, Length and String. I wonder if it is needed to repeat the > figure in all the attribute descriptions or whether you can indicate in > a general paragraph the commonality shared by all the attributes (among > others, the structure represented in those figures). OK. > 7) Section 2.1 in draft-sterman. The definition of Type says: > Type > DIG-RES for Digest-Response. Early implementations have used > the experimental type 206. > > I would suggest to remove the last sentence. It is not relevant for > this document the value an early implementation has used or not. What is > important is the value assigned by IANA. OK. > 8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter > SIP app are not synchronized with the possible values of this attribute. > > Draft-sterman indicates that if Digest-Stale is present, its value will > always be set to "1". This will be mapped to the stale="true" parameter > in Digest. I understan that if Digest-Stale is not present, then the > RADIUS client should assume that stale="false" or simple not present in > Digest > [..] > My proposal is that draft-sterman aligns with Diameter SIP app and the > value of the Digest-Stale AVP includes a quoted string that is straight > forward mapped to the stale parameter in Digest. Is this acceptable? Yes. > In general, I found that this section 4 has to be rewritten once we > agree on the proposals in this e-mail. It would become easier to map > both documents now. There will be some more changes as I will use Access-Challenge in the next version of the draft. > 11) Section 5: > > I would expect that this section starts with the following sentence: > > "This document serves as IANA registration request for ..." > > Particularly, I would remove the dependency on becoming a working group > (item) or IESG document. OK. > 12) Examples in Section 7: > > This one was a shock to me. It violates all the rules of writing RFCs. > For instance, it does not use the IP address space suggested for > examples, it does not use the example.com domain name. > > The SIP examples luck a few mandatory headers (e.g., Max-Forwards), > contains the name of commertial products, contains undocumented > extensions to SDP, misses recommendations of populating several SIP > headers and SDP lines... > > If you want to continue in this path, I may suggest that an expert > reviewer assigned by the transport AD should inspect this examples. > > I have a better suggestion: at the end of the day, this draft is about > Digest and RADIUS. So why don't you focus on Digest and RADIUS in the > examples? create some sort of abstract SIP/HTTP request, and just write > down the Digest headers, but not the whole SIP message. To be honest, I took the examples without much review from the -00 version which was based on RfC 2543. Thank you for this detailed review, Wolfgang -- Wolfgang Beck T-Systems Internet Netzplattformen +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt From owner-aaa-wg@merit.edu Mon Aug 9 04:20:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12229 for ; Mon, 9 Aug 2004 04:20:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BEBC91201; Mon, 9 Aug 2004 04:20:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9A1891203; Mon, 9 Aug 2004 04:20:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E72E91201 for ; Mon, 9 Aug 2004 04:20:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5813D5A8D4; Mon, 9 Aug 2004 04:20:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 3C4A85A928 for ; Mon, 9 Aug 2004 04:20:29 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i798IXj25615; Mon, 9 Aug 2004 11:18:33 +0300 (EET DST) X-Scanned: Mon, 9 Aug 2004 11:16:38 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i798Gc2H030028; Mon, 9 Aug 2004 11:16:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ctCgmH; Mon, 09 Aug 2004 11:16:36 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i798GSn18444; Mon, 9 Aug 2004 11:16:29 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Aug 2004 11:16:26 +0300 Message-ID: <411732DA.4030406@nokia.com> Date: Mon, 09 Aug 2004 11:16:26 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu, baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: [AAA-WG]: Re: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03 References: <76C27E1CE3FFC847B4D51C645D6F42AA15FD5F@E9JDF.mgb01.telekom.de> In-Reply-To: <76C27E1CE3FFC847B4D51C645D6F42AA15FD5F@E9JDF.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2004 08:16:27.0005 (UTC) FILETIME=[2AAD02D0:01C47DE9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Wolfgang: It is nice to see that we are agreeing on most issues. Since I understand that issues 4 and 5 (see discussion below) will remain as they are, I think it would be benefitial to include a discussion of the reasons why the RADIUS extension for SIP went for that approach. I would say that the section that discusses the compatibility with Diameter SIP application is the candidate to include such discussion. Can you also elaborate a bit more of what is "Access-Challenge" that will be part of the next version? Last, but not least, I will be posting a working version of the Diameter SIP app. as soon as it is ready. Regards, Miguel Beck01, Wolfgang wrote: > Miguel, > > >>1) Abstract: The abstract looks more like an introduction to me, >>providing a motivation for this work. I think the abstract should just >>indicate what this document provides, rather than a historical >>description of the capabilities of RADIUS, SIP and HTTP. I would suggest >>a text around this lines: >> >>"This document specifies an extension to RADIUS that allows a RADIUS >>client in a SIP/HTTP server, upon reception of a SIP/HTTP request, >>retrieve and compute Digest authentication information from a RADIUS >>server. Additionally, a scenario describing the authentication of a >>user emiting a SIP/HTTP request is provided." > > Thank you for this proposal. > > >>3) draft-sterman defines a Digest-Body attribute. But actually, the >>attribute will not contain a body, but the hash of a body. I would >>suggest to rename this attribute to Digest-Entity-Body-Hash. It happens >>that this is the name of the same AVP in Diamter SIP app. > > Digest-Body-Digest looked a bit strange to me and Digest-Entity-Body-Hash > a bit long. But I've no problem changing it. > > >>4) I noticed that draft-sterman does not specified a Digest-Nextnonce >>attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It >>seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. >>While the mechanism probably works, I would suggest to define a new >>Digest-Nextnonce attribute in draft-sterman, since the semantics of >>Nonce and Nextnonce are completely different, so they are sent in >>different parameters in the Digest header. Is this acceptable? >> >>5) Similar to #4 above, I noticed that draft-sterman defines a >>Digest-Response that presumably is used to map it to both "response" and >>"rspauth" in Digest. As in #4, the semantics of both Digest parameters >>are different, so the attributes should be. In Diameter SIP app. we >>define Digest-Response and Digest-Response-Auth AVPs. I would suggest >>that draft-sterman splits Digest-Response similarly. Is this acceptable? > > After converting the draft to flat attributes, I tried to save attribute > space. It is a scarce resource in RADIUS. > > >>6) Question of documentation. I noticed that all the attribute >>descriptions in draft-sterman include a figure containing the position >>of Type, Length and String. I wonder if it is needed to repeat the >>figure in all the attribute descriptions or whether you can indicate in >>a general paragraph the commonality shared by all the attributes (among >>others, the structure represented in those figures). > > OK. > > >>7) Section 2.1 in draft-sterman. The definition of Type says: >> Type >> DIG-RES for Digest-Response. Early implementations have used >> the experimental type 206. >> >> I would suggest to remove the last sentence. It is not relevant for >>this document the value an early implementation has used or not. What is >>important is the value assigned by IANA. > > OK. > > >>8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter >>SIP app are not synchronized with the possible values of this attribute. >> >>Draft-sterman indicates that if Digest-Stale is present, its value will >>always be set to "1". This will be mapped to the stale="true" parameter >>in Digest. I understan that if Digest-Stale is not present, then the >>RADIUS client should assume that stale="false" or simple not present in >>Digest >>[..] >>My proposal is that draft-sterman aligns with Diameter SIP app and the >>value of the Digest-Stale AVP includes a quoted string that is straight >>forward mapped to the stale parameter in Digest. Is this acceptable? > > Yes. > > >>In general, I found that this section 4 has to be rewritten once we >>agree on the proposals in this e-mail. It would become easier to map >>both documents now. > > There will be some more changes as I will use Access-Challenge in the next > version of the draft. > > >>11) Section 5: >> >>I would expect that this section starts with the following sentence: >> >>"This document serves as IANA registration request for ..." >> >>Particularly, I would remove the dependency on becoming a working group >>(item) or IESG document. > > OK. > > >>12) Examples in Section 7: >> >>This one was a shock to me. It violates all the rules of writing RFCs. >>For instance, it does not use the IP address space suggested for >>examples, it does not use the example.com domain name. >> >>The SIP examples luck a few mandatory headers (e.g., Max-Forwards), >>contains the name of commertial products, contains undocumented >>extensions to SDP, misses recommendations of populating several SIP >>headers and SDP lines... >> >>If you want to continue in this path, I may suggest that an expert >>reviewer assigned by the transport AD should inspect this examples. >> >>I have a better suggestion: at the end of the day, this draft is about >>Digest and RADIUS. So why don't you focus on Digest and RADIUS in the >>examples? create some sort of abstract SIP/HTTP request, and just write >>down the Digest headers, but not the whole SIP message. > > To be honest, I took the examples without much review from the -00 version > which was based on RfC 2543. > > Thank you for this detailed review, > > Wolfgang > > -- > Wolfgang Beck > T-Systems > Internet Netzplattformen > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Aug 12 08:11:07 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26685 for ; Thu, 12 Aug 2004 08:11:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B1E4912A8; Thu, 12 Aug 2004 08:07:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 124FF91280; Thu, 12 Aug 2004 08:07:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 377F6912AE for ; Thu, 12 Aug 2004 08:07:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 230D65A90E; Thu, 12 Aug 2004 08:07:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 1FD045A989 for ; Thu, 12 Aug 2004 08:07:45 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CC7h324981 for ; Thu, 12 Aug 2004 15:07:43 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 15:02:47 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7CC2lD7020130 for ; Thu, 12 Aug 2004 15:02:47 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00RvyuJE; Thu, 12 Aug 2004 15:02:45 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CC2eu10290 for ; Thu, 12 Aug 2004 15:02:40 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 15:02:33 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Small nits for NASREQ author's 48 hours Date: Thu, 12 Aug 2004 15:02:31 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C151@esebe023.ntc.nokia.com> Thread-Topic: Small nits for NASREQ author's 48 hours Thread-Index: AcSAZD9PWCu1F0TTQ02IaFLHIbhpeA== From: To: X-OriginalArrivalTime: 12 Aug 2004 12:02:33.0061 (UTC) FILETIME=[3FEA2150:01C48064] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 12, 2004 Document: NASREQ-17 Comment type: Editorial Priority: 2 Section: 6.4 and 3.2 Rationale/Explanation of issue: One of the issues left for Diameter EAP was to sync the ABNFs and AVP occurrence tables with the latest NASREQ version. When doing this, I noticed two small inconsistencies (which could be handled in author's 48 hours). 1)=20 ABNF and AVP occurrence tables say Idle-Timeout AVP is not allowed in AAR. This was changed between -11 and -12 (issue 404). However, the text in Section 6.4 still says it may be=20 used as a hint in AAR. Proposal: Remove the sentence "It MAY be used in an authentication and/or authorization request (or challenge) as a hint to the server that an idle timeout is desired, but the server is not required to honor the hint in the corresponding response." 2)=20 AVP occurrence table says AAA can contain 0-1 Multi-Round- Time-Out AVP, but it's not listed in ABNF. =20 Proposal: Add it to AA-Answer ABNF in Section 3.2. Best regards, Pasi From owner-aaa-wg@merit.edu Thu Aug 12 12:34:39 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13218 for ; Thu, 12 Aug 2004 12:34:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 391EC91265; Thu, 12 Aug 2004 12:34:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0294591267; Thu, 12 Aug 2004 12:34:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C039391265 for ; Thu, 12 Aug 2004 12:34:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A897D5A85B; Thu, 12 Aug 2004 12:34:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id D620C5A78A for ; Thu, 12 Aug 2004 12:34:20 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CGYIv27809 for ; Thu, 12 Aug 2004 19:34:19 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 19:30:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7CGUOpg004060 for ; Thu, 12 Aug 2004 19:30:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00J79T74; Thu, 12 Aug 2004 19:30:21 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CGULu22375 for ; Thu, 12 Aug 2004 19:30:21 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 19:30:21 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Diameter EAP -09 Date: Thu, 12 Aug 2004 19:30:21 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3BB3@esebe023.ntc.nokia.com> Thread-Topic: Diameter EAP -09 Thread-Index: AcSAianPuaA/aQpWSCmH7a7dzfhaUA== From: To: X-OriginalArrivalTime: 12 Aug 2004 16:30:21.0727 (UTC) FILETIME=[A995FAF0:01C48089] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Version -09 should appear in the I-D repository soon. This version handles the issues from 2nd WGLC. Chairs, time for IESG review & IETF last call? - Updated ABNFs and AVP occurrence tables to match NASREQ -17=20 (issue 466): Removed Session-Timeout, Idle-Timeout, Class and=20 Failed-AVP from DER (and reordered ABNF to match NASREQ).=20 Added Failed-AVP and QoS-Filter-Rule to DEA. - Clarified that EAP-Key-Name in DER must be empty (issue 465). HTML diff is available from the usual place: http://www.cs.hut.fi/~peronen/eap/diameter_eap.html Best regards, Pasi From owner-aaa-wg@merit.edu Fri Aug 13 08:29:18 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11102 for ; Fri, 13 Aug 2004 08:29:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86292912B2; Fri, 13 Aug 2004 08:29:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 598CE912B3; Fri, 13 Aug 2004 08:29:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DA5B912B2 for ; Fri, 13 Aug 2004 08:29:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20B875AAA4; Fri, 13 Aug 2004 08:29:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 473E45AA94 for ; Fri, 13 Aug 2004 08:29:03 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DCT1v16881 for ; Fri, 13 Aug 2004 15:29:01 +0300 (EET DST) X-Scanned: Fri, 13 Aug 2004 15:26:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7DCQESs028344 for ; Fri, 13 Aug 2004 15:26:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00fn2EsY; Fri, 13 Aug 2004 15:26:11 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DCQBu09828 for ; Fri, 13 Aug 2004 15:26:11 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 13 Aug 2004 15:25:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Diameter Credit Control 06 Date: Fri, 13 Aug 2004 15:25:53 +0300 Message-ID: Thread-Topic: Diameter EAP -09 Thread-Index: AcSAianPuaA/aQpWSCmH7a7dzfhaUAApfBVQ From: To: X-OriginalArrivalTime: 13 Aug 2004 12:25:54.0540 (UTC) FILETIME=[ADAC9AC0:01C48130] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Version -06 should be in the I-D repository soon. This version addresses the IESG DISCUSS documents, so hopefully the document=20 will be ready to ship. Until it is announce, a copy can be found here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-cc-06.txt John From owner-aaa-wg@merit.edu Tue Aug 17 09:32:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14233 for ; Tue, 17 Aug 2004 09:32:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2ADF4912EE; Tue, 17 Aug 2004 09:31:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5950912ED; Tue, 17 Aug 2004 09:31:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35C7491266 for ; Tue, 17 Aug 2004 09:31:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 185A95AB35; Tue, 17 Aug 2004 09:31:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3E2B25AAC1 for ; Tue, 17 Aug 2004 09:31:47 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDVSB22148; Tue, 17 Aug 2004 16:31:31 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 16:17:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7HDHqbr006740; Tue, 17 Aug 2004 16:17:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00JnWM5e; Tue, 17 Aug 2004 16:17:50 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDHhn25598; Tue, 17 Aug 2004 16:17:43 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 16:17:38 +0300 Message-ID: <41220572.50802@nokia.com> Date: Tue, 17 Aug 2004 16:17:38 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: AAA mailing list Cc: Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: [AAA-WG]: Authentication-Info in Diameter SIP app Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2004 13:17:38.0526 (UTC) FILETIME=[917247E0:01C4845C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks: We are still trying to make sure that we provide full support for the HTTP Digest Authentication-Info header in the Diameter SIP application. I believe there has been a number of issues raised lately, and I am trying to study them and provide solutions. I have open 4 open issues in the Diameter SIP app open issues tracker, those are issues allocated with ID number: 14, 15, 16 and 17. I certainly welcome HTTP Digest expertise to make sure that we are not making a mistake. We have to support two different scenarios, one where the whole authentication is done at the Diameter server; the other where the Diameter server delegates authentication to the SIP server (just keep in mind). So please study the issues and provide comments. The Diameter SIP app. open issues lists is stored at: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue?:columns=title,category,id,creation,creator,priority,status,assignedto&:sort=priority&:group=document&:pagesize=50&:startwith=0 Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Aug 18 02:48:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13092 for ; Wed, 18 Aug 2004 02:48:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7486E912C3; Wed, 18 Aug 2004 02:46:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45D9B912CA; Wed, 18 Aug 2004 02:46:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D21C4912C3 for ; Wed, 18 Aug 2004 02:46:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36AEF5A77E; Wed, 18 Aug 2004 02:46:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 00AE35A8F0 for ; Wed, 18 Aug 2004 02:46:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7I6f7322498 for ; Tue, 17 Aug 2004 23:41:07 -0700 Date: Tue, 17 Aug 2004 23:41:07 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: RADEXT WG last call on RFC 2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a reminder of RADEXT WG Last Call in progress on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Wed Aug 18 02:53:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13383 for ; Wed, 18 Aug 2004 02:53:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC58E912D4; Wed, 18 Aug 2004 02:46:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B57E5912F5; Wed, 18 Aug 2004 02:46:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E4B4912D4 for ; Wed, 18 Aug 2004 02:46:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1BB105A972; Wed, 18 Aug 2004 02:46:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 996E45A8E6 for ; Wed, 18 Aug 2004 02:46:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7I6fag22530 for ; Tue, 17 Aug 2004 23:41:36 -0700 Date: Tue, 17 Aug 2004 23:41:36 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a reminder of the ongoing RADEXT WG Last Call on the "RADIUS Extension for Digest Authentication" specification, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Wed Aug 18 02:55:18 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13588 for ; Wed, 18 Aug 2004 02:55:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F83A91315; Wed, 18 Aug 2004 02:54:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF26B91344; Wed, 18 Aug 2004 02:54:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 028739136E for ; Wed, 18 Aug 2004 02:54:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D432D5AE75; Wed, 18 Aug 2004 02:54:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 3F5845AEB6 for ; Wed, 18 Aug 2004 02:54:28 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I6sMj28497 for ; Wed, 18 Aug 2004 09:54:22 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 09:49:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7I6nU1A027896 for ; Wed, 18 Aug 2004 09:49:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00BIoUhe; Wed, 18 Aug 2004 09:49:29 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I6nOu29156 for ; Wed, 18 Aug 2004 09:49:24 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 09:49:05 +0300 Message-ID: <4122FBE0.5050709@nokia.com> Date: Wed, 18 Aug 2004 09:49:04 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: AAA mailing list Subject: [AAA-WG]: AAA URI draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2004 06:49:05.0136 (UTC) FILETIME=[73FF0700:01C484EF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: During the presentation of the AAA URI draft (http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt) I made in San Diego, I indicated that I will submit the document for revision to the URI-review list in the IETF. I did it, I sent the draft to the list, and surprise surprise I got no comments at all. I wonder if the draft is so perfect... Anyway, the WG LC of the AAA URI draft ends today, and we got no comments. The only issue that came to my mind is that the Generic URI syntax, RFC 2396 has been reviewed this days, and it is currently in IETF Last Call (http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt) heading to full standard. This document will (if approved) obsolete RFC 2396 and RFC 2732, both of them normative dependencies in AAA URI. My concern is whether we should analyze the differences between RFC 2396 and 2396bis, and create a dependency on the bis document. Comments? Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Aug 18 02:57:56 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13748 for ; Wed, 18 Aug 2004 02:57:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13DB69126F; Wed, 18 Aug 2004 02:57:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D10B091273; Wed, 18 Aug 2004 02:57:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CEB59126F for ; Wed, 18 Aug 2004 02:57:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19A6F5AE99; Wed, 18 Aug 2004 02:57:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 86F695AD8F for ; Wed, 18 Aug 2004 02:57:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7I6qLe23258; Tue, 17 Aug 2004 23:52:21 -0700 Date: Tue, 17 Aug 2004 23:52:21 -0700 (PDT) From: Bernard Aboba To: Miguel Garcia Cc: AAA mailing list Subject: Re: [AAA-WG]: AAA URI draft In-Reply-To: <4122FBE0.5050709@nokia.com> Message-ID: References: <4122FBE0.5050709@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk My understanding is that the primary changes in the URI spec relate to internationalization. Don't these changes apply to the AAA URI as well? If so, then I think a normative dependency may be unavoidable. On Wed, 18 Aug 2004, Miguel Garcia wrote: > Hi: > > During the presentation of the AAA URI draft > (http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt) I made > in San Diego, I indicated that I will submit the document for revision > to the URI-review list in the IETF. I did it, I sent the draft to the > list, and surprise surprise I got no comments at all. I wonder if the > draft is so perfect... > > Anyway, the WG LC of the AAA URI draft ends today, and we got no > comments. The only issue that came to my mind is that the Generic URI > syntax, RFC 2396 has been reviewed this days, and it is currently in > IETF Last Call > (http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt) > heading to full standard. This document will (if approved) obsolete RFC > 2396 and RFC 2732, both of them normative dependencies in AAA URI. > > My concern is whether we should analyze the differences between RFC 2396 > and 2396bis, and create a dependency on the bis document. Comments? > > Regards, > > Miguel > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > From owner-aaa-wg@merit.edu Wed Aug 18 03:51:57 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15969 for ; Wed, 18 Aug 2004 03:51:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 703C991273; Wed, 18 Aug 2004 03:51:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41C9F91275; Wed, 18 Aug 2004 03:51:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A612191273 for ; Wed, 18 Aug 2004 03:51:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 814225AF5D; Wed, 18 Aug 2004 03:51:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B40575AE2E for ; Wed, 18 Aug 2004 03:51:44 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I7pfB29366; Wed, 18 Aug 2004 10:51:41 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 10:45:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7I7jYa3014681; Wed, 18 Aug 2004 10:45:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006NvxKG; Wed, 18 Aug 2004 10:45:17 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I7L0n10482; Wed, 18 Aug 2004 10:21:00 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 10:20:51 +0300 Message-ID: <41230353.4090902@nokia.com> Date: Wed, 18 Aug 2004 10:20:51 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Bernard Aboba Cc: AAA mailing list Subject: Re: [AAA-WG]: AAA URI draft References: <4122FBE0.5050709@nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2004 07:20:51.0185 (UTC) FILETIME=[E4170610:01C484F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Right, I also sympathize with the idea of making the AAA URI dependent on a full standard document. I will, therefore, analyze the difference between 2396 and 2396bis and create a new version of AAA URI that depends on 2396bis. Regards, Miguel Bernard Aboba wrote: > My understanding is that the primary changes in the URI spec > relate to internationalization. Don't these changes apply to the AAA URI > as well? If so, then I think a normative dependency may be unavoidable. > > On Wed, 18 Aug 2004, Miguel Garcia wrote: > > >>Hi: >> >>During the presentation of the AAA URI draft >>(http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt) I made >>in San Diego, I indicated that I will submit the document for revision >>to the URI-review list in the IETF. I did it, I sent the draft to the >>list, and surprise surprise I got no comments at all. I wonder if the >>draft is so perfect... >> >>Anyway, the WG LC of the AAA URI draft ends today, and we got no >>comments. The only issue that came to my mind is that the Generic URI >>syntax, RFC 2396 has been reviewed this days, and it is currently in >>IETF Last Call >>(http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt) >>heading to full standard. This document will (if approved) obsolete RFC >>2396 and RFC 2732, both of them normative dependencies in AAA URI. >> >>My concern is whether we should analyze the differences between RFC 2396 >>and 2396bis, and create a dependency on the bis document. Comments? >> >>Regards, >> >> Miguel >> >> >>-- >>Miguel A. Garcia tel:+358-50-4804586 >>Nokia Research Center Helsinki, Finland >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Aug 18 11:20:20 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12822 for ; Wed, 18 Aug 2004 11:20:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE14F91229; Wed, 18 Aug 2004 11:20:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89ADF91273; Wed, 18 Aug 2004 11:20:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3088F91229 for ; Wed, 18 Aug 2004 11:20:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C1B15AC39; Wed, 18 Aug 2004 11:20:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id A60A55A99F for ; Wed, 18 Aug 2004 11:20:06 -0400 (EDT) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7IFK49q011574 for ; Wed, 18 Aug 2004 10:20:05 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 11:20:04 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D714F8704E@oh0012itsa1.cb.lucent.com> From: "Wang, Yile Enoch (Enoch)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Multiple outstanding CCRs within one credit control session Date: Wed, 18 Aug 2004 11:20:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48536.D5E2EDE6" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C48536.D5E2EDE6 Content-Type: text/plain Dear charging colleagues, IETF Credit Control Application (up to rev 06) client state machine prohibits client from further sending out CCR at PendingU state. Is this view changed after MSCC is introduced? In another word, can a client send out CCRs for different services simultaneously? If this is relaxed, we need to revise related sections of the draft, e.g., state machine, CC-Request-Number, Tx timer, etc. Thanks, Enoch Y. Wang Lucent Technologies O Bell Labs Innovations Intelligent Network Unit Tier 1 Systems Engineer 2J-328 101 Crawfords Corner Rd Holmdel, NJ 07733 Tel: (732) 332-6687 Fax: (732) 332-6687 E-mail: ewang@lucent.com ------_=_NextPart_001_01C48536.D5E2EDE6 Content-Type: text/html Message
Dear charging colleagues,
 
IETF Credit Control Application (up to rev 06) client state machine prohibits client from further sending out CCR at PendingU state.  Is this view changed after MSCC is introduced?  In another word, can a client send out CCRs for different services simultaneously?  If this is relaxed, we need to revise related sections of the draft, e.g., state machine, CC-Request-Number, Tx timer, etc.
 
Thanks,

Enoch Y. Wang
Lucent Technologies O 
Bell Labs Innovations
Intelligent Network Unit
Tier 1 Systems Engineer
2J-328
101 Crawfords Corner Rd
Holmdel, NJ 07733
Tel:      (732) 332-6687
Fax:      (732) 332-6687
E-mail: ewang@lucent.com

 
------_=_NextPart_001_01C48536.D5E2EDE6-- From owner-aaa-wg@merit.edu Wed Aug 18 11:36:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14434 for ; Wed, 18 Aug 2004 11:36:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 797679127F; Wed, 18 Aug 2004 11:36:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4912991280; Wed, 18 Aug 2004 11:36:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFF559127F for ; Wed, 18 Aug 2004 11:36:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C48615ADEF; Wed, 18 Aug 2004 11:36:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id A81A95AAD6 for ; Wed, 18 Aug 2004 11:36:19 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i7IFaIx1025869 for ; Wed, 18 Aug 2004 17:36:18 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Aug 2004 17:36:13 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48539.17C6683F" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: Multiple outstanding CCRs within one credit control session Date: Wed, 18 Aug 2004 17:36:13 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906406255@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: Multiple outstanding CCRs within one credit control session Thread-Index: AcSFNt69YhA1NiQsRouYFE6HXAJSvwAALOFg From: "STURA Marco Consultant" To: "Wang, Yile Enoch (Enoch)" Cc: X-OriginalArrivalTime: 18 Aug 2004 15:36:13.0341 (UTC) FILETIME=[17E01CD0:01C48539] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C48539.17C6683F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The state machine is meant to document only mandatory features, the MSCC is optional. Moreover, recommendations how to implement the MSCC with the described state machine are given in sect. 5.1.2 in the last two paragraph, there is no need for revisions. =20 Note that the documented approach has been accepted by the AAA working group a while ago (the document has passed couple=20 of WGLC, IETF last call and has been approved by the IESG). =20 Regards Marco =20 -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com]=20 Sent: Wednesday, August 18, 2004 5:20 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Multiple outstanding CCRs within one credit control session =20 Dear charging colleagues, =20 IETF Credit Control Application (up to rev 06) client state machine prohibits client from further sending out CCR at PendingU state. Is this view changed after MSCC is introduced? In another word, can a client send out CCRs for different services simultaneously? If this is relaxed, we need to revise related sections of the draft, e.g., state machine, CC-Request-Number, Tx timer, etc. =20 Thanks, Enoch Y. Wang=20 Lucent Technologies O =20 Bell Labs Innovations=20 Intelligent Network Unit=20 Tier 1 Systems Engineer=20 2J-328=20 101 Crawfords Corner Rd=20 Holmdel, NJ 07733=20 Tel: (732) 332-6687=20 Fax: (732) 332-6687=20 E-mail: ewang@lucent.com=20 =20 ------_=_NextPart_001_01C48539.17C6683F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

The state machine is meant to = document only mandatory features, the MSCC is = optional.

Moreover, recommendations how to = implement the MSCC with the described state machine = are given in sect. 5.1.2

in the last two paragraph, there is = no need for revisions.

 

Note that the documented approach = has been accepted by the AAA working group a while ago (the document has passed = couple

of WGLC, IETF last call and has been approved by the IESG).

 

Regards

=

Marco

 

-----Original = Message-----
From: Wang, Yile Enoch = (Enoch) [mailto:ewang@lucent.com]
Sent: Wednesday, August = 18, 2004 5:20 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: = Multiple outstanding CCRs within one credit control session

 

Dear charging = colleagues,

 

IETF Credit Control = Application (up to rev 06) client state machine prohibits client from further sending = out CCR at PendingU state.  Is this view changed after MSCC is = introduced?  In another word, can a client send out CCRs for different services simultaneously?  If this is relaxed, we need to revise related = sections of the draft, e.g., state machine, CC-Request-Number, Tx timer, = etc.

 

Thanks,

Enoch Y. Wang
Lucent Technologies = O  =
Bell Labs Innovations
Intelligent Network Unit
Tier 1 Systems Engineer
2J-328
101 Crawfords Corner Rd
Holmdel, NJ 07733
Tel:     = (732) 332-6687
Fax:     = (732) 332-6687
E-mail: ewang@lucent.com

 

=00 ------_=_NextPart_001_01C48539.17C6683F-- From owner-aaa-wg@merit.edu Wed Aug 18 18:53:03 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28358 for ; Wed, 18 Aug 2004 18:53:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 149B2912EE; Wed, 18 Aug 2004 18:50:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0BBA912D7; Wed, 18 Aug 2004 18:50:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F1E0912C3 for ; Wed, 18 Aug 2004 18:49:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DCBE5AB9D; Wed, 18 Aug 2004 18:49:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id B52075AA34 for ; Wed, 18 Aug 2004 18:49:22 -0400 (EDT) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7IMnLVI013157 for ; Wed, 18 Aug 2004 17:49:21 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 18:49:20 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D715034DEE@oh0012itsa1.cb.lucent.com> From: "Wang, Yile Enoch (Enoch)" To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Multiple service instances of the same service type Date: Wed, 18 Aug 2004 18:49:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48575.99187A04" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C48575.99187A04 Content-Type: text/plain Marco and colleagues, MSCC provides a mechanism that allows multiple (sub)services in one credit control session. I noticed that Service-Identifier is included in MSCC to differentiate services. To my understanding, the use of Service-Identifier is not intended to identify run-time service instances. If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances? If not, do we need to introduce a Service-Instance-Identifier in MSCC? Thanks, Enoch ------_=_NextPart_001_01C48575.99187A04 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Marco=20 and colleagues,
 
MSCC=20 provides a mechanism that allows multiple (sub)services in one credit = control=20 session.  I noticed that Service-Identifier is included in MSCC to = differentiate services.  To my understanding, the use of = Service-Identifier=20 is not intended to identify run-time service instances.  If there = are=20 multiple services instances of the same type (e.g., voice service) = within one=20 credit control session, and a separate credit pool shall be maintained = for each=20 of the instance, do we have a mechanism to associate MSCCs to their=20 corresponding service instances?  If not, do we need to introduce = a=20 Service-Instance-Identifier in MSCC?
 
Thanks,
 
Enoch
------_=_NextPart_001_01C48575.99187A04-- From owner-aaa-wg@merit.edu Thu Aug 19 04:54:15 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13723 for ; Thu, 19 Aug 2004 04:54:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C9793912C2; Thu, 19 Aug 2004 04:54:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74245912C7; Thu, 19 Aug 2004 04:54:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB2B1912C2 for ; Thu, 19 Aug 2004 04:54:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A42C06E95E; Thu, 19 Aug 2004 04:54:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id B236B6E957 for ; Thu, 19 Aug 2004 04:53:59 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i7J8rrHC026055 for ; Thu, 19 Aug 2004 10:53:53 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Aug 2004 10:53:51 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C485CA.0C64FBA2" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: [AAA-WG]: RE: Multiple service instances of the same service type Date: Thu, 19 Aug 2004 10:53:51 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906406259@OMIMEXO06.omnitel.it> Thread-Topic: Multiple service instances of the same service type Thread-Index: AcSFdZxM6Wxl6DqqS6CNhoM7sB20aQAU6w6A From: "STURA Marco Consultant" To: "Wang, Yile Enoch (Enoch)" Cc: X-OriginalArrivalTime: 19 Aug 2004 08:53:51.0449 (UTC) FILETIME=[0C997C90:01C485CA] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C485CA.0C64FBA2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Enoch, =20 I'm not sure I understand the real use case behind your suggestion, but as a matter of fact the technical content of the draft is definitely frozen. However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining new AVPs in the future. =20 Regards Marco =20 =20 -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com]=20 Sent: Thursday, August 19, 2004 12:49 AM To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: Multiple service instances of the same service type =20 Marco and colleagues, =20 MSCC provides a mechanism that allows multiple (sub)services in one credit control session. I noticed that Service-Identifier is included in MSCC to differentiate services. To my understanding, the use of Service-Identifier is not intended to identify run-time service instances. If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances? If not, do we need to introduce a Service-Instance-Identifier in MSCC? =20 Thanks, =20 Enoch ------_=_NextPart_001_01C485CA.0C64FBA2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

Enoch,

 

I’m not sure I understand the = real use case behind your suggestion, but as a matter of fact the technical = content of the draft is definitely frozen.

However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining = new AVPs

in the = future.

 =

Regards

=

Marco

 

 

-----Original = Message-----
From: Wang, Yile Enoch = (Enoch) [mailto:ewang@lucent.com]
Sent: Thursday, August = 19, 2004 12:49 AM
To: STURA Marco = Consultant
Cc: aaa-wg@merit.edu
Subject: Multiple service instances of the same service type

 

Marco and = colleagues,

 

MSCC provides a = mechanism that allows multiple (sub)services in one credit control session.  = I noticed that Service-Identifier is included in MSCC to differentiate services.  To my understanding, the use of Service-Identifier is = not intended to identify run-time service instances.  If there are = multiple services instances of the same type (e.g., voice service) within one = credit control session, and a separate credit pool shall be maintained for each = of the instance, do we have a mechanism to associate MSCCs to their = corresponding service instances?  If not, do we need to introduce a Service-Instance-Identifier in MSCC?

 

Thanks,

 

Enoch

=00 ------_=_NextPart_001_01C485CA.0C64FBA2-- From admin@computeradmin.org Thu Aug 19 06:14:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17420 for ; Thu, 19 Aug 2004 06:14:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxk2R-0008Sv-O8 for aaa-archive@ietf.org; Thu, 19 Aug 2004 06:20:57 -0400 Received: from [219.240.1.3] (helo=HUNTER01) by mx2.foretec.com with smtp (Exim 4.24) id 1Bxjw1-00043y-11 for aaa-archive@ietf.org; Thu, 19 Aug 2004 06:14:17 -0400 Received: from mui4.ojl4gf.org (HELO uq9fffg) [48.25.49.27] by HUNTER01; Thu, 19 Aug 2004 14:08:36 +0300 Message-ID: <63my-vp033ty6$9688h6@uylrw> From: "Administrator" To: 82@ietf.org Subject: Staff Bulletin Date: Thu, 19 Aug 04 14:08:36 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D__CFC_D6_3FE." X-Spam-Score: 26.8 (++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --D__CFC_D6_3FE. Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Friday, August 20, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Staff Members who respond to this message before 5 P.M., Friday, August 20, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, August 20, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Nonprofit or School Staff Member. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, August 20, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, August 20, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --D__CFC_D6_3FE.-- From owner-aaa-wg@merit.edu Thu Aug 19 06:35:18 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18847 for ; Thu, 19 Aug 2004 06:35:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86494912D0; Thu, 19 Aug 2004 06:35:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D276C912D6; Thu, 19 Aug 2004 06:35:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19CBB912D0 for ; Thu, 19 Aug 2004 06:35:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 090B46E95A; Thu, 19 Aug 2004 06:35:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 210106E951 for ; Thu, 19 Aug 2004 06:35:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7JATkb20459 for ; Thu, 19 Aug 2004 03:29:46 -0700 Date: Thu, 19 Aug 2004 03:29:46 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk RFC 3588, Section 1.2.3 describes when a new authentication Application Identifier is needed. Section 1.2.4 describes when new accounting Application Identifiers are required. Included in the list of conditions requiring a new Application-ID is: " - Adding new AVPs to the command, which have the "M" bit set." Given the discussion since the publication of RFC 3588, I now believe that the above sentence is in error. A new Application-ID should not be required due to addition of AVPs to an application, whether the mandatory bit is set or not. I am curious what the WG thinks about this. Given that we are just now getting ready to publish Diameter applications as RFCs, it is possible to correct this mistake. Below I argue that letting this sentence remain in the spec could prove costly. ANALYSIS Section 1.2.3 states: "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application." So addition of an AVP by itself does not require a new Application-ID, if the 'M' bit is not set. So what is it about the 'M' bit that changes the situation so fundamentally? Let's review the purpose of the 'M' bit. The purpose of the Mandatory bit was to enable implementations that receive an AVP they do not support to determine whether they can ignore that AVP, or whether a fatal error has occurred. In other words, the purpose of the Mandatory bit was to enable Diameter applications to be extended while maintaining well defined behavior. Given this, if a Diameter application were to be extended with new AVPs without obtaining a new Application ID, what happens? Since no new Application-ID is used, Diameter peers will negotiate capabilities with the existing Application-IDs, oblivious as to whether new 'M' bit AVPs will be used or not. As a result, Diameter connections will be established all along the path between the Diameter peers. If the new AVPs do not have the 'M' bit set, then a Diameter peer can ignore them, presumably without harm. If the AVPs have the 'M' bit set, then a Diameter peer doesn't support them, then a fatal error will result -- but Diameter error messages will make it clear what the problem was. What is done on receipt of the error message is implementation dependent -- but one possibility would be to stop sending the offending AVP to the peer that objected. Note that in most cases, Diameter agents will not care about new AVPs, whether they have the 'M' bit set or not. Relays and Redirects won't care. Proxies might care -- but if they do then they can send their own fatal errors. Now let us look at what happens if a new Application-ID is required. Since Diameter peers exchange the supported Application-IDs within the CER/CEA exchange, if the new Application-IDs are not supported by one or more peers along the path, then the Diameter messages won't get routed to the destination. The end result is the same -- an attempt to send a non-understood AVP with the 'M' bit set will result in an Error-Message coming back, but now the error message will be returned from an intermediary unable to find a Diameter peer to deliver to, rather than from the endpoint peer. This is a bit like the distinction between receiving a "host unreachable" ICMP message and a "port unreachable" ICMP message. Not a great difference. However, consider the downside to requiring a new Application-ID due to addition of a new mandatory AVP: * Proliferation of Application-IDs. What if it is necessary to extend an application with multiple additional mandatory AVPs? Do we now need a new Application-ID for each potential set of mandatory AVPs? For example, what if we want to extend Diameter EAP with additional wired 802 VLAN attributes as well as some WLAN attributes and perhaps some filter attributes? Do we need to obtain 3 new application-IDs? Or as an alternative, do we require each application to support versioning? * Additional work in intermediaries. Do intermediaries now need a "Dictionary" of Application-IDs? Why isn't an AVP dictionary sufficient (if one is needed at all)? * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to extend NASREQ with some additional filter attributes. Does this mean that both NASREQ and EAP applications need new Application-IDs to support this? * Bureaucratic overhead. New Application-IDs are allocated by Expert Review. Who is volunteering to be the Expert to "review" all these new Application-IDs? Why isn't review of the new AVP definitions sufficient? Based on the limited upside and substantial downside of requiring new Application-IDs due to addition of AVPs with the 'M' bit set, my conclusion is that the sentence requiring this in RFC 3588 was an error. Assuming that the AAA WG agrees with this, then my recommendation is to post an errata to the RFC Editor to this effect. From owner-aaa-wg@merit.edu Thu Aug 19 06:46:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19335 for ; Thu, 19 Aug 2004 06:46:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42C3C912D6; Thu, 19 Aug 2004 06:45:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 160DE912DC; Thu, 19 Aug 2004 06:45:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19418912D6 for ; Thu, 19 Aug 2004 06:45:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 734ED5AACB; Thu, 19 Aug 2004 06:45:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id 908296E984 for ; Thu, 19 Aug 2004 06:45:20 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i7JAjIHC015448 for ; Thu, 19 Aug 2004 12:45:19 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Aug 2004 12:45:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Thu, 19 Aug 2004 12:45:16 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB90640625B@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2DVizzC7td4ZT6Sy/Ej0COyHeQAAONhQ From: "STURA Marco Consultant" To: "Bernard Aboba" , X-OriginalArrivalTime: 19 Aug 2004 10:45:17.0861 (UTC) FILETIME=[9E02FD50:01C485D9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bernard, I fully share your view and analysis. Therefore I support sending an RFC 3588 errata as you recommend. Regards Marco -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Thursday, August 19, 2004 12:30 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID RFC 3588, Section 1.2.3 describes when a new authentication Application Identifier is needed. Section 1.2.4 describes when new accounting Application Identifiers are required. Included in the list of conditions requiring a new Application-ID is: " - Adding new AVPs to the command, which have the "M" bit set." Given the discussion since the publication of RFC 3588, I now believe that the above sentence is in error. A new Application-ID should not be required due to addition of AVPs to an application, whether the mandatory bit is set or not. I am curious what the WG thinks about this. Given that we are just now getting ready to publish Diameter applications as RFCs, it is possible to correct this mistake. Below I argue that letting this sentence remain in the spec could prove costly. ANALYSIS Section 1.2.3 states: "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application." So addition of an AVP by itself does not require a new Application-ID, if the 'M' bit is not set. So what is it about the 'M' bit that changes the situation so fundamentally? Let's review the purpose of the 'M' bit. The purpose of the Mandatory bit was to enable implementations that receive an AVP they do not support to determine whether they can ignore that AVP, or whether a fatal error has occurred. In other words, the purpose of the Mandatory bit was to enable Diameter applications to be extended while maintaining well defined behavior. Given this, if a Diameter application were to be extended with new AVPs without obtaining a new Application ID, what happens? Since no new Application-ID is used, Diameter peers will negotiate capabilities with the existing Application-IDs, oblivious as to whether new 'M' bit AVPs will be used or not. As a result, Diameter connections will be established all along the path between the Diameter peers. If the new AVPs do not have the 'M' bit set, then a Diameter peer can ignore them, presumably without harm. If the AVPs have the 'M' bit set, then a Diameter peer doesn't support them, then a fatal error will result -- but Diameter error messages will make it clear what the problem was. What is done on receipt of the error message is implementation dependent -- but one possibility would be to stop sending the offending AVP to the peer that objected. Note that in most cases, Diameter agents will not care about new AVPs, whether they have the 'M' bit set or not. Relays and Redirects won't care. Proxies might care -- but if they do then they can send their own fatal errors. Now let us look at what happens if a new Application-ID is required. Since Diameter peers exchange the supported Application-IDs within the CER/CEA exchange, if the new Application-IDs are not supported by one or more peers along the path, then the Diameter messages won't get routed to the destination. The end result is the same -- an attempt to send a non-understood AVP with the 'M' bit set will result in an Error-Message coming back, but now the error message will be returned from an intermediary unable to find a Diameter peer to deliver to, rather than from the endpoint peer. This is a bit like the distinction between receiving a "host unreachable" ICMP message and a "port unreachable" ICMP message. Not a great difference. However, consider the downside to requiring a new Application-ID due to addition of a new mandatory AVP: * Proliferation of Application-IDs. What if it is necessary to extend an application with multiple additional mandatory AVPs? Do we now need a new Application-ID for each potential set of mandatory AVPs? For example, what if we want to extend Diameter EAP with additional wired 802 VLAN attributes as well as some WLAN attributes and perhaps some filter attributes? Do we need to obtain 3 new application-IDs? Or as an alternative, do we require each application to support versioning? * Additional work in intermediaries. Do intermediaries now need a "Dictionary" of Application-IDs? Why isn't an AVP dictionary sufficient (if one is needed at all)? * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to extend NASREQ with some additional filter attributes. Does this mean that both NASREQ and EAP applications need new Application-IDs to support this? * Bureaucratic overhead. New Application-IDs are allocated by Expert Review. Who is volunteering to be the Expert to "review" all these new Application-IDs? Why isn't review of the new AVP definitions sufficient? Based on the limited upside and substantial downside of requiring new Application-IDs due to addition of AVPs with the 'M' bit set, my conclusion is that the sentence requiring this in RFC 3588 was an error. Assuming that the AAA WG agrees with this, then my recommendation is to post an errata to the RFC Editor to this effect. From owner-aaa-wg@merit.edu Thu Aug 19 07:19:58 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22425 for ; Thu, 19 Aug 2004 07:19:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDA92912C8; Thu, 19 Aug 2004 07:19:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4C83912EE; Thu, 19 Aug 2004 07:19:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DCF5912C8 for ; Thu, 19 Aug 2004 07:19:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF09B5ACC3; Thu, 19 Aug 2004 07:19:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 1BD555AA27 for ; Thu, 19 Aug 2004 07:19:05 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 87F0A8984A; Thu, 19 Aug 2004 14:18:58 +0300 (EEST) Message-ID: <41248C8A.9070703@kolumbus.fi> Date: Thu, 19 Aug 2004 14:18:34 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, Thanks for posting this, and yes, I also agree with your analysis. I would in addition point out that the distinction between a syntactically mandatory and a policy-wise mandatory attribute is often fuzzy. And we have always allowed nodes to reject a transaction if they have a policy that requires something that wasn't sent or was sent with a wrong value. For instance, do you require a particular AVP Foo-Parameter because its your policy that you only serve link layer FOO even if you use NASREQ, or do you require it because you are doing NASREQ-Foo which has Foo-Parameter marked as mandatory? Of course, with NASREQ-Foo you can increase the granularity of negotiation. But we are not prohibiting people to come up with a new application identifier if their application really is different. Just that you would not *have* to do it. For instance, if people come up with three new security-related (=> mandatory) new features usable in the network access context, does this mean that one has to develop NASREQ-F1, NASREQ-F2, NASREQ-F3, NASREQ-F1-and-F2, and so on just to be able to mark the attributes as mandatory? --Jari Bernard Aboba wrote: > RFC 3588, Section 1.2.3 describes when a new authentication Application > Identifier is needed. Section 1.2.4 describes when new accounting > Application Identifiers are required. > > Included in the list of conditions requiring a new Application-ID is: > > " - Adding new AVPs to the command, which have the "M" bit set." > > Given the discussion since the publication of RFC 3588, I now believe that > the above sentence is in error. A new Application-ID should not be > required due to addition of AVPs to an application, whether the mandatory > bit is set or not. > > I am curious what the WG thinks about this. Given that we are just now > getting ready to publish Diameter applications as RFCs, it is possible to > correct this mistake. Below I argue that letting this sentence remain in > the spec could prove costly. > > ANALYSIS > > Section 1.2.3 states: > > "An implementation MAY add arbitrary non-mandatory AVPs to any command > defined in an application, including vendor-specific AVPs without > needing to define a new application." > > So addition of an AVP by itself does not require a new > Application-ID, if the 'M' bit is not set. > > So what is it about the 'M' bit that changes the situation so > fundamentally? > > Let's review the purpose of the 'M' bit. > > The purpose of the Mandatory bit was to enable implementations > that receive an AVP they do not support to determine whether they can > ignore that AVP, or whether a fatal error has occurred. > > In other words, the purpose of the Mandatory bit was to enable Diameter > applications to be extended while maintaining well defined behavior. > > Given this, if a Diameter application were to be extended with new AVPs > without obtaining a new Application ID, what happens? > > Since no new Application-ID is used, Diameter peers will negotiate > capabilities with the existing Application-IDs, oblivious as to whether > new 'M' bit AVPs will be used or not. As a result, Diameter connections > will be established all along the path between the Diameter peers. > > If the new AVPs do not have the 'M' bit set, then a Diameter peer can > ignore them, presumably without harm. If the AVPs have the 'M' bit set, > then a Diameter peer doesn't support them, then a fatal error > will result -- but Diameter error messages will make it clear what the > problem was. What is done on receipt of the error message is > implementation dependent -- but one possibility would be to stop sending > the offending AVP to the peer that objected. > > Note that in most cases, Diameter agents will not care about new AVPs, > whether they have the 'M' bit set or not. Relays and Redirects won't > care. Proxies might care -- but if they do then they can send their own > fatal errors. > > Now let us look at what happens if a new Application-ID is required. > Since Diameter peers exchange the supported Application-IDs within the > CER/CEA exchange, if the new Application-IDs are not supported by one or > more peers along the path, then the Diameter messages won't get routed to > the destination. The end result is the same -- an attempt to send a > non-understood AVP with the 'M' bit set will result in an Error-Message > coming back, but now the error message will be returned from an > intermediary unable to find a Diameter peer to deliver to, rather than > from the endpoint peer. > > This is a bit like the distinction between receiving a "host unreachable" > ICMP message and a "port unreachable" ICMP message. Not a great > difference. > > However, consider the downside to requiring a new Application-ID due to > addition of a new mandatory AVP: > > * Proliferation of Application-IDs. > > What if it is necessary to extend an application with multiple > additional mandatory AVPs? Do we now need a new Application-ID for > each potential set of mandatory AVPs? For example, what if we want to > extend Diameter EAP with additional wired 802 VLAN attributes as well as > some WLAN attributes and perhaps some filter attributes? Do we need to > obtain 3 new application-IDs? > > Or as an alternative, do we require each application to support > versioning? > > * Additional work in intermediaries. Do intermediaries now need a > "Dictionary" of Application-IDs? Why isn't an AVP dictionary sufficient > (if one is needed at all)? > > * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to > extend NASREQ with some additional filter attributes. Does this mean that > both NASREQ and EAP applications need new Application-IDs to support this? > > * Bureaucratic overhead. New Application-IDs are allocated by Expert > Review. Who is volunteering to be the Expert to "review" all these new > Application-IDs? Why isn't review of the new AVP definitions sufficient? > > Based on the limited upside and substantial downside of requiring new > Application-IDs due to addition of AVPs with the 'M' bit set, my > conclusion is that the sentence requiring this in RFC 3588 was an error. > Assuming that the AAA WG agrees with this, then my recommendation is to > post an errata to the RFC Editor to this effect. > > From owner-aaa-wg@merit.edu Thu Aug 19 22:50:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27957 for ; Thu, 19 Aug 2004 22:50:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AAFF9131D; Thu, 19 Aug 2004 22:50:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 132BB9131F; Thu, 19 Aug 2004 22:50:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A10E19131D for ; Thu, 19 Aug 2004 22:50:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CC125ADA1; Thu, 19 Aug 2004 22:50:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 5073D5AD9A for ; Thu, 19 Aug 2004 22:50:32 -0400 (EDT) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7K2oUPR004935 for ; Thu, 19 Aug 2004 21:50:30 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Aug 2004 22:50:30 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D715035C1E@oh0012itsa1.cb.lucent.com> From: "Wang, Yile Enoch (Enoch)" To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Multiple service instances of the same service type Date: Thu, 19 Aug 2004 22:50:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48660.73A69B5C" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C48660.73A69B5C Content-Type: text/plain Marco, I am more from the angle of CDMA2000 data support. Currently, IS-835C uses Radius to perform prepaid credit control and it allows multiple service instances of the same service option (e.g., value 60 stands for voice over IP) over one established PPP/credit control session. Credit quotas are allocated and maintained for individual service instances. Going forward, when we migrate to Diameter (IS-835E/F), MSCC is the best candidate for this type of multi-service credit control. I am currently struggling at what AVP to use in order to identify MSCCs to their corresponding service instances. Thanks, Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] Sent: Thursday, August 19, 2004 4:54 AM To: Wang, Yile Enoch (Enoch) Cc: aaa-wg@merit.edu Subject: RE: Multiple service instances of the same service type Enoch, I'm not sure I understand the real use case behind your suggestion, but as a matter of fact the technical content of the draft is definitely frozen. However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining new AVPs in the future. Regards Marco -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com] Sent: Thursday, August 19, 2004 12:49 AM To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: Multiple service instances of the same service type Marco and colleagues, MSCC provides a mechanism that allows multiple (sub)services in one credit control session. I noticed that Service-Identifier is included in MSCC to differentiate services. To my understanding, the use of Service-Identifier is not intended to identify run-time service instances. If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances? If not, do we need to introduce a Service-Instance-Identifier in MSCC? Thanks, Enoch ------_=_NextPart_001_01C48660.73A69B5C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Marco,
 
I am=20 more from the angle of CDMA2000 data support.
 
Currently, IS-835C uses Radius to perform = prepaid=20 credit control and it allows multiple service instances of the same = service=20 option (e.g., value 60 stands for voice over IP) over one established = PPP/credit=20 control session.  Credit quotas are allocated and maintained = for=20 individual service instances.  Going forward, when we migrate to = Diameter=20 (IS-835E/F), MSCC is the best candidate for this type of = multi-service=20 credit control.  I am currently struggling at what AVP to use in = order to=20 identify MSCCs to their corresponding service = instances.
 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco = Consultant=20 [mailto:Marco.STURA@consultant.vodafoneomnitel.it]
Sent: = Thursday,=20 August 19, 2004 4:54 AM
To: Wang, Yile Enoch = (Enoch)
Cc:=20 aaa-wg@merit.edu
Subject: RE: Multiple service instances of = the same=20 service type

Enoch,

 

I'm not sure = I=20 understand the real use case behind your suggestion, but as a matter of = fact the=20 technical content of the draft is definitely=20 frozen.

However, = following the=20 RFC 3588 principles and the recommendations = in sect.=20 4.1 of the DCC, it is possible to extend = the DCC by defining new AVPs

in the=20 future.

 

Regards

Marco

 

 

-----Original=20 Message-----
From: = Wang, Yile=20 Enoch (Enoch) [mailto:ewang@lucent.com]
Sent: Thursday, August 19, 2004 = 12:49=20 AM
To: STURA Marco=20 Consultant
Cc:=20 aaa-wg@merit.edu
Subject:=20 Multiple service instances of the same service type

 

Marco and=20 colleagues,

 

MSCC=20 provides a mechanism that allows multiple (sub)services in one credit = control=20 session.  I noticed that Service-Identifier is included in MSCC to = differentiate services.  To my understanding, the use of = Service-Identifier=20 is not intended to identify run-time service instances.  If there = are=20 multiple services instances of the same type (e.g., voice service) = within one=20 credit control session, and a separate credit pool shall be maintained = for each=20 of the instance, do we have a mechanism to associate MSCCs to their=20 corresponding service instances?  If not, do we need to introduce = a=20 Service-Instance-Identifier in MSCC?

 

Thanks,

 

Enoch

------_=_NextPart_001_01C48660.73A69B5C-- From owner-aaa-wg@merit.edu Fri Aug 20 02:57:50 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22907 for ; Fri, 20 Aug 2004 02:57:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA2409120A; Fri, 20 Aug 2004 02:57:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 572129131D; Fri, 20 Aug 2004 02:57:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E463F9120A for ; Fri, 20 Aug 2004 02:57:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A77E16EA7C; Fri, 20 Aug 2004 02:57:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7D9546EA46 for ; Fri, 20 Aug 2004 02:57:32 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7K6vPq19597; Fri, 20 Aug 2004 09:57:25 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 09:53:53 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7K6rr7r005558; Fri, 20 Aug 2004 09:53:53 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 007Fy4ro; Fri, 20 Aug 2004 09:53:51 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7K6rlu14929; Fri, 20 Aug 2004 09:53:47 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 09:53:47 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 09:53:47 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48682.70465E67" Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Fri, 20 Aug 2004 09:53:46 +0300 Message-ID: Thread-Topic: [AAA-WG]: RE: Multiple service instances of the same service type Thread-Index: AcSGYMvbCHuiGdWdSfWb27+RZ0WCvQAHCCkg From: To: , Cc: X-OriginalArrivalTime: 20 Aug 2004 06:53:47.0445 (UTC) FILETIME=[71177650:01C48682] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C48682.70465E67 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yile, =20 Are the current 3GPP2 specs alligned with the proposed RADIUS Credit = Control work being standardized? There is some effort to align both = RADIUS and Diameter in this aspect. =20 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Wang, Yile Enoch (Enoch) Sent: 20 August, 2004 05:50 To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Multiple service instances of the same service = type Marco, =20 I am more from the angle of CDMA2000 data support. =20 Currently, IS-835C uses Radius to perform prepaid credit control and it = allows multiple service instances of the same service option (e.g., = value 60 stands for voice over IP) over one established PPP/credit = control session. Credit quotas are allocated and maintained for = individual service instances. Going forward, when we migrate to = Diameter (IS-835E/F), MSCC is the best candidate for this type of = multi-service credit control. I am currently struggling at what AVP to = use in order to identify MSCCs to their corresponding service instances. =20 Thanks, =20 Enoch -----Original Message----- From: STURA Marco Consultant = [mailto:Marco.STURA@consultant.vodafoneomnitel.it]=20 Sent: Thursday, August 19, 2004 4:54 AM To: Wang, Yile Enoch (Enoch) Cc: aaa-wg@merit.edu Subject: RE: Multiple service instances of the same service type Enoch, =20 I'm not sure I understand the real use case behind your suggestion, but = as a matter of fact the technical content of the draft is definitely = frozen. However, following the RFC 3588 principles and the recommendations in = sect. 4.1 of the DCC, it is possible to extend the DCC by defining new = AVPs in the future. =20 Regards Marco =20 =20 -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com]=20 Sent: Thursday, August 19, 2004 12:49 AM To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: Multiple service instances of the same service type =20 Marco and colleagues, =20 MSCC provides a mechanism that allows multiple (sub)services in one = credit control session. I noticed that Service-Identifier is included = in MSCC to differentiate services. To my understanding, the use of = Service-Identifier is not intended to identify run-time service = instances. If there are multiple services instances of the same type = (e.g., voice service) within one credit control session, and a separate = credit pool shall be maintained for each of the instance, do we have a = mechanism to associate MSCCs to their corresponding service instances? = If not, do we need to introduce a Service-Instance-Identifier in MSCC? =20 Thanks, =20 Enoch ------_=_NextPart_001_01C48682.70465E67 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Yile,
 
Are=20 the current 3GPP2 specs alligned with the proposed RADIUS Credit Control = work=20 being standardized?  There is some effort to align both RADIUS and = Diameter=20 in this aspect.
 
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Wang, Yile = Enoch=20 (Enoch)
Sent: 20 August, 2004 05:50
To: STURA = Marco=20 Consultant
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: = RE:=20 Multiple service instances of the same service = type

Marco,
 
I am=20 more from the angle of CDMA2000 data support.
 
Currently, IS-835C uses Radius to perform = prepaid=20 credit control and it allows multiple service instances of the same = service=20 option (e.g., value 60 stands for voice over IP) over one established=20 PPP/credit control session.  Credit quotas are allocated and = maintained for individual service instances.  Going forward, when = we=20 migrate to Diameter (IS-835E/F), MSCC is the best candidate for = this type=20 of multi-service credit control.  I am currently struggling at = what AVP=20 to use in order to identify MSCCs to their corresponding service=20 instances.
 
Thanks,
 
Enoch
-----Original Message-----
From: = STURA Marco=20 Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] =
Sent:=20 Thursday, August 19, 2004 4:54 AM
To: Wang, Yile Enoch=20 (Enoch)
Cc: aaa-wg@merit.edu
Subject: RE: Multiple = service=20 instances of the same service type

Enoch,

 

I'm not = sure I=20 understand the real use case behind your suggestion, but as a matter = of fact=20 the technical content of the draft is definitely=20 frozen.

However, = following=20 the RFC 3588 principles and the = recommendations in=20 sect. 4.1 of the DCC, it is possible to = extend the=20 DCC by defining new AVPs

in the=20 future.

 

Regards

Marco

 

 

-----Original=20 Message-----
From: = Wang, Yile=20 Enoch (Enoch) [mailto:ewang@lucent.com]
Sent: Thursday, August 19, 2004 = 12:49=20 AM
To: STURA Marco=20 Consultant
Cc:=20 aaa-wg@merit.edu
Subject:=20 Multiple service instances of the same service type

 

Marco=20 and colleagues,

 

MSCC=20 provides a mechanism that allows multiple (sub)services in one credit = control=20 session.  I noticed that Service-Identifier is included in MSCC = to=20 differentiate services.  To my understanding, the use of=20 Service-Identifier is not intended to identify run-time service=20 instances.  If there are multiple services instances of the same = type=20 (e.g., voice service) within one credit control session, and a = separate credit=20 pool shall be maintained for each of the instance, do we have a = mechanism to=20 associate MSCCs to their corresponding service instances?  If = not, do we=20 need to introduce a Service-Instance-Identifier in=20 MSCC?

 

Thanks,

 

Enoch

= ------_=_NextPart_001_01C48682.70465E67-- From owner-aaa-wg@merit.edu Fri Aug 20 03:19:03 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23767 for ; Fri, 20 Aug 2004 03:19:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEC389132D; Fri, 20 Aug 2004 03:17:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DD5791337; Fri, 20 Aug 2004 03:17:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A46E9132D for ; Fri, 20 Aug 2004 03:17:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 49F915AC9E; Fri, 20 Aug 2004 03:17:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 341B95AA4C for ; Fri, 20 Aug 2004 03:17:18 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7K7H9j22626; Fri, 20 Aug 2004 10:17:09 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 10:10:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7K7A6Vc002810; Fri, 20 Aug 2004 10:10:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MrIRt4; Fri, 20 Aug 2004 10:10:04 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7K6rnu14987; Fri, 20 Aug 2004 09:53:49 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 09:53:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 09:53:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 09:53:46 +0300 Message-ID: Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2Haf4K2IVWwJRhaIL689H5NqKQApYPCA From: To: , X-OriginalArrivalTime: 20 Aug 2004 06:53:48.0242 (UTC) FILETIME=[71911320:01C48682] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, This sounds like a reasonable proposal. I think we may need to improve the text for why a new Application-ID would be needed. I guess the main driver would be the need for new command codes. However, I think we may need to work on a BCP on creating new Diameter Applications. John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: 19 August, 2004 13:30 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new > Application-ID >=20 >=20 > RFC 3588, Section 1.2.3 describes when a new authentication=20 > Application > Identifier is needed. Section 1.2.4 describes when new accounting > Application Identifiers are required. >=20 > Included in the list of conditions requiring a new Application-ID is: >=20 > " - Adding new AVPs to the command, which have the "M" bit set." >=20 > Given the discussion since the publication of RFC 3588, I now=20 > believe that > the above sentence is in error. A new Application-ID should not be > required due to addition of AVPs to an application, whether=20 > the mandatory > bit is set or not. >=20 > I am curious what the WG thinks about this. Given that we=20 > are just now > getting ready to publish Diameter applications as RFCs, it is=20 > possible to > correct this mistake. Below I argue that letting this=20 > sentence remain in > the spec could prove costly. >=20 > ANALYSIS >=20 > Section 1.2.3 states: >=20 > "An implementation MAY add arbitrary non-mandatory AVPs to any command > defined in an application, including vendor-specific AVPs without > needing to define a new application." >=20 > So addition of an AVP by itself does not require a new > Application-ID, if the 'M' bit is not set. >=20 > So what is it about the 'M' bit that changes the situation so > fundamentally? >=20 > Let's review the purpose of the 'M' bit. >=20 > The purpose of the Mandatory bit was to enable implementations > that receive an AVP they do not support to determine whether they can > ignore that AVP, or whether a fatal error has occurred. >=20 > In other words, the purpose of the Mandatory bit was to=20 > enable Diameter > applications to be extended while maintaining well defined behavior. >=20 > Given this, if a Diameter application were to be extended=20 > with new AVPs > without obtaining a new Application ID, what happens? >=20 > Since no new Application-ID is used, Diameter peers will negotiate > capabilities with the existing Application-IDs, oblivious as=20 > to whether > new 'M' bit AVPs will be used or not. As a result, Diameter=20 > connections > will be established all along the path between the Diameter peers. >=20 > If the new AVPs do not have the 'M' bit set, then a Diameter peer can > ignore them, presumably without harm. If the AVPs have the=20 > 'M' bit set, > then a Diameter peer doesn't support them, then a fatal error > will result -- but Diameter error messages will make it clear what the > problem was. What is done on receipt of the error message is > implementation dependent -- but one possibility would be to=20 > stop sending > the offending AVP to the peer that objected. >=20 > Note that in most cases, Diameter agents will not care about new AVPs, > whether they have the 'M' bit set or not. Relays and Redirects won't > care. Proxies might care -- but if they do then they can=20 > send their own > fatal errors. >=20 > Now let us look at what happens if a new Application-ID is required. > Since Diameter peers exchange the supported Application-IDs within the > CER/CEA exchange, if the new Application-IDs are not=20 > supported by one or > more peers along the path, then the Diameter messages won't=20 > get routed to > the destination. The end result is the same -- an attempt to send a > non-understood AVP with the 'M' bit set will result in an=20 > Error-Message > coming back, but now the error message will be returned from an > intermediary unable to find a Diameter peer to deliver to, rather than > from the endpoint peer. >=20 > This is a bit like the distinction between receiving a "host=20 > unreachable" > ICMP message and a "port unreachable" ICMP message. Not a great > difference. >=20 > However, consider the downside to requiring a new=20 > Application-ID due to > addition of a new mandatory AVP: >=20 > * Proliferation of Application-IDs. >=20 > What if it is necessary to extend an application with multiple > additional mandatory AVPs? Do we now need a new Application-ID for > each potential set of mandatory AVPs? For example, what if we want to > extend Diameter EAP with additional wired 802 VLAN attributes=20 > as well as > some WLAN attributes and perhaps some filter attributes? Do=20 > we need to > obtain 3 new application-IDs? >=20 > Or as an alternative, do we require each application to support > versioning? >=20 > * Additional work in intermediaries. Do intermediaries now need a > "Dictionary" of Application-IDs? Why isn't an AVP dictionary=20 > sufficient > (if one is needed at all)? >=20 > * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to > extend NASREQ with some additional filter attributes. Does=20 > this mean that > both NASREQ and EAP applications need new Application-IDs to=20 > support this? >=20 > * Bureaucratic overhead. New Application-IDs are allocated by Expert > Review. Who is volunteering to be the Expert to "review" all=20 > these new > Application-IDs? Why isn't review of the new AVP definitions=20 > sufficient? >=20 > Based on the limited upside and substantial downside of requiring new > Application-IDs due to addition of AVPs with the 'M' bit set, my > conclusion is that the sentence requiring this in RFC 3588=20 > was an error. > Assuming that the AAA WG agrees with this, then my=20 > recommendation is to > post an errata to the RFC Editor to this effect. >=20 >=20 From owner-aaa-wg@merit.edu Fri Aug 20 04:11:07 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26037 for ; Fri, 20 Aug 2004 04:11:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D55839132D; Fri, 20 Aug 2004 04:10:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75B129132C; Fri, 20 Aug 2004 04:10:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81C0191329 for ; Fri, 20 Aug 2004 04:10:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AC096EA77; Fri, 20 Aug 2004 04:10:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id C9C255AB44 for ; Fri, 20 Aug 2004 04:10:48 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i7K7xkx1000312 for ; Fri, 20 Aug 2004 09:59:46 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Aug 2004 09:59:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4868B.A7E037F8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Fri, 20 Aug 2004 09:59:44 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906406260@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: RE: Multiple service instances of the same service type Thread-Index: AcSGYMvbCHuiGdWdSfWb27+RZ0WCvQAHCCkgAAMqjPA= From: "STURA Marco Consultant" To: , Cc: X-OriginalArrivalTime: 20 Aug 2004 07:59:45.0316 (UTC) FILETIME=[A82AA640:01C4868B] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4868B.A7E037F8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 I have been checking the last RADIUS prepaid draft and it seems they use the Service-Id to identify a service instance. =20 Enoch, why wouldn't you use the Service-Identifier? For instance you could specify in your DCC service specific document that Service-Identifiers from 60 to 69 are used when multiple service instances of the VoIP service option are established. Where 60 is the first service instance established, 61 the second and so on until 69 (in this example 10 instances are possible). =20 The combination of the Service-Context-Id and the Service-Identifier uniquely identify your VoIP service option. =20 Alternatively, for each of the service instances you could open a separate CC-sub-session. =20 Just a thought. What do you think? =20 Regards Marco -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Friday, August 20, 2004 8:54 AM To: ewang@lucent.com; STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type =20 Hi Yile, =20 Are the current 3GPP2 specs alligned with the proposed RADIUS Credit Control work being standardized? There is some effort to align both RADIUS and Diameter in this aspect. =20 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Wang, Yile Enoch (Enoch) Sent: 20 August, 2004 05:50 To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Multiple service instances of the same service type Marco, =20 I am more from the angle of CDMA2000 data support. =20 Currently, IS-835C uses Radius to perform prepaid credit control and it allows multiple service instances of the same service option (e.g., value 60 stands for voice over IP) over one established PPP/credit control session. Credit quotas are allocated and maintained for individual service instances. Going forward, when we migrate to Diameter (IS-835E/F), MSCC is the best candidate for this type of multi-service credit control. I am currently struggling at what AVP to use in order to identify MSCCs to their corresponding service instances. =20 Thanks, =20 Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it]=20 Sent: Thursday, August 19, 2004 4:54 AM To: Wang, Yile Enoch (Enoch) Cc: aaa-wg@merit.edu Subject: RE: Multiple service instances of the same service type Enoch, =20 I'm not sure I understand the real use case behind your suggestion, but as a matter of fact the technical content of the draft is definitely frozen. However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining new AVPs in the future. =20 Regards Marco =20 =20 -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com]=20 Sent: Thursday, August 19, 2004 12:49 AM To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: Multiple service instances of the same service type =20 Marco and colleagues, =20 MSCC provides a mechanism that allows multiple (sub)services in one credit control session. I noticed that Service-Identifier is included in MSCC to differentiate services. To my understanding, the use of Service-Identifier is not intended to identify run-time service instances. If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances? If not, do we need to introduce a Service-Instance-Identifier in MSCC? =20 Thanks, =20 Enoch ------_=_NextPart_001_01C4868B.A7E037F8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

Hi,

 

I have been checking the last = RADIUS prepaid draft and it seems they use the Service-Id to identify a service instance.

 

Enoch, why wouldn’t you use = the Service-Identifier? For instance you could specify in your DCC service = specific document that

Service-Identifiers from 60 to 69 = are used when multiple service instances of the VoIP service option are = established. Where 60

is the first service instance = established, 61 the second and so on until 69 (in this example 10 instances are = possible).

 

The combination of the = Service-Context-Id and the Service-Identifier uniquely identify your VoIP service = option.

 

Alternatively, for each of the = service instances you could open a separate = CC-sub-session.

 

Just a thought. What do you = think?

 

Regards

=

Marco

-----Original = Message-----
From: = john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Friday, August 20, = 2004 8:54 AM
To: ewang@lucent.com; = STURA Marco Consultant
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: = RE: Multiple service instances of the same service type

 

Hi = Yile,

 

Are the current = 3GPP2 specs alligned with the proposed RADIUS Credit Control work being standardized?  There is some effort to align both RADIUS and = Diameter in this aspect.

 

John

-----Original Message-----
From: = owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On = Behalf Of ext Wang, Yile Enoch (Enoch)
Sent: 20 August, 2004 = 05:50
To: STURA Marco = Consultant
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: RE: = Multiple service instances of the same service type

Marco,

 

I am more from = the angle of CDMA2000 data support.

 

Currently, = IS-835C uses Radius to perform prepaid credit control and it allows multiple service instances of the same service option (e.g., value 60 stands for voice = over IP) over one established PPP/credit control session.  Credit = quotas are allocated and maintained for individual service instances.  Going = forward, when we migrate to Diameter (IS-835E/F), MSCC is the best candidate = for this type of multi-service credit control.  I am currently = struggling at what AVP to use in order to identify MSCCs to their corresponding service = instances.

 

Thanks,

 

Enoch

-----Original Message-----
From: STURA Marco = Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it]
Sent: Thursday, August = 19, 2004 4:54 AM
To: Wang, Yile Enoch = (Enoch)
Cc: aaa-wg@merit.edu
Subject: RE: Multiple = service instances of the same service type

Enoch,=

 =

I'm not sure I = understand the real use case behind your suggestion, but as a matter of fact the = technical content of the draft is definitely frozen.

However, = following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it = is possible to extend the DCC by defining new = AVPs

in the = future.

 =

Regards

Marco<= /span>

 =

 =

-----Original = Message-----
From: Wang, Yile Enoch = (Enoch) [mailto:ewang@lucent.com]
Sent: Thursday, August = 19, 2004 12:49 AM
To: STURA Marco = Consultant
Cc: aaa-wg@merit.edu
Subject: Multiple service instances of the same service type

 

Marco and colleagues,

 

MSCC provides a mechanism that allows multiple (sub)services in one credit control session.  I noticed that Service-Identifier is included in MSCC to differentiate services.  To my understanding, the use of Service-Identifier is not intended to identify run-time service instances.  If there are multiple services instances of the same = type (e.g., voice service) within one credit control session, and a separate = credit pool shall be maintained for each of the instance, do we have a = mechanism to associate MSCCs to their corresponding service instances?  If not, = do we need to introduce a Service-Instance-Identifier in = MSCC?

 

Thanks,

 

Enoch

=00 ------_=_NextPart_001_01C4868B.A7E037F8-- From owner-aaa-wg@merit.edu Fri Aug 20 04:41:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27776 for ; Fri, 20 Aug 2004 04:41:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C95691329; Fri, 20 Aug 2004 04:41:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2590F9132C; Fri, 20 Aug 2004 04:41:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 823C191329 for ; Fri, 20 Aug 2004 04:41:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EF905AA66; Fri, 20 Aug 2004 04:41:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id AC3EB5AA7A for ; Fri, 20 Aug 2004 04:41:14 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 10:41:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 10:41:09 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260141E132@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2Haf4K2IVWwJRhaIL689H5NqKQApYPCAAAN7MmA= From: "MORAND Lionel RD-CORE-ISS" To: , , X-OriginalArrivalTime: 20 Aug 2004 08:41:12.0133 (UTC) FILETIME=[726CCF50:01C48691] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John, Bernard, About the need for new command codes, it is not clearly explained in the = RFC 3588 if a new command code is required if the application FOO is = reusing an existing command code defined for the application BAR but = modifying the command code ABNF specification. In another way: is it possible to use the same command code (allocated by IANA in the = range for standard commands) defined with different ABNF specifications = in their related Diameter application specifications? Based on information collected all along the RFC, I would assume that = the response is "NO". But I cannot find a clear statement. However, I = may be wrong in my understanding... Lionel > -----Message d'origine----- > De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > De la part de john.loughney@nokia.com > Envoy=E9 : vendredi 20 ao=FBt 2004 08:54 > =C0 : aboba@internaut.com; aaa-wg@merit.edu > Objet : RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs=20 > requires new Application-ID >=20 >=20 > Bernard, >=20 > This sounds like a reasonable proposal. I think we may need=20 > to improve the text for why a new Application-ID would be=20 > needed. I guess the main driver would be the need for new=20 > command codes. However, I think we may need to work on a BCP=20 > on creating new Diameter Applications. >=20 > John >=20 > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > ext Bernard Aboba > > Sent: 19 August, 2004 13:30 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new > > Application-ID > >=20 > >=20 > > RFC 3588, Section 1.2.3 describes when a new authentication > > Application > > Identifier is needed. Section 1.2.4 describes when new accounting > > Application Identifiers are required. > >=20 > > Included in the list of conditions requiring a new=20 > Application-ID is: > >=20 > > " - Adding new AVPs to the command, which have the "M" bit set." > >=20 > > Given the discussion since the publication of RFC 3588, I now > > believe that > > the above sentence is in error. A new Application-ID should not be > > required due to addition of AVPs to an application, whether=20 > > the mandatory > > bit is set or not. > >=20 > > I am curious what the WG thinks about this. Given that we > > are just now > > getting ready to publish Diameter applications as RFCs, it is=20 > > possible to > > correct this mistake. Below I argue that letting this=20 > > sentence remain in > > the spec could prove costly. > >=20 > > ANALYSIS > >=20 > > Section 1.2.3 states: > >=20 > > "An implementation MAY add arbitrary non-mandatory AVPs to=20 > any command=20 > > defined in an application, including vendor-specific AVPs without=20 > > needing to define a new application." > >=20 > > So addition of an AVP by itself does not require a new=20 > Application-ID,=20 > > if the 'M' bit is not set. > >=20 > > So what is it about the 'M' bit that changes the situation so=20 > > fundamentally? > >=20 > > Let's review the purpose of the 'M' bit. > >=20 > > The purpose of the Mandatory bit was to enable implementations that=20 > > receive an AVP they do not support to determine whether they can=20 > > ignore that AVP, or whether a fatal error has occurred. > >=20 > > In other words, the purpose of the Mandatory bit was to > > enable Diameter > > applications to be extended while maintaining well defined behavior. > >=20 > > Given this, if a Diameter application were to be extended > > with new AVPs > > without obtaining a new Application ID, what happens? > >=20 > > Since no new Application-ID is used, Diameter peers will negotiate=20 > > capabilities with the existing Application-IDs, oblivious as to=20 > > whether new 'M' bit AVPs will be used or not. As a result, Diameter > > connections > > will be established all along the path between the Diameter peers. > >=20 > > If the new AVPs do not have the 'M' bit set, then a=20 > Diameter peer can=20 > > ignore them, presumably without harm. If the AVPs have the 'M' bit=20 > > set, then a Diameter peer doesn't support them, then a fatal error > > will result -- but Diameter error messages will make it=20 > clear what the > > problem was. What is done on receipt of the error message is > > implementation dependent -- but one possibility would be to=20 > > stop sending > > the offending AVP to the peer that objected. > >=20 > > Note that in most cases, Diameter agents will not care=20 > about new AVPs,=20 > > whether they have the 'M' bit set or not. Relays and=20 > Redirects won't=20 > > care. Proxies might care -- but if they do then they can=20 > send their=20 > > own fatal errors. > >=20 > > Now let us look at what happens if a new Application-ID is=20 > required.=20 > > Since Diameter peers exchange the supported Application-IDs=20 > within the=20 > > CER/CEA exchange, if the new Application-IDs are not=20 > supported by one=20 > > or more peers along the path, then the Diameter messages won't > > get routed to > > the destination. The end result is the same -- an attempt=20 > to send a > > non-understood AVP with the 'M' bit set will result in an=20 > > Error-Message > > coming back, but now the error message will be returned from an > > intermediary unable to find a Diameter peer to deliver to,=20 > rather than > > from the endpoint peer. > >=20 > > This is a bit like the distinction between receiving a "host > > unreachable" > > ICMP message and a "port unreachable" ICMP message. Not a great > > difference. > >=20 > > However, consider the downside to requiring a new > > Application-ID due to > > addition of a new mandatory AVP: > >=20 > > * Proliferation of Application-IDs. > >=20 > > What if it is necessary to extend an application with multiple=20 > > additional mandatory AVPs? Do we now need a new Application-ID for=20 > > each potential set of mandatory AVPs? For example, what if=20 > we want to=20 > > extend Diameter EAP with additional wired 802 VLAN=20 > attributes as well=20 > > as some WLAN attributes and perhaps some filter attributes? Do > > we need to > > obtain 3 new application-IDs? > >=20 > > Or as an alternative, do we require each application to support=20 > > versioning? > >=20 > > * Additional work in intermediaries. Do intermediaries now need a=20 > > "Dictionary" of Application-IDs? Why isn't an AVP dictionary=20 > > sufficient (if one is needed at all)? > >=20 > > * Inheritance effects. Diameter EAP depends on NASREQ. =20 > Say I want to=20 > > extend NASREQ with some additional filter attributes. Does=20 > this mean=20 > > that both NASREQ and EAP applications need new Application-IDs to > > support this? > >=20 > > * Bureaucratic overhead. New Application-IDs are allocated=20 > by Expert=20 > > Review. Who is volunteering to be the Expert to "review" all these=20 > > new Application-IDs? Why isn't review of the new AVP definitions > > sufficient? > >=20 > > Based on the limited upside and substantial downside of=20 > requiring new=20 > > Application-IDs due to addition of AVPs with the 'M' bit set, my=20 > > conclusion is that the sentence requiring this in RFC 3588 was an=20 > > error. Assuming that the AAA WG agrees with this, then my > > recommendation is to > > post an errata to the RFC Editor to this effect. > >=20 > >=20 >=20 From owner-aaa-wg@merit.edu Fri Aug 20 05:17:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29463 for ; Fri, 20 Aug 2004 05:17:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F22A19120A; Fri, 20 Aug 2004 05:15:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDC1A91329; Fri, 20 Aug 2004 05:15:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 914AB9120A for ; Fri, 20 Aug 2004 05:15:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5704B5A9DC; Fri, 20 Aug 2004 05:15:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 56EA15AB41 for ; Fri, 20 Aug 2004 05:15:41 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7K9FY125743; Fri, 20 Aug 2004 12:15:34 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 12:13:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7K9DT9i000318; Fri, 20 Aug 2004 12:13:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00LFCQnc; Fri, 20 Aug 2004 12:13:29 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7K9DSn19056; Fri, 20 Aug 2004 12:13:28 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 12:13:28 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 12:13:27 +0300 Message-ID: Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2Haf4K2IVWwJRhaIL689H5NqKQApYPCAAAN7MmAAAnUu8A== From: To: , , X-OriginalArrivalTime: 20 Aug 2004 09:13:28.0189 (UTC) FILETIME=[F46782D0:01C48695] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Lionel, > About the need for new command codes, it is not clearly=20 > explained in the RFC 3588 if a new command code is required=20 > if the application FOO is reusing an existing command code=20 > defined for the application BAR but modifying the command=20 > code ABNF specification. In another way: >=20 > is it possible to use the same command code (allocated by=20 > IANA in the range for standard commands) defined with=20 > different ABNF specifications in their related Diameter=20 > application specifications? >=20 > Based on information collected all along the RFC, I would=20 > assume that the response is "NO". But I cannot find a clear=20 > statement. However, I may be wrong in my understanding... Well, I think it would mean what different ABNF is being used. If the new application added new parameters, that would be OK. I don't think it would be OK if existing parameters were dropped. John From owner-aaa-wg@merit.edu Fri Aug 20 05:39:42 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00700 for ; Fri, 20 Aug 2004 05:39:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABBE891333; Fri, 20 Aug 2004 05:39:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76BA59132F; Fri, 20 Aug 2004 05:39:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44CFE9132C for ; Fri, 20 Aug 2004 05:39:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BBB25ACF5; Fri, 20 Aug 2004 05:39:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by segue.merit.edu (Postfix) with ESMTP id 7719A5AC9E for ; Fri, 20 Aug 2004 05:39:25 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 11:39:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 11:39:09 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260141E15D@ftrdmel2.rd.francetelecom.fr> Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2Haf4K2IVWwJRhaIL689H5NqKQApYPCAAAN7MmAAAnUu8AAAVdkQ From: "MORAND Lionel RD-CORE-ISS" To: , , X-OriginalArrivalTime: 20 Aug 2004 09:39:11.0126 (UTC) FILETIME=[8C110360:01C48699] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John, =20 > > About the need for new command codes, it is not clearly > > explained in the RFC 3588 if a new command code is required=20 > > if the application FOO is reusing an existing command code=20 > > defined for the application BAR but modifying the command=20 > > code ABNF specification. In another way: > >=20 > > is it possible to use the same command code (allocated by > > IANA in the range for standard commands) defined with=20 > > different ABNF specifications in their related Diameter=20 > > application specifications? > >=20 > > Based on information collected all along the RFC, I would > > assume that the response is "NO". But I cannot find a clear=20 > > statement. However, I may be wrong in my understanding... >=20 > Well, I think it would mean what different ABNF is being=20 > used. If the new application added new parameters, that would=20 > be OK. I don't think it would be OK if existing parameters=20 > were dropped. It is exactly my concern. Three kind of AVPs are used in the ABNF specification: fixed, required and optional AVPs. And different rules will be apllied based on the AVP type in the ABNF. There is no problem to add/remove any optional AVP without modifying the command definition. Rules concerning fixed and required AVPs are more ambiguous. Lionel From owner-aaa-wg@merit.edu Fri Aug 20 08:34:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09347 for ; Fri, 20 Aug 2004 08:34:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CDE49120D; Fri, 20 Aug 2004 08:33:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20A399132F; Fri, 20 Aug 2004 08:33:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24D309120D for ; Fri, 20 Aug 2004 08:33:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B7395A996; Fri, 20 Aug 2004 08:33:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 267A45A9AF for ; Fri, 20 Aug 2004 08:33:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7KCS4h13063; Fri, 20 Aug 2004 05:28:04 -0700 Date: Fri, 20 Aug 2004 05:28:03 -0700 (PDT) From: Bernard Aboba To: MORAND Lionel RD-CORE-ISS Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260141E132@ftrdmel2.rd.francetelecom.fr> Message-ID: References: <7DBAFEC6A76F3E42817DF1EBE64CB0260141E132@ftrdmel2.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > is it possible to use the same command code (allocated by IANA in the range for > standard commands) defined with different ABNF specifications in their > related Diameter application specifications? RFC 3588 indicates if you add AVPs with the 'M' bit set, a new application-ID is required, but optional AVPs don't require a new Application-ID. Or were you thinking of other ABNF changes? I'm proposing that addition of AVPs (whatever the 'M' bit setting) should not require a new application-ID (although one could be used if desired). I'm not as sure about subtraction of mandatory AVPs; that would appear to create interoperability problems. From owner-aaa-wg@merit.edu Fri Aug 20 08:37:19 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09532 for ; Fri, 20 Aug 2004 08:37:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3995891337; Fri, 20 Aug 2004 08:37:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EBED9132F; Fri, 20 Aug 2004 08:37:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4F2991337 for ; Fri, 20 Aug 2004 08:37:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 814385AB89; Fri, 20 Aug 2004 08:37:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 22F785ABE2 for ; Fri, 20 Aug 2004 08:37:01 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KCauT11235; Fri, 20 Aug 2004 15:36:56 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 15:35:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7KCZRDd023346; Fri, 20 Aug 2004 15:35:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 003Ry25U; Fri, 20 Aug 2004 15:35:26 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KCZQu10763; Fri, 20 Aug 2004 15:35:26 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 15:35:21 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 15:35:21 +0300 Message-ID: Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2Haf4K2IVWwJRhaIL689H5NqKQApYPCAAAN7MmAAAnUu8AAAVdkQAAa6ceA= From: To: , , X-OriginalArrivalTime: 20 Aug 2004 12:35:21.0397 (UTC) FILETIME=[28705E50:01C486B2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Lionel, > It is exactly my concern. Three kind of AVPs are used in the ABNF > specification: fixed, required and optional AVPs. And different rules > will be apllied based on the AVP type in the ABNF. There is no problem > to add/remove any optional AVP without modifying the command = definition. > Rules concerning fixed and required AVPs are more ambiguous. Fixed AVPs need to be there. Mandatory AVPs need to be there as well, or an error will be generated. Optional AVPs are exactly as advertised, they do not need to be present. John From owner-aaa-wg@merit.edu Fri Aug 20 08:39:32 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09584 for ; Fri, 20 Aug 2004 08:39:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3987A91338; Fri, 20 Aug 2004 08:39:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0892F9132F; Fri, 20 Aug 2004 08:39:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7CED91338 for ; Fri, 20 Aug 2004 08:39:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA1245ABD7; Fri, 20 Aug 2004 08:39:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 3101C5AC26 for ; Fri, 20 Aug 2004 08:39:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7KCXq913499; Fri, 20 Aug 2004 05:33:52 -0700 Date: Fri, 20 Aug 2004 05:33:52 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: lionel.morand@francetelecom.com, aaa-wg@merit.edu Subject: Re: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Fixed AVPs need to be there. Mandatory AVPs need to be there as well, > or an error will be generated. Optional AVPs are exactly as advertised, > they do not need to be present. Yes, that was my understanding. From owner-aaa-wg@merit.edu Fri Aug 20 08:41:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09708 for ; Fri, 20 Aug 2004 08:41:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2CB4B91339; Fri, 20 Aug 2004 08:41:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFE439132F; Fri, 20 Aug 2004 08:41:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E43149133A for ; Fri, 20 Aug 2004 08:41:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBAF25AB32; Fri, 20 Aug 2004 08:41:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 45DDC5AC9E for ; Fri, 20 Aug 2004 08:41:14 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KCfD126501 for ; Fri, 20 Aug 2004 15:41:13 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 15:39:25 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7KCdPZE031140 for ; Fri, 20 Aug 2004 15:39:25 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 003XDbbq; Fri, 20 Aug 2004 15:39:23 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KCdIu12841 for ; Fri, 20 Aug 2004 15:39:18 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 15:39:18 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 15:39:17 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 15:39:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 15:39:18 +0300 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F704@esebe054.ntc.nokia.com> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSF2Haf4K2IVWwJRhaIL689H5NqKQApYPCAAAN7MmAACWCUIA== From: To: X-OriginalArrivalTime: 20 Aug 2004 12:39:19.0065 (UTC) FILETIME=[B619A090:01C486B2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > is it possible to use the same command code (allocated by=20 > IANA in the range for standard commands) defined with=20 > different ABNF specifications in their related Diameter=20 > application specifications? So far my interpretaton has been that yes, it is possible and that the Application-Id is used to identify the ABNF of the command (in addition to Command-Code). BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext MORAND Lionel RD-CORE-ISS > Sent: 20 August, 2004 11:41 > To: Loughney John (Nokia-NRC/Helsinki); aboba@internaut.com; > aaa-wg@merit.edu > Subject: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires > new Application-ID >=20 >=20 > John, Bernard, >=20 > About the need for new command codes, it is not clearly=20 > explained in the RFC 3588 if a new command code is required=20 > if the application FOO is reusing an existing command code=20 > defined for the application BAR but modifying the command=20 > code ABNF specification. In another way: >=20 > is it possible to use the same command code (allocated by=20 > IANA in the range for standard commands) defined with=20 > different ABNF specifications in their related Diameter=20 > application specifications? >=20 > Based on information collected all along the RFC, I would=20 > assume that the response is "NO". But I cannot find a clear=20 > statement. However, I may be wrong in my understanding... >=20 > Lionel >=20 > > -----Message d'origine----- > > De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > > De la part de john.loughney@nokia.com > > Envoy=E9 : vendredi 20 ao=FBt 2004 08:54 > > =C0 : aboba@internaut.com; aaa-wg@merit.edu > > Objet : RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs=20 > > requires new Application-ID > >=20 > >=20 > > Bernard, > >=20 > > This sounds like a reasonable proposal. I think we may need=20 > > to improve the text for why a new Application-ID would be=20 > > needed. I guess the main driver would be the need for new=20 > > command codes. However, I think we may need to work on a BCP=20 > > on creating new Diameter Applications. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: owner-aaa-wg@merit.edu > > > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > ext Bernard Aboba > > > Sent: 19 August, 2004 13:30 > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs=20 > requires new > > > Application-ID > > >=20 > > >=20 > > > RFC 3588, Section 1.2.3 describes when a new authentication > > > Application > > > Identifier is needed. Section 1.2.4 describes when new accounting > > > Application Identifiers are required. > > >=20 > > > Included in the list of conditions requiring a new=20 > > Application-ID is: > > >=20 > > > " - Adding new AVPs to the command, which have the "M"=20 > bit set." > > >=20 > > > Given the discussion since the publication of RFC 3588, I now > > > believe that > > > the above sentence is in error. A new Application-ID=20 > should not be > > > required due to addition of AVPs to an application, whether=20 > > > the mandatory > > > bit is set or not. > > >=20 > > > I am curious what the WG thinks about this. Given that we > > > are just now > > > getting ready to publish Diameter applications as RFCs, it is=20 > > > possible to > > > correct this mistake. Below I argue that letting this=20 > > > sentence remain in > > > the spec could prove costly. > > >=20 > > > ANALYSIS > > >=20 > > > Section 1.2.3 states: > > >=20 > > > "An implementation MAY add arbitrary non-mandatory AVPs to=20 > > any command=20 > > > defined in an application, including vendor-specific AVPs without=20 > > > needing to define a new application." > > >=20 > > > So addition of an AVP by itself does not require a new=20 > > Application-ID,=20 > > > if the 'M' bit is not set. > > >=20 > > > So what is it about the 'M' bit that changes the situation so=20 > > > fundamentally? > > >=20 > > > Let's review the purpose of the 'M' bit. > > >=20 > > > The purpose of the Mandatory bit was to enable=20 > implementations that=20 > > > receive an AVP they do not support to determine whether they can=20 > > > ignore that AVP, or whether a fatal error has occurred. > > >=20 > > > In other words, the purpose of the Mandatory bit was to > > > enable Diameter > > > applications to be extended while maintaining well=20 > defined behavior. > > >=20 > > > Given this, if a Diameter application were to be extended > > > with new AVPs > > > without obtaining a new Application ID, what happens? > > >=20 > > > Since no new Application-ID is used, Diameter peers will=20 > negotiate=20 > > > capabilities with the existing Application-IDs, oblivious as to=20 > > > whether new 'M' bit AVPs will be used or not. As a=20 > result, Diameter > > > connections > > > will be established all along the path between the Diameter peers. > > >=20 > > > If the new AVPs do not have the 'M' bit set, then a=20 > > Diameter peer can=20 > > > ignore them, presumably without harm. If the AVPs have=20 > the 'M' bit=20 > > > set, then a Diameter peer doesn't support them, then a fatal error > > > will result -- but Diameter error messages will make it=20 > > clear what the > > > problem was. What is done on receipt of the error message is > > > implementation dependent -- but one possibility would be to=20 > > > stop sending > > > the offending AVP to the peer that objected. > > >=20 > > > Note that in most cases, Diameter agents will not care=20 > > about new AVPs,=20 > > > whether they have the 'M' bit set or not. Relays and=20 > > Redirects won't=20 > > > care. Proxies might care -- but if they do then they can=20 > > send their=20 > > > own fatal errors. > > >=20 > > > Now let us look at what happens if a new Application-ID is=20 > > required.=20 > > > Since Diameter peers exchange the supported Application-IDs=20 > > within the=20 > > > CER/CEA exchange, if the new Application-IDs are not=20 > > supported by one=20 > > > or more peers along the path, then the Diameter messages won't > > > get routed to > > > the destination. The end result is the same -- an attempt=20 > > to send a > > > non-understood AVP with the 'M' bit set will result in an=20 > > > Error-Message > > > coming back, but now the error message will be returned from an > > > intermediary unable to find a Diameter peer to deliver to,=20 > > rather than > > > from the endpoint peer. > > >=20 > > > This is a bit like the distinction between receiving a "host > > > unreachable" > > > ICMP message and a "port unreachable" ICMP message. Not a great > > > difference. > > >=20 > > > However, consider the downside to requiring a new > > > Application-ID due to > > > addition of a new mandatory AVP: > > >=20 > > > * Proliferation of Application-IDs. > > >=20 > > > What if it is necessary to extend an application with multiple=20 > > > additional mandatory AVPs? Do we now need a new=20 > Application-ID for=20 > > > each potential set of mandatory AVPs? For example, what if=20 > > we want to=20 > > > extend Diameter EAP with additional wired 802 VLAN=20 > > attributes as well=20 > > > as some WLAN attributes and perhaps some filter attributes? Do > > > we need to > > > obtain 3 new application-IDs? > > >=20 > > > Or as an alternative, do we require each application to support=20 > > > versioning? > > >=20 > > > * Additional work in intermediaries. Do intermediaries=20 > now need a=20 > > > "Dictionary" of Application-IDs? Why isn't an AVP dictionary=20 > > > sufficient (if one is needed at all)? > > >=20 > > > * Inheritance effects. Diameter EAP depends on NASREQ. =20 > > Say I want to=20 > > > extend NASREQ with some additional filter attributes. Does=20 > > this mean=20 > > > that both NASREQ and EAP applications need new Application-IDs to > > > support this? > > >=20 > > > * Bureaucratic overhead. New Application-IDs are allocated=20 > > by Expert=20 > > > Review. Who is volunteering to be the Expert to "review"=20 > all these=20 > > > new Application-IDs? Why isn't review of the new AVP definitions > > > sufficient? > > >=20 > > > Based on the limited upside and substantial downside of=20 > > requiring new=20 > > > Application-IDs due to addition of AVPs with the 'M' bit set, my=20 > > > conclusion is that the sentence requiring this in RFC 3588 was an=20 > > > error. Assuming that the AAA WG agrees with this, then my > > > recommendation is to > > > post an errata to the RFC Editor to this effect. > > >=20 > > >=20 > >=20 >=20 From owner-aaa-wg@merit.edu Fri Aug 20 08:42:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09763 for ; Fri, 20 Aug 2004 08:42:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A00D29132F; Fri, 20 Aug 2004 08:41:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DE6D9133A; Fri, 20 Aug 2004 08:41:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 155EE91349 for ; Fri, 20 Aug 2004 08:41:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 282795ABE0; Fri, 20 Aug 2004 08:41:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 38D215ADAD for ; Fri, 20 Aug 2004 08:41:45 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KCfej02251; Fri, 20 Aug 2004 15:41:40 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 15:38:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7KCcW9j007995; Fri, 20 Aug 2004 15:38:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00nuxICd; Fri, 20 Aug 2004 15:38:30 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KCcOn12677; Fri, 20 Aug 2004 15:38:24 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 15:38:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 15:38:25 +0300 Message-ID: Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSGsiR5OLSPeSy5QVeKpmu693nXBgAAG5ZQ From: To: , Cc: X-OriginalArrivalTime: 20 Aug 2004 12:38:24.0785 (UTC) FILETIME=[95BF2810:01C486B2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bernard, > RFC 3588 indicates if you add AVPs with the 'M' bit set, a new = application-ID is > required, but optional AVPs don't require a new Application-ID. Or = were > you thinking of other ABNF changes? >=20 > I'm proposing that addition of AVPs (whatever the 'M' bit setting) = should > not require a new application-ID (although one could be used if = desired). > I'm not as sure about subtraction of mandatory AVPs; that would appear = to > create interoperability problems. Subtraction of mandatory AVPs would create interoperability problems, = therefore I think the command-code could not be re-used, so a new command code = would be necessary. John From owner-aaa-wg@merit.edu Fri Aug 20 08:55:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10605 for ; Fri, 20 Aug 2004 08:55:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D2A19120D; Fri, 20 Aug 2004 08:55:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CE1A9133A; Fri, 20 Aug 2004 08:55:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2022C9120D for ; Fri, 20 Aug 2004 08:55:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A15A5A9DC; Fri, 20 Aug 2004 08:55:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 9CC955AB20 for ; Fri, 20 Aug 2004 08:55:30 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 14:55:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 14:55:25 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260141E1DB@ftrdmel2.rd.francetelecom.fr> Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSGsrW4xN8BMVrRTs2uWSdOacgWPAAAENUg From: "MORAND Lionel RD-CORE-ISS" To: "Bernard Aboba" , Cc: X-OriginalArrivalTime: 20 Aug 2004 12:55:27.0493 (UTC) FILETIME=[F7540350:01C486B4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bernard, The original question was on the use of the same command code by = different diameter applications. Should the ABNF specification for this command code be remain unchanged = for fixed/required AVPs Or if a fixed/required AVP is added/remove to/from the original ABNF = specification, a new command code should be allocated (even if the = command is used by different applications)? Lionel =20 > -----Message d'origine----- > De : Bernard Aboba [mailto:aboba@internaut.com]=20 > Envoy=E9 : vendredi 20 ao=FBt 2004 14:34 > =C0 : john.loughney@nokia.com > Cc : MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu > Objet : Re: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit=20 > AVPs requires new Application-ID >=20 >=20 > > Fixed AVPs need to be there. Mandatory AVPs need to be=20 > there as well,=20 > > or an error will be generated. Optional AVPs are exactly as=20 > > advertised, they do not need to be present. >=20 > Yes, that was my understanding. >=20 From owner-aaa-wg@merit.edu Fri Aug 20 09:47:54 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13051 for ; Fri, 20 Aug 2004 09:47:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80C2291339; Fri, 20 Aug 2004 09:47:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51EAF9132F; Fri, 20 Aug 2004 09:47:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53B6E91339 for ; Fri, 20 Aug 2004 09:47:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 323915A7D5; Fri, 20 Aug 2004 09:47:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 5C7A55A93F for ; Fri, 20 Aug 2004 09:47:31 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KDlUq09460 for ; Fri, 20 Aug 2004 16:47:30 +0300 (EET DST) X-Scanned: Fri, 20 Aug 2004 16:44:28 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7KDiSSI021900 for ; Fri, 20 Aug 2004 16:44:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00WfkMFU; Fri, 20 Aug 2004 16:44:26 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7KDiJn04269 for ; Fri, 20 Aug 2004 16:44:19 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 16:44:03 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Aug 2004 16:44:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Date: Fri, 20 Aug 2004 16:44:03 +0300 Message-ID: <78577AECEB6226409F9F4BFB53FE1837072503@esebe054.ntc.nokia.com> Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID Thread-Index: AcSGsiR5OLSPeSy5QVeKpmu693nXBgAAG5ZQAAIzauA= From: To: X-OriginalArrivalTime: 20 Aug 2004 13:44:02.0704 (UTC) FILETIME=[C0EDE900:01C486BB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > Subtraction of mandatory AVPs would create interoperability problems, > therefore I think the command-code could not be re-used, so a new=20 > command code would be necessary. I think another solution is to change the Application-Id. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext=20 > Sent: 20 August, 2004 15:38 > To: aboba@internaut.com; lionel.morand@francetelecom.com > Cc: aaa-wg@merit.edu > Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs > requires new Application-ID >=20 >=20 > Hi Bernard, >=20 > > RFC 3588 indicates if you add AVPs with the 'M' bit set, a=20 > new application-ID is > > required, but optional AVPs don't require a new=20 > Application-ID. Or were > > you thinking of other ABNF changes? > >=20 > > I'm proposing that addition of AVPs (whatever the 'M' bit=20 > setting) should > > not require a new application-ID (although one could be=20 > used if desired). > > I'm not as sure about subtraction of mandatory AVPs; that=20 > would appear to > > create interoperability problems. >=20 > Subtraction of mandatory AVPs would create interoperability=20 > problems, therefore > I think the command-code could not be re-used, so a new=20 > command code would be > necessary. >=20 > John >=20 From owner-aaa-wg@merit.edu Fri Aug 20 09:50:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13198 for ; Fri, 20 Aug 2004 09:50:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8BC539132F; Fri, 20 Aug 2004 09:50:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50C049120D; Fri, 20 Aug 2004 09:50:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 413E09133A for ; Fri, 20 Aug 2004 09:49:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F0365A924; Fri, 20 Aug 2004 09:49:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 7EEEE5A9B3 for ; Fri, 20 Aug 2004 09:49:23 -0400 (EDT) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KDnJRv021226 for ; Fri, 20 Aug 2004 08:49:20 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Aug 2004 09:49:19 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7150E4605@oh0012itsa1.cb.lucent.com> From: "Wang, Yile Enoch (Enoch)" To: john.loughney@nokia.com, Marco.STURA@consultant.vodafoneomnitel.it Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Fri, 20 Aug 2004 09:49:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C486BC.7C4805C8" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C486BC.7C4805C8 Content-Type: text/plain John, 3GPP2 has standardized Radius based credit control for data network in IS-835C/X.S0011. There was discussion about introducing Diameter in IS-835E/F. However, I have not seen any contribution or draft yet. Thanks, Enoch -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, August 20, 2004 2:54 AM To: ewang@lucent.com; Marco.STURA@consultant.vodafoneomnitel.it Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Hi Yile, Are the current 3GPP2 specs alligned with the proposed RADIUS Credit Control work being standardized? There is some effort to align both RADIUS and Diameter in this aspect. John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Wang, Yile Enoch (Enoch) Sent: 20 August, 2004 05:50 To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Multiple service instances of the same service type Marco, I am more from the angle of CDMA2000 data support. Currently, IS-835C uses Radius to perform prepaid credit control and it allows multiple service instances of the same service option (e.g., value 60 stands for voice over IP) over one established PPP/credit control session. Credit quotas are allocated and maintained for individual service instances. Going forward, when we migrate to Diameter (IS-835E/F), MSCC is the best candidate for this type of multi-service credit control. I am currently struggling at what AVP to use in order to identify MSCCs to their corresponding service instances. Thanks, Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] Sent: Thursday, August 19, 2004 4:54 AM To: Wang, Yile Enoch (Enoch) Cc: aaa-wg@merit.edu Subject: RE: Multiple service instances of the same service type Enoch, I'm not sure I understand the real use case behind your suggestion, but as a matter of fact the technical content of the draft is definitely frozen. However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining new AVPs in the future. Regards Marco -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com] Sent: Thursday, August 19, 2004 12:49 AM To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: Multiple service instances of the same service type Marco and colleagues, MSCC provides a mechanism that allows multiple (sub)services in one credit control session. I noticed that Service-Identifier is included in MSCC to differentiate services. To my understanding, the use of Service-Identifier is not intended to identify run-time service instances. If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances? If not, do we need to introduce a Service-Instance-Identifier in MSCC? Thanks, Enoch ------_=_NextPart_001_01C486BC.7C4805C8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
John,
 
3GPP2=20 has standardized Radius based credit control for data network in=20 IS-835C/X.S0011.  There was discussion about introducing = Diameter in=20 IS-835E/F.  However, I have not seen any contribution or draft=20 yet.
 
Thanks,
 
Enoch
-----Original Message-----
From: = john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: Friday, August 20, = 2004 2:54=20 AM
To: ewang@lucent.com;=20 Marco.STURA@consultant.vodafoneomnitel.it
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: RE: Multiple service = instances=20 of the same service type

Hi=20 Yile,
 
Are=20 the current 3GPP2 specs alligned with the proposed RADIUS Credit = Control work=20 being standardized?  There is some effort to align both RADIUS and = Diameter=20 in this aspect.
 
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Wang, Yile = Enoch=20 (Enoch)
Sent: 20 August, 2004 05:50
To: STURA = Marco=20 Consultant
Cc: aaa-wg@merit.edu
Subject: = [AAA-WG]: RE:=20 Multiple service instances of the same service = type

Marco,
 
I am=20 more from the angle of CDMA2000 data support.
 
Currently, IS-835C uses Radius to perform = prepaid=20 credit control and it allows multiple service instances of the same = service=20 option (e.g., value 60 stands for voice over IP) over one established = PPP/credit control session.  Credit quotas are allocated = and=20 maintained for individual service instances.  Going forward, = when we=20 migrate to Diameter (IS-835E/F), MSCC is the best candidate for = this type=20 of multi-service credit control.  I am currently struggling at = what AVP=20 to use in order to identify MSCCs to their corresponding service=20 instances.
 
Thanks,
 
Enoch
-----Original Message-----
From: = STURA Marco=20 Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] =
Sent:=20 Thursday, August 19, 2004 4:54 AM
To: Wang, Yile Enoch=20 (Enoch)
Cc: aaa-wg@merit.edu
Subject: RE: = Multiple service=20 instances of the same service type

Enoch,

 

I'm not = sure I=20 understand the real use case behind your suggestion, but as a matter = of fact=20 the technical content of the draft is definitely=20 frozen.

However, = following=20 the RFC 3588 principles and the = recommendations in=20 sect. 4.1 of the DCC, it is possible to = extend the=20 DCC by defining new AVPs

in the=20 future.

 

Regards

Marco

 

 

-----Original=20 Message-----
From: = Wang, Yile=20 Enoch (Enoch) [mailto:ewang@lucent.com]
Sent: Thursday, August 19, = 2004 12:49=20 AM
To: STURA Marco = Consultant
Cc:=20 aaa-wg@merit.edu
Subject:=20 Multiple service instances of the same service type

 

Marco=20 and colleagues,

 

MSCC=20 provides a mechanism that allows multiple (sub)services in one credit = control=20 session.  I noticed that Service-Identifier is included in MSCC = to=20 differentiate services.  To my understanding, the use of=20 Service-Identifier is not intended to identify run-time service=20 instances.  If there are multiple services instances of the same = type=20 (e.g., voice service) within one credit control session, and a = separate credit=20 pool shall be maintained for each of the instance, do we have a = mechanism to=20 associate MSCCs to their corresponding service instances?  If = not, do we=20 need to introduce a Service-Instance-Identifier in=20 MSCC?

 

Thanks,

 

Enoch

------_=_NextPart_001_01C486BC.7C4805C8-- From owner-aaa-wg@merit.edu Fri Aug 20 09:59:55 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13767 for ; Fri, 20 Aug 2004 09:59:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 898ED9120D; Fri, 20 Aug 2004 09:59:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5737091338; Fri, 20 Aug 2004 09:59:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C8059120D for ; Fri, 20 Aug 2004 09:59:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF9605AD3B; Fri, 20 Aug 2004 09:59:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 8F2875ABE5 for ; Fri, 20 Aug 2004 09:59:40 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KDxbqX011146 for ; Fri, 20 Aug 2004 08:59:38 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Aug 2004 15:59:37 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505056723@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Aaa-Wg (E-mail)" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 20 Aug 2004 15:59:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk I had/have a vague recollection that the discussion about the M bit was part of the vendor extensions discussion that took place a few years back (was it Yokohama timeframe) and that had some heavy IESG involvmenet back then. SO I checked with IESG. Below is what Harald recalls. So it seems this cannot/should not be sent just as an erratum to RFC-Editor Thanks, Bert -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Friday, August 20, 2004 13:53 To: Wijnen, Bert (Bert); Iesg (E-mail) Subject: Re: Is this acceptable as erratum: RFC 3588 Errata: Adding 'M' bit A VPs requires new Application-ID I think this was quite deliberate, and should not be changed. This is based on what happened in CERT-land, X.400-land and other places.... Act 1: Protocols are defined, with extension mechansims Act 2: Multiple vendors field interoperable implementations Act 3: Evil Vendor (TM) fields an implementation that uses a mandatory extension - yet claims conformance to the spec. Act 4: Other vendors are unable to interoperate with Evil Vendor (TM) because they can't use his mandatory extension, and since it's mandatory, they can't even go on with reduced functionality. Act 5: Evil Vendor (TM) has locked competitors out of his marketplace.... It's "embrace and extend". And the rule against new M-bit extensions was to try to push non-interoperable usage of the protocol towards the Diameter version of a "new port" (new Application-ID): "If you want to be incompatible, that's OK - but not in OUR back yard". I won't say this is right in all cases.... there are multiple other ways to lock people out of a marketplace. But this was one small push towards making it a little more hard. Harald -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, August 19, 2004 12:30 To: aaa-wg@merit.edu Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID RFC 3588, Section 1.2.3 describes when a new authentication Application Identifier is needed. Section 1.2.4 describes when new accounting Application Identifiers are required. Included in the list of conditions requiring a new Application-ID is: " - Adding new AVPs to the command, which have the "M" bit set." Given the discussion since the publication of RFC 3588, I now believe that the above sentence is in error. A new Application-ID should not be required due to addition of AVPs to an application, whether the mandatory bit is set or not. I am curious what the WG thinks about this. Given that we are just now getting ready to publish Diameter applications as RFCs, it is possible to correct this mistake. Below I argue that letting this sentence remain in the spec could prove costly. ANALYSIS Section 1.2.3 states: "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application." So addition of an AVP by itself does not require a new Application-ID, if the 'M' bit is not set. So what is it about the 'M' bit that changes the situation so fundamentally? Let's review the purpose of the 'M' bit. The purpose of the Mandatory bit was to enable implementations that receive an AVP they do not support to determine whether they can ignore that AVP, or whether a fatal error has occurred. In other words, the purpose of the Mandatory bit was to enable Diameter applications to be extended while maintaining well defined behavior. Given this, if a Diameter application were to be extended with new AVPs without obtaining a new Application ID, what happens? Since no new Application-ID is used, Diameter peers will negotiate capabilities with the existing Application-IDs, oblivious as to whether new 'M' bit AVPs will be used or not. As a result, Diameter connections will be established all along the path between the Diameter peers. If the new AVPs do not have the 'M' bit set, then a Diameter peer can ignore them, presumably without harm. If the AVPs have the 'M' bit set, then a Diameter peer doesn't support them, then a fatal error will result -- but Diameter error messages will make it clear what the problem was. What is done on receipt of the error message is implementation dependent -- but one possibility would be to stop sending the offending AVP to the peer that objected. Note that in most cases, Diameter agents will not care about new AVPs, whether they have the 'M' bit set or not. Relays and Redirects won't care. Proxies might care -- but if they do then they can send their own fatal errors. Now let us look at what happens if a new Application-ID is required. Since Diameter peers exchange the supported Application-IDs within the CER/CEA exchange, if the new Application-IDs are not supported by one or more peers along the path, then the Diameter messages won't get routed to the destination. The end result is the same -- an attempt to send a non-understood AVP with the 'M' bit set will result in an Error-Message coming back, but now the error message will be returned from an intermediary unable to find a Diameter peer to deliver to, rather than from the endpoint peer. This is a bit like the distinction between receiving a "host unreachable" ICMP message and a "port unreachable" ICMP message. Not a great difference. However, consider the downside to requiring a new Application-ID due to addition of a new mandatory AVP: * Proliferation of Application-IDs. What if it is necessary to extend an application with multiple additional mandatory AVPs? Do we now need a new Application-ID for each potential set of mandatory AVPs? For example, what if we want to extend Diameter EAP with additional wired 802 VLAN attributes as well as some WLAN attributes and perhaps some filter attributes? Do we need to obtain 3 new application-IDs? Or as an alternative, do we require each application to support versioning? * Additional work in intermediaries. Do intermediaries now need a "Dictionary" of Application-IDs? Why isn't an AVP dictionary sufficient (if one is needed at all)? * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to extend NASREQ with some additional filter attributes. Does this mean that both NASREQ and EAP applications need new Application-IDs to support this? * Bureaucratic overhead. New Application-IDs are allocated by Expert Review. Who is volunteering to be the Expert to "review" all these new Application-IDs? Why isn't review of the new AVP definitions sufficient? Based on the limited upside and substantial downside of requiring new Application-IDs due to addition of AVPs with the 'M' bit set, my conclusion is that the sentence requiring this in RFC 3588 was an error. Assuming that the AAA WG agrees with this, then my recommendation is to post an errata to the RFC Editor to this effect. From owner-aaa-wg@merit.edu Fri Aug 20 11:08:22 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19458 for ; Fri, 20 Aug 2004 11:08:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 806799134B; Fri, 20 Aug 2004 11:05:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9D2D9134D; Fri, 20 Aug 2004 11:05:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06F6D9134B for ; Fri, 20 Aug 2004 11:03:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB2C45A93F; Fri, 20 Aug 2004 11:03:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 330BF5ABE9 for ; Fri, 20 Aug 2004 11:03:53 -0400 (EDT) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KF3mkH019954 for ; Fri, 20 Aug 2004 10:03:49 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Aug 2004 11:03:48 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7150E47C7@oh0012itsa1.cb.lucent.com> From: "Wang, Yile Enoch (Enoch)" To: STURA Marco Consultant , john.loughney@nokia.com, "Wang, Yile Enoch (Enoch)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Fri, 20 Aug 2004 11:03:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C486C6.E14FE454" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C486C6.E14FE454 Content-Type: text/plain Marco, Are you talking about 3GPP2 Prepaid draft for IS-835D? I checked the June version of draft but could not find Service-Id VSA. The service reference Id that identifies a particular service instance is assigned by the RAN and passed to PDSN when R-P is established. Its value is dynamic and entirely out of the control of core network. Each service instance belongs to a certain service option (e.g., 60 or 61 are for Voice over IP). For example, if I make a three-way voice call over my data session, two service instances, with reference ids 111 and 222, are established for service option 60. Each of the call leg has its own credit quota. When I tear down the data session, all ongoing service instances, including the two voice call legs are also terminated. The problem I am facing here is to associate service instance, created at the RAN side, with the quota allocated by the core network. My struggle here is the intended semantics of Service-Identifier. Practically, we can just use it. However, I want to use it in the right way that IETF purposed. My study of the Credit Control Application convinced me that Service-Identifier is intended to identify a specific service (type). When a suite of services share the same rate, then can be further aggregated in the same rating group. Service-Identifier would be a key, if Rating-Group is absent, that determines the rate of a service. Its values shall be statically pre-defined, therefore not suitable to identify service instances. The reason that I am reluctant to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit manipulation. MSCC is more economy than sub-session. Thanks, Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] Sent: Friday, August 20, 2004 4:00 AM To: john.loughney@nokia.com; ewang@lucent.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Hi, I have been checking the last RADIUS prepaid draft and it seems they use the Service-Id to identify a service instance. Enoch, why wouldn't you use the Service-Identifier? For instance you could specify in your DCC service specific document that Service-Identifiers from 60 to 69 are used when multiple service instances of the VoIP service option are established. Where 60 is the first service instance established, 61 the second and so on until 69 (in this example 10 instances are possible). The combination of the Service-Context-Id and the Service-Identifier uniquely identify your VoIP service option. Alternatively, for each of the service instances you could open a separate CC-sub-session. Just a thought. What do you think? Regards Marco -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, August 20, 2004 8:54 AM To: ewang@lucent.com; STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Hi Yile, Are the current 3GPP2 specs alligned with the proposed RADIUS Credit Control work being standardized? There is some effort to align both RADIUS and Diameter in this aspect. John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Wang, Yile Enoch (Enoch) Sent: 20 August, 2004 05:50 To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Multiple service instances of the same service type Marco, I am more from the angle of CDMA2000 data support. Currently, IS-835C uses Radius to perform prepaid credit control and it allows multiple service instances of the same service option (e.g., value 60 stands for voice over IP) over one established PPP/credit control session. Credit quotas are allocated and maintained for individual service instances. Going forward, when we migrate to Diameter (IS-835E/F), MSCC is the best candidate for this type of multi-service credit control. I am currently struggling at what AVP to use in order to identify MSCCs to their corresponding service instances. Thanks, Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] Sent: Thursday, August 19, 2004 4:54 AM To: Wang, Yile Enoch (Enoch) Cc: aaa-wg@merit.edu Subject: RE: Multiple service instances of the same service type Enoch, I'm not sure I understand the real use case behind your suggestion, but as a matter of fact the technical content of the draft is definitely frozen. However, following the RFC 3588 principles and the recommendations in sect. 4.1 of the DCC, it is possible to extend the DCC by defining new AVPs in the future. Regards Marco -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com] Sent: Thursday, August 19, 2004 12:49 AM To: STURA Marco Consultant Cc: aaa-wg@merit.edu Subject: Multiple service instances of the same service type Marco and colleagues, MSCC provides a mechanism that allows multiple (sub)services in one credit control session. I noticed that Service-Identifier is included in MSCC to differentiate services. To my understanding, the use of Service-Identifier is not intended to identify run-time service instances. If there are multiple services instances of the same type (e.g., voice service) within one credit control session, and a separate credit pool shall be maintained for each of the instance, do we have a mechanism to associate MSCCs to their corresponding service instances? If not, do we need to introduce a Service-Instance-Identifier in MSCC? Thanks, Enoch ------_=_NextPart_001_01C486C6.E14FE454 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Marco,
 
Are=20 you talking about 3GPP2 Prepaid draft for IS-835D?  I checked the = June=20 version of draft but could not find Service-Id VSA.
 
The=20 service reference Id that identifies a particular service = instance is=20 assigned by the RAN and passed to PDSN when R-P is established.  = Its value=20 is dynamic and entirely out of the control of core network.  Each = service=20 instance belongs to a certain service option (e.g., 60 or 61 are for = Voice over=20 IP).  For example, if I make a three-way voice call over my data = session,=20 two service instances, with reference ids 111 and 222, are established = for=20 service option 60.  Each of the call leg has its own credit = quota. =20 When I tear down the data session, all ongoing service = instances,=20 including the two voice call legs are also terminated.  The = problem I am=20 facing here is to associate service instance, created at the RAN side, = with the=20 quota allocated by the core network.
 
My struggle here is = the intended=20 semantics of Service-Identifier.  Practically, we can just use = it. =20 However, I want to use it in the right way that IETF purposed.  My = study of=20 the Credit Control Application convinced me that Service-Identifier is = intended=20 to identify a specific service (type).  When a suite of services = share the=20 same rate, then can be further aggregated in the same rating = group. =20 Service-Identifier would be a key, if Rating-Group is absent, that = determines the rate of a service.  Its values shall = be statically=20 pre-defined, therefore not suitable to identify service = instances.
 
The reason that I am reluctant to use sub-session is that it = forces=20 individual CCR/CCA messages for each sub-session credit = manipulation.  MSCC=20 is more economy than sub-session.
 
Thanks,
 
Enoch
 
-----Original Message-----
From: STURA Marco = Consultant=20 [mailto:Marco.STURA@consultant.vodafoneomnitel.it]
Sent: = Friday,=20 August 20, 2004 4:00 AM
To: john.loughney@nokia.com;=20 ewang@lucent.com
Cc: aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 RE: Multiple service instances of the same service = type

Hi,

 

I have been = checking=20 the last RADIUS prepaid draft and it seems they use the Service-Id to = identify a=20 service instance.

 

Enoch, why = wouldn't you=20 use the Service-Identifier? For instance you could specify in your DCC = service=20 specific document that

Service-Identifiers=20 from 60 to 69 are used when multiple service instances of the VoIP = service=20 option are established. Where 60

is the first = service=20 instance established, 61 the second and so on until 69 (in this example = 10=20 instances are possible).

 

The = combination of the=20 Service-Context-Id and the Service-Identifier uniquely identify your = VoIP=20 service option.

 

Alternatively, for each=20 of the service instances you could open a separate=20 CC-sub-session.

 

Just a = thought. What do=20 you think?

 

Regards

Marco

-----Original=20 Message-----
From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Friday, August 20, 2004 = 8:54=20 AM
To: = ewang@lucent.com; STURA=20 Marco Consultant
Cc: = aaa-wg@merit.edu
Subject: RE:=20 [AAA-WG]: RE: Multiple service instances of the same service=20 type

 

Hi=20 Yile,

 

Are the=20 current 3GPP2 specs alligned with the proposed RADIUS Credit Control = work being=20 standardized?  There is some effort to align both RADIUS and = Diameter in=20 this aspect.

 

John

-----Original=20 Message-----
From: = owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Wang, Yile = Enoch=20 (Enoch)
Sent: 20 = August, 2004=20 05:50
To: STURA = Marco=20 Consultant
Cc:=20 aaa-wg@merit.edu
Subject:=20 [AAA-WG]: RE: Multiple service instances of the same service=20 type

Marco,

 

I am=20 more from the angle of CDMA2000 data=20 support.

 

Currently, = IS-835C=20 uses Radius to perform prepaid credit control and it allows multiple = service=20 instances of the same service option (e.g., value 60 stands for voice = over IP)=20 over one established PPP/credit control session.  Credit = quotas are=20 allocated and maintained for individual service instances.  = Going=20 forward, when we migrate to Diameter (IS-835E/F), MSCC is the = best=20 candidate for this type of multi-service credit control.  I am = currently=20 struggling at what AVP to use in order to identify MSCCs to their=20 corresponding service instances.

 

Thanks,

 

Enoch

-----Original=20 Message-----
From: = STURA=20 Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it]=20
Sent: Thursday, = August 19,=20 2004 4:54 AM
To: = Wang, Yile=20 Enoch (Enoch)
Cc:=20 aaa-wg@merit.edu
Subject: RE:=20 Multiple service instances of the same service=20 type

Enoch,

 

I'm not=20 sure I understand the real use case behind your suggestion, but as a = matter of=20 fact the technical content of the draft is definitely=20 frozen.

However,=20 following the RFC 3588 principles and the recommendations in sect. = 4.1 of the=20 DCC, it is possible to extend the DCC by defining new=20 AVPs

in the=20 future.

 

Regards

Marco

 

 

-----Original=20 Message-----
From: = Wang, Yile=20 Enoch (Enoch) [mailto:ewang@lucent.com]
Sent: Thursday, August 19, = 2004 12:49=20 AM
To: STURA Marco = Consultant
Cc:=20 aaa-wg@merit.edu
Subject:=20 Multiple service instances of the same service=20 type

 

Marco=20 and colleagues,

 

MSCC=20 provides a mechanism that allows multiple (sub)services in one credit = control=20 session.  I noticed that Service-Identifier is included in MSCC = to=20 differentiate services.  To my understanding, the use of=20 Service-Identifier is not intended to identify run-time service=20 instances.  If there are multiple services instances of the same = type=20 (e.g., voice service) within one credit control session, and a = separate credit=20 pool shall be maintained for each of the instance, do we have a = mechanism to=20 associate MSCCs to their corresponding service instances?  If = not, do we=20 need to introduce a Service-Instance-Identifier in=20 MSCC?

 

Thanks,

 

Enoch

------_=_NextPart_001_01C486C6.E14FE454-- From owner-aaa-wg@merit.edu Fri Aug 20 12:11:19 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24188 for ; Fri, 20 Aug 2004 12:11:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4065391210; Fri, 20 Aug 2004 12:11:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05DED91211; Fri, 20 Aug 2004 12:11:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76D5091210 for ; Fri, 20 Aug 2004 12:11:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 596C55AE42; Fri, 20 Aug 2004 12:11:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id 158185AF03 for ; Fri, 20 Aug 2004 12:11:04 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i7KGAvHC019695 for ; Fri, 20 Aug 2004 18:10:57 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Aug 2004 18:10:55 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C486D0.457A6CBC" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Fri, 20 Aug 2004 18:10:55 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906406266@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: RE: Multiple service instances of the same service type Thread-Index: AcSGxzqHbcyKfhfrTuu+Wn2mL/y3TQAAT/EA From: "STURA Marco Consultant" To: "Wang, Yile Enoch (Enoch)" Cc: , X-OriginalArrivalTime: 20 Aug 2004 16:10:55.0595 (UTC) FILETIME=[45D25BB0:01C486D0] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C486D0.457A6CBC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Are you talking about 3GPP2 Prepaid draft for IS-835D? I checked the June version of draft but could not find Service-Id VSA. =20 No, I'm talking about this one http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions -05.txt. =20 Sub-Type (=3D10) : Sub-Type for Service ID=20 Length : Length of Service ID=20 =20 =20 Service-Id: =20 =20 Opaque string that uniquely describes a service instance for which=20 we want to apply prepaid metering to. A Service-Id could be an IP=20 5-tuple (source address, source port, destination address,=20 destination port, protocol). If Service-ID is present in the PPAQ=20 the PPAQ applies to that Service. If a PPAQ does not contain a=20 Service-Id then the PPAQ applies to the Access Service.=20 =20 >The service reference Id that identifies a particular service instance is assigned by the RAN and passed to PDSN when R-P is established. Its value is dynamic and >entirely out of the control of core network. Each service instance belongs to a certain service option (e.g., 60 or 61 are for Voice over IP). For example, if I make a three->way voice call over my data session, two service instances, with reference ids 111 and 222, are established for service option 60. Each of the call leg has its own credit >quota. When I tear down the data session, all ongoing service instances, including the two voice call legs are also terminated. The problem I am facing here is to >associate service instance, created at the RAN side, with the quota allocated by the core network. =20 I'm not very familiar with how the service instances are assigned, thank you for the clarification.=20 But, couldn't the PDSN map the first instance (whatever is its RAN generated reference) to the SI value of 61, the second instance (whatever is its RAN reference) to the SI value of 62 and so on and maintain the mapping for the duration of the service instance? =20 If the cost of the access is determined by the service option, it would be possible to group Service-Identifiers 60 to 69 under a Rating-group. Then the DCC-S could decide to authorize the whole rating-group (i.e. all the service instances will draw from the same credit quota) or a single service instance (i.e. one credit quota per each of the service instances). =20 >My struggle here is the intended semantics of Service-Identifier. Practically, we can just use it. However, I want to use it in the right way that IETF purposed. My study >of the Credit Control Application convinced me that Service-Identifier is intended to identify a specific service (type). When a suite of services share the same rate, then >can be further aggregated in the same rating group. Service-Identifier would be a key, if Rating-Group is absent, that determines the rate of a service. Its values shall >be statically pre-defined, therefore not suitable to identify service instances. =20 I think you got it right. But the value of the Service-Identifier is not necessarily pre-defined, it can be dynamic if you have a mechanism in your environment to do this. How the Rating-Groups and Service-identifiers are provisioned/determined is actually out of the scope of the DCC specification. =20 >The reason that I am reluctant to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit manipulation. MSCC is more economy >than sub-session. =20 I understand. =20 I hope this help Marco ------_=_NextPart_001_01C486D0.457A6CBC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

> Are you talking about 3GPP2 Prepaid draft for IS-835D?  I checked the June version of draft but could not find Service-Id VSA.

 

No, I’m talking about this = one http://www.ietf.org/internet-drafts/draft-lior-radius-pre= paid-extensions-05.txt.

 

Sub-Type (=3D10) : Sub-Type for Service ID =

   Length       &nbs=
p; : Length of Service ID =

       &nbs=
p;            =
;
    
   Service-Id:  
    
     Opaque =
string that uniquely describes a service instance for which =

     we want =
to apply prepaid metering to.  =
A Service-Id could be an IP =

     5-tuple (source address, source port, destination address, 
     destinati=
on port, protocol).  =
If Service-ID is present in the PPAQ 
     the =
PPAQ applies to that Service.  If a PPAQ does not contain a =

     Service-I=
d then the PPAQ applies to the Access Service. =

 

>The service reference Id that identifies a particular service instance is assigned by the RAN and = passed to PDSN when R-P is established.  Its = value is dynamic and >entirely out of the control of core network.  Each = service instance belongs to a certain service option (e.g., 60 or 61 are for = Voice over IP).  For example, if I make a three->way voice call over my = data session, two service instances, with reference ids 111 and 222, are = established for service option 60.  Each of the call leg has its own credit = >quota.  When I tear down the data session, all ongoing service = instances, including the two voice call legs are also terminated.  The problem = I am facing here is to >associate service instance, created at the RAN = side, with the quota allocated by the core network.

 

I’m not very familiar with = how the service instances are assigned, thank you for the clarification. =

But, couldn’t the PDSN map the first instance (whatever is its RAN = generated reference) to the SI value of 61, the second = instance (whatever is its RAN reference) to the SI = value of 62 and so on and maintain the mapping for the duration of the service = instance?

 

If the cost of the access is = determined by the service option, it would be possible to group Service-Identifiers 60 = to 69 under a Rating-group. Then the DCC-S could = decide to authorize the whole rating-group (i.e. all the service instances will = draw from the same credit quota) or a single service instance (i.e. one credit = quota per each of the service instances).

 

>My struggle here is the = intended semantics of Service-Identifier.  Practically, we can just use = it.  However, I want to use it in the right way that IETF purposed.  My study >of the Credit Control Application convinced = me that Service-Identifier is intended to identify a specific service (type).  When a suite of services share the same rate, then >can = be further aggregated in the same rating group.  Service-Identifier = would be a key, if Rating-Group is absent, that determines the rate of a service.  Its values shall >be statically pre-defined, therefore not suitable to identify service instances.

 

I think you got it right. But the = value of the Service-Identifier is not necessarily pre-defined, it can be dynamic = if you have a mechanism in your environment to do = this.

How the Rating-Groups and Service-identifiers are provisioned/determined is actually out of the = scope of the DCC = specification.

 

>The reason that I am reluctant = to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit manipulation.  MSCC is more economy >than sub-session.

 

I = understand.

 

I hope this = help

Marco

=00 ------_=_NextPart_001_01C486D0.457A6CBC-- From owner-aaa-wg@merit.edu Fri Aug 20 14:38:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04581 for ; Fri, 20 Aug 2004 14:38:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 239FB91368; Fri, 20 Aug 2004 14:36:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E70D691366; Fri, 20 Aug 2004 14:36:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 473009121A for ; Fri, 20 Aug 2004 14:36:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EADE6EA07; Fri, 20 Aug 2004 14:36:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 2E2125AFDF for ; Fri, 20 Aug 2004 14:36:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7KIVIh01570; Fri, 20 Aug 2004 11:31:18 -0700 Date: Fri, 20 Aug 2004 11:31:18 -0700 (PDT) From: Bernard Aboba To: "Wijnen, Bert (Bert)" Cc: "Aaa-Wg (E-mail)" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15505056723@nl0006exch001u.nl.lucent.com> Message-ID: References: <7D5D48D2CAA3D84C813F5B154F43B15505056723@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Since some additional issues have arisen (such as command code reuse), it's probably appropriate to write a short document on the subject to clarify the issues, and update RFC 3588. Note that we've been discussing IETF standard uses of the protocol, and the interoperability problems caused by Application-IDs in that standard usage. Extension by Vendor-Specific AVPs requires more careful analysis, but that's not been the focus of the discussion so far. However, even there, I believe that requiring a new Application-ID for *each* vendor-specific AVP probably makes no sense. On Fri, 20 Aug 2004, Wijnen, Bert (Bert) wrote: > I had/have a vague recollection that the discussion about the M bit was > part of the vendor extensions discussion that took place a few years > back (was it Yokohama timeframe) and that had some heavy IESG > involvmenet back then. SO I checked with IESG. > > Below is what Harald recalls. So it seems this cannot/should not be sent > just as an erratum to RFC-Editor > > Thanks, Bert > > > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Friday, August 20, 2004 13:53 > To: Wijnen, Bert (Bert); Iesg (E-mail) > Subject: Re: Is this acceptable as erratum: RFC 3588 Errata: Adding 'M' > bit A VPs requires new Application-ID > > > I think this was quite deliberate, and should not be changed. > This is based on what happened in CERT-land, X.400-land and other places.... > > Act 1: Protocols are defined, with extension mechansims > Act 2: Multiple vendors field interoperable implementations > Act 3: Evil Vendor (TM) fields an implementation that uses a mandatory > extension - yet claims conformance to the spec. > Act 4: Other vendors are unable to interoperate with Evil Vendor (TM) > because they can't use his mandatory extension, and since it's mandatory, > they can't even go on with reduced functionality. > Act 5: Evil Vendor (TM) has locked competitors out of his marketplace.... > > It's "embrace and extend". And the rule against new M-bit extensions was to > try to push non-interoperable usage of the protocol towards the Diameter > version of a "new port" (new Application-ID): "If you want to be > incompatible, that's OK - but not in OUR back yard". > > I won't say this is right in all cases.... there are multiple other ways to > lock people out of a marketplace. But this was one small push towards > making it a little more hard. > > Harald > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, August 19, 2004 12:30 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new > Application-ID > > > RFC 3588, Section 1.2.3 describes when a new authentication Application > Identifier is needed. Section 1.2.4 describes when new accounting > Application Identifiers are required. > > Included in the list of conditions requiring a new Application-ID is: > > " - Adding new AVPs to the command, which have the "M" bit set." > > Given the discussion since the publication of RFC 3588, I now believe that > the above sentence is in error. A new Application-ID should not be > required due to addition of AVPs to an application, whether the mandatory > bit is set or not. > > I am curious what the WG thinks about this. Given that we are just now > getting ready to publish Diameter applications as RFCs, it is possible to > correct this mistake. Below I argue that letting this sentence remain in > the spec could prove costly. > > ANALYSIS > > Section 1.2.3 states: > > "An implementation MAY add arbitrary non-mandatory AVPs to any command > defined in an application, including vendor-specific AVPs without > needing to define a new application." > > So addition of an AVP by itself does not require a new > Application-ID, if the 'M' bit is not set. > > So what is it about the 'M' bit that changes the situation so > fundamentally? > > Let's review the purpose of the 'M' bit. > > The purpose of the Mandatory bit was to enable implementations > that receive an AVP they do not support to determine whether they can > ignore that AVP, or whether a fatal error has occurred. > > In other words, the purpose of the Mandatory bit was to enable Diameter > applications to be extended while maintaining well defined behavior. > > Given this, if a Diameter application were to be extended with new AVPs > without obtaining a new Application ID, what happens? > > Since no new Application-ID is used, Diameter peers will negotiate > capabilities with the existing Application-IDs, oblivious as to whether > new 'M' bit AVPs will be used or not. As a result, Diameter connections > will be established all along the path between the Diameter peers. > > If the new AVPs do not have the 'M' bit set, then a Diameter peer can > ignore them, presumably without harm. If the AVPs have the 'M' bit set, > then a Diameter peer doesn't support them, then a fatal error > will result -- but Diameter error messages will make it clear what the > problem was. What is done on receipt of the error message is > implementation dependent -- but one possibility would be to stop sending > the offending AVP to the peer that objected. > > Note that in most cases, Diameter agents will not care about new AVPs, > whether they have the 'M' bit set or not. Relays and Redirects won't > care. Proxies might care -- but if they do then they can send their own > fatal errors. > > Now let us look at what happens if a new Application-ID is required. > Since Diameter peers exchange the supported Application-IDs within the > CER/CEA exchange, if the new Application-IDs are not supported by one or > more peers along the path, then the Diameter messages won't get routed to > the destination. The end result is the same -- an attempt to send a > non-understood AVP with the 'M' bit set will result in an Error-Message > coming back, but now the error message will be returned from an > intermediary unable to find a Diameter peer to deliver to, rather than > from the endpoint peer. > > This is a bit like the distinction between receiving a "host unreachable" > ICMP message and a "port unreachable" ICMP message. Not a great > difference. > > However, consider the downside to requiring a new Application-ID due to > addition of a new mandatory AVP: > > * Proliferation of Application-IDs. > > What if it is necessary to extend an application with multiple > additional mandatory AVPs? Do we now need a new Application-ID for > each potential set of mandatory AVPs? For example, what if we want to > extend Diameter EAP with additional wired 802 VLAN attributes as well as > some WLAN attributes and perhaps some filter attributes? Do we need to > obtain 3 new application-IDs? > > Or as an alternative, do we require each application to support > versioning? > > * Additional work in intermediaries. Do intermediaries now need a > "Dictionary" of Application-IDs? Why isn't an AVP dictionary sufficient > (if one is needed at all)? > > * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to > extend NASREQ with some additional filter attributes. Does this mean that > both NASREQ and EAP applications need new Application-IDs to support this? > > * Bureaucratic overhead. New Application-IDs are allocated by Expert > Review. Who is volunteering to be the Expert to "review" all these new > Application-IDs? Why isn't review of the new AVP definitions sufficient? > > Based on the limited upside and substantial downside of requiring new > Application-IDs due to addition of AVPs with the 'M' bit set, my > conclusion is that the sentence requiring this in RFC 3588 was an error. > Assuming that the AAA WG agrees with this, then my recommendation is to > post an errata to the RFC Editor to this effect. > From owner-aaa-wg@merit.edu Fri Aug 20 15:13:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07327 for ; Fri, 20 Aug 2004 15:13:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC50891335; Fri, 20 Aug 2004 15:12:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A21D49121A; Fri, 20 Aug 2004 15:12:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BCD49121A for ; Fri, 20 Aug 2004 15:12:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DAC95AF39; Fri, 20 Aug 2004 15:12:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 247195AEBB for ; Fri, 20 Aug 2004 15:12:55 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KJCqYg007550 for ; Fri, 20 Aug 2004 14:12:53 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Aug 2004 21:12:52 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155050567A7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Bernard Aboba Cc: "Aaa-Wg (E-mail)" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 20 Aug 2004 21:12:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard writes: > > Since some additional issues have arisen (such as command code > reuse), it's probably appropriate to write a short document on the > subject to clarify the issues, and update RFC 3588. > That would be fine as it will go through the normal consensus building process. If times/circumstances change we must re-evaluate and sometimes that leads to changes in our earlier documents. I was just worried that you would do this simply by posting an erratum, which seems not the best/correct way of handling it, specifically given earlier conscious evaluation of the topic (or so I recall). > Note that we've been discussing IETF standard uses of the protocol, and > the interoperability problems caused by Application-IDs in that standard > usage. Extension by Vendor-Specific AVPs requires more careful analysis, > but that's not been the focus of the discussion so far. However, even > there, I believe that requiring a new Application-ID for *each* > vendor-specific AVP probably makes no sense. > Looking forward to a possible upcoming document. Bert > > On Fri, 20 Aug 2004, Wijnen, Bert (Bert) wrote: > > > I had/have a vague recollection that the discussion about > the M bit was > > part of the vendor extensions discussion that took place a few years > > back (was it Yokohama timeframe) and that had some heavy IESG > > involvmenet back then. SO I checked with IESG. > > > > Below is what Harald recalls. So it seems this > cannot/should not be sent > > just as an erratum to RFC-Editor > > > > Thanks, Bert > > > > > > -----Original Message----- > > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > > Sent: Friday, August 20, 2004 13:53 > > To: Wijnen, Bert (Bert); Iesg (E-mail) > > Subject: Re: Is this acceptable as erratum: RFC 3588 > Errata: Adding 'M' > > bit A VPs requires new Application-ID > > > > > > I think this was quite deliberate, and should not be changed. > > This is based on what happened in CERT-land, X.400-land and > other places.... > > > > Act 1: Protocols are defined, with extension mechansims > > Act 2: Multiple vendors field interoperable implementations > > Act 3: Evil Vendor (TM) fields an implementation that uses > a mandatory > > extension - yet claims conformance to the spec. > > Act 4: Other vendors are unable to interoperate with Evil > Vendor (TM) > > because they can't use his mandatory extension, and since > it's mandatory, > > they can't even go on with reduced functionality. > > Act 5: Evil Vendor (TM) has locked competitors out of his > marketplace.... > > > > It's "embrace and extend". And the rule against new M-bit > extensions was to > > try to push non-interoperable usage of the protocol towards > the Diameter > > version of a "new port" (new Application-ID): "If you want to be > > incompatible, that's OK - but not in OUR back yard". > > > > I won't say this is right in all cases.... there are > multiple other ways to > > lock people out of a marketplace. But this was one small > push towards > > making it a little more hard. > > > > Harald > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Thursday, August 19, 2004 12:30 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new > > Application-ID > > > > > > RFC 3588, Section 1.2.3 describes when a new authentication > Application > > Identifier is needed. Section 1.2.4 describes when new accounting > > Application Identifiers are required. > > > > Included in the list of conditions requiring a new > Application-ID is: > > > > " - Adding new AVPs to the command, which have the "M" bit set." > > > > Given the discussion since the publication of RFC 3588, I > now believe that > > the above sentence is in error. A new Application-ID should not be > > required due to addition of AVPs to an application, whether > the mandatory > > bit is set or not. > > > > I am curious what the WG thinks about this. Given that we > are just now > > getting ready to publish Diameter applications as RFCs, it > is possible to > > correct this mistake. Below I argue that letting this > sentence remain in > > the spec could prove costly. > > > > ANALYSIS > > > > Section 1.2.3 states: > > > > "An implementation MAY add arbitrary non-mandatory AVPs to > any command > > defined in an application, including vendor-specific AVPs without > > needing to define a new application." > > > > So addition of an AVP by itself does not require a new > > Application-ID, if the 'M' bit is not set. > > > > So what is it about the 'M' bit that changes the situation so > > fundamentally? > > > > Let's review the purpose of the 'M' bit. > > > > The purpose of the Mandatory bit was to enable implementations > > that receive an AVP they do not support to determine > whether they can > > ignore that AVP, or whether a fatal error has occurred. > > > > In other words, the purpose of the Mandatory bit was to > enable Diameter > > applications to be extended while maintaining well defined behavior. > > > > Given this, if a Diameter application were to be extended > with new AVPs > > without obtaining a new Application ID, what happens? > > > > Since no new Application-ID is used, Diameter peers will negotiate > > capabilities with the existing Application-IDs, oblivious > as to whether > > new 'M' bit AVPs will be used or not. As a result, > Diameter connections > > will be established all along the path between the Diameter peers. > > > > If the new AVPs do not have the 'M' bit set, then a > Diameter peer can > > ignore them, presumably without harm. If the AVPs have the > 'M' bit set, > > then a Diameter peer doesn't support them, then a fatal error > > will result -- but Diameter error messages will make it > clear what the > > problem was. What is done on receipt of the error message is > > implementation dependent -- but one possibility would be to > stop sending > > the offending AVP to the peer that objected. > > > > Note that in most cases, Diameter agents will not care > about new AVPs, > > whether they have the 'M' bit set or not. Relays and > Redirects won't > > care. Proxies might care -- but if they do then they can > send their own > > fatal errors. > > > > Now let us look at what happens if a new Application-ID is required. > > Since Diameter peers exchange the supported Application-IDs > within the > > CER/CEA exchange, if the new Application-IDs are not > supported by one or > > more peers along the path, then the Diameter messages won't > get routed to > > the destination. The end result is the same -- an attempt > to send a > > non-understood AVP with the 'M' bit set will result in an > Error-Message > > coming back, but now the error message will be returned from an > > intermediary unable to find a Diameter peer to deliver to, > rather than > > from the endpoint peer. > > > > This is a bit like the distinction between receiving a > "host unreachable" > > ICMP message and a "port unreachable" ICMP message. Not a great > > difference. > > > > However, consider the downside to requiring a new > Application-ID due to > > addition of a new mandatory AVP: > > > > * Proliferation of Application-IDs. > > > > What if it is necessary to extend an application with multiple > > additional mandatory AVPs? Do we now need a new Application-ID for > > each potential set of mandatory AVPs? For example, what if > we want to > > extend Diameter EAP with additional wired 802 VLAN > attributes as well as > > some WLAN attributes and perhaps some filter attributes? > Do we need to > > obtain 3 new application-IDs? > > > > Or as an alternative, do we require each application to support > > versioning? > > > > * Additional work in intermediaries. Do intermediaries now need a > > "Dictionary" of Application-IDs? Why isn't an AVP > dictionary sufficient > > (if one is needed at all)? > > > > * Inheritance effects. Diameter EAP depends on NASREQ. > Say I want to > > extend NASREQ with some additional filter attributes. Does > this mean that > > both NASREQ and EAP applications need new Application-IDs > to support this? > > > > * Bureaucratic overhead. New Application-IDs are allocated > by Expert > > Review. Who is volunteering to be the Expert to "review" > all these new > > Application-IDs? Why isn't review of the new AVP > definitions sufficient? > > > > Based on the limited upside and substantial downside of > requiring new > > Application-IDs due to addition of AVPs with the 'M' bit set, my > > conclusion is that the sentence requiring this in RFC 3588 > was an error. > > Assuming that the AAA WG agrees with this, then my > recommendation is to > > post an errata to the RFC Editor to this effect. > > > From owner-aaa-wg@merit.edu Fri Aug 20 15:50:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09644 for ; Fri, 20 Aug 2004 15:50:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95CB69120C; Fri, 20 Aug 2004 15:50:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5954791218; Fri, 20 Aug 2004 15:50:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C7209120C for ; Fri, 20 Aug 2004 15:49:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42AB15ABE2; Fri, 20 Aug 2004 15:49:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id D2A375A750 for ; Fri, 20 Aug 2004 15:49:21 -0400 (EDT) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KJnJBv003227 for ; Fri, 20 Aug 2004 14:49:20 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Aug 2004 15:49:19 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7150E4D14@oh0012itsa1.cb.lucent.com> From: "Wang, Yile Enoch (Enoch)" To: STURA Marco Consultant , "Wang, Yile Enoch (Enoch)" Cc: aaa-wg@merit.edu, john.loughney@nokia.com Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Fri, 20 Aug 2004 15:49:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C486EE.C7AC864C" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C486EE.C7AC864C Content-Type: text/plain Marco, I am trying hard to figure out the exact meaning of Service-Identifier in credit control application. You confirmed my view through the discussion. Thanks for the help! Since Service-Identifier is not meant to reference run-time service instances, we can either hijack it (e.g., through a mapping mechanism as you suggested) or introduce a new AVP to further refine this overloaded AVP (as we did to Service-Context-Identifier). I am leaning toward the latter for the sake of clarity. When IS-835 starts to introduce Diameter, we might propose to introduce a 3GPP2 AVP to carry the service instance identifier in order to address this issue. I ran this issue through this board to 1) confirm that my understanding of Service-Identifier is correct, and 2) see if people would like to handle this generic issue at IETF level. Thanks, Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it] Sent: Friday, August 20, 2004 12:11 PM To: Wang, Yile Enoch (Enoch) Cc: aaa-wg@merit.edu; john.loughney@nokia.com Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type > Are you talking about 3GPP2 Prepaid draft for IS-835D? I checked the June version of draft but could not find Service-Id VSA. No, I'm talking about this one http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-05.txt . Sub-Type (=10) : Sub-Type for Service ID Length : Length of Service ID Service-Id: Opaque string that uniquely describes a service instance for which we want to apply prepaid metering to. A Service-Id could be an IP 5-tuple (source address, source port, destination address, destination port, protocol). If Service-ID is present in the PPAQ the PPAQ applies to that Service. If a PPAQ does not contain a Service-Id then the PPAQ applies to the Access Service. >The service reference Id that identifies a particular service instance is assigned by the RAN and passed to PDSN when R-P is established. Its value is dynamic and >entirely out of the control of core network. Each service instance belongs to a certain service option (e.g., 60 or 61 are for Voice over IP). For example, if I make a three->way voice call over my data session, two service instances, with reference ids 111 and 222, are established for service option 60. Each of the call leg has its own credit >quota. When I tear down the data session, all ongoing service instances, including the two voice call legs are also terminated. The problem I am facing here is to >associate service instance, created at the RAN side, with the quota allocated by the core network. I'm not very familiar with how the service instances are assigned, thank you for the clarification. But, couldn't the PDSN map the first instance (whatever is its RAN generated reference) to the SI value of 61, the second instance (whatever is its RAN reference) to the SI value of 62 and so on and maintain the mapping for the duration of the service instance? If the cost of the access is determined by the service option, it would be possible to group Service-Identifiers 60 to 69 under a Rating-group. Then the DCC-S could decide to authorize the whole rating-group (i.e. all the service instances will draw from the same credit quota) or a single service instance (i.e. one credit quota per each of the service instances). >My struggle here is the intended semantics of Service-Identifier. Practically, we can just use it. However, I want to use it in the right way that IETF purposed. My study >of the Credit Control Application convinced me that Service-Identifier is intended to identify a specific service (type). When a suite of services share the same rate, then >can be further aggregated in the same rating group. Service-Identifier would be a key, if Rating-Group is absent, that determines the rate of a service. Its values shall >be statically pre-defined, therefore not suitable to identify service instances. I think you got it right. But the value of the Service-Identifier is not necessarily pre-defined, it can be dynamic if you have a mechanism in your environment to do this. How the Rating-Groups and Service-identifiers are provisioned/determined is actually out of the scope of the DCC specification. >The reason that I am reluctant to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit manipulation. MSCC is more economy >than sub-session. I understand. I hope this help Marco ------_=_NextPart_001_01C486EE.C7AC864C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Marco,
 
I am=20 trying hard to figure out the exact meaning of Service-Identifier in = credit=20 control application.  You confirmed my view through the = discussion. =20 Thanks for the help!
 
Since=20 Service-Identifier is not meant to reference run-time service = instances, we can=20 either hijack it (e.g., through a mapping mechanism as you = suggested) or=20 introduce a new AVP to further refine this overloaded AVP (as we did to = Service-Context-Identifier). I am leaning toward the latter for the = sake of=20 clarity.  When IS-835 starts to introduce Diameter, we might = propose=20 to introduce a 3GPP2 AVP to carry the service instance identifier in = order to=20 address this issue.
 
I ran=20 this issue through this board to 1) confirm that my understanding of=20 Service-Identifier is correct, and 2) see if people would like to = handle=20 this generic issue at IETF level.
 
Thanks,
 
Enoch
-----Original Message-----
From: STURA Marco = Consultant=20 [mailto:Marco.STURA@consultant.vodafoneomnitel.it]
Sent: = Friday,=20 August 20, 2004 12:11 PM
To: Wang, Yile Enoch = (Enoch)
Cc:=20 aaa-wg@merit.edu; john.loughney@nokia.com
Subject: RE: = [AAA-WG]: RE:=20 Multiple service instances of the same service = type

> Are=20 you talking about 3GPP2 Prepaid draft for=20 IS-835D?  I checked the June version of draft but could not find = Service-Id=20 VSA.

 

No, I'm = talking about=20 this one http://www.ietf.org/internet-drafts/draft-lior-radius-p= repaid-extensions-05.txt.

 

Sub-Type (=3D10) : =
Sub-Type for Service ID 
   Length         : Length =
of Service ID 
           &=
nbsp;        <=
/SPAN>
    
=
   Service-Id:  
    
     Opaque =
string that uniquely describes a service instance for which =

     we want to apply prepaid =
metering to.  A =
Service-Id could be an IP 
     5-tuple (source address, source port, =
destination address, =

     destination port, protocol).  If Service-ID is present in the PPAQ 
     the =
PPAQ applies to that Service.  If a PPAQ does not contain a =

     Service-Id then the PPAQ applies to the Access Service. =

 

>The = service=20 reference Id that identifies a particular service instance is = assigned by=20 the RAN and passed to PDSN when R-P is=20 established.  Its value is dynamic and >entirely out of the = control of=20 core network.  Each service instance belongs to a certain service = option=20 (e.g., 60 or 61 are for Voice over IP).  For example, if I make a=20 three->way voice call over my data session, two service instances, = with=20 reference ids 111 and 222, are established for service option 60.  = Each of=20 the call leg has its own credit >quota.  When I tear = down the=20 data session, all ongoing service instances, including the two voice = call legs=20 are also terminated.  The problem I am facing here is to = >associate=20 service instance, created at the RAN side, with the quota allocated by = the core=20 network.

 

I'm not very = familiar=20 with how the service instances are assigned, thank you for the = clarification.=20

But, = couldn't the PDSN map the first instance (whatever is its RAN = generated=20 reference) to the SI value of 61, the = second instance=20 (whatever is its RAN reference) to the SI = value of 62=20 and so on and maintain the mapping for the duration of the service=20 instance?

 

If the cost = of the=20 access is determined by the service option, it would be possible to = group=20 Service-Identifiers 60 to 69 under a Rating-group. Then the DCC-S could decide to authorize the whole = rating-group (i.e.=20 all the service instances will draw from the same credit quota) or a = single=20 service instance (i.e. one credit quota per each of the service=20 instances).

 

>My = struggle here is=20 the intended semantics of Service-Identifier.  Practically, we can = just use=20 it.  However, I want to use it in the right way that IETF purposed.  My study >of the Credit = Control=20 Application convinced me that Service-Identifier is intended to = identify a=20 specific service (type).  When a suite of services share the same = rate,=20 then >can be further aggregated in the same rating group. =20 Service-Identifier would be a key, if Rating-Group is absent, that = determines the rate of a service.  Its values shall=20 >be statically pre-defined, therefore not suitable to identify = service=20 instances.

 

I think you = got it=20 right. But the value of the Service-Identifier is not necessarily = pre-defined,=20 it can be dynamic if you have a mechanism in your environment to do=20 this.

How the = Rating-Groups=20 and Service-identifiers are provisioned/determined is actually out of = the scope=20 of the DCC = specification.

 

>The = reason that I=20 am reluctant to use sub-session is that it forces individual CCR/CCA messages for each sub-session credit=20 manipulation.  MSCC is more economy = >than=20 sub-session.

 

I=20 understand.

 

I hope this=20 help

Marco

------_=_NextPart_001_01C486EE.C7AC864C-- From owner-aaa-wg@merit.edu Fri Aug 20 20:30:51 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26051 for ; Fri, 20 Aug 2004 20:30:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16B129121D; Fri, 20 Aug 2004 20:30:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FDD5912B2; Fri, 20 Aug 2004 20:30:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 430FF9121D for ; Fri, 20 Aug 2004 20:30:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B31875AFD2; Fri, 20 Aug 2004 20:30:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id BFA555AAA2 for ; Fri, 20 Aug 2004 20:30:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7L0OcN21436; Fri, 20 Aug 2004 17:24:38 -0700 Date: Fri, 20 Aug 2004 17:24:37 -0700 (PDT) From: Bernard Aboba To: "Wijnen, Bert (Bert)" Cc: "Aaa-Wg (E-mail)" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155050567A7@nl0006exch001u.nl.lucent.com> Message-ID: References: <7D5D48D2CAA3D84C813F5B154F43B155050567A7@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I was just worried that you would do this simply by posting an erratum, > which seems not the best/correct way of handling it, specifically given > earlier conscious evaluation of the topic (or so I recall). The early discussion has indicated that this issue deserves more consideration (and text) than an errata can provide. > Looking forward to a possible upcoming document. I look forward to writing it ;) From owner-aaa-wg@merit.edu Sat Aug 21 10:21:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15668 for ; Sat, 21 Aug 2004 10:21:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA27791227; Sat, 21 Aug 2004 10:21:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75C859126D; Sat, 21 Aug 2004 10:21:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B8BB91227 for ; Sat, 21 Aug 2004 10:21:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DA745AEC5; Sat, 21 Aug 2004 10:21:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 6DE445AB89 for ; Sat, 21 Aug 2004 10:21:03 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7LEKxAh005749 for ; Sat, 21 Aug 2004 16:20:59 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Aug 2004 16:20:59 +0200 Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.22.253]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PRJA57MN; Sat, 21 Aug 2004 16:20:59 +0200 Received: from madrid.ericsson.se ([159.107.1.110]) by wadias.es.eu.ericsson.se (8.12.10/8.12.10) with ESMTP id i7LEKint012340; Sat, 21 Aug 2004 16:20:48 +0200 (MET DST) Message-ID: <41275A12.8090609@madrid.ericsson.se> Date: Sat, 21 Aug 2004 16:20:02 +0200 X-Sybari-Trust: ac5706f6 74470f8f a74a52d8 00000138 From: MCarmen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Cc: radiusext@ops.ietf.org, AAA mailing list , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: Re: [AAA-WG]: Comments to Diameter SIP application References: <41138A9A.2040903@nokia.com> In-Reply-To: <41138A9A.2040903@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2004 14:20:59.0557 (UTC) FILETIME=[14B09550:01C4878A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Miguel, Regarding the Diameter SIP Application, I suggest to remove the User-Data-Request-Type AVP. We got to the conclusion in 3GPP that it is better to download the whole profile instead of splitting it into parts, since it may lead to unexpected error cases and inconsistencies between the diameter client and the diameter server data. br, MCarmen From owner-aaa-wg@merit.edu Mon Aug 23 03:21:44 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16942 for ; Mon, 23 Aug 2004 03:21:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B493791217; Mon, 23 Aug 2004 03:21:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84C3491206; Mon, 23 Aug 2004 03:21:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 451B191206 for ; Mon, 23 Aug 2004 03:21:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20DA55ACBB; Mon, 23 Aug 2004 03:21:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id C8AB96EA6E for ; Mon, 23 Aug 2004 03:21:28 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i7N7LLx1009775 for ; Mon, 23 Aug 2004 09:21:21 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Aug 2004 09:21:20 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C488E1.C928C4DE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: RE: Multiple service instances of the same service type Date: Mon, 23 Aug 2004 09:21:19 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906406267@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: RE: Multiple service instances of the same service type Thread-Index: AcSG7srtW49JAX/DR8ilaUehiHUx+gB8Pczg From: "STURA Marco Consultant" To: "Wang, Yile Enoch (Enoch)" Cc: , X-OriginalArrivalTime: 23 Aug 2004 07:21:20.0181 (UTC) FILETIME=[C9703650:01C488E1] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C488E1.C928C4DE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable >Since Service-Identifier is not meant to reference run-time service instances, we can either hijack it (e.g., through a mapping mechanism as you suggested) or introduce >a new AVP to further refine this overloaded AVP (as we did to Service-Context-Identifier). I am leaning toward the latter for the sake of clarity. When IS-835 starts to >introduce Diameter, we might propose to introduce a 3GPP2 AVP to carry the service instance identifier in order to address this issue. =20 Either one is feasible, I think.=20 Perhaps introducing a 3GPP2 AVP to carry the service instance semantic sounds like the best solution to your problem, you can define this AVP in your standard DCC service specific document (identified by the Service-Context-Id). This is absolutely feasible since the MSCC can be extended by means of *[AVP]. =20 Regards Marco ------_=_NextPart_001_01C488E1.C928C4DE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

>Since Service-Identifier is not = meant to reference run-time service instances, we can either hijack it (e.g., = through a mapping mechanism as you suggested) or introduce >a new AVP to further refine this overloaded AVP (as we did to = Service-Context-Identifier). I am leaning toward the latter for the sake of clarity.  When IS-835 = starts to >introduce Diameter, we might propose to introduce a 3GPP2 = AVP to carry the service instance identifier in order to address this = issue.

 

Either one is feasible, I think. =

Perhaps introducing a 3GPP2 AVP to = carry the service instance semantic sounds like the best solution to your = problem, you can define this AVP

in your standard DCC service = specific document (identified by the Service-Context-Id). This is absolutely = feasible since the MSCC can be extended

by means of = *[AVP].

 

Regards

=

Marco

=00 ------_=_NextPart_001_01C488E1.C928C4DE-- From owner-aaa-wg@merit.edu Mon Aug 23 03:50:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18665 for ; Mon, 23 Aug 2004 03:50:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 297FB91217; Mon, 23 Aug 2004 03:50:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C07AD9124A; Mon, 23 Aug 2004 03:50:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3947091206 for ; Mon, 23 Aug 2004 03:50:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D1606EA81; Mon, 23 Aug 2004 03:50:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 596185ADFA for ; Mon, 23 Aug 2004 03:50:22 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7N7lKq24571; Mon, 23 Aug 2004 10:47:20 +0300 (EET DST) X-Scanned: Mon, 23 Aug 2004 10:44:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7N7iTIU023672; Mon, 23 Aug 2004 10:44:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003Rs1lF; Mon, 23 Aug 2004 10:44:27 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7N7iRu00315; Mon, 23 Aug 2004 10:44:27 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 23 Aug 2004 10:44:24 +0300 Message-ID: <4129A058.6040503@nokia.com> Date: Mon, 23 Aug 2004 10:44:24 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: MCarmen Cc: AAA mailing list , Miguel-Angel Pallares , "Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: Re: [AAA-WG]: Comments to Diameter SIP application References: <41138A9A.2040903@nokia.com> <41275A12.8090609@madrid.ericsson.se> In-Reply-To: <41275A12.8090609@madrid.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2004 07:44:24.0983 (UTC) FILETIME=[02D83A70:01C488E5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mari Carmen: Thanks for sharing this information. My analysis of the situation: 3GPP had a requirement, sometime ago, to be able to download the whole user profile, or a fraction of it. It seems now that implementors have realized that this brings some extra complexity to the implementation and very little benefit. It seems that the only saving is a few bytes in memory and a few bytes in bandwidth, which is not a big deal since bandwidth is not so scarce in the core network. So, I would propose also that we remove the SIP-User-Data-Request-Type from the Diameter SIP app., since the presence there was solely a 3GPP requirement. If anyone has a concern, please raise it now. I have listed this as an open issue: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue18 Regards, Miguel MCarmen wrote: > Hi Miguel, > > Regarding the Diameter SIP Application, I suggest to remove the > User-Data-Request-Type AVP. We got to the conclusion in 3GPP that it is > better to download the whole profile instead of splitting it into parts, > since it may lead to unexpected error cases and inconsistencies between > the diameter client and the diameter server data. > > br, > MCarmen > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Aug 24 09:48:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06005 for ; Tue, 24 Aug 2004 09:48:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DBC6912B8; Tue, 24 Aug 2004 09:48:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1538D912B6; Tue, 24 Aug 2004 09:48:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3409912B8 for ; Tue, 24 Aug 2004 09:48:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D88A5A8F4; Tue, 24 Aug 2004 09:48:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 57FBA5AB26 for ; Tue, 24 Aug 2004 09:48:32 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ODmN111111; Tue, 24 Aug 2004 16:48:23 +0300 (EET DST) X-Scanned: Tue, 24 Aug 2004 16:46:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7ODkwwl006442; Tue, 24 Aug 2004 16:46:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00P4SN4v; Tue, 24 Aug 2004 16:46:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ODkjn20049; Tue, 24 Aug 2004 16:46:45 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Aug 2004 16:46:44 +0300 Message-ID: <412B46C4.8060905@nokia.com> Date: Tue, 24 Aug 2004 16:46:44 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani , "ext Beck01, Wolfgang" , AAA mailing list Subject: [AAA-WG]: [Diameter SIP app] Working -04 version Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2004 13:46:44.0155 (UTC) FILETIME=[CAD060B0:01C489E0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have a "working version" of draft -04 of Diameter SIP app. I will not submit this document yet until I have made all the required changes, but I make this copy available so that you can provide comments before I submit it. Text version: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.txt HTML version: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.html Diff version of -03 and -04: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-03-to-04.html Remaining open issues: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/ Please take a look at it, even to a small section if you don't have time to read the whole document, and provide comments. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Aug 26 10:17:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02925 for ; Thu, 26 Aug 2004 10:17:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9CFBD9120F; Thu, 26 Aug 2004 10:16:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EC18912EA; Thu, 26 Aug 2004 10:16:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C50B9120F for ; Thu, 26 Aug 2004 10:16:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 378D66EA4F; Thu, 26 Aug 2004 10:16:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from gtfw2.enterasys.com (gtfw2.enterasys.com [12.25.1.128]) by segue.merit.edu (Postfix) with ESMTP id B2E6E6ED7B for ; Thu, 26 Aug 2004 10:16:03 -0400 (EDT) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i7QEG0ao015408 for ; Thu, 26 Aug 2004 10:16:00 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 26 Aug 2004 10:16:00 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 26 Aug 2004 10:15:59 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 10:15:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: REMINDER: RADEXT WG last call on RFC 2486bis Date: Thu, 26 Aug 2004 10:15:13 -0400 Message-ID: Thread-Topic: [AAA-WG]: REMINDER: RADEXT WG last call on RFC 2486bis Thread-Index: AcSE70rrTSKJMrkWSWOTZWD6hx5FjQGh7/Mw From: "Nelson, David" To: X-OriginalArrivalTime: 26 Aug 2004 14:15:13.0624 (UTC) FILETIME=[1A902580:01C48B77] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 P:95.9108 R:95.9108 S:10.2183 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Last reminder -- this WGLC completes today. > This is a reminder of RADEXT WG Last Call in progress on "The Network > Access Identifier" specification, RFC 2486bis, prior to sending the draft > on to the IESG for consideration as an IETF Proposed Standard (recycled). > The draft is available for inspection at: >=20 > http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.tx t >=20 > RADEXT WG Last Call will complete on August 26, 2004. Please send > comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the > issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Thu Aug 26 10:27:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03935 for ; Thu, 26 Aug 2004 10:27:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDFB9912E9; Thu, 26 Aug 2004 10:26:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B902E912EC; Thu, 26 Aug 2004 10:26:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5725912E9 for ; Thu, 26 Aug 2004 10:26:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21A0F6EDFB; Thu, 26 Aug 2004 10:26:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 0C6216EE2E for ; Thu, 26 Aug 2004 10:15:08 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA18589 for ; Thu, 26 Aug 2004 10:19:13 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma018576; Thu, 26 Aug 04 10:18:59 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 26 Aug 2004 10:14:50 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 26 Aug 2004 10:14:49 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 10:14:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication Date: Thu, 26 Aug 2004 10:14:38 -0400 Message-ID: Thread-Topic: [AAA-WG]: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication Thread-Index: AcSE75WJB2u+DVfGQ9SHYLRo4qlyrAGh1vxA From: "Nelson, David" To: X-OriginalArrivalTime: 26 Aug 2004 14:14:39.0171 (UTC) FILETIME=[06070930:01C48B77] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 P:95.9108 R:95.9108 S: 6.6977 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Last reminder -- this WGLC completes today. > This is a reminder of the ongoing RADEXT WG Last Call on the "RADIUS > Extension > for Digest Authentication" specification, prior to sending the draft on to > the IESG for consideration as an IETF Proposed Standard. The > draft is available for inspection at: >=20 > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt >=20 > RADEXT WG Last Call will complete on August 26, 2004. Please send > comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the > issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. From owner-aaa-wg@merit.edu Thu Aug 26 16:43:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10005 for ; Thu, 26 Aug 2004 16:43:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B3F891226; Thu, 26 Aug 2004 16:43:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0D5091228; Thu, 26 Aug 2004 16:43:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7A3D91226 for ; Thu, 26 Aug 2004 16:43:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B79496EE7F; Thu, 26 Aug 2004 16:43:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 0A3B16EE7A for ; Thu, 26 Aug 2004 16:43:11 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1EF3D8986C; Thu, 26 Aug 2004 23:43:04 +0300 (EEST) Message-ID: <412E4B3B.4020007@kolumbus.fi> Date: Thu, 26 Aug 2004 23:42:35 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: review of draft-ietf-aaa-diameter-sip-04.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I read the draft, and it looks very good! I do have a few technical and editorial comments, however -- see below. --Jari P.S. Sorry for being so late. And I'm still working on draft-sterman... TECHNICAL ========= > 5.1 General architecture > > The Diameter SIP application can be used in a SIP environment where > an interface to a AAA infrastructure is required to authenticate, > authorize or provide accounting information. Figure 1 below shows a You talk about accounting above, but yet this spec does not define any specific accounting AVPs for SIP. Do you expect base accounting to be used as-is, is accounting out of scope for you, or should you be talking about what SIP-specific AVPs can and should appear in accounting requests? > This application does not require or is not related to other > authentication services provided by the Mobile IP Diameter > [I-D.ietf-aaa-diameter-mobileip] or the Network Access Server > Diameter [I-D.ietf-aaa-diameter-nasreq] applications. What about Diameter CC/prepaid? I think the reader may be interested in whether this application works together with that. > +--------+ +--------+ +--------+ > | SIP | |Diameter| | SIP | > |server 1| | server | |server 2| > +--------+ +--------+ +--------+ > | | | > 1. SIP REGISTER | | | > -------------------->| 2. UAR | | > |------------------>| | > | 3. UAA | | > |<------------------| | > | 4. SIP REGISTER | > |-------------------------------------->| > | | 5. MAR | > | |<------------------| > | | 6. MAA | > | |------------------>| So, how does a SIP server know that it is of type 1 or type 2? I would presume that there can be a case where this choice depends on the particular user. For instance, some local users are known and authenticated by the server, but for others we pass the SIP request somewhere else. > SIP server 1 will forward the SIP REGISTER request (step 4) to an > appropriate SIP server (SIP server 2). The Diameter client in SIP > server 2 will then request user authentication from the Diameter > server by sending a Diameter Multimedia-Auth-Request (MAR) message Question: Can the Diameter server decide that this particular SIP request does not require authentication? Can I use just the routing aspect of this spec, or do I always need to authenticate too? > If the Diameter client in SIP server 2 is interested in downloading > the user profile information, then it will send a Diameter SAR > message (step 17) to the Diameter server. The Diameter server will > reply with a Diameter SAA message (step 18) that contains the > requested user profile information. These actions are only needed > when the SIP server needs to retrieve a user profile used to provide > services to the served user. Question: Does the download exchange have to happen in a separate roundtrip, or can we do it in parallel with the MAR/MAA? And why do we need a separate message, this does not seem to be the case in other applications such as NASREQ, all authz information is provided in the same return messages? > If the Diameter server requires a User-Name AVP value to process the > Diameter PPR request, but the Diameter PPR message did not contain a I'm not sure I understand how the user name would not be required. Would this be a global profile change for all users? > [RFC3588]). The location of the authentication user name in the SIP > REGISTER request varies depending on the authentication mechanism. > When the authentication mechanism is HTTP Digest as defined in RFC > 2617 [RFC2617], the authentication user name is found in the > "username" directive of the SIP Authorization header field value. Is there some other alternative? A current one? If not, it might be better to say that you support HTTP Digest only. > 8.11 SIP-User-Data AVP > > The SIP-User-Data AVP (AVP Code TBD) is of type OctetString. The > Diameter peers do not need to understand the value of this AVP. > > The AVP contains the user profile data required for a SIP server to > give service to the user. Hmm... capabilities are defined in the network, the user profile is an opaque string of data. Does this imply that it isn't possible to use equipment from multiple vendors in a networking involving SIP and Diameter? Is there an existing 3GPP definition of these profiles? What is the reason to avoid the user profile definition, diversity of SIP services? Do the SIP nodes have to *act* upon the profile data, or is it just somehow passed on? > 12. Security Considerations > > This memo does not describe a stand-alone protocol, but a particular > application for the Diameter protocol [RFC3588]. Consequently, all > the security considerations applicable to Diameter automatically > apply to this memo. In particular, section 13 of RFC 3588 applies to > this memo. Some references to the security of Digest might also be applicable. At the very least point to the Security Considerations sections of RFCs 2617 and 3310, maybe also draft-torvinen-http-digest-aka-v2-01.txt. EDITORIAL ========= > This document assumes a general architecture where a Home Realm is > composed of one or more nodes implementing Diameter or SIP functions. > At least, one of such nodes implements the Diameter Server > functionality and the Diameter Server has access to a user database. > The user data associated to a particular user is stored in a single > point in the network referred to as the user database. There may be > more than a single Diameter Server in the network, and all these > servers have access to such user database. But at a given time, the > data a Diameter Server returns is independent of the Diameter Server > that returns the information. I found the above seven lines hard to understand. Perhaps one way to restructure the text would be to concentrate on the following key aspects of your assumed architecture: - Per-user information may be needed for authentication and/or routing purposes - User database resides outside the SIP node - User database may be distributed > Table of Contents How about capitalizing first letters of words in section titles? > The Diameter Subscriber Locator (SL) serves for the purposes of > locating the Diameter server that contains the user related data. > Its functionality is further described in Section 5.8. So, Diameter Redirect would not be sufficient for this?. Reading on... it seems that you _are_ using redirect. Perhaps you could say this upfront. Maybe "Its functionality is based on the Diameter redirect mechanism, and is further described in Section 5.8." > 5.2 Diameter server authenticates the user I would actually start with the pure authentication MAR/MAA/SAR/SAA exchange, and have another section for the UAR/UAA case. > If the Diameter client in SIP server 2 is interested in downloading > the user profile information, then it will send a Diameter SAR > message (step 17) to the Diameter server. The Diameter server will > reply with a Diameter SAA message (step 18) that contains the > requested user profile information. These actions are only needed > when the SIP server needs to retrieve a user profile used to provide > services to the served user. Section 7.3 talks about the URI storage as the primary function of the SAR/SAA exchange. Add something about that to the above? > 5.3 Diameter server delegates authentication to the SIP server > > An operator with a large base of installed SIP servers may wish to > minimize the impact of modifying SIP servers to interact with > Diameter servers. This can be achieved by allowing SIP servers to > retain the functionality of authentication, rather than centralizing > this capability in a Diameter server. However, it should be noted I would classify the difference in another manner. Basically, it seems that the authentication is still factually performed at the Diameter server, because it calculates the expected response. But the real difference is that one roundtrip is eliminated through sending the response to the SIP server rather than having it checked in Diameter. And the price we have to pay for this is the loss of support for client nonces. Maybe you could rename the section to "Delegating final authentication check to the SIP server", and include some of the above tradeoffs when you describe the properties of this variant. > SIP server 1 will then forward the SIP REGISTER request to SIP server > 2 (step 12). If the credentials include a client nounce, then SIP s/nounce/nonce/ > 5.5 Session attempt Session attempt? Would "Locating a called user" be better? > Termination of the session can be initiated either by the Diameter > client or the Diameter server. We provide support for both Diameter > client and Diameter server initiated session termination. The second sentence seems to duplicate what the first sentence said. > 7.1 User-Authorization-Request (UAR) Command > > The User-Authorization-Request (UAR) is indicated by the Command-Code > set to aaa and the Command Flags' 'R' bit set. The Diameter client > in a SIP server sends this command to the Diameter server to request > authorization for the SIP User Agent to route a SIP REGISTER request. > As the SIP REGISTER request implicitly carries a permision to bind an s/permision/permission/ > The user name used for authentication of the user is conveyed in a > User-Name AVP (imported from the Diameter base protocol, RFC 3588 s/imported from/defined in/ > ::= < Diameter Header: bbb, PXY > > < Session-Id > > { Auth-Application-Id } > { Result-Code } > { Auth-Session-State } > { Origin-Host } > { Origin-Realm } > [ SIP-User-Data ] > [ SIP-Accouting-Information ] s/Accouting/Accounting/ > This Diameter application provides Diameter clients in SIP servers > with a centralized routing information functionality, so that if a > Diameter client in a SIP server wants to find out routing information > for a particular user, the Diameter server can return (in a Diameter > LIA message) the SIP URI of the SIP server allocated to the user. > This allows SIP servers operating in a stateful mode to receive all > the SIP traffic addressed to the user. For this functionality to > work, the SIP server allocated to the user ought to register its URI > to the Diameter server. This is accomplished with the SIP-Server-URI > AVP provided in the Diameter MAR command that we describe in this > section. The above paragraph seems a bit out of place here. Maybe just: "The MAR command also registers the SIP server's own URI to the Diameter server so that future LIR/LIA messages can return this URI." > +-------------------------------+------+-------------+--------------+ > | AVP Name | AVP | Reference | Data-Type | > | | Code | | | > +-------------------------------+------+-------------+--------------+ > | SIP-User-Authorization-Type | xx25 | Section | Enumerated | > | | | 8.10 | | > | SIP-User-Data-Already-Availab | xx27 | Section | Enumerated | > | le | | 8.12 | | Suggest breaking the line at "-" rather than in the middle of the word. > value combination per AVP value. If the Digest header contains > serval unknown parameters, then the Diameter implementation MUST s/serval/several/ > 8.5.23 Digest-Expected-Response AVP > > The Digest-Expected-Response AVP (AVP code TBD) is of type UTF8String > and contains the value, pre-calculated at the Diameter server, of the > Digest response that the SIP UA is expected to include in the > response parameter in the Digest authentication. The Diameter server > MAY include this AVP to enable and assist the SIP server in > authenticating the SIP UA. This pre-authentication mechanism is only > applicable when the SIP UA does not use client nounces (see below). s/nounces/nonces/ > It is up to the Diameter server to include a Digest-Expected-Response > AVP. The Diameter server calculates the Digest expected response > with the username, password, realm and nounce as inputs, and places s/nounce/nonce/ > o DIAMETER_SUCCESS_SERVER_NOT_STORED 2xx7 > The user was successfully authenticate. The Diameter server does s/authenticate/authenticated/ > (i.e., the Digest-Expected-Response AVP is available to the SIP > server) is not enough to conclude that authentication will take place > in the SIP server. It might be still possible that the SIP UA > includes client nounces in the expected response (e.g., "qop" s/nounces/nonces/ > o Added a new Digest-Expected-Response AVP that allows the Diameter > server to send a pre-calculated expected digest response to the > Diameter client. This is only applicable to the case when the SIP > UA does not use client nounces. s/nounces/nonces/ > o List of auhors trimmed. Contributors section added. s/auhors/authors/ > o The scenario "Diameter server authenticates the user" had an > error, because it was assuming that the MAR/MAA commands were used > to download the user profile. However, MAR/MAA do not contain > provisions to donwload any user profile. The solution is to add a s/donwload/download/ From owner-aaa-wg@merit.edu Thu Aug 26 20:55:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28682 for ; Thu, 26 Aug 2004 20:55:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52275912F0; Thu, 26 Aug 2004 20:54:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AF0E91223; Thu, 26 Aug 2004 20:54:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7695C912F0 for ; Thu, 26 Aug 2004 20:54:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B67A6EE4A; Thu, 26 Aug 2004 20:54:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id ED7196ECBA for ; Thu, 26 Aug 2004 20:54:54 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7R0sqbY005099; Thu, 26 Aug 2004 19:54:53 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i7R0spi19917; Thu, 26 Aug 2004 19:54:51 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I32YIW-0001PO-00; Thu, 26 Aug 2004 20:54:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16686.34375.195368.690295@gargle.gargle.HOWL> Date: Thu, 26 Aug 2004 19:54:31 -0500 From: Pete McCann To: "'aaa-wg@merit.edu'" , Miguel Garcia Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt In-Reply-To: <412E4B3B.4020007@kolumbus.fi> References: <412E4B3B.4020007@kolumbus.fi> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Apologies for being so very last-minute with these, but here are some comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt I just saw Jari's note (haven't read it yet) so some of these may be duplicates of his comments. Also I still need to read carefully the command and AVP specs but I assume they are in reasonable shape. Most of these are editorial but I have a few technical questions as well. -Pete Change: (SIP) Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information to a Diameter server for Session Initiation Protocol To: (SIP) Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information from a Diameter server for Session Initiation Protocol Change: the SIP server is able to receive and process SIP requests and responses which in turn relies on the AAA infrastructure for To: the SIP server is able to receive and process SIP requests and responses and in turn relies on the AAA infrastructure for Change: This application does not require or is not related to other authentication services provided by the Mobile IP Diameter To: This application does not require and is not related to other authentication services provided by the Mobile IP Diameter Change: At least, one of such nodes implements the Diameter Server To: At least one of the nodes implements the Diameter Server Change: The user data associated to a particular user is stored in a single To: The user data associated with a particular user is stored in a single Change: more than a single Diameter Server in the network, and all these To: more than one Diameter Server in the network, and all these Change: This document allows several configurations of the Home Realm. In one of such configurations, a SIP server is allocated to a user for To: This document allows several configurations of the Home Realm. In one such configuration, a SIP server is allocated to a user for Hmm... sort of reads like a patent application... :) In section 5.2: According to Figure 2 a SIP User Agent Client (UAC) sends a SIP REGISTER request (step 1) to its home domain. It's not clear that the SIP server 1 is in its home domain, right? Maybe just say "to a first-hop SIP proxy". In section 5.2: Diameter server will respond with a Diameter Multimedia-Auth-Answer (MAA) message (step 6) with Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a challenge, which SIP server 2 will use to map into the So, this document rules out the scenario where the SIP server chooses the challenge, right? Does this cause some backwards-compatibility problems with draft-sterman, especially in light of the rsp-auth issue? Maybe it's not a problem. Section 5.3: Should note in the security considerations section that if an attacker has access to the Diameter server to send MAR, it may be able to get a set of expected responses if operating in delegated authentication mode. Section 5.8: This section describes a mechanism for redirecting to a particular Diameter server based on an AVP contained within the request. While it does state: Note that according to the Diameter procedures the redirect functionality in the Diameter client is performed automatically in the Diameter stack, and it does not require any knowledge or support by the Diameter application. However, this text seems to be contradicted by the use of an application-specific AVP (the SIP-AOR) to do the proxy/redirect. It seems like message routing should be based on the User-Name AVP and/or the Application ID and nothing else if you want compatibility with the redirect functionality in the base Diameter protocol. Would it be possible to encode the SIP-AOR in the User-Name AVP? Change: All the data associated to a user will be still stored in a single To: All the data associated with a user will be still stored in a single Change: This configuration, although scales well, introduces a new problem, namely: giving the SIP AOR as an input, how to determine which of To: This configuration, although scales well, introduces a new problem, namely: given the SIP AOR as an input, how to determine which of The Security Considerations seem inadequate and I expect this document would be returned by the IESG on that basis... unfortunately I only have the one concrete suggestion for this section (given above) but I would recommend that a more thorough investigation of the security considerations be performed. On the issue of compatibility with draft-sterman, I note that this application contains a lot more functionality than draft-sterman; the capabilities to route SIP messages and download/update subscriber profiles are not contemplated by draft-sterman, which is a simple mapping of HTTP-Digest onto RADIUS. Maybe this is ok, if the only goal is to allow draft-sterman networks to use a Diameter back-end, but maybe it should be noted that a SIP server using the SIP-Diameter application cannot be supported by a RADIUS back-end. From owner-aaa-wg@merit.edu Sun Aug 29 05:50:46 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27467 for ; Sun, 29 Aug 2004 05:50:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83E3D9125F; Sun, 29 Aug 2004 05:50:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B16C9125D; Sun, 29 Aug 2004 05:50:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D17589125A for ; Sun, 29 Aug 2004 05:50:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F2CA845AE; Sun, 29 Aug 2004 05:50:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 5AABB845A8 for ; Sun, 29 Aug 2004 05:49:54 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7T9nkT26274; Sun, 29 Aug 2004 12:49:47 +0300 (EET DST) X-Scanned: Sun, 29 Aug 2004 12:48:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7T9mAQE003979; Sun, 29 Aug 2004 12:48:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Epyktr; Sun, 29 Aug 2004 12:48:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7T9m8n00879; Sun, 29 Aug 2004 12:48:08 +0300 (EET DST) Received: from nokia.com ([10.163.23.234]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Aug 2004 12:48:06 +0300 Message-ID: <4131A655.8020908@nokia.com> Date: Sun, 29 Aug 2004 12:48:05 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: "'aaa-wg@merit.edu'" , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: [AAA-WG]: Re: review of draft-ietf-aaa-diameter-sip-04.txt References: <412E4B3B.4020007@kolumbus.fi> In-Reply-To: <412E4B3B.4020007@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2004 09:48:06.0948 (UTC) FILETIME=[4928B640:01C48DAD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jari: Thanks for reviewing the draft. Inline discussion follows: I have made a few changes to the current working copy (not submitted yet). Note the date of the draft should be August 29 or later, otherwise, refresh your browser. As usually, this working copy can be found at: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.txt HTML version: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.html The diff with respect version -03 is: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-03-to-04.html Jari Arkko wrote: > I read the draft, and it looks very good! I do > have a few technical and editorial comments, however -- > see below. > > --Jari > > P.S. Sorry for being so late. And I'm still working on > draft-sterman... > > TECHNICAL > ========= > > > 5.1 General architecture > > > > The Diameter SIP application can be used in a SIP environment where > > an interface to a AAA infrastructure is required to authenticate, > > authorize or provide accounting information. Figure 1 below shows a > > You talk about accounting above, but yet this spec does not define any > specific accounting AVPs for SIP. Do you expect base accounting to be > used as-is, is accounting out of scope for you, or should you be > talking about what SIP-specific AVPs can and should appear in > accounting requests? The text says "provide accounting information", because the Diameter server sends the addresses of the AAA servers that collect accounting data. I agree that the text is not clear: here is the proposed text: "The Diameter SIP application can be used in a SIP environment where an interface to a AAA infrastructure is required to authenticate and authorize the usage of SIP resources. This application provides a limited support for accounting serviers, limited to the Diameter server being able to provide the addresses of accounting severs to the Diameter client. " > > > This application does not require or is not related to other > > authentication services provided by the Mobile IP Diameter > > [I-D.ietf-aaa-diameter-mobileip] or the Network Access Server > > Diameter [I-D.ietf-aaa-diameter-nasreq] applications. > > What about Diameter CC/prepaid? I think the reader may be interested > in whether this application works together with that. Yes, section 8.1.2 provides a linkage to the CC application. But I think it is reasonable to link also in this section, since we are describing other Diameter applications. I will add the following text: " This Diameter SIP application is loosely related to the Diameter Credit Control Application[I-D.ietf-aaa-diameter-cc]. Although both applications are independent, the Diameter SIP application is able to supply the addresses of credit control servers that will be implementing the Diameter Credit Control Application[I-D.ietf-aaa-diameter-cc]." > > > +--------+ +--------+ +--------+ > > | SIP | |Diameter| | SIP | > > |server 1| | server | |server 2| > > +--------+ +--------+ +--------+ > > | | | > > 1. SIP REGISTER | | | > > -------------------->| 2. UAR | | > > |------------------>| | > > | 3. UAA | | > > |<------------------| | > > | 4. SIP REGISTER | > > |-------------------------------------->| > > | | 5. MAR | > > | |<------------------| > > | | 6. MAA | > > | |------------------>| > > So, how does a SIP server know that it is of type 1 or type 2? I would > presume that there can be a case where this choice depends on the > particular user. For instance, some local users are known and > authenticated by the server, but for others we pass the SIP request > somewhere else. This is known because the SIP architecture provides for the existance of "roles" of servers. For instance, SIP defines the concet of an "outbound proxy" (it could be SIP server 1). Also, SIP server 1 could be an "edge proxy" that has knowledge of the topology of the network, so requests coming from external networks are treated differently from requests that are coming from internal networks. If an external user happens to send a SIP REGISTER request to SIP server 1, since the user is external (SIP URI belonging to a different domain), the SIP server will either forward, redirect, or reject this request. I don't think we need to explain these SIP concepts in this draft. > > > SIP server 1 will forward the SIP REGISTER request (step 4) to an > > appropriate SIP server (SIP server 2). The Diameter client in SIP > > server 2 will then request user authentication from the Diameter > > server by sending a Diameter Multimedia-Auth-Request (MAR) message > > Question: Can the Diameter server decide that this particular SIP > request does not require authentication? Can I use just the routing > aspect of this spec, or do I always need to authenticate too? We never had a requirement to use the routing aspects of this spec, so I never thought about this scenario. But I believe it is possible. Section 5.5 (Session attemp) provides an example of a routing scenario. While this scenario is meant to route incoming requests from other users, I believe it is applicable for the case you have in mind. > > > If the Diameter client in SIP server 2 is interested in downloading > > the user profile information, then it will send a Diameter SAR > > message (step 17) to the Diameter server. The Diameter server will > > reply with a Diameter SAA message (step 18) that contains the > > requested user profile information. These actions are only needed > > when the SIP server needs to retrieve a user profile used to provide > > services to the served user. > > Question: Does the download exchange have to happen in a separate > roundtrip, or can we do it in parallel with the MAR/MAA? And why do we > need a separate message, this does not seem to be the case in other > applications such as NASREQ, all authz information is provided in the > same return messages? First of all, let me start indicating that we need to support two scenarios (described in Figures 2 and 3). If we want to avoid one roundtrip less, then we would need to add the "please send me the user profile" semantics to MAR/MAA, and I think is simpler just to keep those semantics in the existing SAR/SAA. Another solution would be to use SAR/SAA in steps 13 and 14 of Figure 2, but we would be changing the semantics of SAR/SAA and mixing them with MAR/MAA. In this figure 2, MAR clearly has the semantics "please authenticate/authorize this user with this credentials", whereas SAR indicates "This SIP server will be serving this user, and please send me the user profile". I wouldn't like to mix semantics more. > > > If the Diameter server requires a User-Name AVP value to process the > > Diameter PPR request, but the Diameter PPR message did not contain a > > I'm not sure I understand how the user name would not be > required. Would this be a global profile change for all users? No, this is not the idea. But it is good that you point it out, because we have already one open issue to this respect: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue11 I think there is an error here, since the Diameter server ***sends*** the PPR command to the Diameter client, so obviously, the text "if the Diameter server requires a User-Name AVP value to process the Diameter PPR request" does not make sense. It seems to be a copy/paste error. So I think the PPR command ought to contain a mandatory User-Name AVP (currently optional), and cannot contain SIP-AOR AVPs, because the SIP-AOR URIs will be part of the profile sent in the SIP-User-Data. Additionally, I have deleted the paragraph that used to discuss the absence of User-Name in the PPR command. > > > [RFC3588]). The location of the authentication user name in the SIP > > REGISTER request varies depending on the authentication mechanism. > > When the authentication mechanism is HTTP Digest as defined in RFC > > 2617 [RFC2617], the authentication user name is found in the > > "username" directive of the SIP Authorization header field value. > > Is there some other alternative? A current one? If not, it might be > better to say that you support HTTP Digest only. The thing is that SIP provides support for several authentication mechanisms: HTTP Digest authentication, S/MIME, TLS, etc. Only HTTP Digest is mandatory to implement, and only HTTP Digest is supported by the Diameter SIP application. So that paragraph is just saying that if HTTP Digest is used to authenticate the user, then the User-Name comes in the username directive of the Authorization header. But if other mechanism is used, then the username will come somewhere else (although it is not supported by the application). I will add yet another reminder that we only support HTTP Digest authentication. > > > 8.11 SIP-User-Data AVP > > > > The SIP-User-Data AVP (AVP Code TBD) is of type OctetString. The > > Diameter peers do not need to understand the value of this AVP. > > > > The AVP contains the user profile data required for a SIP server to > > give service to the user. > > Hmm... capabilities are defined in the network, the user profile is an > opaque string of data. Does this imply that it isn't possible to use > equipment from multiple vendors in a networking involving SIP and > Diameter? Is there an existing 3GPP definition of these profiles? > What is the reason to avoid the user profile definition, diversity of > SIP services? Do the SIP nodes have to *act* upon the profile data, or > is it just somehow passed on? I think this is, by far, the most important issue that we need to solve, and this is linked to this open issue: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue4 So, basically. I believe we need the means to identify the type of profile that is sent. Of course we don't want to describe here the contents of the profile, but just list it. 3GPP has defined their own user profile in TS 29.228 version 5.8.0 Annex E. I am not aware of the existence of other user profiles. My suggestion: - Create a new grouped AVP, by name SIP-User-Profile, that contains two other AVPs. - One is a new integer SIP-User-Profile-Type, that contains an integer describing the type of user profile - The other is the current SIP-User-Data, i.e., the actual user profile. Additionally, we should create another AVP (that allows repetion), by name SIP-Supported-User-Profiles. The idea is that the Diameter client can indicate in the SAR command which types of user profiles are supported, and the Diameter server can send one that suits the Diameter client. How about that? Further more: I think this requires to open an IANA registration of the types of user profiles. This is the bit that I don't like, so I am open to suggestions to avoid this IANA registration process. > > > 12. Security Considerations > > > > This memo does not describe a stand-alone protocol, but a particular > > application for the Diameter protocol [RFC3588]. Consequently, all > > the security considerations applicable to Diameter automatically > > apply to this memo. In particular, section 13 of RFC 3588 applies to > > this memo. > > Some references to the security of Digest might also be applicable. At > the very least point to the Security Considerations sections of RFCs > 2617 and 3310, maybe also draft-torvinen-http-digest-aka-v2-01.txt. I added the following paragraphs: This Diameter SIP application allows a Diameter client to use the properties of HTTP Digest authentication[RFC2617] by evaluating or sending to the Diameter server the credentials supplied by a user. When Section 4 of RFC 2617[RFC2617] discusses HTTP Digest authentication, it is also applicable to this memo. This Diameter SIP application also allows a Diameter client to use the properties of HTTP Digest authentication using AKA[RFC3310] by evaluating or sending to the Diameter server the credentials supplied by a user. Section 5 of RFC 3310[RFC3310] is also applicable to this memo. I don't want to create a dependency on AKA v2, because of two reasons: first we haven't studied whether we support it straight forward or not. Second, this will create a normative dependency... and I am not sure of the fate of AKA v2. > > EDITORIAL > ========= > > > This document assumes a general architecture where a Home Realm is > > composed of one or more nodes implementing Diameter or SIP functions. > > At least, one of such nodes implements the Diameter Server > > functionality and the Diameter Server has access to a user database. > > The user data associated to a particular user is stored in a single > > point in the network referred to as the user database. There may be > > more than a single Diameter Server in the network, and all these > > servers have access to such user database. But at a given time, the > > data a Diameter Server returns is independent of the Diameter Server > > that returns the information. > > I found the above seven lines hard to understand. Perhaps one way to > restructure the text would be to concentrate on the following key > aspects of your assumed architecture: > > - Per-user information may be needed for authentication and/or > routing purposes > - User database resides outside the SIP node > - User database may be distributed Good. Changed to: This document assumes a general architecture where a Home Realm is composed of one or more nodes implementing Diameter or SIP functions. Users are issuing SIP request to access SIP resources. For each particular user, the Home Realm needs to authenticate and authorize the usage of those resources and/or route to the appropriate node. We assume that the database containing the user related data is located outside the SIP node that requires authorization. Data belonging to different users may be stored in different nodes in the Home Realm, but we assume that all the data related to a particular user is stored in a single node. > > > Table of Contents > > How about capitalizing first letters of words in section > titles? Yeap. Done. > > > The Diameter Subscriber Locator (SL) serves for the purposes of > > locating the Diameter server that contains the user related data. > > Its functionality is further described in Section 5.8. > > So, Diameter Redirect would not be sufficient for this?. Reading > on... it seems that you _are_ using redirect. Perhaps you could say > this upfront. Maybe "Its functionality is based on the Diameter > redirect mechanism, and is further described in Section 5.8." Done. > > > 5.2 Diameter server authenticates the user > > I would actually start with the pure authentication > MAR/MAA/SAR/SAA exchange, and have another section for the > UAR/UAA case. This is just an example of operation, wher we can see the whole picture. I think that if we move the UAR/UAA case to another section, we will miss the whole picture with the REGISTER request. I will keep this as is. > > > If the Diameter client in SIP server 2 is interested in downloading > > the user profile information, then it will send a Diameter SAR > > message (step 17) to the Diameter server. The Diameter server will > > reply with a Diameter SAA message (step 18) that contains the > > requested user profile information. These actions are only needed > > when the SIP server needs to retrieve a user profile used to provide > > services to the served user. > > Section 7.3 talks about the URI storage as the primary function of the > SAR/SAA exchange. Add something about that to the above? Ok, I will add it. > > > 5.3 Diameter server delegates authentication to the SIP server > > > > An operator with a large base of installed SIP servers may wish to > > minimize the impact of modifying SIP servers to interact with > > Diameter servers. This can be achieved by allowing SIP servers to > > retain the functionality of authentication, rather than centralizing > > this capability in a Diameter server. However, it should be noted > > I would classify the difference in another manner. Basically, it > seems that the authentication is still factually performed at the > Diameter server, because it calculates the expected response. But the > real difference is that one roundtrip is eliminated through sending > the response to the SIP server rather than having it checked in > Diameter. And the price we have to pay for this is the loss of support > for client nonces. Maybe you could rename the section to "Delegating > final authentication check to the SIP server", and include some of the > above tradeoffs when you describe the properties of this variant. Section renamed as suggested. Now this paragraph reads: An operator with a large base of installed SIP servers may wish to minimize the number of round trips between the Diameter client and the Diameter server. We provide support for a mechanism that allows the Diameter server to delegate the final authentication check to the SIP server, saving a round trip. However, it must also noted that this scenario is only applicable when the authentication of the user does not use client nonces, since the mechanism is based on the computation of an expected response in the Diameter server, which makes it available to the SIP server. > > > SIP server 1 will then forward the SIP REGISTER request to SIP server > > 2 (step 12). If the credentials include a client nounce, then SIP > > s/nounce/nonce/ Ooops, I fixed it across all document. > > > 5.5 Session attempt > > Session attempt? Would "Locating a called user" be better? We can't even speak about "called" user, since there may not be a call. For instance, the SIP request can be a SUBSCRIBE request, that does not create a call. But I agree that "Session attempt" is not good either. I have renamed this section to "Locating the recipient of the SIP request", which I believe I generic enough to be valid in all scenarios. > > > Termination of the session can be initiated either by the Diameter > > client or the Diameter server. We provide support for both Diameter > > client and Diameter server initiated session termination. > > The second sentence seems to duplicate what the first sentence said. Agree. I deleted the first sentence. > > > 7.1 User-Authorization-Request (UAR) Command > > > > The User-Authorization-Request (UAR) is indicated by the Command-Code > > set to aaa and the Command Flags' 'R' bit set. The Diameter client > > in a SIP server sends this command to the Diameter server to request > > authorization for the SIP User Agent to route a SIP REGISTER request. > > As the SIP REGISTER request implicitly carries a permision to bind an > > s/permision/permission/ ok > > > The user name used for authentication of the user is conveyed in a > > User-Name AVP (imported from the Diameter base protocol, RFC 3588 > > s/imported from/defined in/ ok > > > ::= < Diameter Header: bbb, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Result-Code } > > { Auth-Session-State } > > { Origin-Host } > > { Origin-Realm } > > [ SIP-User-Data ] > > [ SIP-Accouting-Information ] > > s/Accouting/Accounting/ ok > > > This Diameter application provides Diameter clients in SIP servers > > with a centralized routing information functionality, so that if a > > Diameter client in a SIP server wants to find out routing information > > for a particular user, the Diameter server can return (in a Diameter > > LIA message) the SIP URI of the SIP server allocated to the user. > > This allows SIP servers operating in a stateful mode to receive all > > the SIP traffic addressed to the user. For this functionality to > > work, the SIP server allocated to the user ought to register its URI > > to the Diameter server. This is accomplished with the SIP-Server-URI > > AVP provided in the Diameter MAR command that we describe in this > > section. > > The above paragraph seems a bit out of place here. Maybe just: "The > MAR command also registers the SIP server's own URI to the Diameter > server so that future LIR/LIA messages can return this URI." Ok, changed as suggested. > > > +-------------------------------+------+-------------+--------------+ > > | AVP Name | AVP | Reference | Data-Type | > > | | Code | | | > > +-------------------------------+------+-------------+--------------+ > > | SIP-User-Authorization-Type | xx25 | Section | Enumerated | > > | | | 8.10 | | > > | SIP-User-Data-Already-Availab | xx27 | Section | Enumerated | > > | le | | 8.12 | | > > Suggest breaking the line at "-" rather than in the middle of the > word. > I am trying to increase the width of that column. Most of this formatting is doing by xml2rfc, so let's see if I am able to do something better than what we have now. > > value combination per AVP value. If the Digest header contains > > serval unknown parameters, then the Diameter implementation MUST > > s/serval/several/ Fixed. I also spell checked the whole buffer. > > > 8.5.23 Digest-Expected-Response AVP > > > > The Digest-Expected-Response AVP (AVP code TBD) is of type UTF8String > > and contains the value, pre-calculated at the Diameter server, of the > > Digest response that the SIP UA is expected to include in the > > response parameter in the Digest authentication. The Diameter server > > MAY include this AVP to enable and assist the SIP server in > > authenticating the SIP UA. This pre-authentication mechanism is only > > applicable when the SIP UA does not use client nounces (see below). > > s/nounces/nonces/ Ok > > > It is up to the Diameter server to include a Digest-Expected-Response > > AVP. The Diameter server calculates the Digest expected response > > with the username, password, realm and nounce as inputs, and places > > s/nounce/nonce/ Ok > > > o DIAMETER_SUCCESS_SERVER_NOT_STORED 2xx7 > > The user was successfully authenticate. The Diameter server does > > s/authenticate/authenticated/ When I was fixing this one, I discovered another error, documented as issue 22 in: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue22 There are two Result-Code values with almost the same name, exactly the same semantics, but different value (2xx4 vs. 2xx7). So I have deleted DIAMETER_SUCCESS_SERVER_NOT_STORED and kept DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED. > > > (i.e., the Digest-Expected-Response AVP is available to the SIP > > server) is not enough to conclude that authentication will take place > > in the SIP server. It might be still possible that the SIP UA > > includes client nounces in the expected response (e.g., "qop" > > s/nounces/nonces/ OK > > > o Added a new Digest-Expected-Response AVP that allows the Diameter > > server to send a pre-calculated expected digest response to the > > Diameter client. This is only applicable to the case when the SIP > > UA does not use client nounces. > > s/nounces/nonces/ Ok > > > o List of auhors trimmed. Contributors section added. > > s/auhors/authors/ Ok > > > o The scenario "Diameter server authenticates the user" had an > > error, because it was assuming that the MAR/MAA commands were used > > to download the user profile. However, MAR/MAA do not contain > > provisions to donwload any user profile. The solution is to add a > > s/donwload/download/ OK Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Aug 30 08:25:13 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18298 for ; Mon, 30 Aug 2004 08:25:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A035991232; Mon, 30 Aug 2004 08:25:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BCF091233; Mon, 30 Aug 2004 08:25:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA22D91232 for ; Mon, 30 Aug 2004 08:24:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C06098456C; Mon, 30 Aug 2004 08:24:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 028C58455B for ; Mon, 30 Aug 2004 08:24:58 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UCOq101443; Mon, 30 Aug 2004 15:24:52 +0300 (EET DST) X-Scanned: Mon, 30 Aug 2004 15:22:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7UCMtgH014391; Mon, 30 Aug 2004 15:22:55 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 004BKff2; Mon, 30 Aug 2004 15:22:53 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UCMq828141; Mon, 30 Aug 2004 15:22:52 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 15:22:50 +0300 Message-ID: <41331C19.2070407@nokia.com> Date: Mon, 30 Aug 2004 15:22:49 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Pete McCann Cc: "'aaa-wg@merit.edu'" , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt References: <412E4B3B.4020007@kolumbus.fi> <16686.34375.195368.690295@gargle.gargle.HOWL> In-Reply-To: <16686.34375.195368.690295@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2004 12:22:50.0608 (UTC) FILETIME=[11108F00:01C48E8C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pete: Thanks for the comments. Yersterday I posted an update of the forthcomng draft, fixing most of Jari's comments. I have now created another update (dating August 30th) that includes your comments: The working copy can be found at: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.txt HTML version: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.html The diff with respect version -03 is: http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-03-to-04.html Now, Inline discussion: Pete McCann wrote: > Hi, > > Apologies for being so very last-minute with these, but here are some > comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt > > I just saw Jari's note (haven't read it yet) so some of these may be > duplicates of his comments. Also I still need to read carefully the > command and AVP specs but I assume they are in reasonable shape. > > Most of these are editorial but I have a few technical questions as > well. > > -Pete > > > > > Change: > (SIP) Application. This is a Diameter application that allows a > Diameter client to request authentication and authorization > information to a Diameter server for Session Initiation Protocol > To: > (SIP) Application. This is a Diameter application that allows a > Diameter client to request authentication and authorization > information from a Diameter server for Session Initiation Protocol ok. > > Change: > the SIP server is able to receive and process SIP requests and > responses which in turn relies on the AAA infrastructure for > To: > the SIP server is able to receive and process SIP requests and > responses and in turn relies on the AAA infrastructure for > ok. > Change: > This application does not require or is not related to other > authentication services provided by the Mobile IP Diameter > To: > This application does not require and is not related to other > authentication services provided by the Mobile IP Diameter > ok. > Change: > At least, one of such nodes implements the Diameter Server > To: > At least one of the nodes implements the Diameter Server This text has changed dur to Jari's comments. > > Change: > The user data associated to a particular user is stored in a single > To: > The user data associated with a particular user is stored in a single OK > > Change: > more than a single Diameter Server in the network, and all these > To: > more than one Diameter Server in the network, and all these ok > > Change: > This document allows several configurations of the Home Realm. In > one of such configurations, a SIP server is allocated to a user for > To: > This document allows several configurations of the Home Realm. In > one such configuration, a SIP server is allocated to a user for > Hmm... sort of reads like a patent application... :) Ok. I also removed "such", so it does not smell to any legal wording. So the text reads: "In one configuration, a SIP server is allocated to ..." > > In section 5.2: > According to Figure 2 a SIP User Agent Client (UAC) sends a SIP > REGISTER request (step 1) to its home domain. > It's not clear that the SIP server 1 is in its home domain, right? Right, it does not necessarily be located in the home domain. > Maybe just say "to a first-hop SIP proxy". It does not even need to be a "first-hop SIP proxy", AKA as an "outbound SIP proxy". It is just a proxy. Full stop. > > In section 5.2: > Diameter server will respond with a Diameter Multimedia-Auth-Answer > (MAA) message (step 6) with Result-Code AVP set to the value > DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a > challenge, which SIP server 2 will use to map into the > So, this document rules out the scenario where the SIP server chooses > the challenge, right? Does this cause some backwards-compatibility problems > with draft-sterman, especially in light of the rsp-auth issue? Maybe it's > not a problem. At least I never heard a requirement where the SIP server chooses the challenge. I thought that what we want is to store the user's configuration (including shared secrets) in the Diameter server. I don't quite figure out what will be the role of the Diameter server if the SIP server challenges the user, which is standard SIP functionality (RFC 3261). > > Section 5.3: > Should note in the security considerations section that if an attacker has > access to the Diameter server to send MAR, it may be able to get a set of > expected responses if operating in delegated authentication mode. What you mention is correct, but I don't see the security breach here. So a malicius SIP server gets an expected response from the Diameter server. So what can the malicious server do with the expected response? It does not contain the user's shared secret. And if the malicious server wants to bypass authentication of the user, what did it contact the Diameter server in the first place? I think if there is a security concern we need to document it, but I am trying to find out what this security concern it. Please elaborate. > > > Section 5.8: > > This section describes a mechanism for redirecting to a particular > Diameter server based on an AVP contained within the request. While > it does state: > > Note that according to the Diameter procedures the redirect > functionality in the Diameter client is performed automatically in > the Diameter stack, and it does not require any knowledge or > support by the Diameter application. I believe the above text is not valid anymore. > > However, this text seems to be contradicted by the use of an > application-specific AVP (the SIP-AOR) to do the proxy/redirect. It > seems like message routing should be based on the User-Name AVP and/or > the Application ID and nothing else if you want compatibility with the > redirect functionality in the base Diameter protocol. Would it be > possible to encode the SIP-AOR in the User-Name AVP? No, it is not possible because, in general, SIP messages do not carry a User-Name, unless the message has been re-sent due to a challenge. So if a User-Name is not included in the SIP message, we can only base this functionality on the SIP-AOR. So what I would do: I would remove the text that indicates that the Diameter redirection takes placein the Diameter stack. I will also emphasize that the SLF is "based" on a Diameter redirect, although is not the same thing. > > Change: > All the data associated to a user will be still stored in a single > To: > All the data associated with a user will be still stored in a single ok > > Change: > This configuration, although scales well, introduces a new problem, > namely: giving the SIP AOR as an input, how to determine which of > To: > This configuration, although scales well, introduces a new problem, > namely: given the SIP AOR as an input, how to determine which of > ok > > The Security Considerations seem inadequate and I expect this document > would be returned by the IESG on that basis... unfortunately I only > have the one concrete suggestion for this section (given above) but I > would recommend that a more thorough investigation of the security > considerations be performed. Mmm... I would like to know what to write. I would like to understand what the IESG would be looking for here. Unfortunately I cannot read the IESG's minds, so I cannot foresee their concerns. > > On the issue of compatibility with draft-sterman, I note that this > application contains a lot more functionality than draft-sterman; the > capabilities to route SIP messages and download/update subscriber > profiles are not contemplated by draft-sterman, which is a simple > mapping of HTTP-Digest onto RADIUS. Maybe this is ok, if the only > goal is to allow draft-sterman networks to use a Diameter back-end, > but maybe it should be noted that a SIP server using the SIP-Diameter > application cannot be supported by a RADIUS back-end. Yes, your assumption of operation is correct. I think we agreed that the compatibility issues will be documented in draft-sterman, so I would expect this discussion to be covered there. > > > > Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Aug 30 09:57:13 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24556 for ; Mon, 30 Aug 2004 09:57:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EAFD91285; Mon, 30 Aug 2004 09:56:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C12A91282; Mon, 30 Aug 2004 09:56:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE3BD91285 for ; Mon, 30 Aug 2004 09:56:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FA5C84619; Mon, 30 Aug 2004 09:56:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 83B4584624 for ; Mon, 30 Aug 2004 09:56:54 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 30 Aug 2004 15:56:45 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Aug 2004 15:56:44 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD83@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com, mccap@lucent.com Cc: aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: AW: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-sip-app-04( pre).txt Date: Mon, 30 Aug 2004 15:56:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel Garcia wrote: >> Pete McCann wrote >> In section 5.2: >> Diameter server will respond with a Diameter Multimedia-Auth-Answer >> (MAA) message (step 6) with Result-Code AVP set to the value >> DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a >> challenge, which SIP server 2 will use to map into the >> So, this document rules out the scenario where the SIP server chooses >> the challenge, right? Does this cause some backwards-compatibility problems >> with draft-sterman, especially in light of the rsp-auth issue? Maybe it's >> not a problem. > > At least I never heard a requirement where the SIP server chooses the > challenge. I thought that what we want is to store the user's > configuration (including shared secrets) in the Diameter server. I don't > quite figure out what will be the role of the Diameter server if the SIP > server challenges the user, which is standard SIP functionality (RFC 3261). The SIP server sends the challenge, the RADIUS server verifies it. There are several draft-sterman..-00 deployments which work fine this way. As draft-sterman supports AAA server challenges, interopability should be possible. While we are at it: "Therefore, a value of "auth-int" in the Digest-Qop AVP of the SIP-Authentication-Info AVP indicates that the Diameter client (SIP server) MUST compute the Digest "rspauth" parameter value at the Diameter client (SIP server)." The Diameter client can't do that without the user's password or H(A1). I am struggling with this, too. H(A1) with algorithm=MD5 is susceptible to replay attacks, H(A1) with algorithm=MD5-sess might be secure enough to be included into a RADIUS attribute or Diameter AVP. >> >> On the issue of compatibility with draft-sterman, I note that this >> application contains a lot more functionality than draft-sterman; the >> capabilities to route SIP messages and download/update subscriber >> profiles are not contemplated by draft-sterman, which is a simple >> mapping of HTTP-Digest onto RADIUS. Maybe this is ok, if the only >> goal is to allow draft-sterman networks to use a Diameter back-end, >> but maybe it should be noted that a SIP server using the SIP-Diameter >> application cannot be supported by a RADIUS back-end. > > Yes, your assumption of operation is correct. I think we agreed that the > compatibility issues will be documented in draft-sterman, so I would > expect this discussion to be covered there. Unlike diameter-sip-app, draft-sterman does not intend to cover all SIP specific parameters. Its scope is limited to HTTP Digest Authentication. Wolfgang -- Wolfgang Beck T-Systems Internet Netzplattformen +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt From owner-aaa-wg@merit.edu Tue Aug 31 03:10:05 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24859 for ; Tue, 31 Aug 2004 03:10:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5558F9121B; Tue, 31 Aug 2004 03:09:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BB829121A; Tue, 31 Aug 2004 03:09:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95EDE9121B for ; Tue, 31 Aug 2004 03:09:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E33684635; Tue, 31 Aug 2004 03:09:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 4E10E84649 for ; Tue, 31 Aug 2004 03:09:30 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7V79IS00355; Tue, 31 Aug 2004 10:09:18 +0300 (EET DST) X-Scanned: Tue, 31 Aug 2004 10:07:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7V77Jhh031528; Tue, 31 Aug 2004 10:07:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00sonxZT; Tue, 31 Aug 2004 10:07:18 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7V77IS22579; Tue, 31 Aug 2004 10:07:18 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 31 Aug 2004 10:06:54 +0300 Message-ID: <4134238E.4050307@nokia.com> Date: Tue, 31 Aug 2004 10:06:54 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: mccap@lucent.com, aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, "Rajaniemi Jaakko (Nokia-NET/Espoo)" , "Tammi Kalle (Nokia-NET/Tampere)" Subject: SIP server generated challenge (Was Re: AW: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt) References: <76C27E1CE3FFC847B4D51C645D6F42AA15FD83@E9JDF.mgb01.telekom.de> In-Reply-To: <76C27E1CE3FFC847B4D51C645D6F42AA15FD83@E9JDF.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2004 07:06:54.0555 (UTC) FILETIME=[18CA2AB0:01C48F29] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Beck01, Wolfgang wrote: > Miguel Garcia wrote: > >>>Pete McCann wrote >>>In section 5.2: >>> Diameter server will respond with a Diameter Multimedia-Auth-Answer >>> (MAA) message (step 6) with Result-Code AVP set to the value >>> DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a >>> challenge, which SIP server 2 will use to map into the >>>So, this document rules out the scenario where the SIP server chooses >>>the challenge, right? Does this cause some backwards-compatibility problems >>>with draft-sterman, especially in light of the rsp-auth issue? Maybe it's >>>not a problem. >> >>At least I never heard a requirement where the SIP server chooses the >>challenge. I thought that what we want is to store the user's >>configuration (including shared secrets) in the Diameter server. I don't >>quite figure out what will be the role of the Diameter server if the SIP >>server challenges the user, which is standard SIP functionality (RFC 3261). > > The SIP server sends the challenge, the RADIUS server verifies it. There are > several draft-sterman..-00 deployments which work fine this way. As > draft-sterman supports AAA server challenges, interopability should be > possible. > Wofgang: So, just for my understanding... Is the scenario you mentioned, the one that you describe in draft-sterman Section 1.3, "Scenario 1, RADIUS client chooses nonces" ? If I understand correctly, the SIP server generates the nonce and the rest of the Digest directives (realm, qop, etc.). The Radius server is computing the final authentication, since it stores the user name, password, etc. As I see it, this scenario is a variant of Section 5.2 in Diameter SIP application, where the first set of MAR/MAA commands (steps 5 and 6) are omitted. Can you verify that my assumption is correct? If it is, I can add a new section to the Diameter SIP app. describing this scenario. I believe there is no impact in the protocol, since this new scenario is a subset of an existing one. So I believe MAR/MAA need not be modified. - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Aug 31 03:55:07 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26919 for ; Tue, 31 Aug 2004 03:55:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79706912DB; Tue, 31 Aug 2004 03:54:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1A589130B; Tue, 31 Aug 2004 03:54:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39CA5912DB for ; Tue, 31 Aug 2004 03:54:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF62D84673; Tue, 31 Aug 2004 03:54:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id F0E5E8466C for ; Tue, 31 Aug 2004 03:54:03 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7V7rwT07319; Tue, 31 Aug 2004 10:53:58 +0300 (EET DST) X-Scanned: Tue, 31 Aug 2004 10:51:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7V7p3IL006660; Tue, 31 Aug 2004 10:51:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 007qqizU; Tue, 31 Aug 2004 10:51:02 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7V7opY29505; Tue, 31 Aug 2004 10:50:51 +0300 (EET DST) Received: from nokia.com ([172.21.42.108]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 31 Aug 2004 10:50:48 +0300 Message-ID: <41342DD7.1060600@nokia.com> Date: Tue, 31 Aug 2004 10:50:47 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: mccap@lucent.com, aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, "Rajaniemi Jaakko (Nokia-NET/Espoo)" , "Tammi Kalle (Nokia-NET/Tampere)" Subject: Computing rspauth (Was Re: AW: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt) References: <76C27E1CE3FFC847B4D51C645D6F42AA15FD83@E9JDF.mgb01.telekom.de> In-Reply-To: <76C27E1CE3FFC847B4D51C645D6F42AA15FD83@E9JDF.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2004 07:50:48.0075 (UTC) FILETIME=[3A7D6DB0:01C48F2F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Now on the second issue. Beck01, Wolfgang wrote: > Miguel Garcia wrote: > > While we are at it: > > "Therefore, a value of "auth-int" in the Digest-Qop AVP of the > SIP-Authentication-Info AVP indicates that the Diameter client (SIP > server) MUST compute the Digest "rspauth" parameter value at the > Diameter client (SIP server)." > > The Diameter client can't do that without the user's password or H(A1). > I am struggling with this, too. H(A1) with algorithm=MD5 is susceptible > to replay attacks, H(A1) with algorithm=MD5-sess might be secure enough > to be included into a RADIUS attribute or Diameter AVP. I agree with your statement. The idea is not for the SIP server to store the user's password or H(A1). These should be stored in the Diameter server. So what we need is: some means to transport H(A1) from the Diameter server to the SIP server. I think this is missing at the moment. So I propose to crete a new AVP (whose name might be HA1) in the SIP-Authentication-Info. This will carry HA1 from the Diameter server to the SIP server, if needed. HA1 should contain the MD5 or MD5-sesssion of A1, as per RFC 2617. On the other hand, you mentioned the problem of reply attacks. Well, I believe the interface between the Diameter client and server should be secure with IPsec or TLS, as per recommendations in RFC 3588, so this is not a problem in Diameter. But I can add this point to the security considerations section. Comments on this proposal? -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Aug 31 11:18:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24563 for ; Tue, 31 Aug 2004 11:18:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBD61912CD; Tue, 31 Aug 2004 11:18:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7211912CC; Tue, 31 Aug 2004 11:18:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AFCE912C9 for ; Tue, 31 Aug 2004 11:18:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 037F85AD0F; Tue, 31 Aug 2004 11:18:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 018716EC84 for ; Tue, 31 Aug 2004 11:18:06 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 31 Aug 2004 17:18:05 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 17:18:05 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD8A@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: mccap@lucent.com, aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: AW: SIP server generated challenge (Was Re: AW: [AAA-WG]: Re: Com ments on draft-ietf-aaa-diameter-sip-app-04(pre).txt) Date: Tue, 31 Aug 2004 17:18:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, you wrote: > Wolfgang: > > So, just for my understanding... Is the scenario you mentioned, the one > that you describe in draft-sterman Section 1.3, "Scenario 1, RADIUS > client chooses nonces" ? Yes > > If I understand correctly, the SIP server generates the nonce and the > rest of the Digest directives (realm, qop, etc.). The Radius server is > computing the final authentication, since it stores the user name, > password, etc. Yes > As I see it, this scenario is a variant of Section 5.2 in Diameter SIP > application, where the first set of MAR/MAA commands (steps 5 and 6) are > omitted. > > Can you verify that my assumption is correct? If it is, I can add a new > section to the Diameter SIP app. describing this scenario. I believe > there is no impact in the protocol, since this new scenario is a subset > of an existing one. So I believe MAR/MAA need not be modified. I will check that (I have some other deadlines this week, so I apologize for not having it checked today). Wolfgang From owner-aaa-wg@merit.edu Tue Aug 31 11:24:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25023 for ; Tue, 31 Aug 2004 11:24:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B8A79120F; Tue, 31 Aug 2004 11:24:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8BAA9122E; Tue, 31 Aug 2004 11:24:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BF6D9120F for ; Tue, 31 Aug 2004 11:24:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3BF96EDB4; Tue, 31 Aug 2004 11:24:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 3501B6EDA1 for ; Tue, 31 Aug 2004 11:24:08 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 31 Aug 2004 17:24:03 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 17:24:03 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD8B@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: mccap@lucent.com, aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: AW: Computing rspauth (Was Re: AW: [AAA-WG]: Re: Comments on draf t-ietf-aaa-diameter-sip-app-04(pre).txt) Date: Tue, 31 Aug 2004 17:24:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, You wrote: > I agree with your statement. The idea is not for the SIP server to store > the user's password or H(A1). These should be stored in the Diameter server. > > So what we need is: some means to transport H(A1) from the Diameter > server to the SIP server. I think this is missing at the moment. Yes. > So I propose to create a new AVP (whose name might be HA1) in the > SIP-Authentication-Info. This will carry HA1 from the Diameter server to > the SIP server, if needed. HA1 should contain the MD5 or MD5-sesssion of > A1, as per RFC 2617. Ok. > On the other hand, you mentioned the problem of replay attacks. Well, I > believe the interface between the Diameter client and server should be > secure with IPsec or TLS, as per recommendations in RFC 3588, so this is > not a problem in Diameter. But I can add this point to the security > considerations section. You are lucky that Diameter has such recommendations (IPSec/TLS). In RADIUS, sending H(A1) might only be secure if the algorithm is MD5-sess. There shouldn't be interopability issues here, if RADIUS has this restrictions. Wolfgang From owner-aaa-wg@merit.edu Tue Aug 31 17:28:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04423 for ; Tue, 31 Aug 2004 17:28:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE92D9131F; Tue, 31 Aug 2004 17:25:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 202199131E; Tue, 31 Aug 2004 17:25:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CBF99131F for ; Tue, 31 Aug 2004 17:25:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 256CE6EDF0; Tue, 31 Aug 2004 17:25:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.245]) by segue.merit.edu (Postfix) with ESMTP id B05F06EDE4 for ; Tue, 31 Aug 2004 17:25:44 -0400 (EDT) Received: by mproxy.gmail.com with SMTP id w67so77749cwb for ; Tue, 31 Aug 2004 14:25:39 -0700 (PDT) Received: by 10.11.119.50 with SMTP id r50mr22251cwc; Tue, 31 Aug 2004 14:25:38 -0700 (PDT) Received: by 10.11.117.12 with HTTP; Tue, 31 Aug 2004 14:25:38 -0700 (PDT) Message-ID: Date: Tue, 31 Aug 2004 23:25:38 +0200 From: Jo Hermans Reply-To: Jo Hermans To: Miguel Garcia Subject: Re: Computing rspauth (Was Re: AW: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt) Cc: aaa-wg@merit.edu In-Reply-To: <41342DD7.1060600@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <76C27E1CE3FFC847B4D51C645D6F42AA15FD83@E9JDF.mgb01.telekom.de> <41342DD7.1060600@nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 31 Aug 2004 10:50:47 +0300, Miguel Garcia wrote: > Now on the second issue. > > Beck01, Wolfgang wrote: > > > Miguel Garcia wrote: > > > > > While we are at it: > > > > "Therefore, a value of "auth-int" in the Digest-Qop AVP of the > > SIP-Authentication-Info AVP indicates that the Diameter client (SIP > > server) MUST compute the Digest "rspauth" parameter value at the > > Diameter client (SIP server)." > > > > The Diameter client can't do that without the user's password or H(A1). > > I am struggling with this, too. H(A1) with algorithm=MD5 is susceptible > > to replay attacks, H(A1) with algorithm=MD5-sess might be secure enough > > to be included into a RADIUS attribute or Diameter AVP. > > I agree with your statement. The idea is not for the SIP server to store > the user's password or H(A1). These should be stored in the Diameter server. > > So what we need is: some means to transport H(A1) from the Diameter > server to the SIP server. I think this is missing at the moment. > > So I propose to crete a new AVP (whose name might be HA1) in the > SIP-Authentication-Info. This will carry HA1 from the Diameter server to > the SIP server, if needed. HA1 should contain the MD5 or MD5-sesssion of > A1, as per RFC 2617. > > On the other hand, you mentioned the problem of reply attacks. Well, I > believe the interface between the Diameter client and server should be > secure with IPsec or TLS, as per recommendations in RFC 3588, so this is > not a problem in Diameter. But I can add this point to the security > considerations section. > > Comments on this proposal? > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > > Not directly related to the current thread, but I've met the same problem. I have been thinking about improving the performance of digest-authentication in large networks (long chains of SIP-proxies and/or DIAMETER-proxies), especially in the light of a DDOS attack. I'm talking about reqauth here, not rspauth. We're having a situation where there's a huge amount of 'border nodes' (SIP-proxies that are as close a possible to the user, but still under the control of the network operator) and only very few authentication servers that actually contain the password. If we can use MD5-session (auth or auth-int), and the MD5 hash of the username, realm and password is forwarded from the AAA-server to the front-end process on the border, then we can calculate the digest in the front-end process, so the packet doesn't have to be forwarded thru the entire chain, and the AAA-server (whether it's RADIUS, DIAMETER or something else) isn't bombarded with authentication-requests. We're seeing the limitations of AAA-server more and more, and it doesn't always have to be a DDOS attack. This is what is mentioned in RFC2617 (para 3.2.2.2) or in draft-smith-sip-auth-examples-00.txt (para 3.4.3) : "The SIP server is required to request the password, through an unspecified mechanism, from a 3rd party authentication server, which returns a digest of the password which can then be used to authenticate the user". Note that it can also be a DIAMETER or RADIUS server that will be storing the digest. The digest might be stored for as long as the password stays the same (as long as the SIP-UA is registered, or maybe with an expiration time). But that digest would be H(unq(username) ":" unq(realm) " :" password), which is the same as H(A1) in the MD5 case (or part of A1 in the MD5-sess case), so it's also vulnerable to these replay attacks. So it should also be used with IPSEQ or TLS. Grrr ... it's a pity that we don't have the CMS Security Application anymore. -- Jo Hermans "Eagles may soar, but weasels aren't sucked into jet engines"