From owner-aaa-wg@merit.edu Mon Sep 2 02:40:23 2002 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 CAA14978 for ; Mon, 2 Sep 2002 02:40:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C37FA9120F; Mon, 2 Sep 2002 02:41:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9377391213; Mon, 2 Sep 2002 02:41:43 -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 6EC7B9120F for ; Mon, 2 Sep 2002 02:41:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 532805DE84; Mon, 2 Sep 2002 02:41:42 -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 99C035DE79 for ; Mon, 2 Sep 2002 02:41:41 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g826djA01099 for ; Mon, 2 Sep 2002 09:39:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Sep 2002 09:41:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Sep 2002 09:41:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue #352 Date: Mon, 2 Sep 2002 09:41:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EF3@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue #352 Thread-Index: AcJHlLbE5VNLI7d0RWiMo0cZtQs2pgKtaSTw From: To: , Cc: , X-OriginalArrivalTime: 02 Sep 2002 06:41:38.0733 (UTC) FILETIME=[CA2655D0:01C2524B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA14978 Hi Pete, I agree with you. I think that a first-come, first-serve approach to the Application ID's would be the best way to go. However, as a fall back, your proposal of text is something I could live with. Bernard / Randy / Allison: could you give proper guidence on how Application IDs should be administered? This needs to be solved ASAP! As a quick refresher, the Application ID identifies which application is using Diamter and is used as a way to ensure that both ends of the session understand and speak the same AAA. br, John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 19 August, 2002 18:26 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue #352 > > > > Hi, > > I wanted to make sure everyone is reading the IANA Considerations > section of draft-12. > > I think the current text is not quite correct with respect to the new > experimental Application ID space. Because these IDs can appear by > themselves in a Diameter header, they really need to be centrally > administered, rather than for Private Use as stated in Section 11.3. > While I would personally favor First Come First Served for this space, > I don't think we could realistically expect the IESG to go along. How > about Designated Expert Review as the assignment policy? > > This would work as follows. First, the existing text from 11.3: > > > 11.3 Application Identifiers > > > > As defined in section 2.4, the Application Identifier is used to > > identify a specific Diameter Application. There are > standards-track > > application ids and vendor specific application ids. > > > > IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for > > standards-track applications; and 0xff00000000 - 0xfffffffe for > > vendor specific applications. > > > > Both Application-Id and Acct-Application-Id AVPs use the same > > Application Identifier space. > > > > Vendor-Specific Application Identifiers, encoded in the Vendor- > > Specific-Application-Id Grouped AVP, with the Vendor-Id > AVP set to > > the vendor's enterprise number, is for Private Use. > > > > Note that the Diameter protocol is not intended to be > extended for > > any purpose. Any applications defined MUST ensure that they fit > > within the existing framework, and that no changes to the base > > protocol are required. > > I propose to strike the last two paragraphs above, and add instead: > > > Vendor-Specific Application Identifiers, encoded in the Vendor- > > Specific-Application-Id Grouped AVP with the Vendor-Id AVP set to > > the vendor's enterprise number, and appearing in the Diameter > > header, will be assigned by IANA after review by a Designated > > Expert. The Expert will ensure that the requested application fits > > within the existing Diameter framework, does not require changes to > > the base protocol, and does not cause interoperability problems > > with any existing Diameter application before approving the > > assignment. > > I hope this sort of wording would satisfy all the interested parties; > it does not allow for completely uncontrolled creation of Diameter > applications, but I think the Designated Expert Review process is the > least onerous to follow. The language should address all of the IESG > concerns regarding interoperability. > > -Pete > > From owner-aaa-wg@merit.edu Mon Sep 2 02:42:35 2002 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 CAA15018 for ; Mon, 2 Sep 2002 02:42:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8ABC91213; Mon, 2 Sep 2002 02:43:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AA7A9121E; Mon, 2 Sep 2002 02:43: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 887F991213 for ; Mon, 2 Sep 2002 02:43:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 771C55DE84; Mon, 2 Sep 2002 02:43:53 -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 91CD05DE79 for ; Mon, 2 Sep 2002 02:43:52 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g826fuA02661 for ; Mon, 2 Sep 2002 09:41:56 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Sep 2002 09:43:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Sep 2002 09:43:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Need more specifics on list of AVPs Date: Mon, 2 Sep 2002 09:43:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5408@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Need more specifics on list of AVPs Thread-Index: AcJK7zBQk4yYCsZmTiqilQYbFMLHzgHXL1JA From: To: , X-OriginalArrivalTime: 02 Sep 2002 06:43:51.0347 (UTC) FILETIME=[1931A030:01C2524C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I have seen no comments on this issue. As it is a request for debugging purposes - I feel that at this late date, we cannot change the spec to meet this request. We need to get Diameter out to IESG for review. best regards, John > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 24 August, 2002 00:50 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Need more specifics on list of AVPs > > > Need more specifics on list of AVPs > Submitter name: Yoshihiro Ohba > Submitter email address: yohba@tari.toshiba.com > Date first submitted: August 23, 2002 > Document: base > Comment type: T > Priority: S > Section: 4 > Rationale/Explanation of issue: > > In section 4 it is descibred that: > > Some AVPs MAY be listed more than once. The effect of such > an AVP is > specific, and is specified in each case by the AVP description. > > But the specification is not clear on whether each AVP in the list of > AVPs of the same type can be dispersely located in the message payload > (e.g, a Host-IP-Address AVP, then an Origin-Realm AVP, > and then a Host-IP-Address AVP again) or must be located back to back > (e.g, two Host-IP-Address AVPs, and then an Origin-Realm AVP). > > From the debugging point of view, the latter would be prefered since > it makes easier to find out where AVPs of a specific type are in the > payload. > > Requested change: > > Each AVP in a list of AVPs of the same type must be located back to > back in the message payload. > From owner-aaa-wg@merit.edu Tue Sep 3 03:38:39 2002 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 DAA18412 for ; Tue, 3 Sep 2002 03:38:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BA0E9120C; Tue, 3 Sep 2002 03:39:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB2369123B; Tue, 3 Sep 2002 03:39: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 A63CB9120C for ; Tue, 3 Sep 2002 03:39:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 890FF5DEEB; Tue, 3 Sep 2002 03:39:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id 4F3DC5DDB9 for ; Tue, 3 Sep 2002 03:39:56 -0400 (EDT) Received: from fokus.gmd.de (dhcp229 [195.37.78.229]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g837dsG12756 for ; Tue, 3 Sep 2002 09:39:54 +0200 (MEST) Message-ID: <3D7466C6.8010606@fokus.gmd.de> Date: Tue, 03 Sep 2002 09:37:42 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: AAA Subject: [AAA-WG]: Diameter as IPFIX candidate Content-Type: multipart/mixed; boundary="------------080905070209050901080107" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------080905070209050901080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, I submitted a first candidate draft to the IPFIX eval team. I hope that some of you Diameter experts have the time to send me some comments so I can improve the next version. Cheers, Sebastian -------- Urspr�ngliche Nachricht -------- Betreff: [ipfix-eval] [Fwd: post draft-zander-ipfix-eval-diameter-00.txt] Datum: Mon, 02 Sep 2002 19:03:26 +0200 Von: Sebastian Zander Firma: Fraunhofer FOKUS An: ipfix-eval@net.doit.wisc.edu CC: ipfix-chairs@net.doit.wisc.edu Hi, please find the Diameter evaluation draft attached. The Diameter protocol spec can be found at http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-12.txt. I will update the diameter eval draft in the next few days to produce a 01 version. Cheers, Sebastian -------- Urspr�ngliche Nachricht -------- Betreff: post draft-zander-ipfix-eval-diameter-00.txt Datum: Mon, 02 Sep 2002 18:59:21 +0200 Von: Sebastian Zander Firma: Fraunhofer FOKUS An: Internet-Drafts@ietf.org Hi, please post the draft attached (draft-zander-ipfix-eval-diameter-00.txt) as internet draft. Thanx, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander --------------080905070209050901080107 Content-Type: text/plain; name="draft-zander-ipfix-diameter-eval-00.txt" Content-Disposition: inline; filename="draft-zander-ipfix-diameter-eval-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Sebastian Zander Document: draft-zander-ipfix-diameter-eval-00.txt Fraunhofer FOKUS Expires: February 2003 September 2002 Evaluation of Diameter Protocol against IPFIX Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at Http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the Diameter protocol [DIAMETER] as an IPFIX protocol. It compares the properties and capabilities of the Diameter protocol to the IPFIX requirements [IPFIX-REQ]. Zander expires February 2003 [Page 1] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Table of Contents 1 Introduction ................................................. 2 1.1 Diameter Standardization ................................... 2 1.2 Diameter Deployment and Evolution .......................... 3 2 Architectural Considerations ................................. 3 2.1 Diameter Protocol Overview ................................. 4 2.2 General Applicability ...................................... 5 2.3 Architectural Differences .................................. 5 3 Item Level Compliance Evaluation ............................. 6 4 Security Considerations ...................................... 11 5 Acknowledgements ............................................. 11 6 References ................................................... 11 7 Author's Addresses ........................................... 12 8 Full Copyright Statement ..................................... 12 1. Introduction This document provides an evaluation of the applicability of the Diameter protocol as an IPFIX protocol. First, the general Diameter architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met. This document uses the terminology defined in [IPFIX-REQ]. The Diameter protocol is the successor of the RADIUS protocol and was developed to overcome several limitations of RADIUS. The Diameter protocol was developed for the purpose of Authentication, Authorization and Accounting (AAA) and is standardized by the IETF Authentication, Authorization and Accounting Working Group (AAA WG). The Diameter base protocol is specified in draft-ietf-aaa- diameter-12.txt [DIAMETER]. The Diameter base protocol provides a AAA framework. Specific applications require extensions to the base protocol and are called Diameter applications. Currently applications are being standardized by the AAA WG for dial-up and mobile IPv4 services. These specific applications are considered out of scope for the purpose of this document. However there are two companion drafts to the Diameter base protocol which need to be considered here: the strong end-to-end security extension [DIAM_CMS] and the transport recommendations for the Diameter base protocol [AAA_TRANS]. Zander expires February 2003 [Page 2] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 1.1. Diameter Standardization The Diameter base protocol has passed Working Group last call after thorough review. The draft will now be reviewed by the IESG and afterwards become a Proposed Standard. The transport recommendations draft is very mature while the CMS draft needs more work. The Diameter protocol will become an open IETF standard and is not protected by any patents. The IETF copyright can be found at the end of [DIAMETER] or at the end of this draft. Currently there exist approximately 5 implementations from different vendors. One of the implementations is even freely available as binary [DIA_SUN]. Furthermore an open source project has been started to create an open source implementation of the protocol [DIA_OS]. 1.2. Diameter Deployment and Evolution The Diameter protocol is already commercially available but not widely used yet because it is not standardized. Also most ISPs will not switch from RADIUS to Diameter for their dial-up services. However if Diameter is used in Release 5 of 3GPP as planned it is expected that the protocol will be widely deployed as part of the 3GPP rollout. A further driver will be ISPs offering mobile IP support. Currently a standardized RADIUS AAA solution for mobile IP does not exist. The further activities of the AAA WG after standardization of Diameter base protocol and base applications are under discussion. The most likely scenario (advocates opinion) is that the AAA WG will continue to develop more Diameter applications (collaborating with other WGs if needed). Also the base protocol will probably be developed further in case the demand is there. 2. Architectural Considerations This section introduces the architecture of the Diameter protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. The Diameter architecture consists of three different entities: Diameter clients, Diameter servers and Diameter agents. Diameter clients send requests for Authentication and/or Authorization to Diameter servers. Diameter clients also send Zander expires February 2003 [Page 3] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 accounting information to Diameter servers. Diameter clients are for example Network Access Servers (NASs) or foreign and home agents (mobile IPv4). Diameter servers perform authentication and authorization decisions based on Diameter clients requests and return answers to Diameter clients. Diameter servers configure accounting of the Diameter clients and get accounting information send by them. When Diameter servers get messages not destinated to themselves they forward both Authentication and Authorization request and accounting data to the appropriate servers. Diameter servers may also automatically direct the Diameter clients to send accounting information in a particular way. Four different types of Diameter agents have been identified and are described in Section 2.8 of [DIAMETER]. Diameter agents are used for a number of purposes: grouping of systems (security associations), request concentration, load balancing and value-added processing of requests/responses. Please note that despite the fact that the terms client and server are used the Diameter protocol is not a client server protocol but a peer-to-peer protocol. Any Diameter peer can start a messages exchange. This will be described in more detail in the next section. 2.1. Diameter Protocol Overview This section only provides a brief overview of the Diameter base protocol. Therefore it is mandatory to read the base protocol draft [DIAMETER] before evaluating the protocol. The Diameter base protocol is intended to provide an AAA framework for applications such as network access or mobile IP [DIAMETER]. is a peer-to-peer protocol allowing any peer to start a message exchange. The Diameter base protocol is never used on its own. It is always extended for a particular application e.g. mobile IPv4. The Diameter protocol is run on top of TCP [TCP] or SCTP [SCTP] which guarantee a reliable and congestion aware transport. Draft [AAA_TRANS] discusses the AAA transport issues in detail. Diameter has a build-in watchdog algorithm which can pro-actively detect transport failures. Also failback and failover procedures have been defined (section 5.5.4 [DIAMETER] and [AAA_TRANS]). Zander expires February 2003 [Page 4] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Diameter supports dynamic peer discovery through different mechanisms e.g. DNS, SLPv2 [SLP] to enable a simpler and more robust deployment. Peers can also be configured manually. Diameter provides application layer sessions which abstracts from transport connections. Diameter messages for multiple sessions are multiplexed through a single transport connection. Diameter server and agents route messages to their final destination based on realms. The data model of Diameter is based on Attribute Value Pairs (AVPs). Each Diameter message consists of a fixed header and a number of AVPs carrying data. The fixed header contains a 16 bit command code which identifies the type of message. A number of data types for AVPs have been defined already. AVPs can be grouped into logical structures. Diameter can be extended by defining new AVP values, new AVPs and new applications (which includes definition of new command codes). The Diameter protocol supports capability negotiation between peers. This enables a more simpler and robust deployment. Diameter supports applications which support Authentication, Authorization and Accounting. It also supports applications which only make use of accounting (see section 8 [DIAMETER]). Diameter uses hop-by-hop security [DIAMETER] and a Diameter extension exists which supports end-to-end security [DIAM_CMS] (see security considerations for more details). 2.2. General Applicability The Diameter architecture consists of three different entities (client, server and agent) while the IPFIX architecture is comprised of: observation point, metering process, exporting process and collecting process. From the viewpoint of the IPFIX protocol only the exporting process and collection process are relevant because these are the entities communicating via the IPFIX protocol. However the IPFIX protocol must carry data generated by the metering process. The process of exporting IP flow information is similar to the accounting part of Diameter: The Diameter client sending accounting information is simlar to the IPFIX exporting process sending IP flow information. The Diameter server receiving accounting information is similar to the collecting process receiving IP flow information. Diameter Relay and Proxy Agents are similar to an IPFIX proxy (a Zander expires February 2003 [Page 5] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 combination of collecting and exporting process) as described in section 9 [IPFIX]. The Diameter Translation Agent is similar to the Protocol Converter as described in section 9 [IPFIX]. The metering process and observation point are similar to entities co-located with the Diameter client which collect the accounting information. The IPFIX protocol could be implemented with Diameter similar as a new Diameter accounting application can be defined. [DIAMETER] explicitly describes how new accounting applications can be defined in section 1.2.4. 2.3. Architectural Differences The Diameter architecture has been developed for providing a AAA framework while IPFIX is to be developed for exporting IP flow information. There are no major differences between both architectures. The Diameter architecture is more generic than IPFIX. It supports a number of different proxy types and message routing. Furthermore the functionality of the first two As is not useful for IPFIX. However IPFIX could be viewed as a subset of Diameter similar to the Diameter accounting functionality. The Diameter standard explicitly supports accounting-only Diameter applications. 3. Item Level Compliance Evaluation This section evaluates the compliance of the Diameter protocol with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement it is explained to what degree protocol Diameter meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is onLY applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protocols, where the protocol specification itself needs to be extended in order to comply with the requirement. Zander expires February 2003 [Page 6] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 -P Partial compliance: The requirement is met partially by the protocol specification. -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. Requirement 4 (Distinguishing Flows): -E The following requirements assumes that Diameter is not only used for exporting IP flow information but also for configuration of the export. In case a different protocol is used for the configuration these requirements do not apply. As Diameter has not been developed for the purpose of IP flow export most of the attributes are not yet defined in the existing data model. To comply to the IPFIX protocol there are several possible options. Either all of the attributes are defined as new AVPs from the defined AVP types (and grouped where appropriate) (see Section 4.3,4.4 [DIAMETER]). Alternatively the existing QoS/IPFilterRule data types can be used and grouped with additional AVPs containing the attributes not yet defined in Diameter (see Section 4.4 [DIAMETER]). A further option is to extend the QoS/IPFilterRule types directly because most of the required attributes are covered already. Requirement 4.1 (Interfaces): -E Incoming interface and outgoing interface can be defined as AVPs. Requirement 4.2 (IP Header): -E Source IP and destination IP address can be defined as new AVPs. Note that Diameter supports both IPv4 and IPv6 addresses. Protocol Type and IP version number can be defined as AVPs. The existing IPFilterRule data type supports source, destination IP, protocol type. It also supports prefix matches of the addresses via masks. Requirement 4.3 (Transport Header): -T/E Source and destination port number can be defined as AVPs. The Zander expires February 2003 [Page 7] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 existing IPFilterRule data type supports ports, list of ports or ranges. Requirement 4.4 (MPLS): -E The MPLs label can be defined as AVP. Requirement 4.5 (DSCP): -T/E The Diffserv Code Point can be defined AVP. The existing QoSFilterRule supports a DSCP attribute. Requirement 4.6 (Header Compression): n/a This imposes no further requirements on the protocol Requirement 5.1 (Reliability): n/a This requirement does not apply to the protocol. Requirement 5.2 (Sampling): -E This requirement is a metering process requirement. However the IPFIX protocol must support to export some information about sampling configuration. New (grouped) AVPs can be defined for carrying the sampling configuration. Requirement 5.3 (Overload Behavior): -E This requirement is a metering process requirement. However some information must be send via the protocol e.g. to indicate overload behavior changes. New AVPs can be defined to signal changes of metering behaviour to the collecting process. Requirement 5.4 (Timestamps): -E This requirement is a metering process requirement. However a candidate protocol must support a proper timestamp format. Diameter does only support the Time data type which is UTC time in seconds. To meet the requirement a new AVP data type must be defined. Alternatively a Time AVP can be used for the seconds and grouped with an additional AVP for the centiseconds. Requirement 5.5 (Time Synchronization): n/a This requirement does not apply to the protocol. Zander expires February 2003 [Page 8] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Requirement 5.6 (Flow Expiration): n/a This requirement does not apply to the protocol. Requirement 5.7 (Multicast Flows): n/a This requirement does not apply to the protocol. Requirement 5.8 (Ignore Port Copy): n/a This requirement does not apply to the protocol. Requirement 6.1 (Information Model): -E For most of the attributes required there currently exist no defined AVPs. But for all attributes listed AVPs can be easily derived from the base data types. Instead of using existing data types new data types could be defined. Requirement 6.2 (Data Model): -T The data model of Diameter is based on the Attribute Value Pair (AVP) concept. An attribute is identified uniquely by a numeric AVP code and AVP length. A number of base types for AVPs have been defined in [DIAMETER]. The data model of Diameter is extensible because new AVPs and new AVP types can be defined. Diameter supports grouping of AVPs and nesting of grouped AVPs to create more complex structure. The data model is flexible because each Diameter message only has a small fixed size header. After the header arbitrary AVPs (as defined for a message) follow. The data model is independent of the transport (TCP or SCTP are used). Requirement 6.3.1 (Congestion Awareness): -T Diameter uses TCP or SCTP as transport. Both protocols are congestion aware. Requirement 6.3.2 (Reliability): -T Diameter is an application layer protocol which uses TCP [TCP] or SCTP [SCTP] as transport protocols which are both reliable. To support application layer reliability the protocol supports application layer ACKs and error messages. Zander expires February 2003 [Page 9] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 A watch dog mechanism has been defined to detect transport problems and failover and failback procedures have been defined. Diameter also supports capability negotiation between peers which assures that both peers have the same capabilities. Requirement 6.3.3 (Security): -T Diameter provides end-to-end as well as hop-by-hop authentication, integrity and encryption. Some mechanisms are provided by underlying security protocols used such as IPSec or TLS. Since [DIAMETER] specifies how to use them this requirement is considered to be met by the protocol. Please read the security considerations section for more details. Requirement 6.3.4 (Push/Pull Mode): -T Diameter is a peer to peer protocol. The current Diameter accounting model uses the push mode (a Diameter client sends accounting information to a Diameter server). However a Diameter application could be defined which supports a pull mode as well. Requirement 6.4 (Regular Report Interval): -T Diameter can send accounting information in regular intervals. Requirement 6.5 (Event Notification): -T A Diameter peer can send messages at times of events. The events and messages must be defined for the specific application. A Diameter configuration message could configure when to send specific event messages. Currently the Diameter base protocol sends accounting messages at the start and end of a session. Requirement 6.6 (Anonymization): n/a Diameter does not support anonymization. However anonymization is not a protocol specific function and therefore the requirement does not apply to the protocol. A function can be integrated into a Diameter peer which anonymizes certain data before it is exported in AVPs. Requirement 7 (Metering Process Configuration): -E These requirements only apply if Diameter is used for configuration of the metering process. Since Diameter is not a protocol for exporting IP flow information the listed attributes are not specified yet. Since the data model is flexible all attributes can Zander expires February 2003 [Page 10] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 be specified as AVPs. Requirement 8.1 (Openness): -T The Diameter base protocol is open and has an extensibility concept specified in the standard. The flexible AVP model allows to support any information model. New Diameter applications can be created which can define application specific messages and message exchange. Requirement 8.2 (Scalability): -T A Diameter peer is not limited in the number of connections to other peers. In Diameter each peer has a unique identifier which must be present in each message (Origin-Host AVP). Furthermore Diameter uses session IDs to uniquely identify specific sessions. Requirement 8.3 (Several Collecting Processes): -T Diameter accounting records are usually only send to the home server. However there is no limitation in the protocol that restricts sending information to only one destination. Diameter supports duplicate data detection over multiple receivers because each accounting message contains client ID, session ID, timestamp and a sequence number in each message. 4. Security Considerations Security considerations for the IPFIX protocol are covered by the comparison against the specific Security requirements in the IPFIX requirements document [IPFIX-REQ] where they are specifically addressed by sections 6.3.3 and 10. The Diameter base protocol assumes that messages are secured by using either IPSec or TLS. This security model is acceptable in environments where there is no untrusted third party agents. The use of TLS, IPSEC and considerations of peer-to-peer security issues are discussed in the security considerations of [DIAMETER]. In situations of untrusted third party agents, end-to-end security is needed. [DIAM_CMS] describes how a security association is established by two peers through agents, and how authentication, integrity, confidentiality and data origin authentication are achieved using a mixture of symmetric and asymmetric transforms. Zander expires February 2003 [Page 11] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 5. Acknowledgements The authors would like to thank Jari Arkko for his valuable comments on the first version of the draft. 6. References [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, work in progress, July 2002. [DIAMETER] P. Calhoun et al. "Diameter Base Protocol", draft-ietf-aaa- diameter-12.txt, work in progress, July 2002. [AAA_TRANS] B. Aboba at al., "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa- transport-07.txt, work in progress, April 2002 [DIAM_CMS] P. Calhoun et al., "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-04.txt, work in progress, March 2002 [TCP] Postel, J., "Transmission Control Protocol", RFC 793, January 1981. [SCTP] R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960. October 2000. [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, Version 2", RFC 2165, June 1999. [DIA_SUN] SUN Diameter implementation, http://playground.sun.com/diameter/ [DIA_OS] Diameter Open Source Project, http://sourceforge.net/projects/diameter/ Zander expires February 2003 [Page 12] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 7. Author's Addresses Sebastian Zander Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 3463 7287 Email: zander@fokus.fhg.de 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zander expires February 2003 [Page 13] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 --------------080905070209050901080107-- From owner-aaa-wg@merit.edu Wed Sep 4 08:28:44 2002 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 IAA24954 for ; Wed, 4 Sep 2002 08:28:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC03B9126E; Wed, 4 Sep 2002 08:29:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5A299126F; Wed, 4 Sep 2002 08:29:59 -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 ADA279126E for ; Wed, 4 Sep 2002 08:29:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 838685DEF6; Wed, 4 Sep 2002 08:29:58 -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 968DE5DDB6 for ; Wed, 4 Sep 2002 08:29:57 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B3AD96A901; Wed, 4 Sep 2002 15:29:45 +0300 (EEST) Message-ID: <3D75FDF4.40303@kolumbus.fi> Date: Wed, 04 Sep 2002 15:35:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: yohba@tari.toshiba.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Need more specifics on list of AVPs References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5408@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi All, > > I have seen no comments on this issue. As it is a request for debugging > purposes - I feel that at this late date, we cannot change the spec > to meet this request. We need to get Diameter out to IESG for > review. I agree with the reject for this issue. (But this isn't strictly for debugging. Its also an interoperability issue for the receiver of be able to decode the messages correctly. Still, if the spec doesn't say which order is allowed then any order is legal. Implementations should take this into account.) Jari From owner-aaa-wg@merit.edu Wed Sep 4 14:41:40 2002 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 OAA15244 for ; Wed, 4 Sep 2002 14:41:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D3D891275; Wed, 4 Sep 2002 14:43:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2CF891276; Wed, 4 Sep 2002 14:42:59 -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 BC6CF91275 for ; Wed, 4 Sep 2002 14:42:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EC135DF18; Wed, 4 Sep 2002 14:42:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 3B1505DDB8 for ; Wed, 4 Sep 2002 14:42:58 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g84IggvH029132; Wed, 4 Sep 2002 14:42:42 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA06729; Wed, 4 Sep 2002 14:43:06 -0400 (EDT) Date: Wed, 4 Sep 2002 14:42:40 -0400 To: Jari Arkko Cc: john.loughney@nokia.com, yohba@tari.toshiba.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Need more specifics on list of AVPs Message-ID: <20020904184240.GE678@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5408@esebe004.ntc.nokia.com> <3D75FDF4.40303@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3D75FDF4.40303@kolumbus.fi> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 23 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Sep 04, 2002 at 03:35:00PM +0300, Jari Arkko wrote: > john.loughney@nokia.com wrote: > > Hi All, > > > > I have seen no comments on this issue. As it is a request for debugging > > purposes - I feel that at this late date, we cannot change the spec > > to meet this request. We need to get Diameter out to IESG for > > review. > > I agree with the reject for this issue. > > (But this isn't strictly for debugging. Its also an interoperability > issue for the receiver of be able to decode the messages correctly. > Still, if the spec doesn't say which order is allowed then any order > is legal. Implementations should take this into account.) > > Jari > OK. In fact, my current implementation supports the any-order processing to provide interoperability. Yoshihiro Ohba From owner-aaa-wg@merit.edu Sat Sep 7 11:38:12 2002 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 LAA14252 for ; Sat, 7 Sep 2002 11:38:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A60999135A; Sat, 7 Sep 2002 11:39:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 690CF91359; Sat, 7 Sep 2002 11:39:37 -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 7127F9135A for ; Sat, 7 Sep 2002 11:39:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 507E85DE8E; Sat, 7 Sep 2002 11:39:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E0C635DDC7 for ; Sat, 7 Sep 2002 11:39:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g87EfXP29546 for ; Sat, 7 Sep 2002 07:41:33 -0700 Date: Sat, 7 Sep 2002 07:41:33 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue 353] Issues with EAP-00 draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 353: Issues with EAP-00 draft Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 7, 2002 Reference: Document: EAP-00 Comment type: T Priority: 1 Section: several Rationale/Explanation of issue: Page 2, last sentence of the Abstract: Change "PPP Extensible Authentication Protocol" to "Extensible Authentication Protocol." Page 2, section 2, last sentence: Change "with PAP and CHAP in a roaming PPP environment." to "with PAP, CHAP or EAP-MD5." Page 3, Section 2.1, second paragraph, first sentence: The first approach was described as "typical". That would imply that additional approaches are non-typical, so that the adjective "preferred" would not apply to them. Also, in the BNF {Section 3.1.1}, the Destination-Realm AVP is noted as required. Where the "typical" approach is taken, it would seem difficult to include this. So perhaps you should describe how this is done. Change "A preferred approach..." to "An alternate approach..." Page 3, Section 2.1, Fourth paragraph: Change: " A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH." To: " A Diameter-EAP-Answer message containing an EAP-Payload of code EAP- Success (3) or EAP-Failure (4) MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH." Page 3, Section 2.1, paragraph 5: "Diameter-EAP-Answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs." You might give an example of a situation where this would occur. Section 4.2.1 last sentence: "If the NAS performs the Termination-Action by sending a new Diameter-EAP-Request command upon termination of the current service, it MUST return the State AVP unmodified in the new Diameter-EAP-Request command." I've never understood the purpose of the State AVP here, or why it is a MUST for inclusion. Some additional explanation would be helpful. Page 9, Section 4.2.5, third paragraph "If the value of the Termaination-Action AVP is equal to AA-REQUEST (1) then upon termination of the authorized service the NAS MAY send a new Diameter-EAP-Request (DER) command." This is what RFC 2865 says, but it makes more sense for the MAY to be a SHOULD or MUST. Essentially, this becomes a way to mandate re-authentication without a server-initiated message. By using the DEFAULT value, it's possible to terminate the session, so a AA-REQUEST value might as well cause something different to happen. Section 4.2.5, page 10, third paragraph: "When used by 802.1x access devices, the service typically terminates due to the expiry of the Session-Timeout AVP. The access device may then reauthenticate the user with a new DER. The RECOMMENDED way to do this in Diameter is to use the Authorization-Lifetime AVP rather than the Termination-Action AVP. However, the Termination-Action AVP MAY be used when copied from a RADIUS Access-Accept packet to a Diameter-EAP-Answer command by a Translation Agent." Actually, the service only terminates if Termination-Action=DEFAULT or no Termination-Action AVP is included at all. If Termination-Acton=AA-REQUEST, then re-authentication occurs. See: http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-20.txt ADDITIONS NAS-Session-Key AVP I think this needs to be defined in the EAP document, not in NASREQ. Since there is controversy about this AVP, including it in NASREQ would prevent that document from advancing. Security considerations You might consider cadging this from RFC 2869bis-03: http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-03.txt Usage Guidelines Please consider the inclusion (with modifications to fit Diameter) of the following section from RFC 2869bis-03, clarifying various aspects of AAA/EAP interoperability: 2.5. Usage guidelines 2.5.1. Authentication completion Within an EAP conversation, a RADIUS Access-Accept will typically contain an EAP-Message attribute encapsulating an EAP Success packet. Similarly, a RADIUS Access-Reject will typically contain an EAP-Message attribute encapsulating an EAP Failure packet. However, this is not required. For example, the RADIUS Access-Accept/Reject could contain an EAP-Message attribute encapsulating an EAP-Request with an appropriate Type code. This could occur, for example, where an EAP method contains its own (protected) success or failure indications. In this case, it may be possible to eliminate sending of the final EAP Success or EAP Failure packet, saving a round-trip. 2.5.2. Conflicting messages In some cases, the authentication result implied by the encapsulated EAP packet may not match the result communicated in the RADIUS message. For example, and EAP Failure packet may be encapsulated within an Access- Accept message and an EAP Success packet may be encapsulated within an Access-Reject. Alternatively, no EAP-Message attribute may be included within a RADIUS Access-Accept or Access-Reject. Such combinations are likely to cause confusion, because the NAS and Peer will arrive at different conclusions as to the outcome of the authentication. For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the Peer. However, on receiving the Success, the Peer will be lead to believe that it authenticated successfully. Similarly, if the NAS receives an Access-Accept with an encapsulated EAP Failure, it will grant access to the Peer. However, on receiving an EAP Failure, the Peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the Peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access. As described in [RFC2284bis], the EAP Success and Failure packets are not acknowledged, and these packets terminate the EAP conversation. As a result, if these packets are encapsulated within an Access-Challenge, no response will be received, and therefore no further Access-Requests will be sent to the RADIUS server. As a result, the NAS will not be given an indication of whether to allow or deny access while the Peer will be informed as to the outcome of the authentication. To avoid these conflicts, the RADIUS server SHOULD check to make sure that the results implied by an encapsulated EAP-Message attribute and the RADIUS message are in agreement. The following combinations SHOULD NOT be sent by a RADIUS server as part of an EAP conversation: Access-Accept/EAP-Message/EAP Failure Access-Accept/no EAP-Message attribute Access-Reject/EAP-Message/EAP Success Access-Reject/no EAP-Message attribute Access-Challenge/EAP-Message/EAP Success Access-Challenge/EAP-Message/EAP Failure Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. 2.5.3. Priority In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, the NAS SHOULD process EAP-Message attributes last. [This is important for 802.1aa, but it makes more sense for it to end up in the Diameter EAP document than to put this in 802.1aa.] 2.5.4. Displayable messages The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which MAY be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server SHOULD encapsulate displayable messages within EAP- Message/EAP-Request/Notification attribute(s), and SHOULD NOT use Reply- Message attribute(s) for this purpose. [I think that Reply-Message is already prohibited in Diameter, since it wasn't included in the EAP Application BNF. If so, this is a good thing, and this section isn't needed.] A NAS receiving Reply-Message attribute(s) MAY copy the Text field(s) into the Type-Data field of an EAP-Request/Notification packet, fill in the Identifier field, and send this to the Peer. However, several issues may arise from this: [1] Unexpected Responses. On receiving an EAP-Request/Notification, the Peer will send an EAP-Response/Notification, and the NAS will pass this on to the RADIUS server, encapsulated within EAP-Message attribute(s). However, the RADIUS server may not be expecting an Access-Request containing an EAP-Message/EAP-Response/Notification attribute. For example, consider what happens when a Reply-Message is included within an Access-Accept or Access-Reject packet with no EAP-Message attribute present. If the value of the Reply-Message attribute is copied into the Type-Data of an EAP-Request/Notification and sent to the peer, this will result in an Access-Request containing an EAP-Message/EAP-Response/Notification attribute being sent by the NAS to the RADIUS server. Since an Access-Accept or Access-Reject packet terminates the RADIUS conversation, such an Access-Request would not be expected. [2] Identifier conflicts. While the EAP-Request/Notification contains an an Identifier, a Reply-Message attribute does not. As a result, a NAS receiving a Reply-Message attribute and wishing to translate this to an EAP-Request/Notification will need to choose an Identifier. It is possible that the chosen Identifier will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. This would violate the requirement in [RFC2284bis] that Identifier values be unique within an EAP conversation. 2.5.5. Displayable messages When used within an EAP conversation, a Reply-Message attribute received by the NAS MAY be translated to an EAP-Request/Notification sent to the peer. As a result, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP- Request/Notification or Reply-Message attribute SHOULD NOT be included within an Access-Accept or Access-Reject packet representing the conclusion of an EAP conversation. [I think this may be irrelevant for Diameter EAP, because the BNF does not include the Reply-Message AVP.] From owner-aaa-wg@merit.edu Sun Sep 8 10:52:35 2002 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 KAA07392 for ; Sun, 8 Sep 2002 10:52:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63B9091205; Sun, 8 Sep 2002 10:53:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F8E391207; Sun, 8 Sep 2002 10:53: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 214B391205 for ; Sun, 8 Sep 2002 10:53:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 020EB5DEA8; Sun, 8 Sep 2002 10:53:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by segue.merit.edu (Postfix) with SMTP id 709525DE7F for ; Sun, 8 Sep 2002 10:53:47 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Sep 2002 15:53:43 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804FDE3DE@rsys002a.roke.co.uk> From: "Hepworth, Eleanor" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: NASREQ Query Date: Sun, 8 Sep 2002 15:53:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, I have a quick query regarding the Diameter NASREQ I-D. The draft contains the following statement in the AA-Request description (section 3.1.1 of version 09): It is possible for a single session to be authorized first, then followed by an authentication request. However, the inverse SHOULD NOT be permitted. I'm a little confused about this as usually I would expect authentication to be followed by an optional authorization step. Should this text be the other way round (or have I misunderstood something)? Thanks Ele ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- From owner-aaa-wg@merit.edu Mon Sep 9 02:03:08 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18029 for ; Mon, 9 Sep 2002 02:03:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D438891212; Mon, 9 Sep 2002 02:04:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E1CB91216; Mon, 9 Sep 2002 02:04: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 CB2AF91212 for ; Mon, 9 Sep 2002 02:04:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF7ED5DD97; Mon, 9 Sep 2002 02:04:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 482175DD8D for ; Mon, 9 Sep 2002 02:04:07 -0400 (EDT) Received: from gwzw2k (tokyo-vpn-user30.cisco.com [10.70.82.30]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id XAA28538; Sun, 8 Sep 2002 23:03:55 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" , Subject: RE: [AAA-WG]: [issue 353] Issues with EAP-00 draft Date: Sun, 8 Sep 2002 18:18:45 -0700 Message-ID: <000001c257c6$933ced60$24f40a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > Issue 353: Issues with EAP-00 draft > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 7, 2002 > Reference: > Document: EAP-00 > Comment type: T > Priority: 1 > Section: several > Rationale/Explanation of issue: > > Page 2, last sentence of the Abstract: > > Change "PPP Extensible Authentication Protocol" to "Extensible > Authentication Protocol." OK > > Page 2, section 2, last sentence: > > Change "with PAP and CHAP in a roaming PPP environment." to > "with PAP, CHAP or EAP-MD5." OK > > Page 3, Section 2.1, second paragraph, first sentence: > > The first approach was described as "typical". That would imply that > additional approaches are non-typical, so that the adjective > "preferred" > would not apply to them. Not sure I follow your reasoning. Are you saying that typical behavior is also optimal? This assertion seems a bit absurd :-)... > Also, in the BNF {Section 3.1.1}, the > Destination-Realm AVP is noted as required. Where the > "typical" approach > is taken, it would seem difficult to include this. Indeed! In fact, it looks to me like the "typical" approach, far from being either optimal or even "preferred" is actually pretty useless: it seems to waste bandwidth to no good purpose, since the empty request cannot be routed to the home realm... > So perhaps > you should > describe how this is done. > > Change "A preferred approach..." to "An alternate approach..." I would prefer :-) to delete or deprecate the first approach. > > Page 3, Section 2.1, Fourth paragraph: > > Change: > > " A Diameter-EAP-Answer message containing an EAP-Payload > of type EAP- > Success or EAP-Failure MUST NOT have the Result-Code AVP set to > DIAMETER_MULTI_ROUND_AUTH." > > To: > > " A Diameter-EAP-Answer message containing an EAP-Payload > of code EAP- > Success (3) or EAP-Failure (4) MUST NOT have the > Result-Code AVP set to > DIAMETER_MULTI_ROUND_AUTH." > OK > Page 3, Section 2.1, paragraph 5: > > "Diameter-EAP-Answer messages whose Result-Code AVP is set to > DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs." > > You might give an example of a situation where this would occur. Can you think of one? > > Section 4.2.1 last sentence: > > "If the NAS performs the > Termination-Action by sending a new Diameter-EAP-Request > command upon > termination of the current service, it MUST return the State AVP > unmodified in the new Diameter-EAP-Request command." > > I've never understood the purpose of the State AVP here, or > why it is a > MUST for inclusion. Some additional explanation would be helpful. > > Page 9, Section 4.2.5, third paragraph > > "If the value of the Termaination-Action AVP is equal to AA-REQUEST > (1) then upon termination of the authorized service the > NAS MAY send > a new Diameter-EAP-Request (DER) command." > > This is what RFC 2865 says, but it makes more sense for the > MAY to be a > SHOULD or MUST. Essentially, this becomes a way to mandate > re-authentication without a server-initiated message. By > using the DEFAULT > value, it's possible to terminate the session, so a > AA-REQUEST value might > as well cause something different to happen. Agreed. > > Section 4.2.5, page 10, third paragraph: > > "When used by 802.1x access devices, the service typically > terminates due to the expiry of the Session-Timeout AVP. > The access device may then reauthenticate the user with a > new DER. The RECOMMENDED way to do this in Diameter is to > use the Authorization-Lifetime AVP rather than the > Termination-Action AVP. However, the > Termination-Action AVP > MAY be used when copied from a RADIUS Access-Accept packet > to a Diameter-EAP-Answer command by a Translation Agent." > > Actually, the service only terminates if > Termination-Action=DEFAULT or no > Termination-Action AVP is included at all. If > Termination-Acton=AA-REQUEST, then re-authentication occurs. See: > > http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-20.txt > > ADDITIONS > > NAS-Session-Key AVP > > I think this needs to be defined in the EAP document, not in > NASREQ. I disagree emphatically. Removing this AVP from NASREQ would result in Diameter actually having _less_ functionality than current (albeit non-standard) RADIUS implementations. > Since > there is controversy about this AVP, including it in NASREQ > would prevent > that document from advancing. The major controversy I recall was from Paul Funk, who hasn't followed up AFAIK, even as far as answering my question as to why the current AVPs do not suffice to do exactly what he wants. Are there other complaints? > > Security considerations > > You might consider cadging this from RFC 2869bis-03: > > http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869 > bis-03.txt > > Usage Guidelines > > Please consider the inclusion (with modifications to fit > Diameter) of the > following section from RFC 2869bis-03, clarifying various aspects of > AAA/EAP interoperability: > > 2.5. Usage guidelines > > 2.5.1. Authentication completion > > Within an EAP conversation, a RADIUS Access-Accept will typically > contain an EAP-Message attribute encapsulating an EAP Success packet. > Similarly, a RADIUS Access-Reject will typically contain an > EAP-Message > attribute encapsulating an EAP Failure packet. However, this is not > required. For example, the RADIUS Access-Accept/Reject could > contain an > EAP-Message attribute encapsulating an EAP-Request with an appropriate > Type code. This could occur, for example, where an EAP method contains > its own (protected) success or failure indications. In this > case, it may > be possible to eliminate sending of the final EAP Success or > EAP Failure > packet, saving a round-trip. > > 2.5.2. Conflicting messages > > In some cases, the authentication result implied by the > encapsulated EAP > packet may not match the result communicated in the RADIUS > message. For > example, and EAP Failure packet may be encapsulated within an Access- > Accept message and an EAP Success packet may be encapsulated within an > Access-Reject. Alternatively, no EAP-Message attribute may be included > within a RADIUS Access-Accept or Access-Reject. > > Such combinations are likely to cause confusion, because the NAS and > Peer will arrive at different conclusions as to the outcome of the > authentication. For example, if the NAS receives an Access-Reject with > an encapsulated EAP Success, it will not grant access to the Peer. > However, on receiving the Success, the Peer will be lead to > believe that > it authenticated successfully. > > Similarly, if the NAS receives an Access-Accept with an > encapsulated EAP > Failure, it will grant access to the Peer. However, on > receiving an EAP > Failure, the Peer will be lead to believe that it failed > authentication. > If no EAP-Message attribute is included within an Access-Accept or > Access-Reject, then the Peer may not be informed as to the outcome of > the authentication, while the NAS will take action to allow or deny > access. > > As described in [RFC2284bis], the EAP Success and Failure packets are > not acknowledged, and these packets terminate the EAP > conversation. As a > result, if these packets are encapsulated within an > Access-Challenge, no > response will be received, and therefore no further > Access-Requests will > be sent to the RADIUS server. As a result, the NAS will not > be given an > indication of whether to allow or deny access while the Peer will be > informed as to the outcome of the authentication. > > To avoid these conflicts, the RADIUS server SHOULD check to make sure > that the results implied by an encapsulated EAP-Message attribute and > the RADIUS message are in agreement. The following combinations SHOULD > NOT be sent by a RADIUS server as part of an EAP conversation: > > Access-Accept/EAP-Message/EAP Failure > Access-Accept/no EAP-Message attribute > Access-Reject/EAP-Message/EAP Success > Access-Reject/no EAP-Message attribute > Access-Challenge/EAP-Message/EAP Success > Access-Challenge/EAP-Message/EAP Failure > > Since the responsibility for avoiding these conflicts lies with the > RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to > correct contradictory messages that it receives. > > > > 2.5.3. Priority > > In addition to containing EAP-Message attributes, RADIUS messages may > also contain other attributes. In order to ensure the correct > processing > of RADIUS messages, the NAS SHOULD process EAP-Message > attributes last. > > [This is important for 802.1aa, but it makes more sense for > it to end up > in the Diameter EAP document than to put this in 802.1aa.] > > 2.5.4. Displayable messages > > The Reply-Message attribute, defined in section 5.18 of [RFC2865], > indicates text which MAY be displayed to the user. This is similar in > concept to the EAP Notification Type, defined in [RFC2284]. When > sending a displayable message to a NAS during an EAP conversation, the > RADIUS server SHOULD encapsulate displayable messages within EAP- > Message/EAP-Request/Notification attribute(s), and SHOULD NOT > use Reply- > Message attribute(s) for this purpose. > > [I think that Reply-Message is already prohibited in > Diameter, since it > wasn't included in the EAP Application BNF. If so, this is a > good thing, > and this section isn't needed.] > > A NAS receiving Reply-Message attribute(s) MAY copy the Text field(s) > into the Type-Data field of an EAP-Request/Notification > packet, fill in > the Identifier field, and send this to the Peer. However, > several issues > may arise from this: > > [1] Unexpected Responses. On receiving an > EAP-Request/Notification, the > Peer will send an EAP-Response/Notification, and the NAS > will pass > this on to the RADIUS server, encapsulated within EAP-Message > attribute(s). However, the RADIUS server may not be expecting an > Access-Request containing an > EAP-Message/EAP-Response/Notification > attribute. > > For example, consider what happens when a Reply-Message > is included > within an Access-Accept or Access-Reject packet with no > EAP-Message > attribute present. If the value of the Reply-Message > attribute is > copied into the Type-Data of an EAP-Request/Notification and sent > to the peer, this will result in an Access-Request containing an > EAP-Message/EAP-Response/Notification attribute being sent by the > NAS to the RADIUS server. Since an Access-Accept or Access-Reject > packet terminates the RADIUS conversation, such an Access-Request > would not be expected. > > [2] Identifier conflicts. While the EAP-Request/Notification contains > an an Identifier, a Reply-Message attribute does not. As > a result, > a NAS receiving a Reply-Message attribute and wishing to > translate > this to an EAP-Request/Notification will need to choose an > Identifier. It is possible that the chosen Identifier > will conflict > with a value chosen by the RADIUS server for another > packet within > the EAP conversation. This would violate the requirement in > [RFC2284bis] that Identifier values be unique within an EAP > conversation. > > 2.5.5. Displayable messages > > When used within an EAP conversation, a Reply-Message > attribute received > by the NAS MAY be translated to an EAP-Request/Notification > sent to the > peer. As a result, a Reply-Message attribute MUST NOT be included in a > RADIUS message containing an EAP-Message attribute. An > EAP-Message/EAP- > Request/Notification or Reply-Message attribute SHOULD NOT be included > within an Access-Accept or Access-Reject packet representing the > conclusion of an EAP conversation. > > [I think this may be irrelevant for Diameter EAP, because the > BNF does not > include the Reply-Message AVP.] > > > From owner-aaa-wg@merit.edu Mon Sep 9 08:22:27 2002 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 IAA29316 for ; Mon, 9 Sep 2002 08:22:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4980691221; Mon, 9 Sep 2002 08:23:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1155A91224; Mon, 9 Sep 2002 08:23: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 E2D8191221 for ; Mon, 9 Sep 2002 08:23:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBCA05DDB1; Mon, 9 Sep 2002 08:23:51 -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 D133D5DD9D for ; Mon, 9 Sep 2002 08:23:50 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g89CNrU13971 for ; Mon, 9 Sep 2002 15:23:53 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Sep 2002 15:15:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Sep 2002 15:15:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Date: Mon, 9 Sep 2002 15:15:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F0C@esebe004.ntc.nokia.com> Thread-Topic: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Thread-Index: AcI043vDx4wX1VFeTbixD5RfGP0R4QjFis8A From: To: , X-OriginalArrivalTime: 09 Sep 2002 12:15:43.0947 (UTC) FILETIME=[9EEB81B0:01C257FA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29316 Hi Pete, Doing final edits on the next version of the base. > Should we say instead, "or a vendor specific experimental Application > Identifier."? Or should we delete the last clause, as all Application > Identifiers are now assigned by IANA, regardless of whether > vendor-specific or not? I think they should be assigned by IANA on a first come, first serve basis. > Also from Section 1.2.4: > > This is why "disk writing" accounting servers should advertise > themselves as "Relays" that can handle any Application ID, > including > Vendor-Specific. > > There is an issue with this text that was raised by Glen Zorn but > never resolved: I think we mean to say "can handle any *Accounting* > Application ID.". A disk-writing accounting server can handle only > ACR and ACA, not just any command. Remember, the standards-track > application IDs that can appear in CER are split into normal App-IDs > and Accounting App-IDs. I think a "disk writing" accounting server > should advertise support for the Relay applicationin an Accounting > App-ID *only*. Also, I don't think such a server can handle any > Vendor-Specific application, because such an application can never > include standards-track commands such as ACR/ACA under the current > rules, as I understand them. I agree with adding the word Accounting, I'm not sure what else you anted to add. > 3.3 Diameter Command Naming Conventions > > Diameter commands typically includes one or more English words > > Should be, "Diameter command names typically include" Got it. > 3 Diameter Header > ... > Command-Code values in the range 0xfffff0 through 0xffffff are > ^^^^^ this is only 16 > commands. It's conceivable that even a > single application may need more. Should we > use 0xffff00 through 0xffffff > instead? If so, also need to correct the > range in Section 11.2.1. I'm just following the guidelines of the AD. If we increased it, it will just get knocked back down during IESG review. > Should we clarify here that experimental use = vendor specific? I.e., > "Command-Code values in the range 0xfffff0 through 0xffffff are > reserved for use by vendor specific, experimental commands." Not sure that would help anything ... > Also, remove extra space between "ID" and "AVP" in the last line. ACK. > 11.3 Application Identifiers > > As defined in section 2.4, the Application Identifier is used to > identify a specific Diameter Application. There are > standards-track > application ids and vendor specific application ids. > > IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for > standards-track applications; and 0xff00000000 - 0xfffffffe for > vendor specific applications. > > Both Application-Id and Acct-Application-Id AVPs use the same > Application Identifier space. > > Vendor-Specific Application Identifiers, encoded in the Vendor- > Specific-Application-Id Grouped AVP, with the Vendor-Id > AVP set to > the vendor's enterprise number, is for Private Use. > > I don't think this is strictly true anymore. The Vendor-Specific > Application Identifiers are now from the experimental range > 0xff00000000 - 0xfffffffe and are in fact managed by IANA. Or perhaps > I've misinterpreted the intention here? > > If the experimental command code space is to be managed by IANA, this > IANA Considerations section is inadequate. It needs to give the > assignment policy (Expert Review, First-come-first-served, etc.). > > We could leave the space for Private Use (I actually favor this > alternative), but I think that brought up the routing concerns raised > by Bernard - then we would need to parse the AVPs to find out how to > route the command. Also such a policy conflicts with the language in > section 3 under "Command Codes", which I quoted above. I'll take care of this in a follow on mail. John From owner-aaa-wg@merit.edu Mon Sep 9 09:35:00 2002 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 JAA01301 for ; Mon, 9 Sep 2002 09:35:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26B0491226; Mon, 9 Sep 2002 09:36:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE8F591227; Mon, 9 Sep 2002 09:36:25 -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 18BDC91226 for ; Mon, 9 Sep 2002 09:36:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05A405DDB6; Mon, 9 Sep 2002 09:36:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 79C6D5DD9D for ; Mon, 9 Sep 2002 09:36:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g89CcAp21169; Mon, 9 Sep 2002 05:38:10 -0700 Date: Mon, 9 Sep 2002 05:38:10 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue 353] Issues with EAP-00 draft In-Reply-To: <000001c257c6$933ced60$24f40a0a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Not sure I follow your reasoning. Are you saying that typical behavior is > also optimal? This assertion seems a bit absurd :-)... I'm just wondering which behavior the draft is advocating, and why. > Indeed! In fact, it looks to me like the "typical" approach, far from being > either optimal or even "preferred" is actually pretty useless: it seems to > waste bandwidth to no good purpose, since the empty request cannot be routed > to the home realm... However, if there is no proxy, then it could conceivably be useful. For example, the RADIUS server could decide to dispense with an EAP Identity exchange altogether and go immediately to an identity-hiding method (EAP TTLS or PEAP). > I would prefer :-) to delete or deprecate the first approach. Perhaps the right thing to do is to indicate that the second approach is preferred, except in special cases where the first approach MAY be used. > > You might give an example of a situation where this would occur. > > Can you think of one? The case that comes to mind is use of Session-Timeout to indicate the desired timeout period for the NAS, before resending the EAP Request. > > Since > > there is controversy about this AVP, including it in NASREQ > > would prevent > > that document from advancing. > > The major controversy I recall was from Paul Funk, who hasn't followed up > AFAIK, even as far as answering my question as to why the current AVPs do > not suffice to do exactly what he wants. Are there other complaints? Yes, see Issue #294. From owner-aaa-wg@merit.edu Mon Sep 9 09:43:37 2002 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 JAA01561 for ; Mon, 9 Sep 2002 09:43:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2CE6491227; Mon, 9 Sep 2002 09:44:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0FF291229; Mon, 9 Sep 2002 09:44: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 0AF5B91227 for ; Mon, 9 Sep 2002 09:44:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7D765DDBA; Mon, 9 Sep 2002 09:44:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6D7765DD9D for ; Mon, 9 Sep 2002 09:44:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g89Ckff21688; Mon, 9 Sep 2002 05:46:41 -0700 Date: Mon, 9 Sep 2002 05:46:40 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: mccap@lucent.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F0C@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree with adding the word Accounting, I'm not sure what else you anted > to add. The point is that a "disk writing" accounting server cannot handle new commands unless it understands them. This means that it can only handle Accounting App-IDs that don't involve a new command -- but there is no way for it to determine whether this is true or not. From owner-aaa-wg@merit.edu Mon Sep 9 10:06:32 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02452 for ; Mon, 9 Sep 2002 10:06:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FC5C9122C; Mon, 9 Sep 2002 10:05:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 934E191233; Mon, 9 Sep 2002 10:05: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 AC0819122C for ; Mon, 9 Sep 2002 10:03:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95F615DDB6; Mon, 9 Sep 2002 10:03:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 293E65DD9D for ; Mon, 9 Sep 2002 10:03:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g89D4io22681; Mon, 9 Sep 2002 06:04:44 -0700 Date: Mon, 9 Sep 2002 06:04:44 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue 353] Issues with EAP-00 draft In-Reply-To: <000001c257c6$933ced60$24f40a0a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > I think this needs to be defined in the EAP document, not in > > NASREQ. > > I disagree emphatically. Removing this AVP from NASREQ would result in > Diameter actually having _less_ functionality than current (albeit > non-standard) RADIUS implementations. Question: Is there a use for this AVP outside of EAP? For example, is it used by 3GPP2? As I recall, the 3GPP2 liason letter requested advancement of NASREQ for use with PAP/CHAP authentication, but there was no mention of a need for keying support. From owner-aaa-wg@merit.edu Mon Sep 9 11:21:38 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07038 for ; Mon, 9 Sep 2002 11:21:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BBBC91246; Mon, 9 Sep 2002 11:22:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC85491247; Mon, 9 Sep 2002 11:22:41 -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 E6C2E91246 for ; Mon, 9 Sep 2002 11:22:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8A055DE44; Mon, 9 Sep 2002 11:22:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (unknown [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id 772E85DDBF for ; Mon, 9 Sep 2002 11:22:39 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g89FMTx29215; Mon, 9 Sep 2002 11:22:30 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA06091; Mon, 9 Sep 2002 10:22:29 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H26G1D-0000I8-00; Mon, 09 Sep 2002 11:22:25 -0400 Message-ID: <15740.48303.763955.797346@gargle.gargle.HOWL> Date: Mon, 9 Sep 2002 10:22:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: Bernard Aboba Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F0C@esebe004.ntc.nokia.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: > > I agree with adding the word Accounting, I'm not sure what else you anted > > to add. > > The point is that a "disk writing" accounting server cannot handle new > commands unless it understands them. This means that it can only handle > Accounting App-IDs that don't involve a new command -- but there is no way > for it to determine whether this is true or not. Yes, and this is true for both standards-track and vendor-specific applications. Additionally, there is no way to tell whether a vendor-specific application is "Authorization" or "Accounting" because there is only one type of Vendor-Specific Application ID AVP in the CER/CEA (not that it would have helped anyway due to the above). Upon further reflection, I think we should just strike the offending paragraph in section 1.2.4: > This is why "disk writing" accounting servers should advertise > themselves as "Relays" that can handle any Application ID, including > Vendor-Specific. Basically, it is impossible to create a disk-writing accounting server without knowing that no additional commands are defined by the given application, or by providing the additional command functionality in another network entity. It was a nice thought, but it just doesn't work. -Pete From owner-aaa-wg@merit.edu Mon Sep 9 11:49:39 2002 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 LAA08052 for ; Mon, 9 Sep 2002 11:49:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C47B91240; Mon, 9 Sep 2002 11:51:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A06A9124C; Mon, 9 Sep 2002 11:51:04 -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 806B391240 for ; Mon, 9 Sep 2002 11:51:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 54B5E5DDBF; Mon, 9 Sep 2002 11:51:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id AF6045DDB5 for ; Mon, 9 Sep 2002 11:51:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g89Eqke28545; Mon, 9 Sep 2002 07:52:46 -0700 Date: Mon, 9 Sep 2002 07:52:45 -0700 (PDT) From: Bernard Aboba To: Pete McCann Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <15740.48303.763955.797346@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > The point is that a "disk writing" accounting server cannot handle new > > commands unless it understands them. This means that it can only handle > > Accounting App-IDs that don't involve a new command -- but there is no way > > for it to determine whether this is true or not. > > Yes, and this is true for both standards-track and vendor-specific > applications. Additionally, there is no way to tell whether a > vendor-specific application is "Authorization" or "Accounting" because > there is only one type of Vendor-Specific Application ID AVP in the > CER/CEA (not that it would have helped anyway due to the above). It seems that the only way this could be made to work is to add bits in the application-id field to differentiate between authorization/accounting applications, and also between new commands/no new command applications. I'm not clear that this is necessary, though (see below for simpler solution). > Upon further reflection, I think we should just strike the offending > paragraph in section 1.2.4: > > > This is why "disk writing" accounting servers should advertise > > themselves as "Relays" that can handle any Application ID, including > > Vendor-Specific. > > Basically, it is impossible to create a disk-writing accounting server > without knowing that no additional commands are defined by the given > application, or by providing the additional command functionality in > another network entity. It was a nice thought, but it just doesn't > work. Originally, a new application-ID required a new command, and therefore there was no reason to expect that a "disk writing" accounting server could handle anything other than the standard Accounting application-ID. In some ways this original formulation is very clean -- the accounting server just advertises the standard accounting application, and there is no reason to get another application-ID unless you're defining a new command. In this case, deleting the paragraph has no ill effects, and I'd agree with you. However, now my understanding is that we are allowing allocation of new application IDs without a new command. This has the troublesome effect of breaking interoperability as a result of trivial changes (e.g. adding a vendor-specific AVP). Although we have put language in the draft discouraging allocation of new application IDs without good reason, in practice, this has had no effect -- virtually every accounting usage in Diameter is now requesting an application ID, whether it is necessary or not. So it seems to me that we have a choice of either putting some teeth into the allocation policy (e.g. going with "expert review" before allocation of an application ID) or putting bits into the application-ID to allow the accounting server to distinguish the new AVP case from the new command case. If we don't do either of these things, the likely outcome is that Diameter will end up being less extensible than RADIUS. From owner-aaa-wg@merit.edu Mon Sep 9 18:00:45 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17757 for ; Mon, 9 Sep 2002 18:00:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADBCC91286; Mon, 9 Sep 2002 17:59:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C64991273; Mon, 9 Sep 2002 17:59:15 -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 F36F291287 for ; Mon, 9 Sep 2002 17:59:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9B095DECE; Mon, 9 Sep 2002 17:59:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (unknown [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 76CB85DEBC for ; Mon, 9 Sep 2002 17:59:05 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g89Lwmq18228; Mon, 9 Sep 2002 17:58:48 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA14495; Mon, 9 Sep 2002 16:58:47 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H26YDU-00008G-00; Mon, 09 Sep 2002 17:58:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15741.6545.126854.12671@gargle.gargle.HOWL> Date: Mon, 9 Sep 2002 16:58:41 -0500 From: Pete McCann To: Bernard Aboba Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: References: <15740.48303.763955.797346@gargle.gargle.HOWL> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: > Originally, a new application-ID required a new command, and therefore > there was no reason to expect that a "disk writing" accounting server > could handle anything other than the standard Accounting application-ID. > In some ways this original formulation is very clean -- the accounting > server just advertises the standard accounting application, and there is > no reason to get another application-ID unless you're defining a new > command. In this case, deleting the paragraph has no ill effects, and I'd > agree with you. Accounting is also "lumped in" with the various authorization applications now, so there are no Application IDs that apply only to accounting or only to authorization. Also, the vendor-specific application IDs only come in one flavor. > However, now my understanding is that we are allowing allocation of new > application IDs without a new command. This has the troublesome effect of > breaking interoperability as a result of trivial changes (e.g. adding a > vendor-specific AVP). > Although we have put language in the draft discouraging allocation of new > application IDs without good reason, in practice, this has had no effect > -- virtually every accounting usage in Diameter is now requesting an > application ID, whether it is necessary or not. > So it seems to me that we have a choice of either putting some teeth into > the allocation policy (e.g. going with "expert review" before allocation > of an application ID) or putting bits into the application-ID to allow the > accounting server to distinguish the new AVP case from the new command > case. > If we don't do either of these things, the likely outcome is that Diameter > will end up being less extensible than RADIUS. I would like to keep FCFS allocation policy if at all possible. I think the best way to add the bits of which you speak would be to differentiate more strongly between the Accounting and Authorization Application-ID AVPs. In other words, Accounting applications must be "pure" in the sense that they only use ACR/ACA. It may be the case that the same Application ID appears inside both Authorization and Accounting Application-ID AVPs during CER/CEA, but this really means that a server supports two different aspects of a protocol: 1) the authorization state machine and any associated machinery, and 2) the ACR/ACA commands and all of the mandatory AVPs associated with the application. This way, we could define the "Relay" Application ID, when it appears inside an Accounting Application-ID AVP, to mean that the server supports ACR/ACA for any application. Also, we should create 2 AVPs to hold vendor-specific application IDs: one for authorization, the other for accounting. The accounting applications, even when vendor-specific, are not allowed to use any commands other than ACR/ACA. A "disk-writing" accounting server could then interoperate with any accounting application, even if it were negotiating with a proxy that didn't know the semantics of the application, because accounting applications are guaranteed to be "pure" (only use ACR/ACA) throughout the system. Would that work? -Pete From owner-aaa-wg@merit.edu Mon Sep 9 18:08:45 2002 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 SAA18018 for ; Mon, 9 Sep 2002 18:08:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 251D391276; Mon, 9 Sep 2002 18:10:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6C2191278; Mon, 9 Sep 2002 18:10: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 22C3A91276 for ; Mon, 9 Sep 2002 18:10:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EA185DED3; Mon, 9 Sep 2002 18:10:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7BCA95DECF for ; Mon, 9 Sep 2002 18:10:01 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g89LBhR16730; Mon, 9 Sep 2002 14:11:43 -0700 Date: Mon, 9 Sep 2002 14:11:42 -0700 (PDT) From: Bernard Aboba To: Pete McCann Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <15741.6545.126854.12671@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think the best way to add the bits of which you speak would be to > differentiate more strongly between the Accounting and Authorization > Application-ID AVPs. In other words, Accounting applications must be > "pure" in the sense that they only use ACR/ACA. In most cases, that should be sufficient, but I don't know that I would require it in every case. It is conceivable that someone could come up with an accounting application that required a new command, no? > It may be the case > that the same Application ID appears inside both Authorization and > Accounting Application-ID AVPs during CER/CEA, but this really means > that a server supports two different aspects of a protocol: 1) the > authorization state machine and any associated machinery, and 2) the > ACR/ACA commands and all of the mandatory AVPs associated with the > application. This way, we could define the "Relay" Application ID, > when it appears inside an Accounting Application-ID AVP, to mean that > the server supports ACR/ACA for any application. That would work most of the time. But if someone did come up with an accounting application that needed a new command, how would they indicate that it *didn't* use ACR/ACA? > Also, we should > create 2 AVPs to hold vendor-specific application IDs: one for > authorization, the other for accounting. The accounting applications, > even when vendor-specific, are not allowed to use any commands other > than ACR/ACA. A "disk-writing" accounting server could then > interoperate with any accounting application, even if it were > negotiating with a proxy that didn't know the semantics of the > application, because accounting applications are guaranteed to be > "pure" (only use ACR/ACA) throughout the system. > > Would that work? 99% of the time, I think it would. But I'm curious as to how we would handle the other 1%. From owner-aaa-wg@merit.edu Tue Sep 10 04:34:09 2002 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 EAA07501 for ; Tue, 10 Sep 2002 04:34:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED98F91225; Tue, 10 Sep 2002 04:35:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B36D09122F; Tue, 10 Sep 2002 04:35: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 02ACD91225 for ; Tue, 10 Sep 2002 04:35:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D712F5DDFD; Tue, 10 Sep 2002 04:35:32 -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 1E18F5DDFA for ; Tue, 10 Sep 2002 04:35:32 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8A8Ze705296 for ; Tue, 10 Sep 2002 11:35:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Sep 2002 11:35:30 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Sep 2002 11:35:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Date: Tue, 10 Sep 2002 11:35:30 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E42E2@esebe016.ntc.nokia.com> Thread-Topic: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Thread-Index: AcJYTKkS441zn3v0SEWGdkwhlXB6yAAVuLvw From: To: , Cc: , X-OriginalArrivalTime: 10 Sep 2002 08:35:30.0733 (UTC) FILETIME=[05A4CDD0:01C258A5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA07501 Hi, the Pete's proposal seems to limit the accounting application to use ACR/ACA only. A new accoutnig application can only define AVPs. I would underline that the base accounting does not satify all the possible accounting requirements that may pop-up in the future, actually it does even not satify some of the existing requirements e.g prepaid requirements. Certain prepaid application used in multiservice environment may need to define also new command and mechanisms. Well, the Pete's proposal seems to place a huge limitation to the use of Diameter as accounting protocol. With such limitation I wonder whether Diameter would be used for accounting at all... Br Marco > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 10. September 2002 0:59 > To: Bernard Aboba > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base > update) > > > > Bernard Aboba writes: > > Originally, a new application-ID required a new command, > and therefore > > there was no reason to expect that a "disk writing" > accounting server > > could handle anything other than the standard Accounting > application-ID. > > In some ways this original formulation is very clean -- > the accounting > > server just advertises the standard accounting > application, and there is > > no reason to get another application-ID unless you're > defining a new > > command. In this case, deleting the paragraph has no ill > effects, and I'd > > agree with you. > > Accounting is also "lumped in" with the various authorization > applications now, so there are no Application IDs that apply only to > accounting or only to authorization. Also, the vendor-specific > application IDs only come in one flavor. > > > However, now my understanding is that we are allowing > allocation of new > > application IDs without a new command. This has the > troublesome effect of > > breaking interoperability as a result of trivial changes > (e.g. adding a > > vendor-specific AVP). > > > Although we have put language in the draft discouraging > allocation of new > > application IDs without good reason, in practice, this has > had no effect > > -- virtually every accounting usage in Diameter is now > requesting an > > application ID, whether it is necessary or not. > > > So it seems to me that we have a choice of either putting > some teeth into > > the allocation policy (e.g. going with "expert review" > before allocation > > of an application ID) or putting bits into the > application-ID to allow the > > accounting server to distinguish the new AVP case from the > new command > > case. > > > If we don't do either of these things, the likely outcome > is that Diameter > > will end up being less extensible than RADIUS. > > I would like to keep FCFS allocation policy if at all possible. > > I think the best way to add the bits of which you speak would be to > differentiate more strongly between the Accounting and Authorization > Application-ID AVPs. In other words, Accounting applications must be > "pure" in the sense that they only use ACR/ACA. It may be the case > that the same Application ID appears inside both Authorization and > Accounting Application-ID AVPs during CER/CEA, but this really means > that a server supports two different aspects of a protocol: 1) the > authorization state machine and any associated machinery, and 2) the > ACR/ACA commands and all of the mandatory AVPs associated with the > application. This way, we could define the "Relay" Application ID, > when it appears inside an Accounting Application-ID AVP, to mean that > the server supports ACR/ACA for any application. Also, we should > create 2 AVPs to hold vendor-specific application IDs: one for > authorization, the other for accounting. The accounting applications, > even when vendor-specific, are not allowed to use any commands other > than ACR/ACA. A "disk-writing" accounting server could then > interoperate with any accounting application, even if it were > negotiating with a proxy that didn't know the semantics of the > application, because accounting applications are guaranteed to be > "pure" (only use ACR/ACA) throughout the system. > > Would that work? > > -Pete > > From owner-aaa-wg@merit.edu Tue Sep 10 05:34:11 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08207 for ; Tue, 10 Sep 2002 05:34:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C867D91287; Tue, 10 Sep 2002 05:35:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FCB591285; Tue, 10 Sep 2002 05:35:12 -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 D65A09122F for ; Tue, 10 Sep 2002 05:35:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6A695DDFD; Tue, 10 Sep 2002 05:35:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from emily.fle.fujitsu.com (unknown [193.122.18.249]) by segue.merit.edu (Postfix) with SMTP id B939F5DDFA; Tue, 10 Sep 2002 05:35:08 -0400 (EDT) Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 10:36:09 +0100 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Sep 2002 10:32:48 +0100 Message-ID: From: Xin Chen To: "'ietf-ppp@merit.edu'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Question on EAP Date: Tue, 10 Sep 2002 10:32:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410" 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. ------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C258AD.01FD9E20" ------_=_NextPart_001_01C258AD.01FD9E20 Content-Type: text/plain Dear all, Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below, An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided. And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal). The question is does the current WLAN technologies and EAP protocol support this operation. Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 ------_=_NextPart_001_01C258AD.01FD9E20 Content-Type: text/html Message
Dear all,
 
Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below,
 
An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided.
 
And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals
 
When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal).
 
The question is does the current WLAN technologies and EAP protocol support this operation.
 
Regards
 
Xin Chen
Mobile Network Architecture
Fujitsu Laboratories of Europe LTD
Tel: +44 (0) 2086064453
Mobile: +44 (0)7775741020
 
------_=_NextPart_001_01C258AD.01FD9E20-- ------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and FLE. ------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410-- From owner-aaa-wg@merit.edu Tue Sep 10 09:21:36 2002 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 JAA12801 for ; Tue, 10 Sep 2002 09:21:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BC1F91291; Tue, 10 Sep 2002 09:22:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F3EE91292; Tue, 10 Sep 2002 09:22:55 -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 27C3791291 for ; Tue, 10 Sep 2002 09:22:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 186265DDF3; Tue, 10 Sep 2002 09:22:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 933495DDF2 for ; Tue, 10 Sep 2002 09:22:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8ACOZj02336 for ; Tue, 10 Sep 2002 05:24:35 -0700 Date: Tue, 10 Sep 2002 05:24:35 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 356: Security issues with TLS up-negotiation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 356: Security issues with TLS up-negotiation Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 5.6 Rationale/Explanation of issue: "For TLS usage, a TLS handshake will begin when both ends are in the open state. If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state." Unfortunately, this model of TLS up-negotiation depends on the Diameter connection being brought up without any security, followed by an exchange of CER/CEA (including the security model) in the clear. The Inband-Security-ID AVP includes a value of NO_INBAND_SECURITY, and nothing in the specification requires that a value of TLS MUST be exchanged by the peers if the connection is not protected by IPsec. So it would appear legal for the Diameter connection to reach the open state after negotiation of NO_INBAND_SECURITY. To fix this, add the following text to section 13, first paragraph: "Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH] and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. Diameter implementations MUST use transmission-level security of some kind (IPsec or TLS) on each connection. If a Diameter connection is not protected by IPsec, then the CER/CEA exchange MUST include an Inband-Security-ID AVP with a vaue of TLS. For TLS usage, a TLS handshake will begin when both ends are in the open state, after completion of the CER/CEA exchange. If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state. It is suggested that IPsec be used primarily at the edges for intra-domain exchanges. For NAS devices without certificate support, pre-shared keys can be used between the NAS and a local AAA proxy. For protection of inter-domain exchanges, TLS is recommended. See sections 13.1 and 13.2 for more details on IPsec and TLS usage." From owner-aaa-wg@merit.edu Tue Sep 10 09:39:26 2002 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 JAA13452 for ; Tue, 10 Sep 2002 09:39:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35838912CD; Tue, 10 Sep 2002 09:39:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03898912CE; Tue, 10 Sep 2002 09:39: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 2B88B912CD for ; Tue, 10 Sep 2002 09:38:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1AB805DDF2; Tue, 10 Sep 2002 09:38:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 885ED5DDC5 for ; Tue, 10 Sep 2002 09:38:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8ACeef03205 for ; Tue, 10 Sep 2002 05:40:40 -0700 Date: Tue, 10 Sep 2002 05:40:39 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 357: Inappropriate UTF-8 encoding Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 4.3 Rationale/Explanation of issue: The DiameterIdentity type is defined to use the UTF-8 charset and is indicated to carry a Fully Qualified Domain Name (FQDN). Unfortunately, FQDNs are to be encoded as specified by the Internationalized Domain Name (IDN) specification, not UTF-8. For example, see: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-11.txt To fix this, the DiameterIdentity type should be defined to use the ASCII character set, not UTF-8, and references to UTF-8 in FQDNs should instead refer to the DiameterIdentity type. AVPs that use UTF8String instead of DiameterIdentity include: Origin-Realm AVP (6.4) Destination-Realm AVP (6.6) Note that there are other questionable uses of UTF-8 within the specification. For example, why does IPFilterRule or QoSFilterRule use UTF-8 instead of ASCII? From owner-aaa-wg@merit.edu Tue Sep 10 10:22:16 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15296 for ; Tue, 10 Sep 2002 10:22:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97F86912F2; Tue, 10 Sep 2002 10:20:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 343F5912EC; Tue, 10 Sep 2002 10:20: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 2CD88912F2 for ; Tue, 10 Sep 2002 10:20:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B9815DE0F; Tue, 10 Sep 2002 10:20:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (unknown [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 6DB065DE0E for ; Tue, 10 Sep 2002 10:20:46 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8AEKUg28247; Tue, 10 Sep 2002 10:20:30 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA03894; Tue, 10 Sep 2002 09:20:29 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H287U1-0001QC-00; Tue, 10 Sep 2002 10:20:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15741.65447.588674.42803@gargle.gargle.HOWL> Date: Tue, 10 Sep 2002 09:20:23 -0500 From: Pete McCann To: Bernard Aboba Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: References: <15741.6545.126854.12671@gargle.gargle.HOWL> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: > It is conceivable that someone could come up > with an accounting application that required a new command, no? Maybe we should say that's not an accounting application. Or rather, if it still used ACR/ACA, that part would be accounting, but the new command would be an authorization application. > > Would that work? > > 99% of the time, I think it would. But I'm curious as to how we would > handle the other 1%. We currently don't have any formal definition of what an accounting application is, so let's just define the problem away by saying that *only* ACR/ACA can be a part of an accounting application, and anything else is part of the corresponding authorization application. If an application doesn't use ACR/ACA, then it's not an accounting application. If it uses ACR/ACA + some other commands, then only the ACR/ACA part is the accounting, but the other commands are authorization. You could always advertise support for each one separately in CER/CEA, or advertise as an accounting relay to say you support all applications' ACR/ACA commands but nothing else. -Pete From owner-aaa-wg@merit.edu Tue Sep 10 10:57:02 2002 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 KAA16546 for ; Tue, 10 Sep 2002 10:57:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83D99912FC; Tue, 10 Sep 2002 10:58:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CDD5912FE; Tue, 10 Sep 2002 10:58: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 22B02912FC for ; Tue, 10 Sep 2002 10:58:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E454E5DE0E; Tue, 10 Sep 2002 10:58:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (unknown [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id 883305DDC5 for ; Tue, 10 Sep 2002 10:58:26 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8AEwFC06493; Tue, 10 Sep 2002 10:58:15 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA25904; Tue, 10 Sep 2002 09:58:15 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H289KZ-0000R0-00; Tue, 10 Sep 2002 10:58:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15742.2177.717488.502835@gargle.gargle.HOWL> Date: Tue, 10 Sep 2002 09:58:09 -0500 From: Pete McCann To: marco.stura@nokia.com Cc: , , Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E42E2@esebe016.ntc.nokia.com> References: <142DC466081D9B409AAD1DDCA4B21E1D9E42E2@esebe016.ntc.nokia.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Marco, We could always just delete that paragraph about "disk-writing" accounting servers, but I was trying to find a way to keep the ability to do that. It seems that to do that, we need some way to indicate support for ACR/ACA (and nothing else) for any application. I certainly don't want to limit the scope of future accounting protocols; I am just playing with definitions of some terms. So if a new protocol used ACR/ACA plus some other commands for doing prepaid, then those new commands would be considered part of the authorization application. We certainly wouldn't expect a "disk-writing" accounting server to handle those additional commands and state machines. However, our "disk-writing" accounting server could advertise support for the ACR/ACAs which could be routed to it and stored on disk, in some particular deployment. Of course, if those ACRs/ACAs were intended to trigger certain actions of the bigger application, you would need the interfaces to do that. There's probably no way for a simple disk-writing accounting server to help with that, so my proposal might break such applications. If it is important to support these, then I tend to think we should just delete the paragraph and move on. What I think Benard proposed originally was to add some "typefulness" to the Application IDs so that you could look at any given application ID and see if it was: 1) "Vanilla" accounting, only used ACR/ACA 2) "Enhanced" accounting, with some additional commands or interactions that would make disk-writing accounting servers inappropriate I guess we could steal the least-order bit from the application ID for this purpose - you could say that even-numbered accounting IDs are "vanilla" and odd-numbered accounting IDs are "enhanced". However, this seems to require a smidge of expert review at assignment time, rather than FCFS. We could modify the text about advertising "Relay" accounting services to say it means you support any "vanilla" accounting application. We would need to understand how to advertise support for true Relay accounting servers, perhaps using the least-order bit of the "Relay" identifier. What do people want to do? -Pete marco.stura@nokia.com writes: > Hi, > > the Pete's proposal seems to limit the accounting application to use > ACR/ACA only. A new accoutnig application can only define AVPs. > > I would underline that the base accounting does not satify all the > possible accounting requirements that may pop-up in the future, actually > it does even not satify some of the existing requirements e.g prepaid > requirements. > Certain prepaid application used in multiservice environment may need > to define also new command and mechanisms. > > Well, the Pete's proposal seems to place a huge limitation to the use > of Diameter as accounting protocol. With such limitation I wonder > whether Diameter would be used for accounting at all... > > Br > Marco From owner-aaa-wg@merit.edu Tue Sep 10 11:28:52 2002 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 LAA17516 for ; Tue, 10 Sep 2002 11:28:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB45591317; Tue, 10 Sep 2002 11:29:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4566791321; Tue, 10 Sep 2002 11:29: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 1105C91317 for ; Tue, 10 Sep 2002 11:29:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7C6D5DDF2; Tue, 10 Sep 2002 11:29:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 5CBDE5DDC5 for ; Tue, 10 Sep 2002 11:29:52 -0400 (EDT) Received: (cpmta 6866 invoked from network); 10 Sep 2002 08:29:49 -0700 Received: from 12.24.40.25 (HELO djmlap.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 10 Sep 2002 08:29:49 -0700 X-Sent: 10 Sep 2002 15:29:49 GMT Message-Id: <5.1.0.14.2.20020910112008.03ae27f0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Sep 2002 11:25:06 -0400 To: "Hepworth, Eleanor" From: David Mitton Subject: Re: [AAA-WG]: NASREQ Query Cc: aaa-wg@merit.edu In-Reply-To: <76C92FBBFB58D411AE760090271ED41804FDE3DE@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk That pair of statements has confounded several of us. I would like to, at least, remove it. I'd even further like to replace it with something clearer, but I cannot understand the requirement. We have Authorization then Authentication sequences with Call directing NASes. We have Authentication/Authorization sequences otherwise. The protocol only has one type of message anyways, so it's all context dependent... Can anyone defend the original requirement for this statement?? Dave. At 9/8/2002 03:53 PM +0100, you wrote: >Hi, > >I have a quick query regarding the Diameter NASREQ I-D. The draft >contains the following statement in the AA-Request description (section >3.1.1 of version 09): > > It is possible for a single session to be authorized first, then > followed by an authentication request. However, the inverse SHOULD > NOT be permitted. > >I'm a little confused about this as usually I would expect authentication >to be followed by an optional authorization step. Should this text be the >other way round (or have I misunderstood something)? > >Thanks > >Ele From owner-aaa-wg@merit.edu Tue Sep 10 12:25:21 2002 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 MAA19109 for ; Tue, 10 Sep 2002 12:25:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A155F9132C; Tue, 10 Sep 2002 12:26:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 645559132D; Tue, 10 Sep 2002 12:26:41 -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 5AD4F9132C for ; Tue, 10 Sep 2002 12:26:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B1DF5DE0E; Tue, 10 Sep 2002 12:26:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 083305DDC2 for ; Tue, 10 Sep 2002 12:26:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: NASREQ Query Date: Tue, 10 Sep 2002 09:26:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <40301581B2962B448690A023EF16DFE103A70F@bsn-mail-01.bstormnetworks.com> Thread-Topic: [AAA-WG]: NASREQ Query Thread-Index: AcJY3vWAzGgR6P7KQQ+nyHJLiaeA+wAB9EKw From: "Pat R. Calhoun" To: "David Mitton" , "Hepworth, Eleanor" Cc: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19109 The sentence is inversed. The text should state that authorization occurs after authentication. PatC -----Original Message----- From: David Mitton [mailto:david@mitton.com] Sent: Tuesday, September 10, 2002 8:25 AM To: Hepworth, Eleanor Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ Query That pair of statements has confounded several of us. I would like to, at least, remove it. I'd even further like to replace it with something clearer, but I cannot understand the requirement. We have Authorization then Authentication sequences with Call directing NASes. We have Authentication/Authorization sequences otherwise. The protocol only has one type of message anyways, so it's all context dependent... Can anyone defend the original requirement for this statement?? Dave. At 9/8/2002 03:53 PM +0100, you wrote: >Hi, > >I have a quick query regarding the Diameter NASREQ I-D. The draft >contains the following statement in the AA-Request description (section >3.1.1 of version 09): > > It is possible for a single session to be authorized first, then > followed by an authentication request. However, the inverse SHOULD > NOT be permitted. > >I'm a little confused about this as usually I would expect >authentication >to be followed by an optional authorization step. Should this text be the >other way round (or have I misunderstood something)? > >Thanks > >Ele From owner-aaa-wg@merit.edu Tue Sep 10 16:36:39 2002 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 QAA26131 for ; Tue, 10 Sep 2002 16:36:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8B87912A4; Tue, 10 Sep 2002 16:37:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A633912A5; Tue, 10 Sep 2002 16:37:59 -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 90AD6912A4 for ; Tue, 10 Sep 2002 16:37:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D0BA5DE25; Tue, 10 Sep 2002 16:37:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 02EF55DE0E for ; Tue, 10 Sep 2002 16:37:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8AJdda26041 for ; Tue, 10 Sep 2002 12:39:39 -0700 Date: Tue, 10 Sep 2002 12:39:38 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Tue, 10 Sep 2002 10:44:32 -0400 From: Eric Brunner-Williams in Portland Maine To: Bernard Aboba Cc: brunner@nic-naa.net Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding Bernard, As an alternative, I suggest the DiameterIdentity type can be left simply as an OctetString AVP, and reference to any charset dropped. If you want to add details to how the DiameterIdentity value is to be used, e.g., case-insensitive character comparison for octets in the range 0-127, that would be consistent with 10[34/35]. The same issue came up recently in dnsext (unknown RDATA formats). The same issue has been present in provreg (character encodings other than UTF-8 (and UTF-16) are allowed by XML, if an encoding attribute, or a byte order mark, or both is present, EPP is specified in XML Schema notation, and is silent on the use of character encodings other than UTF-8 except "in environments where parser encoding support incompatibility might have an impact on interoperability", in which case UTF-8 is RECOMMENDED). Eric From owner-aaa-wg@merit.edu Tue Sep 10 17:11:40 2002 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 RAA26657 for ; Tue, 10 Sep 2002 17:11:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F5D8912AC; Tue, 10 Sep 2002 17:13:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28EA5912AD; Tue, 10 Sep 2002 17:13: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 3F73F912AC for ; Tue, 10 Sep 2002 17:13:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D7B65DE18; Tue, 10 Sep 2002 17:13:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9D4745DE25 for ; Tue, 10 Sep 2002 17:13:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8AKEin27947 for ; Tue, 10 Sep 2002 13:14:44 -0700 Date: Tue, 10 Sep 2002 13:14:44 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 358: Issues with references Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 358: Issues with references Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: E Priority: 1 Section: 14.2 and others Rationale/Explanation of issue: Add the following non-normative references to section 14.2: [AAAREQ] Aboba, B. et al., "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000. [DYNAUTH] Chiba, M., et al., "Dynamic Authorization Extensions to RADIUS", IETF work in progress. [RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RADEXT] Rigney, C., Willats W., Calhoun P., "RADIUS Extensions", RFC 2869, June 2000. [TACACS] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993. In Sections 11.12, 11.13, 11.14 (page 129) change the reference from [TCP] to [IANA]. In section 14.2, change reference to [IPCOMP] from non-normative to normative. This is referred to with a MAY in Section 9.2 (page 114). From owner-aaa-wg@merit.edu Tue Sep 10 17:21:50 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26860 for ; Tue, 10 Sep 2002 17:21:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8CE8912B1; Tue, 10 Sep 2002 17:22:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38F08912B5; Tue, 10 Sep 2002 17:22: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 D3E6C912B1 for ; Tue, 10 Sep 2002 17:22:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9E705DE26; Tue, 10 Sep 2002 17:22:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3F7D75DE18 for ; Tue, 10 Sep 2002 17:22:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8AKNg428479 for ; Tue, 10 Sep 2002 13:23:42 -0700 Date: Tue, 10 Sep 2002 13:23:42 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 358: Terminology and Organizational issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 358: Terminology and Organizational issues Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: E Priority: S Section: 1.4, 8.2 Rationale/Explanation of issue: Several terms are not defined in the terminology section, including: Transaction state Session state Quite a few terms are used prior to their definition in Section 1.4, so that I would recommend that the terminology section (currently 1.4) be moved up earlier in the document. I'd also note that I found it very confusing that section 8.2 (Accounting State machine) occurs prior to Section 9 (Accounting). I'd recommend that 8.2 be moved to Section 9.9 (after definition of the AVPs, including Accounting-Realtime-Required AVP). From owner-aaa-wg@merit.edu Tue Sep 10 17:32:52 2002 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 RAA27157 for ; Tue, 10 Sep 2002 17:32:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EA5D912B2; Tue, 10 Sep 2002 17:34:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC5E2912AF; Tue, 10 Sep 2002 17:34: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 2370491356 for ; Tue, 10 Sep 2002 17:34:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F15A15DE26; Tue, 10 Sep 2002 17:34:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7B9095DDF3 for ; Tue, 10 Sep 2002 17:34:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8AKZr129198 for ; Tue, 10 Sep 2002 13:35:53 -0700 Date: Tue, 10 Sep 2002 13:35:53 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 359: Terminology and Organizational issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 359: Terminology and Organizational issues Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: E Priority: S Section: 1.4, 8.2 Rationale/Explanation of issue: Several terms are not defined in the terminology section, including: Transaction state Session state Quite a few terms are used prior to their definition in Section 1.4, so that I would recommend that the terminology section (currently 1.4) be moved up earlier in the document. I'd also note that I found it very confusing that section 8.2 (Accounting State machine) occurs prior to Section 9 (Accounting). I'd recommend that 8.2 be moved to Section 9.9 (after definition of the AVPs, including Accounting-Realtime-Required AVP). From owner-aaa-wg@merit.edu Tue Sep 10 21:59:59 2002 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 VAA02151 for ; Tue, 10 Sep 2002 21:59:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BFFC91364; Tue, 10 Sep 2002 22:01:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1462591366; Tue, 10 Sep 2002 22:01:15 -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 E5EEF91364 for ; Tue, 10 Sep 2002 22:01:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C42945DE96; Tue, 10 Sep 2002 22:01:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 204875DD90 for ; Tue, 10 Sep 2002 22:01:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B12ks11881 for ; Tue, 10 Sep 2002 18:02:46 -0700 Date: Tue, 10 Sep 2002 18:02:46 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 360: Accounting standalone Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 360: Accounting standalone Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 1, 2, 7.1.3 Rationale/Explanation of issue: The specification is contradictory on whether the Accounting functionality of the Diameter base protocol can be used without a corresponding application (MIP, NASREQ, etc.) For example, the SIP accounting extension does not include an authentication application definition, yet makes use of the Base protocol: (see http://www.ietf.org/internet-drafts/draft-narayanan-sipping-aaa-diameter-00.txt Thus, the above specification seems to provide an example of how the Diameter Accounting can be used by itself, and I would argue that this is to be encouraged instead of create Yet Another Accounting Protocol (YAAP). The proposed fix is to adjust the text in the following places to make this clear: Page 14: Change definition of Diameter Server to the following: "A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm." Section 2, page 17, first paragraph. Change the first sentence of the first paragraph to: "The base Diameter protocol may be used by itself for accounting applications, but for use in authentication and authorization it is always extended for a particular application." Section 7.1.3, Page 81, DIAMETER_UNABLE_TO_DELIVER Change "no host within the realm was available" to "no host within the realm supporting the required application was available" Page 94, last paragraph Delete the paragraph starting with "Note that the server side state machine..." This paragraph appears to be redundant with the first paragraph of page 93. From owner-aaa-wg@merit.edu Tue Sep 10 22:03:21 2002 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 WAA02207 for ; Tue, 10 Sep 2002 22:03:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3C94912BB; Tue, 10 Sep 2002 22:04:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA0159136A; Tue, 10 Sep 2002 22:01: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 478DC91371 for ; Tue, 10 Sep 2002 22:01:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 371B15DEAD; Tue, 10 Sep 2002 22:01:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 651835DEB5 for ; Tue, 10 Sep 2002 22:01:43 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B13Mh11937 for ; Tue, 10 Sep 2002 18:03:22 -0700 Date: Tue, 10 Sep 2002 18:03:22 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 361: Support for TLS compression Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 361: Support for TLS compression Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: 2 Section: 9.2 Rationale/Explanation of issue: TLS compression is more efficient than IP compression, since TCP is stateful. As a result, it makes sense to use TLS compression where TLS is negotiated and it is desired to reduce the network bandwidth used for Diameter accounting. Replace the last paragraph of Section 9.2 with the following: "Each Diameter Accounting protocol message MAY be compressed, in order to reduce network bandwidth usage. If IPsec and IKE are used to secure the Diameter session, then IP compression [IPComp] MAY be used and IKE [IKE] MAY be used to negotiate the compression parameters. If TLS is used to secure the Diameter session, then TLS compression [TLS] MAY be used." From owner-aaa-wg@merit.edu Tue Sep 10 22:23:46 2002 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 WAA02476 for ; Tue, 10 Sep 2002 22:23:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CDFC912BC; Tue, 10 Sep 2002 22:25:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 225D791367; Tue, 10 Sep 2002 22:25:12 -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 32CB4912BC for ; Tue, 10 Sep 2002 22:25:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 164AA5DEAD; Tue, 10 Sep 2002 22:25:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 734095DD90 for ; Tue, 10 Sep 2002 22:25:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B1Qos13131 for ; Tue, 10 Sep 2002 18:26:50 -0700 Date: Tue, 10 Sep 2002 18:26:50 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 362: Clarification of Proxy, Relay and Redirect Usage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 362: Clarification of Proxy, Relay, and Redirect Usage Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: E Priority: S Section: many Rationale/Explanation of issue: Throughout the document, the term "proxy" is used when actually it is intended refer to proxies, relays and redirects. Also, the term "stateful" is unclear; sometimes this refers to session state, sometimes to transaction state. Section 2.8.1, page 24, last paragraph, change to: "Relays modify Diameter messages by inserting and removing routing information, but do not modify any other portion of a message. Relays SHOULD NOT maintain session state but MUST maintain transaction state." Section 2.8.2, page 25, third paragraph, change to: "Proxies that wish to limit resources MUST maintain session state. All proxies MUST maintain transaction state." Section 2.8.3, page 27, first paragraph, change to: "Since Redirect agents do not perform any application level processing, the provide services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier." Page 28, first second and third paragraphs, change to: "End-to-end security services include confidentiality and message origin authentication. These services are provided by supporting AVP integrity and confidentiality between two peers, communicating through agents. End-to-end security is provided via the End-to-End security extension, described in [AAACMS]. The circumstances requiring the use of end-to-end security are determined by policy on each of the peers. Security policies, which are not the subject of standardization, may be applied by next hop Diameter peer or by destination realm. For example, where TLS or IPsec transmission-level security is sufficient, there may be no need for end-to-end security. End-to-end security policies include:" Page 30, last paragraph. Change "The End-to-End Identifier MUST NOT be modified by relay agents" to: "The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind." Page 49, second to last paragraph: Change "be sent via proxy/agent" to: "be sent via a Diameter agent (proxy, redirect or relay)" Page 68, third paragraph Change "Proxiable request messages MUST also contain an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP. A message that MUST NOT be relayed, proxied or redirect MUST not include..." To: "Request messages that may be forwarded by Diameter agents (proxies, redirects or relays) MUST also contain an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP. A message that MUST NOT be forwarded by Diameter agents (proxies, redirects or relays) MUST not include..." Page 70, Section 6.1.6 Change: "A Diameter message that is able to be proxied MUST include..." to: "A Diameter message that may be forwarded by Diameter agents (proxies, redirects or relays) MUST include..." From owner-aaa-wg@merit.edu Tue Sep 10 22:41:24 2002 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 WAA03016 for ; Tue, 10 Sep 2002 22:41:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18BBA91367; Tue, 10 Sep 2002 22:42:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA01891368; Tue, 10 Sep 2002 22:42: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 E6DD191367 for ; Tue, 10 Sep 2002 22:42:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE45A5DEC3; Tue, 10 Sep 2002 22:42:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4C1425DD90 for ; Tue, 10 Sep 2002 22:42:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B1iRW14111 for ; Tue, 10 Sep 2002 18:44:27 -0700 Date: Tue, 10 Sep 2002 18:44:27 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 366: Vendor-Specific Result AVP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 366: Vendor-specific Result AVP Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 7.6 Rationale/Explanation of issue: It would appear that this AVP was created for use with Vendor-specific Commands which are no longer supported in the protocol. Should this be renamed to "Experimental Result AVP" with the appropriate changes in text? From owner-aaa-wg@merit.edu Tue Sep 10 22:43:27 2002 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 WAA03078 for ; Tue, 10 Sep 2002 22:43:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7680191368; Tue, 10 Sep 2002 22:44:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47A2391369; Tue, 10 Sep 2002 22:44:55 -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 5CAC191368 for ; Tue, 10 Sep 2002 22:44:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A5345DD90; Tue, 10 Sep 2002 22:44:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CEBDA5DEC3 for ; Tue, 10 Sep 2002 22:44:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B1kXF14317 for ; Tue, 10 Sep 2002 18:46:33 -0700 Date: Tue, 10 Sep 2002 18:46:33 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 364: Revised Introduction & Abstract Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 364: Revised Introduction & Abstract Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: E Priority: 1 Section: Abstract, 1 Rationale/Explanation of issue: This issue represents an effort to improve the readability and completeness of the Introductory section. Comments welcome. Complete text is included in: http://www.drizzle.com/~aboba/AAA/issues.html#Issue 364 From owner-aaa-wg@merit.edu Tue Sep 10 22:49:22 2002 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 WAA03177 for ; Tue, 10 Sep 2002 22:49:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9FFA49136A; Tue, 10 Sep 2002 22:50:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EC26912BD; Tue, 10 Sep 2002 22:50: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 1A53091369 for ; Tue, 10 Sep 2002 22:48:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F05A35DEC3; Tue, 10 Sep 2002 22:48:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 66A245DD90 for ; Tue, 10 Sep 2002 22:48:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B1oF414499 for ; Tue, 10 Sep 2002 18:50:15 -0700 Date: Tue, 10 Sep 2002 18:50:14 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 363: IANA Considerations Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 363: IANA Considerations Issues Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 11 Rationale/Explanation of issue: The IANA considerations section lacks some boilerplate. Also, as I recall, the agreement with the IESG was that standard AVP codes would be allocated via "Expert Review with Specification Required", and I would also recommend this for non-vendor specific application IDs. Change Section 11 to the following: "This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Diameter protocol, in accordance with BCP 26 [IANA]. The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", IETF Consensus", "Standards Action". This section explains the criteria to be used by the IANA for assignment of numbers within namespaces defined within this document. Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For registration requests requiring Expert Review, the AAA mailing list should be consulted." Section 11.1.1 AVP Code Change the last sentence of the first paragraph to: "AVP Codes 0-254 are managed separtely as RADIUS Attribute Types [RADTYPE], while the remaining namespace is available for assignmetn via Expert Review with Specification Required [IANA]." Section 11.2.1, second to last paragraph, last sentence. Change to: "The range of values will have a limited lifetime, and will eventually be reallocated within a range available for standardization." Change "guarentee" to "guarantee" Section 11.3 Application Identifiers Second paragraph, add the following sentence: "Assignment of standards-track application IDs are by Expert Review with Specification Required [IANA]." From owner-aaa-wg@merit.edu Wed Sep 11 02:05:26 2002 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 CAA12818 for ; Wed, 11 Sep 2002 02:05:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9BA55912C0; Wed, 11 Sep 2002 02:06:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 693FA912C1; Wed, 11 Sep 2002 02:06:46 -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 1ACED912C0 for ; Wed, 11 Sep 2002 02:06:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01D8E5DE25; Wed, 11 Sep 2002 02:06:45 -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 14F665DDF3 for ; Wed, 11 Sep 2002 02:06:44 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B66q723282 for ; Wed, 11 Sep 2002 09:06:52 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:06:42 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:06:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:06:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 358: Issues with references Date: Wed, 11 Sep 2002 09:06:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54BE@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 358: Issues with references Thread-Index: AcJZDufszllJTaHMThuRx3AGjvxniwASnNzw From: To: , X-OriginalArrivalTime: 11 Sep 2002 06:06:42.0269 (UTC) FILETIME=[664710D0:01C25959] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12818 Hi Bernard, Can do. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 10 September, 2002 23:15 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 358: Issues with references > > > Issue 358: Issues with references > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: E > Priority: 1 > Section: 14.2 and others > Rationale/Explanation of issue: > > Add the following non-normative references to section 14.2: > > [AAAREQ] Aboba, B. et al., "Criteria for Evaluating AAA Protocols > for Network Access", RFC 2989, November 2000. > > [DYNAUTH] Chiba, M., et al., "Dynamic Authorization Extensions to > RADIUS", IETF work in progress. > > [RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. > > [RADEXT] Rigney, C., Willats W., Calhoun P., "RADIUS > Extensions", RFC > 2869, June 2000. > > [TACACS] Finseth, C., "An Access Control Protocol, > Sometimes Called > TACACS", RFC 1492, July 1993. > > In Sections 11.12, 11.13, 11.14 (page 129) change the > reference from [TCP] > to [IANA]. > > In section 14.2, change reference to [IPCOMP] from non-normative to > normative. This is referred to with a MAY in Section 9.2 (page 114). > > From owner-aaa-wg@merit.edu Wed Sep 11 02:12:18 2002 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 CAA14904 for ; Wed, 11 Sep 2002 02:12:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6E91912C1; Wed, 11 Sep 2002 02:13:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8862C91369; Wed, 11 Sep 2002 02:13:43 -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 7C96F912C1 for ; Wed, 11 Sep 2002 02:13:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 673D15DE25; Wed, 11 Sep 2002 02:13:42 -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 7E6225DDF3 for ; Wed, 11 Sep 2002 02:13:41 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B6Do726845 for ; Wed, 11 Sep 2002 09:13:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:13:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:13:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 361: Support for TLS compression Date: Wed, 11 Sep 2002 09:13:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54BF@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 361: Support for TLS compression Thread-Index: AcJZO1ZIx9x2CYWlQ9qKwqZfJqsEkgAHv7vA From: To: , X-OriginalArrivalTime: 11 Sep 2002 06:13:39.0591 (UTC) FILETIME=[5F055970:01C2595A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA14904 Hi Bernard, Good point. This should be added. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11 September, 2002 04:03 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 361: Support for TLS compression > > > Issue 361: Support for TLS compression > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: T > Priority: 2 > Section: 9.2 > Rationale/Explanation of issue: > > TLS compression is more efficient than IP compression, since TCP > is stateful. As a result, it makes sense to use TLS compression > where TLS is negotiated and it is desired to reduce the network > bandwidth used for Diameter accounting. > > Replace the last paragraph of Section 9.2 with the following: > > "Each Diameter Accounting protocol message MAY be compressed, in order > to reduce network bandwidth usage. If IPsec and IKE are used to > secure the Diameter session, then IP compression [IPComp] MAY > be used and > IKE [IKE] MAY be used to negotiate the compression parameters. If TLS > is used to secure the Diameter session, then TLS compression [TLS] MAY > be used." > > From owner-aaa-wg@merit.edu Wed Sep 11 02:26:06 2002 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 CAA27662 for ; Wed, 11 Sep 2002 02:26:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C8889121C; Wed, 11 Sep 2002 02:27:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 449BB91369; Wed, 11 Sep 2002 02:27:30 -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 5EDE49121C for ; Wed, 11 Sep 2002 02:27:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BE145DEC5; Wed, 11 Sep 2002 02:27:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D1FB55DE25 for ; Wed, 11 Sep 2002 02:27:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B5T7q26472 for ; Tue, 10 Sep 2002 22:29:07 -0700 Date: Tue, 10 Sep 2002 22:29:07 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: AAA WG last call on draft-ietf-aaa-diameter-mobileip-12.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk There is an ongoing AAA WG last call on the document "Diameter Mobile IPv4 Application", which is a standards track document, to be found at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-12.txt Please email your issues to the authors, with a cc: to the AAA WG mailing list, prior to the conclusion of AAA WG last call on September 15, 2002. The format required for issue submissions (and a list of the currently open and previously resolved issues) can be found at: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Wed Sep 11 02:27:10 2002 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 CAA28751 for ; Wed, 11 Sep 2002 02:27:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B19E91369; Wed, 11 Sep 2002 02:28:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D64879136C; Wed, 11 Sep 2002 02:28:30 -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 D0DB991369 for ; Wed, 11 Sep 2002 02:28:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C22235DEC5; Wed, 11 Sep 2002 02:28:29 -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 132855DE25 for ; Wed, 11 Sep 2002 02:28:29 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B6SSk16998 for ; Wed, 11 Sep 2002 09:28:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:28:27 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:28:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:28:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 364: Revised Introduction & Abstract Date: Wed, 11 Sep 2002 09:28:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C0@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 364: Revised Introduction & Abstract Thread-Index: AcJZP1zA4plhu1V8QYuufRGR8KGiLQAHOqaw From: To: , X-OriginalArrivalTime: 11 Sep 2002 06:28:27.0577 (UTC) FILETIME=[704D4290:01C2595C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA28751 Hi Bernard, > This issue represents an effort to improve the readability and > completeness of the Introductory section. Comments welcome. > Complete text is included in: > > http://www.drizzle.com/~aboba/AAA/issues.html#Issue 364 I agree with the text you have proposed, I think it should be included in version 14. One small nit, you did not include section 1.1.1 in your text - should this section stay as is, or should it be deleted? John From owner-aaa-wg@merit.edu Wed Sep 11 02:33:01 2002 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 CAA29539 for ; Wed, 11 Sep 2002 02:33:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D82F49136C; Wed, 11 Sep 2002 02:34:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A149D9136D; Wed, 11 Sep 2002 02: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 DEEAE9136C for ; Wed, 11 Sep 2002 02:32:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C03A95DEC5; Wed, 11 Sep 2002 02:32:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4DE145DE25 for ; Wed, 11 Sep 2002 02:32:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8B5Xvb26830; Tue, 10 Sep 2002 22:33:57 -0700 Date: Tue, 10 Sep 2002 22:33:57 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 364: Revised Introduction & Abstract In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C0@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree with the text you have proposed, I think it should be included > in version 14. One small nit, you did not include section 1.1.1 in > your text - should this section stay as is, or should it be deleted? The material that was in section 1.1.1 is now the major topic of section 1 (how Diameter is different/better than RADIUS), so it seemed redundant. My recommendation is to delete it. From owner-aaa-wg@merit.edu Wed Sep 11 02:33:28 2002 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 CAA29560 for ; Wed, 11 Sep 2002 02:33:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 956AB9136D; Wed, 11 Sep 2002 02:34:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 628C39136E; Wed, 11 Sep 2002 02:34:55 -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 8E63E9136D for ; Wed, 11 Sep 2002 02:34:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CEF95DECF; Wed, 11 Sep 2002 02:34:53 -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 9185F5DE25 for ; Wed, 11 Sep 2002 02:34:52 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B6Ypk22413 for ; Wed, 11 Sep 2002 09:34:51 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:34:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:34:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Date: Wed, 11 Sep 2002 09:34:47 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F13@esebe004.ntc.nokia.com> Thread-Topic: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Thread-Index: AcJY1UUDS39bcbPTR+KOEhsLqUv72gAh0gaA From: To: , Cc: X-OriginalArrivalTime: 11 Sep 2002 06:34:50.0870 (UTC) FILETIME=[54C32160:01C2595D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29560 Hi Pete & Bernard, This discussion is opening a can of worms, in my opinion - and I'm not so sure we're quite ready to fish (just to mix some metaphors!) The can of worms is this: what is a Diameter application (not just accounting). This is a rather simple question, but there are a lot of issues behind it. I'd like to avoid, at present, issues about 'typing' of Diameter applications, as I think we don't yet have enough experience with them. I am sure we could device a rather complex system which would inform peers about the different applications - what type, suggested compatability, etc. - but I am not entirely sure that this complexity would be useful. Perhaps some sort of additional application negotiation mechanism could be added as an extension to the Diameter base, which would help. However, I think this could / should be done after we get the Base out the door. John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 10 September, 2002 17:20 > To: Bernard Aboba > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base > update) > > > > Bernard Aboba writes: > > It is conceivable that someone could come up > > with an accounting application that required a new command, no? > > Maybe we should say that's not an accounting application. Or rather, > if it still used ACR/ACA, that part would be accounting, but the new > command would be an authorization application. > > > > Would that work? > > > > 99% of the time, I think it would. But I'm curious as to > how we would > > handle the other 1%. > > We currently don't have any formal definition of what an accounting > application is, so let's just define the problem away by saying that > *only* ACR/ACA can be a part of an accounting application, and > anything else is part of the corresponding authorization application. > If an application doesn't use ACR/ACA, then it's not an accounting > application. If it uses ACR/ACA + some other commands, then only the > ACR/ACA part is the accounting, but the other commands are > authorization. You could always advertise support for each one > separately in CER/CEA, or advertise as an accounting relay to say you > support all applications' ACR/ACA commands but nothing else. > > -Pete > > From owner-aaa-wg@merit.edu Wed Sep 11 02:34:26 2002 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 CAA29582 for ; Wed, 11 Sep 2002 02:34:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D49489136E; Wed, 11 Sep 2002 02:35:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B9F79136F; Wed, 11 Sep 2002 02:35: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 79E849136E for ; Wed, 11 Sep 2002 02:35:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A0705DECF; Wed, 11 Sep 2002 02:35:53 -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 6386B5DE25 for ; Wed, 11 Sep 2002 02:35:52 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B6ZuU08731 for ; Wed, 11 Sep 2002 09:35:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:34:59 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:34:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:34:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 364: Revised Introduction & Abstract Date: Wed, 11 Sep 2002 09:34:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C2@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 364: Revised Introduction & Abstract Thread-Index: AcJZXP5B8OFgpN+TTW+gZAjdi2kjGgAAAVMA From: To: Cc: X-OriginalArrivalTime: 11 Sep 2002 06:34:59.0010 (UTC) FILETIME=[599D3220:01C2595D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29582 Hi Bernard, > > I agree with the text you have proposed, I think it should > be included > > in version 14. One small nit, you did not include section 1.1.1 in > > your text - should this section stay as is, or should it be deleted? > > The material that was in section 1.1.1 is now the major topic of section 1 > (how Diameter is different/better than RADIUS), so it seemed redundant. > My recommendation is to delete it. That's OK with me, I'll just renumber then. John From owner-aaa-wg@merit.edu Wed Sep 11 02:37:07 2002 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 CAA29638 for ; Wed, 11 Sep 2002 02:37:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A73739136F; Wed, 11 Sep 2002 02:38:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DF9091370; Wed, 11 Sep 2002 02:38: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 4C22A9136F for ; Wed, 11 Sep 2002 02:38:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37A6F5DED0; Wed, 11 Sep 2002 02:38:27 -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 7E3255DE25 for ; Wed, 11 Sep 2002 02:38:26 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B6cY710218 for ; Wed, 11 Sep 2002 09:38:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:38:25 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:38:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:38:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 356: Security issues with TLS up-negotiation Date: Wed, 11 Sep 2002 09:38:24 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C3@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 356: Security issues with TLS up-negotiation Thread-Index: AcJYzTaK1+/e5Xu5TT6XCqw0v7O51AAkIXrw From: To: , X-OriginalArrivalTime: 11 Sep 2002 06:38:24.0968 (UTC) FILETIME=[D45FE480:01C2595D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29638 Hi Bernard, > Issue 356: Security issues with TLS up-negotiation > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: T > Priority: S > Section: 5.6 > Rationale/Explanation of issue: > > "For TLS usage, a TLS handshake will begin when both ends > are in the open state. If the TLS handshake is successful, > all further messages will be sent via TLS. If the handshake > fails, both ends move to the closed state." > > Unfortunately, this model of TLS up-negotiation depends on > the Diameter connection being brought up without any security, > followed by an exchange of CER/CEA (including the security > model) in the clear. > > The Inband-Security-ID AVP includes a value of NO_INBAND_SECURITY, > and nothing in the specification requires that a value of TLS > MUST be exchanged by the peers if the connection is not protected > by IPsec. > > So it would appear legal for the Diameter connection to reach the > open state after negotiation of NO_INBAND_SECURITY. Good catch. I'll add this. John > To fix this, add the following text to section 13, first paragraph: > > "Diameter clients, such as Network Access Servers (NASes) and Mobility > Agents MUST support IP Security [SECARCH] and MAY support TLS [TLS]. > Diameter servers MUST support TLS and IPsec. Diameter implementations > MUST use transmission-level security of some kind (IPsec or TLS) on > each connection. > > If a Diameter connection is not protected by IPsec, > then the CER/CEA exchange MUST include an Inband-Security-ID AVP > with a vaue of TLS. For TLS usage, a TLS handshake will begin > when both > ends > are in the open state, after completion of the CER/CEA exchange. > If the TLS handshake is successful, all further messages will > be sent via TLS. If the handshake fails, both ends move to the > closed state. > > It is suggested that IPsec be used primarily at the edges for > intra-domain exchanges. For NAS devices without certificate support, > pre-shared keys can be used between the NAS and a local AAA proxy. > > For protection of inter-domain exchanges, TLS is recommended. See > sections 13.1 and 13.2 for more details on IPsec and TLS usage." > > From owner-aaa-wg@merit.edu Wed Sep 11 02:38:47 2002 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 CAA29660 for ; Wed, 11 Sep 2002 02:38:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F193E91370; Wed, 11 Sep 2002 02:40:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2CD791371; Wed, 11 Sep 2002 02:40: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 A0ED391370 for ; Wed, 11 Sep 2002 02:40:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9197A5DED0; Wed, 11 Sep 2002 02:40:08 -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 A94645DE25 for ; Wed, 11 Sep 2002 02:40:07 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B6e6k25472 for ; Wed, 11 Sep 2002 09:40:06 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 09:40:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 09:40:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 363: IANA Considerations Issues Date: Wed, 11 Sep 2002 09:40:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C4@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 363: IANA Considerations Issues Thread-Index: AcJZPg/IoekqDhC5TraPcD03jOgkngAH96JA From: To: , X-OriginalArrivalTime: 11 Sep 2002 06:40:06.0602 (UTC) FILETIME=[10F402A0:01C2595E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29660 Hi Bernard, I agree with your suggestions here. If anyone has specific issues with the text Bernard proposes, then please suggest what, in your opinion, should be added. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11 September, 2002 04:50 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 363: IANA Considerations Issues > > > Issue 363: IANA Considerations Issues > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: T > Priority: S > Section: 11 > Rationale/Explanation of issue: > > The IANA considerations section lacks some boilerplate. Also, > as I recall, > the agreement with the IESG was that standard AVP codes would > be allocated > via "Expert Review with Specification Required", and I would also > recommend this for non-vendor specific application IDs. > > Change Section 11 to the following: > > "This section provides guidance to the Internet Assigned > Numbers Authority > (IANA) regarding registration of values related to the > Diameter protocol, > in accordance with BCP 26 [IANA]. > > The following policies are used here with the meanings > defined in BCP 26: > "Private Use", "First Come First Served", "Expert Review", > "Specification Required", IETF Consensus", "Standards Action". > > This section explains the criteria to be used by the IANA for > assignment > of numbers within namespaces defined within this document. > > Diameter is not intended as a general purpose protocol, and > allocations > SHOULD NOT be made for purposes unrelated to authentication, > authorization > or accounting. For registration requests where a Designated > Expert should > be consulted, the responsible IESG area director should appoint the > Designated Expert. > > For registration requests requiring Expert Review, the AAA > mailing list > should be consulted." > > Section 11.1.1 AVP Code > > Change the last sentence of the first paragraph to: > > "AVP Codes 0-254 are managed separtely as RADIUS Attribute Types > [RADTYPE], while the remaining namespace is available for > assignmetn via > Expert Review with Specification Required [IANA]." > > Section 11.2.1, second to last paragraph, last sentence. > > Change to: "The range of values will have a limited lifetime, and will > eventually be reallocated within a range available for > standardization." > > Change "guarentee" to "guarantee" > > Section 11.3 Application Identifiers > > Second paragraph, add the following sentence: > > "Assignment of standards-track application IDs are by Expert > Review with > Specification Required [IANA]." > > From owner-aaa-wg@merit.edu Wed Sep 11 03:41:08 2002 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 DAA00540 for ; Wed, 11 Sep 2002 03:41:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDBE591371; Wed, 11 Sep 2002 03:42:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEE0B91372; Wed, 11 Sep 2002 03:42: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 B1A3D91371 for ; Wed, 11 Sep 2002 03:42:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E2745DE40; Wed, 11 Sep 2002 03:42:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id BB4745DE25 for ; Wed, 11 Sep 2002 03:42:32 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Sep 2002 16:40:27 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A7A7CDB@cms3.etri.re.kr> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: Why remove Auth-Grace-Period AVP at AMR/AMR. Date: Wed, 11 Sep 2002 16:40:25 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25966.7DC51740" 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_01C25966.7DC51740 Content-Type: text/plain; charset="euc-kr" from diameter-moibleip-11, Diameter messages(AMR/AMA/HAR) don't include Auth-Grace-Period AVP. i failed to find the reason at the previous mails. Let me know why, please.... thanks in advance. ------_=_NextPart_001_01C25966.7DC51740 Content-Type: text/html; charset="euc-kr" Why remove Auth-Grace-Period AVP at AMR/AMR.

from diameter-moibleip-11,
Diameter messages(AMR/AMA/HAR) don't include Auth-Grace-Period AVP.

i failed to find the reason at the previous mails.
Let me know why, please....

thanks in advance.

------_=_NextPart_001_01C25966.7DC51740-- From owner-aaa-wg@merit.edu Wed Sep 11 03:44:45 2002 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 DAA00728 for ; Wed, 11 Sep 2002 03:44:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB7DB91372; Wed, 11 Sep 2002 03:45:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3674A91373; Wed, 11 Sep 2002 03:45: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 3B52E91372 for ; Wed, 11 Sep 2002 03:45:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 301D95DED3; Wed, 11 Sep 2002 03:45:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 7CB3F5DE25 for ; Wed, 11 Sep 2002 03:45:15 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8B7j6rU026588; Wed, 11 Sep 2002 09:45:06 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 09:45:05 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Wed, 11 Sep 2002 09:45:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, If the Accounting functionality of the Diameter base protocol can be used without a corresponding application, which would be good, what application id should a Diameter accounting client advertise during the capabilities exchange phase and when sending Accounting Request command ? Relay application Id ? Regards........Harri -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: 11. syyskuuta 2002 4:03 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 360: Accounting standalone Issue 360: Accounting standalone Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 1, 2, 7.1.3 Rationale/Explanation of issue: The specification is contradictory on whether the Accounting functionality of the Diameter base protocol can be used without a corresponding application (MIP, NASREQ, etc.) For example, the SIP accounting extension does not include an authentication application definition, yet makes use of the Base protocol: (see http://www.ietf.org/internet-drafts/draft-narayanan-sipping-aaa-diameter-00.txt Thus, the above specification seems to provide an example of how the Diameter Accounting can be used by itself, and I would argue that this is to be encouraged instead of create Yet Another Accounting Protocol (YAAP). The proposed fix is to adjust the text in the following places to make this clear: Page 14: Change definition of Diameter Server to the following: "A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm." Section 2, page 17, first paragraph. Change the first sentence of the first paragraph to: "The base Diameter protocol may be used by itself for accounting applications, but for use in authentication and authorization it is always extended for a particular application." Section 7.1.3, Page 81, DIAMETER_UNABLE_TO_DELIVER Change "no host within the realm was available" to "no host within the realm supporting the required application was available" Page 94, last paragraph Delete the paragraph starting with "Note that the server side state machine..." This paragraph appears to be redundant with the first paragraph of page 93. From owner-aaa-wg@merit.edu Wed Sep 11 04:03:47 2002 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 EAA01088 for ; Wed, 11 Sep 2002 04:03:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5AE5A912C3; Wed, 11 Sep 2002 04:05:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 280F591373; Wed, 11 Sep 2002 04:05:06 -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 14235912C3 for ; Wed, 11 Sep 2002 04:05:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EABDA5DE18; Wed, 11 Sep 2002 04:05:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hindon.hss.co.in (unknown [202.54.26.202]) by segue.merit.edu (Postfix) with ESMTP id 6F5855DED9 for ; Wed, 11 Sep 2002 04:05:03 -0400 (EDT) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g8B851S29662 for ; Wed, 11 Sep 2002 13:35:01 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g8B850i29654 for ; Wed, 11 Sep 2002 13:35:00 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g8B862o22198 for ; Wed, 11 Sep 2002 13:36:02 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C31.002BED28 ; Wed, 11 Sep 2002 13:29:47 +0530 X-Lotus-FromDomain: HSS From: akbansal@hss.hns.com To: aaa-wg@merit.edu Message-ID: <65256C31.002BEC16.00@sandesh.hss.hns.com> Date: Wed, 11 Sep 2002 13:30:13 +0530 Subject: [AAA-WG]: Diameter Draft 12 : Vendor-Specific-Application-Id AVP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-wg@merit.edu Precedence: bulk As per section 6.11 of diameter draft 12: 6.11 Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application. This AVP SHOULD be placed as close to the Diameter header as possible. AVP Format ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Why are multiple occurences of Vendor-Id AVP required? Since an application is vendor specific, the number of different applications in this case comes out to be equal to the number of Vendor-Id AVPs present. But shouldn't this AVP represent only one vendor specific application id as one message can be of relevance to only one specific application? -Ankit DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. From owner-aaa-wg@merit.edu Wed Sep 11 08:34:24 2002 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 IAA06232 for ; Wed, 11 Sep 2002 08:34:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 232BE91378; Wed, 11 Sep 2002 08:35:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBFA69137B; Wed, 11 Sep 2002 08:35:50 -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 5D1CB91378 for ; Wed, 11 Sep 2002 08:35:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B15F5DD93; Wed, 11 Sep 2002 08:35:49 -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 843035DD92 for ; Wed, 11 Sep 2002 08:35:48 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8BCZhk15800 for ; Wed, 11 Sep 2002 15:35:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 15:35:43 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 15:35:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Wed, 11 Sep 2002 15:35:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C9@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 360: Accounting standalone Thread-Index: AcJZafIEbKgAaxfBRrW2XlYueZw7VwAJZJsg From: To: , , X-OriginalArrivalTime: 11 Sep 2002 12:35:43.0126 (UTC) FILETIME=[BE833360:01C2598F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06232 Hi Harri, > If the Accounting functionality of the Diameter base protocol > can be used without a corresponding application, which would be > good, what application id should a Diameter accounting client > advertise during the capabilities exchange phase and when sending > Accounting Request command ? Relay application Id ? Should we allocate an application id for base accounting application? John From owner-aaa-wg@merit.edu Wed Sep 11 09:39:15 2002 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 JAA09173 for ; Wed, 11 Sep 2002 09:39:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB667912CA; Wed, 11 Sep 2002 09:40:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C8C0912CB; Wed, 11 Sep 2002 09:40: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 7932F912CA for ; Wed, 11 Sep 2002 09:40:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62D2C5DDF8; Wed, 11 Sep 2002 09:40:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id EA25E5DD92 for ; Wed, 11 Sep 2002 09:40:38 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8BDeYRb000155; Wed, 11 Sep 2002 15:40:34 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 15:40:35 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'john.loughney@nokia.com'" , aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Wed, 11 Sep 2002 15:40:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk If we want to say that the base Diameter protocol may be used by itself for accounting applications, then we need application Id for it. I think that we are back to issue 196. / Harri -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 11. syyskuuta 2002 15:36 To: Harri.Hakala@lmf.ericsson.se; aboba@internaut.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Hi Harri, > If the Accounting functionality of the Diameter base protocol > can be used without a corresponding application, which would be > good, what application id should a Diameter accounting client > advertise during the capabilities exchange phase and when sending > Accounting Request command ? Relay application Id ? Should we allocate an application id for base accounting application? John From owner-aaa-wg@merit.edu Wed Sep 11 11:08:20 2002 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 LAA12192 for ; Wed, 11 Sep 2002 11:08:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E819912DB; Wed, 11 Sep 2002 11:09:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D9C6912DD; Wed, 11 Sep 2002 11:09: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 31E9F912DB for ; Wed, 11 Sep 2002 11:09:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F9F75DE43; Wed, 11 Sep 2002 11:09:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (unknown [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 88F3E5DE30 for ; Wed, 11 Sep 2002 11:09:43 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8BF8al17209; Wed, 11 Sep 2002 11:08:36 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA26219; Wed, 11 Sep 2002 10:08:36 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H2A4QA-0001A8-00; Wed, 11 Sep 2002 11:08:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15743.23664.335850.231704@gargle.gargle.HOWL> Date: Wed, 11 Sep 2002 10:08:32 -0500 From: Pete McCann To: john.loughney@nokia.com Cc: , Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F13@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F13@esebe004.ntc.nokia.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, John, I see your point. Why don't we just delete the paragraph that talks about disk-writing accounting servers. I think if we are going to allocate a new Application ID specifically for base-accounting, that should take care of most kinds of disk-writing accounting servers: they can advertise support for base accounting and nothing else. If someone really felt the need to invent a new Application ID for an accounting application, it is probably (hopefully) because some new functionality was added that would make the application incompatible with those simple disk-writing servers anyway. -Pete john.loughney@nokia.com writes: > Hi Pete & Bernard, > > This discussion is opening a can of worms, in my opinion - and I'm > not so sure we're quite ready to fish (just to mix some metaphors!) > > The can of worms is this: what is a Diameter application (not just > accounting). This is a rather simple question, but there are a lot > of issues behind it. I'd like to avoid, at present, issues about > 'typing' of Diameter applications, as I think we don't yet have > enough experience with them. I am sure we could device a rather > complex system which would inform peers about the different > applications - what type, suggested compatability, etc. - but I am > not entirely sure that this complexity would be useful. > > Perhaps some sort of additional application negotiation mechanism could > be added as an extension to the Diameter base, which would help. However, > I think this could / should be done after we get the Base out the door. > > John > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@lucent.com] > > Sent: 10 September, 2002 17:20 > > To: Bernard Aboba > > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > > Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base > > update) > > > > > > > > Bernard Aboba writes: > > > It is conceivable that someone could come up > > > with an accounting application that required a new command, no? > > > > Maybe we should say that's not an accounting application. Or rather, > > if it still used ACR/ACA, that part would be accounting, but the new > > command would be an authorization application. > > > > > > Would that work? > > > > > > 99% of the time, I think it would. But I'm curious as to > > how we would > > > handle the other 1%. > > > > We currently don't have any formal definition of what an accounting > > application is, so let's just define the problem away by saying that > > *only* ACR/ACA can be a part of an accounting application, and > > anything else is part of the corresponding authorization application. > > If an application doesn't use ACR/ACA, then it's not an accounting > > application. If it uses ACR/ACA + some other commands, then only the > > ACR/ACA part is the accounting, but the other commands are > > authorization. You could always advertise support for each one > > separately in CER/CEA, or advertise as an accounting relay to say you > > support all applications' ACR/ACA commands but nothing else. > > > > -Pete > > > > From owner-aaa-wg@merit.edu Wed Sep 11 11:11:40 2002 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 LAA12302 for ; Wed, 11 Sep 2002 11:11:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5BC8912DF; Wed, 11 Sep 2002 11:13:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B52F3912E0; Wed, 11 Sep 2002 11:13:02 -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 CDEC5912DF for ; Wed, 11 Sep 2002 11:13:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE90E5DE43; Wed, 11 Sep 2002 11:13:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3DA165DE30 for ; Wed, 11 Sep 2002 11:13:01 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BEEXU23485; Wed, 11 Sep 2002 07:14:33 -0700 Date: Wed, 11 Sep 2002 07:14:33 -0700 (PDT) From: Bernard Aboba To: "Harri Hakala (LMF)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If the Accounting functionality of the Diameter base protocol > can be used without a corresponding application, which would be > good, what application id should a Diameter accounting client > advertise during the capabilities exchange phase and when sending > Accounting Request command ? Relay application Id ? Since Accounting support is required on both Diameter clients and servers, if the client only wanted to do accounting and nothing else, since there is no application id for accounting (not clear why this is, really), then it would not offer any application id. The server would offer the applications it supports -- and the CER/CEA negotiation would succeed, no? From owner-aaa-wg@merit.edu Wed Sep 11 11:17:57 2002 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 LAA12752 for ; Wed, 11 Sep 2002 11:17:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB9A5912E2; Wed, 11 Sep 2002 11:19:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43D70912E5; Wed, 11 Sep 2002 11:19: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 1FD87912E2 for ; Wed, 11 Sep 2002 11:17:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E9CB65DE36; Wed, 11 Sep 2002 11:17:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0D5D85DE30 for ; Wed, 11 Sep 2002 11:17:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BEIMN23785; Wed, 11 Sep 2002 07:18:22 -0700 Date: Wed, 11 Sep 2002 07:18:22 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: Harri.Hakala@lmf.ericsson.se, Subject: RE: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54C9@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Hi Harri, > > > If the Accounting functionality of the Diameter base protocol > > can be used without a corresponding application, which would be > > good, what application id should a Diameter accounting client > > advertise during the capabilities exchange phase and when sending > > Accounting Request command ? Relay application Id ? > > Should we allocate an application id for base accounting application? Makes sense to me. In fact, I might suggest that we allocate two: - One that indicates "I support Diameter Base Accounting" - One that indicates "I support any application using ACR/ACA" Diameter peers MUST advertise one of these accounting application IDs. From owner-aaa-wg@merit.edu Wed Sep 11 11:18:29 2002 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 LAA12783 for ; Wed, 11 Sep 2002 11:18:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 586D0912E3; Wed, 11 Sep 2002 11:19:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25D82912E5; Wed, 11 Sep 2002 11:19: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 3C8D3912E3 for ; Wed, 11 Sep 2002 11:19:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 298215DE36; Wed, 11 Sep 2002 11:19:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id ACB055DE30 for ; Wed, 11 Sep 2002 11:19:55 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BELQw23949; Wed, 11 Sep 2002 07:21:26 -0700 Date: Wed, 11 Sep 2002 07:21:26 -0700 (PDT) From: Bernard Aboba To: Pete McCann Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <15743.23664.335850.231704@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If someone really felt > the need to invent a new Application ID for an accounting application, > it is probably (hopefully) because some new functionality was added > that would make the application incompatible with those simple > disk-writing servers anyway. > That's the rub. If a new accounting application *required* a new command (not just mandatory AVPs), then there'd be no problem. But it's also possible to create a new accounting application that uses ACR/ACA, but just adds some mandatory AVPs. From owner-aaa-wg@merit.edu Wed Sep 11 11:19:55 2002 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 LAA12840 for ; Wed, 11 Sep 2002 11:19:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7214912E6; Wed, 11 Sep 2002 11:21:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB7F3912E5; Wed, 11 Sep 2002 11:21: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 2BFCF912EE for ; Wed, 11 Sep 2002 11:21:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0635F5DE36; Wed, 11 Sep 2002 11:21:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (unknown [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 8FE3A5DE30 for ; Wed, 11 Sep 2002 11:21:14 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8BFL2a25764; Wed, 11 Sep 2002 11:21:02 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA29185; Wed, 11 Sep 2002 10:21:01 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H2A5AZ-0000CW-00; Wed, 11 Sep 2002 11:20:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15743.24409.667732.852820@gargle.gargle.HOWL> Date: Wed, 11 Sep 2002 10:20:57 -0500 From: Pete McCann To: Bernard Aboba Cc: "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: References: X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: > > If the Accounting functionality of the Diameter base protocol > > can be used without a corresponding application, which would be > > good, what application id should a Diameter accounting client > > advertise during the capabilities exchange phase and when sending > > Accounting Request command ? Relay application Id ? > > Since Accounting support is required on both Diameter clients and servers, > if the client only wanted to do accounting and nothing else, since there > is no application id for accounting (not clear why this is, really), then > it would not offer any application id. The server would offer the > applications it supports -- and the CER/CEA negotiation would succeed, no? But the question was about the header of the ACR/ACA messages during actual operation of the accounting protocol, not pre-negotiation in CER/CEA. What application ID goes there? -Pete From owner-aaa-wg@merit.edu Wed Sep 11 11:36:31 2002 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 LAA13292 for ; Wed, 11 Sep 2002 11:36:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A4D79137B; Wed, 11 Sep 2002 11:37:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 399559136B; Wed, 11 Sep 2002 11:37: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 93B689135E for ; Wed, 11 Sep 2002 11:37:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 377FD5DE3C; Wed, 11 Sep 2002 11:37:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (unknown [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id C53E95DE30 for ; Wed, 11 Sep 2002 11:37:47 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8BFbba03197; Wed, 11 Sep 2002 11:37:37 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA24843; Wed, 11 Sep 2002 10:37:36 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H2A62M-0000P0-00; Wed, 11 Sep 2002 11:37:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15743.25404.558478.970479@gargle.gargle.HOWL> Date: Wed, 11 Sep 2002 10:37:32 -0500 From: Pete McCann To: Bernard Aboba Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: References: <15743.23664.335850.231704@gargle.gargle.HOWL> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: > > If someone really felt > > the need to invent a new Application ID for an accounting application, > > it is probably (hopefully) because some new functionality was added > > that would make the application incompatible with those simple > > disk-writing servers anyway. > > That's the rub. If a new accounting application *required* a new command > (not just mandatory AVPs), then there'd be no problem. But it's also > possible to create a new accounting application that uses ACR/ACA, but > just adds some mandatory AVPs. Right, it's possible, but as I understand it, not required. If you get a new ID, you just won't be able to take advantage of already-deployed "disk-writing" accounting servers. That's the disincentive for people to request the new Application ID. If someone does so anyway, it's their own fault, and they get what they deserve. Or rather, we assume they know what they're doing, and those mandatory AVPs are so important that they are willing to break backwards compatibility with those disk-writers. -Pete From owner-aaa-wg@merit.edu Wed Sep 11 11:37:13 2002 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 LAA13331 for ; Wed, 11 Sep 2002 11:37:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24C0D9135E; Wed, 11 Sep 2002 11:38:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A74F89136B; Wed, 11 Sep 2002 11:38: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 5D28B9135E for ; Wed, 11 Sep 2002 11:38:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4090D5DE43; Wed, 11 Sep 2002 11:38:30 -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 4FA3D5DE3C for ; Wed, 11 Sep 2002 11:38:29 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8BFcSk07033 for ; Wed, 11 Sep 2002 18:38:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 18:38:19 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 18:38:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Wed, 11 Sep 2002 18:38:18 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E42ED@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 360: Accounting standalone Thread-Index: AcJZpqqMQ5svRIK/RYCuR/+gOXRB1wAAdIbQ From: To: , Cc: , X-OriginalArrivalTime: 11 Sep 2002 15:38:19.0093 (UTC) FILETIME=[40C71850:01C259A9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13331 Hi, it sounds good proposal to allocate this kind of accounting application Id. But why would you need two? one that indicate "I support Diameter Base Accounting and any application using only ACR/ACA" is not enough? Disk-writing accounting server can just advertise this application id. Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11. September 2002 17:18 > To: Loughney John (NRC/Helsinki) > Cc: Harri.Hakala@lmf.ericsson.se; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 360: Accounting standalone > > > > Hi Harri, > > > > > If the Accounting functionality of the Diameter base protocol > > > can be used without a corresponding application, which would be > > > good, what application id should a Diameter accounting client > > > advertise during the capabilities exchange phase and when sending > > > Accounting Request command ? Relay application Id ? > > > > Should we allocate an application id for base accounting > application? > > Makes sense to me. In fact, I might suggest that we allocate two: > > - One that indicates "I support Diameter Base Accounting" > > - One that indicates "I support any application using ACR/ACA" > > Diameter peers MUST advertise one of these accounting application IDs. > > From owner-aaa-wg@merit.edu Wed Sep 11 11:47:47 2002 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 LAA13696 for ; Wed, 11 Sep 2002 11:47:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5530D9136B; Wed, 11 Sep 2002 11:49:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2466A9137E; Wed, 11 Sep 2002 11:49: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 CE9E79136B for ; Wed, 11 Sep 2002 11:48:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B06D05DE3D; Wed, 11 Sep 2002 11:48:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2A31F5DE30 for ; Wed, 11 Sep 2002 11:48:01 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BEnX425540; Wed, 11 Sep 2002 07:49:33 -0700 Date: Wed, 11 Sep 2002 07:49:33 -0700 (PDT) From: Bernard Aboba To: Pete McCann Cc: john.loughney@nokia.com, Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <15743.25404.558478.970479@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If you get a new ID, you just won't be able to take advantage of > already-deployed "disk-writing" accounting servers. That's the > disincentive for people to request the new Application ID. Unfortunately, application developers don't seem to be perceiving that as a "disincentive": so far most accounting applications seem to want an application ID, even if they don't need one (The SIP accounting draft is one example). I'd hate for this to imply that only Diameter clients and servers from the same vendor will be likely to work together, but in practice that's what might happen. From owner-aaa-wg@merit.edu Wed Sep 11 11:59:55 2002 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 LAA14109 for ; Wed, 11 Sep 2002 11:59:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBC5C91381; Wed, 11 Sep 2002 11:58:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8926E91392; Wed, 11 Sep 2002 11:58:39 -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 8082891381 for ; Wed, 11 Sep 2002 11:58:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FE745DE49; Wed, 11 Sep 2002 11:58:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D67F65DE43 for ; Wed, 11 Sep 2002 11:58:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BExbv26014; Wed, 11 Sep 2002 07:59:37 -0700 Date: Wed, 11 Sep 2002 07:59:36 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: john.loughney@nokia.com, , Subject: RE: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E42ED@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > it sounds good proposal to allocate this kind of accounting application Id. > But why would you need two? one that indicate "I support Diameter Base > Accounting and any application using only ACR/ACA" is not enough? Let's look at three cases. Suppose Accounting server advertises "any application using only ACR/ACA". Accounting client advertises their application ID, which the accounting server might not understand, as well as "any application using only ACR/ACA". Negotiation succeeds. Accounting client now sends an ACR command with their application ID, perhaps some new mandatory AVPs. Accounting server will only look at the ACR, ignore the application ID (since can handle any application ID with ACR), and responds with an ACA with that application ID. Seems to work fine. Now what if the accounting server doesn't support "any app with ACR/ACA"? Accounting server advertises no application ID (implying that it does basic accounting only). Accounting client advertises the new application ID, plus "any application using only ACR/ACA". Negotiation fails. The last case is if both client and server only do basic accounting. Both will advertise no application ID in CER/CEA, and negotiation will succeed. But then the issue is what application goes in the header, along with ACR/ACA. From owner-aaa-wg@merit.edu Wed Sep 11 12:35:46 2002 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 MAA15540 for ; Wed, 11 Sep 2002 12:35:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 285A691308; Wed, 11 Sep 2002 12:37:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E39B991382; Wed, 11 Sep 2002 12:37:06 -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 B37B391308 for ; Wed, 11 Sep 2002 12:37:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A30A15DE43; Wed, 11 Sep 2002 12:37:05 -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 B84B55DDEE for ; Wed, 11 Sep 2002 12:37:04 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8BGb3k01882 for ; Wed, 11 Sep 2002 19:37:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 19:37:03 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 19:37:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Wed, 11 Sep 2002 19:37:03 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E42F0@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 360: Accounting standalone Thread-Index: AcJZrAMCdUWp04hmSluKV5e0lAqH8QAAOv9A From: To: Cc: , , X-OriginalArrivalTime: 11 Sep 2002 16:37:03.0489 (UTC) FILETIME=[757B3F10:01C259B1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15540 OK, then it seems we need two accounting application Id. However, A disk-writing accounting server is probably just storing AVPs to the disk, later on it will send the AVPs to a postprocessing system (e.g. billing system)that may understand this information to create the bill. This does not mean tha such accounting server can handle any application using only ACR/ACA. For example, you might have prepaid accounting application that make only use of ACR/ACA. When the server receive ACR would need to reserve money from some account, calculate the quota and send back the calculated quota to the client. This is "any application using only ACR/ACA", but clearly a disk-writing accounting server cannot handle this application. Perhaps it is still better to delete the "disk-writing" text as originally proposed by Pete. Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11. September 2002 18:00 > To: Stura Marco (NET/Helsinki) > Cc: Loughney John (NRC/Helsinki); Harri.Hakala@lmf.ericsson.se; > aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 360: Accounting standalone > > > > it sounds good proposal to allocate this kind of accounting > application Id. > > But why would you need two? one that indicate "I support > Diameter Base > > Accounting and any application using only ACR/ACA" is not enough? > > Let's look at three cases. > > Suppose Accounting server advertises "any application > using only ACR/ACA". Accounting client advertises their > application ID, > which the accounting server might not understand, as well as "any > application using only ACR/ACA". Negotiation succeeds. > > Accounting client now sends an ACR command with their application ID, > perhaps some new mandatory AVPs. Accounting server will only > look at the > ACR, ignore the application ID (since can handle any > application ID with > ACR), and responds with an ACA with that application ID. > > Seems to work fine. > > Now what if the accounting server doesn't support "any app > with ACR/ACA"? > > Accounting server advertises no application ID (implying that it does > basic accounting only). Accounting client advertises the new > application > ID, plus "any application using only ACR/ACA". Negotiation fails. > > The last case is if both client and server only do basic > accounting. Both > will advertise no application ID in CER/CEA, and negotiation > will succeed. > But then the issue is what application goes in the header, along with > ACR/ACA. > > From owner-aaa-wg@merit.edu Wed Sep 11 12:47:28 2002 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 MAA15890 for ; Wed, 11 Sep 2002 12:47:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39C4C91385; Wed, 11 Sep 2002 12:46:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5694D91384; Wed, 11 Sep 2002 12:46:39 -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 BB38091382 for ; Wed, 11 Sep 2002 12:46:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B0FC5DE4F; Wed, 11 Sep 2002 12:46:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 277DB5DE3A for ; Wed, 11 Sep 2002 12:46:30 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g8BGk4Vn006824; Wed, 11 Sep 2002 12:46:05 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA20492; Wed, 11 Sep 2002 12:46:30 -0400 (EDT) Date: Wed, 11 Sep 2002 12:45:58 -0400 To: Pete McCann Cc: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) Message-ID: <20020911164558.GB641@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F13@esebe004.ntc.nokia.com> <15743.23664.335850.231704@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <15743.23664.335850.231704@gargle.gargle.HOWL> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 91 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Sep 11, 2002 at 10:08:32AM -0500, Pete McCann wrote: > > Hi, John, > > I see your point. > > Why don't we just delete the paragraph that talks about disk-writing > accounting servers. Or more explanation for "disk-writing" accounting would be necessary. It is difficult to follow the discussion without knowing what the "disk-writing" accounting actually does and why the "disk-writing" accounting is important. Yoshihiro Ohba > I think if we are going to allocate a new > Application ID specifically for base-accounting, that should take care > of most kinds of disk-writing accounting servers: they can advertise > support for base accounting and nothing else. If someone really felt > the need to invent a new Application ID for an accounting application, > it is probably (hopefully) because some new functionality was added > that would make the application incompatible with those simple > disk-writing servers anyway. > > -Pete > > john.loughney@nokia.com writes: > > Hi Pete & Bernard, > > > > This discussion is opening a can of worms, in my opinion - and I'm > > not so sure we're quite ready to fish (just to mix some metaphors!) > > > > The can of worms is this: what is a Diameter application (not just > > accounting). This is a rather simple question, but there are a lot > > of issues behind it. I'd like to avoid, at present, issues about > > 'typing' of Diameter applications, as I think we don't yet have > > enough experience with them. I am sure we could device a rather > > complex system which would inform peers about the different > > applications - what type, suggested compatability, etc. - but I am > > not entirely sure that this complexity would be useful. > > > > Perhaps some sort of additional application negotiation mechanism could > > be added as an extension to the Diameter base, which would help. However, > > I think this could / should be done after we get the Base out the door. > > > > John > > > -----Original Message----- > > > From: ext Pete McCann [mailto:mccap@lucent.com] > > > Sent: 10 September, 2002 17:20 > > > To: Bernard Aboba > > > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > > > Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base > > > update) > > > > > > > > > > > > Bernard Aboba writes: > > > > It is conceivable that someone could come up > > > > with an accounting application that required a new command, no? > > > > > > Maybe we should say that's not an accounting application. Or rather, > > > if it still used ACR/ACA, that part would be accounting, but the new > > > command would be an authorization application. > > > > > > > > Would that work? > > > > > > > > 99% of the time, I think it would. But I'm curious as to > > > how we would > > > > handle the other 1%. > > > > > > We currently don't have any formal definition of what an accounting > > > application is, so let's just define the problem away by saying that > > > *only* ACR/ACA can be a part of an accounting application, and > > > anything else is part of the corresponding authorization application. > > > If an application doesn't use ACR/ACA, then it's not an accounting > > > application. If it uses ACR/ACA + some other commands, then only the > > > ACR/ACA part is the accounting, but the other commands are > > > authorization. You could always advertise support for each one > > > separately in CER/CEA, or advertise as an accounting relay to say you > > > support all applications' ACR/ACA commands but nothing else. > > > > > > -Pete > > > > > > > > From owner-aaa-wg@merit.edu Wed Sep 11 13:17:41 2002 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 NAA17375 for ; Wed, 11 Sep 2002 13:17:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C05191398; Wed, 11 Sep 2002 13:17:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF1459138A; Wed, 11 Sep 2002 13:17:27 -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 B7B2E91398 for ; Wed, 11 Sep 2002 13:15:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E7FF5DE77; Wed, 11 Sep 2002 13:15:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E67555DE43 for ; Wed, 11 Sep 2002 13:15:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BGHCm30370; Wed, 11 Sep 2002 09:17:12 -0700 Date: Wed, 11 Sep 2002 09:17:12 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: john.loughney@nokia.com, , Subject: RE: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E42F0@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > However, > A disk-writing accounting server is probably just storing AVPs to the > disk, later on it will send the AVPs to a postprocessing system (e.g. > billing system)that may understand this information to create the bill. > This does not mean tha such accounting server can handle any application > using only ACR/ACA. That's a fair statement. I think you are saying that in an accounting command, the "M" bit in an AVP means "this AVP *must* be understood by the backend billing system", not necessarily "this AVP *must* be understood by the accounting server." Note that this is *not* the same thing as saying that the AVP is required by the ABNF in the accounting application definition. It is possible for the ABNF to require inclusion of an AVP without the "M" bit set. The implication is that AVPs marked with the "M" bit for authentication would not necessarily have this bit marked for use within an accounting command. For example, it might be important that the NAS implement a special filtering AVP, (set "M" in the authentication), but that might be irrelevant for accounting purposes (NAS doesn't set "M" bit in the ACR). If we can guarantee that the "M" bit is set this way in accounting AVPs, I'm not clear why you'd need a new accounting application unless a new command is being defined. You just let the Accounting server advertise the standard accounting command; if you send it mandatory AVPs it doesn't understand, it will send you an error message. > Perhaps it is still better to delete the "disk-writing" text as originally > proposed by Pete. This could work, provided that the above issues with the "M" bit and accounting application id allocation are worked through. From owner-aaa-wg@merit.edu Wed Sep 11 13:21:26 2002 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 NAA17525 for ; Wed, 11 Sep 2002 13:21:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA2A2913BE; Wed, 11 Sep 2002 13:22:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 684A5913D6; Wed, 11 Sep 2002 13:22: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 2F7C9913CC for ; Wed, 11 Sep 2002 13:21:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C9215DE59; Wed, 11 Sep 2002 13:21:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 652A95DDEE for ; Wed, 11 Sep 2002 13:21:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BGN3h30666; Wed, 11 Sep 2002 09:23:03 -0700 Date: Wed, 11 Sep 2002 09:23:03 -0700 (PDT) From: Bernard Aboba To: Yoshihiro Ohba Cc: Pete McCann , , Subject: Re: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: <20020911164558.GB641@catfish> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Or more explanation for "disk-writing" accounting would be necessary. > It is difficult to follow the discussion without knowing what the > "disk-writing" accounting actually does and why the "disk-writing" > accounting is important. The issue is inclusion of additional AVPs in accounting applications which do not have to be understood by the backend billing system. Such AVPs may be required to be included by the accounting application (e.g. mandatory within the ABNF), but if they don't change the customer bill, then they don't need to be marked with the "M" bit in an accounting command. This is true even if the "M" bit would be set on that same AVP within an authentication command. Thus, an AVP can have the "M" bit set for authentication, but not have it set for accounting. From owner-aaa-wg@merit.edu Wed Sep 11 13:53:21 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18918 for ; Wed, 11 Sep 2002 13:53:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 280EB9138D; Wed, 11 Sep 2002 13:53:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAD3291394; Wed, 11 Sep 2002 13:53: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 B92889138D for ; Wed, 11 Sep 2002 13:53:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A70C15DE5A; Wed, 11 Sep 2002 13:53:12 -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 BF82F5DE3A for ; Wed, 11 Sep 2002 13:53:11 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8BHrL713829 for ; Wed, 11 Sep 2002 20:53:21 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 20:50:32 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 20:50:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Wed, 11 Sep 2002 20:50:31 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E42F1@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 360: Accounting standalone Thread-Index: AcJZttrl5f2dZ8MVQqCXhWigpEMUGwAAGNpw From: To: Cc: , , X-OriginalArrivalTime: 11 Sep 2002 17:50:32.0092 (UTC) FILETIME=[B936ADC0:01C259BB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18918 Hi Bernard, I think you fully missunderstood my point, I don't know where in my mail you read the "fair statement" you speak about. I'm not discussing AVP with M bit set at all, I'm arguing that disk-writing accounting server cannot handle "any accounting application that only use ACR/ACA" as they probably just store say accounting information, may be it's more clear, that may be used by other systems to create the bill. There was also a clear example that you didn't comment at all "For example, you might have prepaid accounting application that make only use of ACR/ACA. When the server receive ACR would need to reserve money from some account, calculate the quota and send back the calculated quota to the client. This is "any application using only ACR/ACA", but clearly a disk-writing accounting server cannot handle this application." This is one good reason to remove the disk-writing text. Moreover, Here I was refferring to AVP required in the accounting application definition that trigger some specific server action necessary to support the requested service (one example is prepaid). How would you differentiate this kind of application if not with an accounting application id? Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11. September 2002 19:17 > To: Stura Marco (NET/Helsinki) > Cc: Loughney John (NRC/Helsinki); Harri.Hakala@lmf.ericsson.se; > aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 360: Accounting standalone > > > > However, > > A disk-writing accounting server is probably just storing > AVPs to the > > disk, later on it will send the AVPs to a postprocessing > system (e.g. > > billing system)that may understand this information to > create the bill. > > This does not mean tha such accounting server can handle > any application > > using only ACR/ACA. > > That's a fair statement. I think you are saying that in an accounting > command, the "M" bit in an AVP means "this AVP *must* be > understood by the > backend billing system", not necessarily "this AVP *must* be > understood by > the accounting server." > > Note that this is *not* the same thing as saying that the AVP > is required > by the ABNF in the accounting application definition. It is > possible for > the ABNF to require inclusion of an AVP without the "M" bit set. > > The implication is that AVPs marked with the "M" bit for > authentication > would not necessarily have this bit marked for use within an > accounting > command. For example, it might be important that the NAS implement a > special filtering AVP, (set "M" in the authentication), but > that might be > irrelevant for accounting purposes (NAS doesn't set "M" bit > in the ACR). > > If we can guarantee that the "M" bit is set this way in > accounting AVPs, > I'm not clear why you'd need a new accounting application unless > a new command is being defined. You just let the Accounting server > advertise the standard accounting command; if you send it > mandatory AVPs > it doesn't understand, it will send you an error message. > > > Perhaps it is still better to delete the "disk-writing" > text as originally > > proposed by Pete. > > This could work, provided that the above issues with the "M" bit and > accounting application id allocation are worked through. > > From owner-aaa-wg@merit.edu Wed Sep 11 14:54:45 2002 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 OAA21169 for ; Wed, 11 Sep 2002 14:54:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6927C91323; Wed, 11 Sep 2002 14:56:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 365C39132A; Wed, 11 Sep 2002 14:56: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 36F6091323 for ; Wed, 11 Sep 2002 14:56:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 252025DDA2; Wed, 11 Sep 2002 14:56:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7E9815DD8C for ; Wed, 11 Sep 2002 14:56:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BHvhY03366; Wed, 11 Sep 2002 10:57:43 -0700 Date: Wed, 11 Sep 2002 10:57:43 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: john.loughney@nokia.com, , Subject: RE: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E42F1@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think you fully missunderstood my point, I don't know where in my > mail you read the "fair statement" you speak about. I agreed with you that a disk-writing accounting server couldn't handle your prepaid accounting application. > I'm arguing that > disk-writing accounting server cannot handle "any accounting > application that only use ACR/ACA" as they probably just store > say accounting information, may be it's more clear, that may be used > by other systems to create the bill. I agree with that. > This is one good reason to remove the disk-writing text. I agree with that, too. > Moreover, Here I was referring to AVP required in the accounting application > definition that trigger some specific server action necessary to support > the requested service (one example is prepaid). > How would you differentiate this kind of application if not with an accounting > application id? There are two cases: 1. If the application not only requires new AVPs to be present in the application (e.g. ABNF mandates them), but also requires the billing server to understand them (e.g. new AVPs have "M" bit set in accounting messages), then a new application ID is required, even if no new commands are used, only ACR/ACA. 2. However, if the application requires new AVPs to be present (ABNF mandatory), but does not require the billing server to understand them (e.g. new AVPs don't have "M" bit set) and there are no new commands, then I'd argue that a new application ID is not required and MUST NOT be used. If you buy this argument, then I think the indicated fix is: a. Delete the "disk writing" text. b. Change the "Extensions" text to indicate that a new accounting application ID is needed only when there are new commands, OR when new AVPs defined in the application ABNF have the "M" bit set. If there are no new commands, and new AVPs are non-mandatory, a new application ID MUST NOT be used. c. Add text to require that in accounting commands, the "M" bit is only set when a backend billing server MUST support the AVP in order to issue a correct bill. If the backend billing server can ignore the AVP in computing the bill, then the AVP MUST NOT have the "M" bit set within an accounting message, even if the "M" bit was set on that AVP within an authentication message. d. Add a "standard accounting application" ID so that accounting can be used by itself within Diameter. From owner-aaa-wg@merit.edu Wed Sep 11 15:33:22 2002 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 PAA22326 for ; Wed, 11 Sep 2002 15:33:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D6D691324; Wed, 11 Sep 2002 15:34:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AB82913AF; Wed, 11 Sep 2002 15:34:46 -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 51F5491324 for ; Wed, 11 Sep 2002 15:32:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A6F75DDA4; Wed, 11 Sep 2002 15:32:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id C21AB5DD8C for ; Wed, 11 Sep 2002 15:32:34 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g8BJWFVn021995; Wed, 11 Sep 2002 15:32:16 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA20981; Wed, 11 Sep 2002 15:32:41 -0400 (EDT) Date: Wed, 11 Sep 2002 15:32:14 -0400 To: Bernard Aboba Cc: marco.stura@nokia.com, john.loughney@nokia.com, Harri.Hakala@lmf.ericsson.se, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 360: Accounting standalone Message-ID: <20020911193214.GD641@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1D9E42F1@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 47 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Sep 11, 2002 at 10:57:43AM -0700, Bernard Aboba wrote: > There are two cases: > > 1. If the application not only requires new AVPs to be present in the > application (e.g. ABNF mandates them), but also requires the billing > server to understand them (e.g. new AVPs have "M" bit set in accounting > messages), then a new application ID is required, even if no new > commands are used, only ACR/ACA. > > 2. However, if the application requires new AVPs to be present (ABNF > mandatory), but does not require the billing server to understand them > (e.g. new AVPs don't have "M" bit set) and there are no new commands, then > I'd argue that a new application ID is not required and MUST NOT be used. But does case 2) mean that it requires an additional ABNF in addition to the ABNF for base ACR/ACA (and thus additional command dictionary entry would be necessary to parse the new AVP)? If so, how the additional command dictionary entry can be distinguished from the command dictionary entry for the base ACR/ACA without using a new application id? Yoshihiro Ohba > > If you buy this argument, then I think the indicated fix is: > > a. Delete the "disk writing" text. > > b. Change the "Extensions" text to indicate that a new accounting > application ID is needed only when there are new commands, OR when new > AVPs defined in the application ABNF have the "M" bit set. If there are no > new commands, and new AVPs are non-mandatory, a new application ID MUST > NOT be used. > > c. Add text to require that in accounting > commands, the "M" bit is only set when a backend billing server MUST > support the AVP in order to issue a correct bill. If the backend billing > server can ignore the AVP in computing the bill, then the AVP MUST NOT > have the "M" bit set within an accounting message, even if the "M" bit > was set on that AVP within an authentication message. > > d. Add a "standard accounting application" ID so that accounting can be > used by itself within Diameter. > > > > From owner-aaa-wg@merit.edu Wed Sep 11 15:43:34 2002 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 PAA22627 for ; Wed, 11 Sep 2002 15:43:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03502913AF; Wed, 11 Sep 2002 15:44:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C036E913B1; Wed, 11 Sep 2002 15:44:55 -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 DB949913AF for ; Wed, 11 Sep 2002 15:44:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C53195DDC2; Wed, 11 Sep 2002 15:44:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 001BA5DDB1 for ; Wed, 11 Sep 2002 15:44:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BIkTW06140 for ; Wed, 11 Sep 2002 11:46:29 -0700 Date: Wed, 11 Sep 2002 11:46:29 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 365: Revised Extensibility Section Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 365: Revised Extensibility Section Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 9, 2002 Reference: Document: BASE-12 Comment type: T Priority: S Section: 1.2 Rationale/Explanation of issue: This revision is designed to clarify the issue of extensibility to make it clear that addition of non-mandatory AVPs does not require definition of a new application ID. Replace section 1.2 with the following: "1.2 Approach to Extensibility The Diameter protocol is designed to be extensible, using several mechanisms, including: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures Reuse of existing AVP values, AVPs, applications and command codes are strongly recommended. Reuse simplifies standardization and implementation and avoids potential interoperability issues. 1.2.1 Defining New AVP Values New applications should attempt to reuse AVPs defined in existing applications when possible, as opposed to creating new AVPs. For AVPs of type Enumerated an application may require a new value to communicate some service-specific information. In order to allocate a new AVP value, a request MUST be sent to IANA [IANA], along with an explanation of the new AVP value. IANA considerations for Diameter are discussed in Section 11. 1.2.2 Creating New AVPs When no existing AVP can be used, a new AVP should be created. The new AVP being defined MUST use one of the data types listed in section 4.3. In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is recommended that a Grouped AVP be used (see Section 4.5). In order to create a new AVP, a request MUST be sent to IANA, with a specification for the AVP. The request MUST include the commands that would make use of the AVP. 1.2.3 Creating New Authentication Applications Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4) or a vendor specific Application Identifier. Should a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Adding new AVPs to the command, which have the "M" bit set. - Requiring a command that has a different number of round trips to satisfy a request (e.g. application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - Adding support for an authentication method requiring definition of new AVPs for use with the application. Since a new EAP authentication method can be supported within Diameter without requiring new AVPs, addition of EAP methods does not require the creation of a new authentication application. Creation of a new application should be viewed as a last resort. 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. Please refer to section 11.1.1 for details. In order to justify allocation of a new application identifier, Diameter applications MUST define one Command Code, or add new mandatory AVPs to the ABNF. The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section 3.2). If the Diameter application has accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3). However, just because a new authentication application id is required, does not imply that a new accounting application id is required. When possible, a new Diameter application SHOULD reuse existing Diameter AVPs, in order to avoid defining multiple AVPs that carry similar information. 1.2.4 Creating New Accounting Applications There are services that only require Diameter accounting. Such services need to define the AVPs carried in the ACR/ACA messages, but do not need to define new command codes. An implementation MAY add arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not set) to any command defined in an application, including vendor-specific AVPs, without needing to define a new accounting application. Please refer to section 11.1.1 for details. Application Identifiers are still required for Diameter capability exchange. Every accounting application MUST have either an IANA allocated Application Identifier, or a vendor specific Application Identifier. Since every Diameter implementation MUST support accounting, there is no need to advertise support for the Base accounting application within the CER/CEA, since this is implicit. This basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application. The creation of a new accounting application should be viewed as a last resort and MUST NOT be used unless a new command is defined with the application, or new mandatory AVPs are added to the ABNF. Within an accounting command, setting the "M" bit implies that the backend billing server MUST understand the AVP in order to compute a correct bill. If the AVP is not relevant to the billing process, when the AVP is included within an accounting command, it MUST NOT have the "M" bit set, even if the "M" bit is set when the same AVP is used within other Diameter commands. When possible, a new Diameter accounting application SHOULD attempt to reuse existing AVPs, in order to to avoid defining multiple AVPs that carry similar information. Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see section 2.4) or a vendor specific Application Identifier." From owner-aaa-wg@merit.edu Wed Sep 11 15:53:29 2002 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 PAA22884 for ; Wed, 11 Sep 2002 15:53:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82C5C9132E; Wed, 11 Sep 2002 15:54:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47D5B91333; Wed, 11 Sep 2002 15: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 58B389132E for ; Wed, 11 Sep 2002 15:54:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C1C45DDCB; Wed, 11 Sep 2002 15:54:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A56725DDA4 for ; Wed, 11 Sep 2002 15:54:54 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BIuLr06593; Wed, 11 Sep 2002 11:56:21 -0700 Date: Wed, 11 Sep 2002 11:56:20 -0700 (PDT) From: Bernard Aboba To: Yoshihiro Ohba Cc: marco.stura@nokia.com, , , Subject: Re: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <20020911193214.GD641@catfish> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > But does case 2) mean that it requires an additional ABNF in addition > to the ABNF for base ACR/ACA (and thus additional command dictionary > entry would be necessary to parse the new AVP)? If so, how the > additional command dictionary entry can be distinguished from the > command dictionary entry for the base ACR/ACA without using a new > application id? It should be possible to add new AVPs to the dictionary without requiring the application id to change. That can be done in RADIUS today. If the AVPs are non-mandatory there is no reason to allocate a new application ID. A new application id would only be required if mandatory AVPs are added. From owner-aaa-wg@merit.edu Wed Sep 11 16:34:46 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23886 for ; Wed, 11 Sep 2002 16:34:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3CDC913BD; Wed, 11 Sep 2002 16:35:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B696E913C0; Wed, 11 Sep 2002 16:35: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 D53FC913BD for ; Wed, 11 Sep 2002 16:35:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFA2C5DDD1; Wed, 11 Sep 2002 16:35:37 -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 723195DD8C for ; Wed, 11 Sep 2002 16:35:37 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 63F936A901; Wed, 11 Sep 2002 23:35:29 +0300 (EEST) Message-ID: <3D7FAA56.1070901@kolumbus.fi> Date: Wed, 11 Sep 2002 23:40:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 358: Issues with references References: 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 Aboba wrote: > Issue 358: Issues with references > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: E > Priority: 1 > Section: 14.2 and others > Rationale/Explanation of issue: > > Add the following non-normative references to section 14.2: > > [AAAREQ] Aboba, B. et al., "Criteria for Evaluating AAA Protocols > for Network Access", RFC 2989, November 2000. > > [DYNAUTH] Chiba, M., et al., "Dynamic Authorization Extensions to > RADIUS", IETF work in progress. > > [RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. > > [RADEXT] Rigney, C., Willats W., Calhoun P., "RADIUS Extensions", RFC > 2869, June 2000. > > [TACACS] Finseth, C., "An Access Control Protocol, Sometimes Called > TACACS", RFC 1492, July 1993. Well, these are good references but isn't it customary to actual refer to these documents from somewhere in the text? Perhaps DYNAUTH, RADACCT, RADEXT could be referenced when [RADIUS[ is introduced at the beginning. AAREQ could be put to the sentence "Although Diameter could be used to solve a wider set of AAA problems, we are currently limiting the scope of the protocol in order to ensure that the effort remains focused on satisfying the requirements of network access." TACACS could be added to section 2.8.4. > In Sections 11.12, 11.13, 11.14 (page 129) change the reference from [TCP] > to [IANA]. Yes. > In section 14.2, change reference to [IPCOMP] from non-normative to > normative. This is referred to with a MAY in Section 9.2 (page 114). Ok. Jari From owner-aaa-wg@merit.edu Wed Sep 11 16:41:02 2002 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 QAA24130 for ; Wed, 11 Sep 2002 16:41:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29DA891341; Wed, 11 Sep 2002 16:42:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB08D913C0; Wed, 11 Sep 2002 16:42: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 EFD1D91341 for ; Wed, 11 Sep 2002 16:42:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DBB245DDDB; Wed, 11 Sep 2002 16:42:28 -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 9D18A5DD8C for ; Wed, 11 Sep 2002 16:42:28 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2857E6A901; Wed, 11 Sep 2002 23:42:27 +0300 (EEST) Message-ID: <3D7FABF8.7050106@kolumbus.fi> Date: Wed, 11 Sep 2002 23:47:52 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 358: Terminology and Organizational issues References: 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 Aboba wrote: > Issue 358: Terminology and Organizational issues > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: E > Priority: S > Section: 1.4, 8.2 > Rationale/Explanation of issue: > > Several terms are not defined in the terminology section, including: > > Transaction state > Session state > > Quite a few terms are used prior to their definition in Section 1.4, so > that I would recommend that the terminology section (currently 1.4) be > moved up earlier in the document. Yes. Apparently, we need to put it before 1.1 (alternatively before 1). > I'd also note that I found it very confusing that section 8.2 (Accounting > State machine) occurs prior to Section 9 (Accounting). I'd recommend that > 8.2 be moved to Section 9.9 (after definition of the AVPs, including > Accounting-Realtime-Required AVP). Agreed. Jari From owner-aaa-wg@merit.edu Wed Sep 11 17:13:17 2002 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 RAA24891 for ; Wed, 11 Sep 2002 17:13:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71873913C9; Wed, 11 Sep 2002 17:14:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 360C1913CA; Wed, 11 Sep 2002 17:14: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 3B8C2913C9 for ; Wed, 11 Sep 2002 17:14:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FEAC5DDD3; Wed, 11 Sep 2002 17:14:46 -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 C675A5DD8C for ; Wed, 11 Sep 2002 17:14:45 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A360A6A901; Thu, 12 Sep 2002 00:14:43 +0300 (EEST) Message-ID: <3D7FB388.2040001@kolumbus.fi> Date: Thu, 12 Sep 2002 00:20:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 361: Support for TLS compression References: 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 Aboba wrote: > Issue 361: Support for TLS compression > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: T > Priority: 2 > Section: 9.2 > Rationale/Explanation of issue: > > TLS compression is more efficient than IP compression, since TCP > is stateful. As a result, it makes sense to use TLS compression > where TLS is negotiated and it is desired to reduce the network > bandwidth used for Diameter accounting. > > Replace the last paragraph of Section 9.2 with the following: > > "Each Diameter Accounting protocol message MAY be compressed, in order > to reduce network bandwidth usage. If IPsec and IKE are used to > secure the Diameter session, then IP compression [IPComp] MAY be used and > IKE [IKE] MAY be used to negotiate the compression parameters. If TLS > is used to secure the Diameter session, then TLS compression [TLS] MAY > be used." Sounds good. Jari From owner-aaa-wg@merit.edu Wed Sep 11 17:30:04 2002 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 RAA25395 for ; Wed, 11 Sep 2002 17:30:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9EA26913CE; Wed, 11 Sep 2002 17:31:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20506913CF; Wed, 11 Sep 2002 17:31: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 22FA2913CE for ; Wed, 11 Sep 2002 17:31:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED5055DDA4; Wed, 11 Sep 2002 17:31:04 -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 B3F545DD8C for ; Wed, 11 Sep 2002 17:31:04 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 611966A901; Thu, 12 Sep 2002 00:31:03 +0300 (EEST) Message-ID: <3D7FB75D.70306@kolumbus.fi> Date: Thu, 12 Sep 2002 00:36:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pete McCann , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) References: 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 Aboba wrote: >>If you get a new ID, you just won't be able to take advantage of >>already-deployed "disk-writing" accounting servers. That's the >>disincentive for people to request the new Application ID. (I haven't read all of this thread yet, so excuse me if this has already been discussed.) I'd view the "disk-writing" accounting servers as such that they can accept any accounting information carried by ACR/ACA regardless of the application ID. It seems unnecessary to require that the disk-writing servers only accept those accounting streams where the client has explicitly required the use of a disk-writing application. We can require the right behaviour in the RFC, i.e. overriding any negative effects unnecessary acct application id tagging has. I do agree that people will probably want to get themselves an id even when they don't need one. Jari From owner-aaa-wg@merit.edu Wed Sep 11 18:15:13 2002 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 SAA26585 for ; Wed, 11 Sep 2002 18:15:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EC8C9134D; Wed, 11 Sep 2002 18:16:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3081913D1; Wed, 11 Sep 2002 18:16:02 -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 EAAB39134D for ; Wed, 11 Sep 2002 18:15:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8C4E5DDF6; Wed, 11 Sep 2002 18:15:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 706485DDF2 for ; Wed, 11 Sep 2002 18:15:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BLHKW14450; Wed, 11 Sep 2002 14:17:20 -0700 Date: Wed, 11 Sep 2002 14:17:20 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 358: Issues with references In-Reply-To: <3D7FAA56.1070901@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Well, these are good references but isn't it customary to actual refer to > these documents from somewhere in the text? The references are referred to in the new text introduced in Issue #364. From owner-aaa-wg@merit.edu Wed Sep 11 18:35:50 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26893 for ; Wed, 11 Sep 2002 18:35:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F3BD913DE; Wed, 11 Sep 2002 18:36:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E412913E1; Wed, 11 Sep 2002 18:36: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 75EF2913DE for ; Wed, 11 Sep 2002 18:36:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64BF95DDF6; Wed, 11 Sep 2002 18:36:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B5EB15DD8C for ; Wed, 11 Sep 2002 18:36:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8BLcMl15572; Wed, 11 Sep 2002 14:38:22 -0700 Date: Wed, 11 Sep 2002 14:38:21 -0700 (PDT) From: Bernard Aboba To: Stura Marco Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > All of these AVPs are not mandatory (M bit is not set) but affect the bill > (e.g SIP-Method, SIP-Media-Info, SIP-From, SIP-To, SIP-Content-Body), > consequently a billing server capable of generating the bill for the usage > of SIP services must understand these AVPs or the same accounting > information in different format (e.g. AVPs translated to CDR ASN.1 coded). I'd claim that the SIP/AAA specification has mis-classified these AVPs as non-mandatory. If the backend billing server MUST understand these AVPs, then the right thing to do is for them to have the "M" bit set as generated by the Accounting client. > 1- The billing server does not understand any AVP, it require Call Detail > Record formatted according to some other format e.g.ASN.1 coding. In this > case the Diameter accounting server, or some sort of gateway node, must > understand these AVPs, translate them in CDR (Call Detail Record) ASN.1 > coded and sends the CDR to the billing server. But if the billing server can't handle the AVPs that are being encoded, what use is it to the Accounting Server to provide them within the CDRs? It makes more sense to fix the problem by failing the capabilities negotiation, than by having the accounting server accept the packets, and generate CDRs that the billing system can't process. I am envisaging having the Accounting Server configured with the application IDs that correspond to applications that the backend billing server can process. It then exchanges these capabilities in the CER/CEA. If the Accounting client wants to do an application that isn't supported in the backend billing server, then the capabilities negotiation will fail until the Accounting Server is re-configured to handle those new applications. That seems like the right thing to me. > 2- The billing server does understand the AVPs. In this case the Diameter > accounting server does not need to understand these AVPs, it simply store > the AVPs to the disk and sends them later on to the billing server. Yes -- and so the accounting server can advertise the applications that the billing server understands and there is no issue. Note that if the Accounting Server is written correctly, the applications can just be selected from a list which can be augmented via a dictionary. That means there is no need to change code on the Accounting Server in order to support a new application, as long as no new commands are required. However, the billing server does need to be upgraded to be able to bill correctly for the new application. > In any case the end system that generate the bill, the billing server, must > understand the service specific accounting information (or AVPs) for those > services it is supposed to bill for. One clear example is the above > mentioned draft sipping-aaa-diameter, and it's very difficult to believe > that you add accounting AVPs that do not affect the bill. I'd expect that most of the AVPs would affect the bill -- that's why they were put in the spec. But not all the accounting AVPs that we have defined fit in that category. > In conclusion when you define new AVPs that carry information to charge for > the service x, either the billing server or some sort of gateway node > (between Acct. Server and BS) must understand these AVPs if you want to be > able to generate the bill for the usage of service x. Yes. > Accordingly I guess I would buy this other argument: > > if the application requires new AVPs to be present (ABNF mandatory), but > does not require the accounting server to understand them (e.g.new AVPs > don't have "M" bit set), there are no new commands and there are no > additional mechanisms defined (e.g. application state machine); a new > application Id is not required and MUST NOT be used. > > Br > Marco OK. Sounds like we agree. From owner-aaa-wg@merit.edu Thu Sep 12 03:51:58 2002 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 DAA15571 for ; Thu, 12 Sep 2002 03:51:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F4B691234; Thu, 12 Sep 2002 03:53:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 412FB91236; Thu, 12 Sep 2002 03:53: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 4B4D891234 for ; Thu, 12 Sep 2002 03:53:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3358D5DEEB; Thu, 12 Sep 2002 03:53:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 868DC5DEE9 for ; Thu, 12 Sep 2002 03:53:22 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8C7rDRc016769; Thu, 12 Sep 2002 09:53:13 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 12 Sep 2002 09:53:13 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 365: Revised Extensibility Section Date: Thu, 12 Sep 2002 09:53:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > 1.2.4 Creating New Accounting Applications > > There are services that only require Diameter accounting. > Such services need to define the AVPs carried in the ACR/ACA messages, > but do not need to define new command codes. An implementation MAY add > arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not > set) to any > command defined in an application, including vendor-specific > AVPs, without needing to define a new accounting application. Please > refer to section 11.1.1 for details. > > Application Identifiers are still required for Diameter capability > exchange. Every accounting application MUST have either an IANA > allocated Application Identifier, or a vendor specific Application > Identifier. > > Since every Diameter implementation MUST support accounting, there > is no need to advertise support for the Base accounting application > within the CER/CEA, since this is implicit. This basic accounting > support is sufficient to handle any application that uses the > ACR/ACA commands defined in this document, as long as no new > mandatory AVPs are added. A mandatory AVP is defined as one > which has the "M" bit set when sent within an accounting command, > regardless of whether it is required or optional within the ABNF for > the accounting application. Should here be mentioned also that if the basic accounting is used without any mandatory AVPs or new commands, then the base protocol defined standard accounting application Id (section 2.4) must be used in ACR/ACA commands. ..... Section 2.4 Application Identifiers Standard accounting X ..... / Harri From owner-aaa-wg@merit.edu Thu Sep 12 03:54:22 2002 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 DAA15646 for ; Thu, 12 Sep 2002 03:54:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A394791236; Thu, 12 Sep 2002 03:55:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6334491239; Thu, 12 Sep 2002 03:55:50 -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 6B49091236 for ; Thu, 12 Sep 2002 03:55:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52C655DEE5; Thu, 12 Sep 2002 03:55:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id D89055DE37 for ; Thu, 12 Sep 2002 03:55:48 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8C7tjRb017974; Thu, 12 Sep 2002 09:55:45 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 12 Sep 2002 09:52:48 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Bernard Aboba'" , marco.stura@nokia.com Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Thu, 12 Sep 2002 09:52:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > If you buy this argument, then I think the indicated fix is: > > a. Delete the "disk writing" text. > > b. Change the "Extensions" text to indicate that a new accounting > application ID is needed only when there are new commands, OR when new > AVPs defined in the application ABNF have the "M" bit set. If > there are no > new commands, and new AVPs are non-mandatory, a new > application ID MUST > NOT be used. > > c. Add text to require that in accounting > commands, the "M" bit is only set when a backend billing server MUST > support the AVP in order to issue a correct bill. If the > backend billing > server can ignore the AVP in computing the bill, then the > AVP MUST NOT > have the "M" bit set within an accounting message, even if the "M" bit > was set on that AVP within an authentication message. > > d. Add a "standard accounting application" ID so that > accounting can be > used by itself within Diameter. I can but this. I think these are clear rules. / Harri From owner-aaa-wg@merit.edu Thu Sep 12 04:03:06 2002 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 EAA15736 for ; Thu, 12 Sep 2002 04:03:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF39191239; Thu, 12 Sep 2002 04:04:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8FF191247; Thu, 12 Sep 2002 04:04: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 946B391239 for ; Thu, 12 Sep 2002 04:04:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81F2A5DEE9; Thu, 12 Sep 2002 04:04:28 -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 C6AA05DE37 for ; Thu, 12 Sep 2002 04:04:27 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8C84Pk04726 for ; Thu, 12 Sep 2002 11:04:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 11:04:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 11:04:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Thu, 12 Sep 2002 11:04:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54DA@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 360: Accounting standalone Thread-Index: AcJaMdf5Ssq64BgJQ6yUcNKa3KlsDwAARFuQ From: To: , , Cc: X-OriginalArrivalTime: 12 Sep 2002 08:04:25.0215 (UTC) FILETIME=[0288D8F0:01C25A33] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA15736 Hi Harri, > I can but this. I think these are clear rules. Sorry, I don't understand - do you mean: 'I can buy this.' ? John From owner-aaa-wg@merit.edu Thu Sep 12 04:05:14 2002 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 EAA15766 for ; Thu, 12 Sep 2002 04:05:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BF6F91247; Thu, 12 Sep 2002 04:06:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 258E091250; Thu, 12 Sep 2002 04:06:38 -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 27BA591247 for ; Thu, 12 Sep 2002 04:06:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14A255DEE5; Thu, 12 Sep 2002 04:06:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 654135DEE9 for ; Thu, 12 Sep 2002 04:06:36 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8C86WRc021622; Thu, 12 Sep 2002 10:06:33 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 12 Sep 2002 10:06:32 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'john.loughney@nokia.com'" , "Harri Hakala (LMF)" , aboba@internaut.com, marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Thu, 12 Sep 2002 10:06:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk yes, sorry my typo. / harri > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 12. syyskuuta 2002 11:04 > To: Harri.Hakala@lmf.ericsson.se; aboba@internaut.com; > marco.stura@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 360: Accounting standalone > > > Hi Harri, > > > I can but this. I think these are clear rules. > > Sorry, I don't understand - do you mean: > > 'I can buy this.' ? > > John > From owner-aaa-wg@merit.edu Thu Sep 12 04:08:21 2002 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 EAA15958 for ; Thu, 12 Sep 2002 04:08:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFCCE91250; Thu, 12 Sep 2002 04:09:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B18C59125C; Thu, 12 Sep 2002 04:09:48 -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 9335391250 for ; Thu, 12 Sep 2002 04:09:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7AD3C5DEEB; Thu, 12 Sep 2002 04:09: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 8D69F5DEE5 for ; Thu, 12 Sep 2002 04:09:46 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8C89oU22084 for ; Thu, 12 Sep 2002 11:09:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 11:09:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 11:09:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Thu, 12 Sep 2002 11:09:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54DB@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 360: Accounting standalone Thread-Index: AcJZxOTWge18JGYxQOyU/zumM5naXwAboKxA From: To: Cc: X-OriginalArrivalTime: 12 Sep 2002 08:09:45.0268 (UTC) FILETIME=[C14D0F40:01C25A33] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA15958 Hi Bernard, > There are two cases: > > 1. If the application not only requires new AVPs to be present in the > application (e.g. ABNF mandates them), but also requires the billing > server to understand them (e.g. new AVPs have "M" bit set in accounting > messages), then a new application ID is required, even if no new > commands are used, only ACR/ACA. > > 2. However, if the application requires new AVPs to be present (ABNF > mandatory), but does not require the billing server to understand them > (e.g. new AVPs don't have "M" bit set) and there are no new commands, then > I'd argue that a new application ID is not required and MUST > NOT be used. > > If you buy this argument, then I think the indicated fix is: I buy the argument. > a. Delete the "disk writing" text. > > b. Change the "Extensions" text to indicate that a new accounting > application ID is needed only when there are new commands, OR when new > AVPs defined in the application ABNF have the "M" bit set. If there are no > new commands, and new AVPs are non-mandatory, a new application ID MUST > NOT be used. > > c. Add text to require that in accounting > commands, the "M" bit is only set when a backend billing server MUST > support the AVP in order to issue a correct bill. If the backend billing > server can ignore the AVP in computing the bill, then the AVP MUST NOT > have the "M" bit set within an accounting message, even if the "M" bit > was set on that AVP within an authentication message. > > d. Add a "standard accounting application" ID so that accounting can be > used by itself within Diameter. I think this is the way to go. Also, your original issue 360 text should be added (added below for reference). Anyone oppose the inclusion of this (above & below) text? John Page 14: Change definition of Diameter Server to the following: "A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm." Section 2, page 17, first paragraph. Change the first sentence of the first paragraph to: "The base Diameter protocol may be used by itself for accounting applications, but for use in authentication and authorization it is always extended for a particular application." Section 7.1.3, Page 81, DIAMETER_UNABLE_TO_DELIVER Change "no host within the realm was available" to "no host within the realm supporting the required application was available" Page 94, last paragraph Delete the paragraph starting with "Note that the server side state machine..." This paragraph appears to be redundant with the first paragraph of page 93. From owner-aaa-wg@merit.edu Thu Sep 12 06:03:09 2002 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 GAA18081 for ; Thu, 12 Sep 2002 06:03:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67DD39125C; Thu, 12 Sep 2002 06:04:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EF9791260; Thu, 12 Sep 2002 06:04: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 9FC5E9125C for ; Thu, 12 Sep 2002 06:04:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D8475DE1F; Thu, 12 Sep 2002 06:04:28 -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 81AE85DE0F for ; Thu, 12 Sep 2002 06:04:27 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8CA4Pk07350 for ; Thu, 12 Sep 2002 13:04:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 13:04:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 13:04:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 363: IANA Considerations Issues Date: Thu, 12 Sep 2002 13:04:24 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54E1@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 363: IANA Considerations Issues Thread-Index: AcJZPg/IoekqDhC5TraPcD03jOgkngBBa/Rg From: To: , X-OriginalArrivalTime: 12 Sep 2002 10:04:26.0202 (UTC) FILETIME=[C6A843A0:01C25A43] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA18081 Hi Bernard, I think all of this is good text. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11 September, 2002 04:50 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 363: IANA Considerations Issues > > > Issue 363: IANA Considerations Issues > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: T > Priority: S > Section: 11 > Rationale/Explanation of issue: > > The IANA considerations section lacks some boilerplate. Also, > as I recall, > the agreement with the IESG was that standard AVP codes would > be allocated > via "Expert Review with Specification Required", and I would also > recommend this for non-vendor specific application IDs. > > Change Section 11 to the following: > > "This section provides guidance to the Internet Assigned > Numbers Authority > (IANA) regarding registration of values related to the > Diameter protocol, > in accordance with BCP 26 [IANA]. > > The following policies are used here with the meanings > defined in BCP 26: > "Private Use", "First Come First Served", "Expert Review", > "Specification Required", IETF Consensus", "Standards Action". > > This section explains the criteria to be used by the IANA for > assignment > of numbers within namespaces defined within this document. > > Diameter is not intended as a general purpose protocol, and > allocations > SHOULD NOT be made for purposes unrelated to authentication, > authorization > or accounting. For registration requests where a Designated > Expert should > be consulted, the responsible IESG area director should appoint the > Designated Expert. > > For registration requests requiring Expert Review, the AAA > mailing list > should be consulted." > > Section 11.1.1 AVP Code > > Change the last sentence of the first paragraph to: > > "AVP Codes 0-254 are managed separtely as RADIUS Attribute Types > [RADTYPE], while the remaining namespace is available for > assignmetn via > Expert Review with Specification Required [IANA]." > > Section 11.2.1, second to last paragraph, last sentence. > > Change to: "The range of values will have a limited lifetime, and will > eventually be reallocated within a range available for > standardization." > > Change "guarentee" to "guarantee" > > Section 11.3 Application Identifiers > > Second paragraph, add the following sentence: > > "Assignment of standards-track application IDs are by Expert > Review with > Specification Required [IANA]." > > From owner-aaa-wg@merit.edu Thu Sep 12 06:19:27 2002 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 GAA18287 for ; Thu, 12 Sep 2002 06:19:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE39391260; Thu, 12 Sep 2002 06:20:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3C9C91261; Thu, 12 Sep 2002 06:20:50 -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 EF8E391260 for ; Thu, 12 Sep 2002 06:20:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D091D5DE62; Thu, 12 Sep 2002 06:20:48 -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 E15765DE0F for ; Thu, 12 Sep 2002 06:20:47 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8CAKx720956 for ; Thu, 12 Sep 2002 13:20:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 13:20:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 13:20:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 362: Clarification of Proxy, Relay and Redirect Usage Date: Thu, 12 Sep 2002 13:20:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54E2@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 362: Clarification of Proxy, Relay and Redirect Usage Thread-Index: AcJZOoOSbtCWPtrOSU6QyXpSzD94FQBC4NoQ From: To: , X-OriginalArrivalTime: 12 Sep 2002 10:20:46.0823 (UTC) FILETIME=[0F272770:01C25A46] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA18287 Hi Bernard, I think these changes are good. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11 September, 2002 04:27 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 362: Clarification of Proxy, Relay > and Redirect > Usage > > > Issue 362: Clarification of Proxy, Relay, and Redirect Usage > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: E > Priority: S > Section: many > Rationale/Explanation of issue: > > Throughout the document, the term "proxy" is used when actually it is > intended refer to proxies, relays and redirects. Also, the > term "stateful" > is unclear; sometimes this refers to session state, sometimes to > transaction state. > > Section 2.8.1, page 24, last paragraph, change to: > > "Relays modify Diameter messages by inserting and removing routing > information, but do not modify any other portion of a message. > Relays SHOULD NOT maintain session state but MUST maintain > transaction state." > > Section 2.8.2, page 25, third paragraph, change to: > > "Proxies that wish to limit resources MUST maintain session state. > All proxies MUST maintain transaction state." > > Section 2.8.3, page 27, first paragraph, change to: > > "Since Redirect agents do not perform any application level > processing, the provide services for all Diameter applications, > and therefore MUST advertise the Relay Application Identifier." > > Page 28, first second and third paragraphs, change to: > > "End-to-end security services include confidentiality > and message origin authentication. These services are provided > by supporting AVP integrity and confidentiality between two > peers, communicating through agents. > > End-to-end security is provided via the End-to-End security > extension, described in [AAACMS]. The circumstances requiring > the use of end-to-end security are determined by policy on > each of the peers. Security policies, which are not the > subject of standardization, may be applied by next hop > Diameter peer or by destination realm. For example, where > TLS or IPsec transmission-level security is sufficient, > there may be no need for end-to-end security. > > End-to-end security policies include:" > > Page 30, last paragraph. Change > > "The End-to-End Identifier MUST NOT be modified by relay agents" > > to: > > "The End-to-End Identifier MUST NOT be modified by Diameter agents > of any kind." > > Page 49, second to last paragraph: > > Change "be sent via proxy/agent" to: > "be sent via a Diameter agent (proxy, redirect or relay)" > > Page 68, third paragraph > > Change > > "Proxiable request messages MUST also contain an > Acct-Application-Id AVP, an Auth-Application-Id AVP or a > Vendor-Specific-Application-Id AVP. A message that MUST NOT > be relayed, proxied or redirect MUST not include..." > > To: > > "Request messages that may be forwarded by Diameter agents > (proxies, redirects or relays) MUST also contain an > Acct-Application-Id AVP, an Auth-Application-Id AVP or a > Vendor-Specific-Application-Id AVP. A message that MUST NOT > be forwarded by Diameter agents (proxies, redirects or > relays) MUST not include..." > > Page 70, Section 6.1.6 > > Change: > > "A Diameter message that is able to be proxied MUST > include..." > > to: > > "A Diameter message that may be forwarded by Diameter > agents (proxies, redirects or relays) MUST include..." > > > From owner-aaa-wg@merit.edu Thu Sep 12 06:25:23 2002 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 GAA18341 for ; Thu, 12 Sep 2002 06:25:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5F5591261; Thu, 12 Sep 2002 06:26:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3A4891262; Thu, 12 Sep 2002 06:26: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 A797991261 for ; Thu, 12 Sep 2002 06:26:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E9B15DE62; Thu, 12 Sep 2002 06:26:50 -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 C48F65DE0F for ; Thu, 12 Sep 2002 06:26:49 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8CAQlk23235 for ; Thu, 12 Sep 2002 13:26:47 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 13:26:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 13:26:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Date: Thu, 12 Sep 2002 13:26:32 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54E3@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJZCf1A1AEFudXIR9SwR3CEY8zsQwBPMNgw From: To: , X-OriginalArrivalTime: 12 Sep 2002 10:26:47.0675 (UTC) FILETIME=[E63CCCB0:01C25A46] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA18341 Hi Bernard, I suggest we follow Eric's advice. Does anyone feel that we should add details about how the DiameterIdentity should be used (as suggested by Eric)? br, John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 10 September, 2002 22:40 > To: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) > > > > > ---------- Forwarded message ---------- > Date: Tue, 10 Sep 2002 10:44:32 -0400 > From: Eric Brunner-Williams in Portland Maine > To: Bernard Aboba > Cc: brunner@nic-naa.net > Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding > > Bernard, > > As an alternative, I suggest the DiameterIdentity type can be left > simply as an OctetString AVP, and reference to any charset dropped. > If you want to add details to how the DiameterIdentity value is to > be used, e.g., case-insensitive character comparison for octets in > the range 0-127, that would be consistent with 10[34/35]. > > The same issue came up recently in dnsext (unknown RDATA formats). > > The same issue has been present in provreg (character encodings other > than UTF-8 (and UTF-16) are allowed by XML, if an encoding attribute, > or a byte order mark, or both is present, EPP is specified in XML > Schema notation, and is silent on the use of character encodings other > than UTF-8 except "in environments where parser encoding support > incompatibility might have an impact on interoperability", in which > case UTF-8 is RECOMMENDED). > > Eric > > From owner-aaa-wg@merit.edu Thu Sep 12 06:41:32 2002 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 GAA18627 for ; Thu, 12 Sep 2002 06:41:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A81C191262; Thu, 12 Sep 2002 06:43:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BE1491263; Thu, 12 Sep 2002 06:43: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 515F691262 for ; Thu, 12 Sep 2002 06:42:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 311EC5DE0F; Thu, 12 Sep 2002 06:42:59 -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 434B25DDE1 for ; Thu, 12 Sep 2002 06:42:58 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8CAh9706234 for ; Thu, 12 Sep 2002 13:43:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 13:42:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 13:42:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 365: Revised Extensibility Section Date: Thu, 12 Sep 2002 13:42:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54E7@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 365: Revised Extensibility Section Thread-Index: AcJZy79iQRZcPEoMRTGNuc7OT58KngAfV2jg From: To: , X-OriginalArrivalTime: 12 Sep 2002 10:42:53.0023 (UTC) FILETIME=[25A136F0:01C25A49] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA18627 Hi Bernard, Your text seems reasonable here also. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11 September, 2002 21:46 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 365: Revised Extensibility Section > > > Issue 365: Revised Extensibility Section > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 9, 2002 > Reference: > Document: BASE-12 > Comment type: T > Priority: S > Section: 1.2 > Rationale/Explanation of issue: > > This revision is designed to clarify the issue of > extensibility to make it clear that addition of > non-mandatory AVPs does not require definition of a > new application ID. > > Replace section 1.2 with the following: > > "1.2 Approach to Extensibility > > The Diameter protocol is designed to be extensible, using > several mechanisms, including: > > - Defining new AVP values. > - Creating new AVPs > - Creating new authentication/authorization applications > - Creating new accounting applications > - Application authentication procedures > > Reuse of existing AVP values, AVPs, applications and command codes > are strongly recommended. Reuse simplifies standardization and > implementation and avoids potential interoperability issues. > > 1.2.1 Defining New AVP Values > > New applications should attempt to reuse AVPs defined in existing > applications when possible, as opposed to creating new AVPs. For AVPs > of type Enumerated an application may require a new > value to communicate some service-specific information. > > In order to allocate a new AVP value, a request MUST be > sent to IANA [IANA], along with an explanation of the new > AVP value. IANA considerations for Diameter are discussed > in Section 11. > > 1.2.2 Creating New AVPs > > When no existing AVP can be used, a new AVP should > be created. The new AVP being defined MUST use one of the > data types listed in section 4.3. > > In the event that a logical grouping of AVPs is necessary, and > multiple "groups" are possible in a given command, it is > recommended that a Grouped AVP be used (see Section 4.5). > > In order to create a new AVP, a request MUST be sent to IANA, > with a specification for the AVP. The request MUST include > the commands that would make use of the AVP. > > 1.2.3 Creating New Authentication Applications > > Every Diameter application specification MUST have an IANA assigned > Application Identifier (see section 2.4) or a vendor specific > Application Identifier. > > Should a new Diameter usage scenario find itself unable to fit > within an existing application without requiring major changes to the > specification, it may be desirable to create a new Diameter > application. Major changes to an application include: > > - Adding new AVPs to the command, which have the "M" bit set. > > - Requiring a command that has a different number of round trips > to satisfy a request (e.g. application foo has a command that > requires one round trip, but new application bar has a command > that requires two round trips to complete). > > - Adding support for an authentication method requiring definition of > new AVPs for use with the application. Since a new EAP authentication > method can be supported within Diameter without requiring new AVPs, > addition of EAP methods does not require the creation of a new > authentication > application. > > Creation of a new application should be viewed as a last resort. > 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. Please refer to section > 11.1.1 for > details. > > In order to justify allocation of a new application > identifier, Diameter > applications MUST define one Command Code, or add new > mandatory AVPs to > the ABNF. > > The expected AVPs MUST be defined in an ABNF [ABNF] grammar > (see section > 3.2). If the Diameter application has accounting requirements, it > MUST also specify the AVPs that are to be present in the Diameter > Accounting messages (see section 9.3). However, just because a new > authentication application id is required, does not imply that a new > accounting application id is required. > > When possible, a new Diameter application SHOULD reuse > existing Diameter AVPs, in order to avoid defining > multiple AVPs that carry similar information. > > 1.2.4 Creating New Accounting Applications > > There are services that only require Diameter accounting. > Such services need to define the AVPs carried in the ACR/ACA messages, > but do not need to define new command codes. An implementation MAY add > arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not > set) to any > command defined in an application, including vendor-specific > AVPs, without needing to define a new accounting application. Please > refer to section 11.1.1 for details. > > Application Identifiers are still required for Diameter capability > exchange. Every accounting application MUST have either an IANA > allocated Application Identifier, or a vendor specific Application > Identifier. > > Since every Diameter implementation MUST support accounting, there > is no need to advertise support for the Base accounting application > within the CER/CEA, since this is implicit. This basic accounting > support is sufficient to handle any application that uses the > ACR/ACA commands defined in this document, as long as no new > mandatory AVPs are added. A mandatory AVP is defined as one > which has the "M" bit set when sent within an accounting command, > regardless of whether it is required or optional within the ABNF for > the accounting application. > > The creation of a new accounting application should be viewed as a > last resort and MUST NOT be used unless a new command is defined with > the application, or new mandatory AVPs are added to the ABNF. > > Within an accounting command, setting the "M" bit implies that > the backend billing server MUST understand the AVP in order to compute > a correct bill. If the AVP is not relevant to the billing > process, when > the AVP is included within an accounting command, it MUST NOT > have the "M" bit set, even if the "M" bit is set when the same AVP is > used within other Diameter commands. > > When possible, a new Diameter accounting application SHOULD attempt > to reuse existing AVPs, in order to to avoid defining multiple AVPs > that carry similar information. > > Every Diameter accounting application specification MUST have an IANA > assigned Application Identifier (see section 2.4) or a vendor specific > Application Identifier." > > From owner-aaa-wg@merit.edu Thu Sep 12 07:30:10 2002 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 HAA19331 for ; Thu, 12 Sep 2002 07:30:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2888F91263; Thu, 12 Sep 2002 07:30:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E855091265; Thu, 12 Sep 2002 07:30:44 -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 C6AF291263 for ; Thu, 12 Sep 2002 07:30:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBF2E5DE0F; Thu, 12 Sep 2002 07:30:42 -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 5910E5DDE9 for ; Thu, 12 Sep 2002 07:30:42 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 529596A901; Thu, 12 Sep 2002 14:30:41 +0300 (EEST) Message-ID: <3D807C27.4030505@kolumbus.fi> Date: Thu, 12 Sep 2002 14:36:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: marco.stura@nokia.com, john.loughney@nokia.com, Harri.Hakala@lmf.ericsson.se, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 360: Accounting standalone References: 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 think the most serious issue we have in the current specifications is what Marco brought up, i.e., that credit control -like applications are not compatible with the disk-writing approach. For this reason, it makes sense to make it the choice of the application specification whether or not fallback to "disk-writing" is allowed or not. This is essentially what deleting the disk-writing text and adding a base accounting application id accomplishes. However, I'm pretty uncertain whether the "M" bit approach is the right one. Remember that billing is a process inherently guided by a policy. How would we as accounting-application-writers know whether a particular field from the SIP protocol is or is not going to be necessary for printing the bill? The answer is that we do not, and any information specified in the application standard *could* be used. Furthermore, the information about whether the AVPs are mandatory in a specific business case is something that only the home network knows. Therefore, it is hard for us to do anything else than to declare most accounting AVPs mandatory, and then have the client set the bits. According to the rules below this would lead to the situation where the basic accounting application is used by almost no one. This is undesirable since in many cases the basic accounting application would in fact be sufficient as long as the record reached the right server. On the other hand, the combination of the home domain and the accounting application Id would act as a convenient routing mechanisms to get to the dial-in/wlan/3g department accounting servers. In conclusion my main concern is that there'll be new applications and we'll be under the mercy of the negotiation process. And I need to get vendor X's server to get it to work with their client, if they chose to invent a new application ID -- even if *I* think I can handle it with my disk-writing basic accounting mechanism. But perhaps there's an easy fix to this. We could require that all implementations of DIAMETER basic accounting must be _configurable_ to advertise a specific accounting application support. This would mean that we lose the automatic fallback to disk-writing server (but for a good reason noted by Marco). Instead, we have a human-controlled process. Jari Bernard Aboba wrote: > 1. If the application not only requires new AVPs to be present in the > application (e.g. ABNF mandates them), but also requires the billing > server to understand them (e.g. new AVPs have "M" bit set in accounting > messages), then a new application ID is required, even if no new > commands are used, only ACR/ACA. > > 2. However, if the application requires new AVPs to be present (ABNF > mandatory), but does not require the billing server to understand them > (e.g. new AVPs don't have "M" bit set) and there are no new commands, then > I'd argue that a new application ID is not required and MUST NOT be used. > > If you buy this argument, then I think the indicated fix is: > > a. Delete the "disk writing" text. > > b. Change the "Extensions" text to indicate that a new accounting > application ID is needed only when there are new commands, OR when new > AVPs defined in the application ABNF have the "M" bit set. If there are no > new commands, and new AVPs are non-mandatory, a new application ID MUST > NOT be used. > > c. Add text to require that in accounting > commands, the "M" bit is only set when a backend billing server MUST > support the AVP in order to issue a correct bill. If the backend billing > server can ignore the AVP in computing the bill, then the AVP MUST NOT > have the "M" bit set within an accounting message, even if the "M" bit > was set on that AVP within an authentication message. > > d. Add a "standard accounting application" ID so that accounting can be > used by itself within Diameter. From owner-aaa-wg@merit.edu Thu Sep 12 08:43:00 2002 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 IAA21343 for ; Thu, 12 Sep 2002 08:42:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AF3491266; Thu, 12 Sep 2002 08:44:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1483691267; Thu, 12 Sep 2002 08:44:27 -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 EA64291266 for ; Thu, 12 Sep 2002 08:44:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C44DC5DE6F; Thu, 12 Sep 2002 08:44:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from emily.fle.fujitsu.com (unknown [193.122.18.249]) by segue.merit.edu (Postfix) with SMTP id 449585DDE9 for ; Thu, 12 Sep 2002 08:44:25 -0400 (EDT) Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Thu, 12 Sep 2002 13:45:12 +0100 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59) id ; Thu, 12 Sep 2002 13:41:57 +0100 Message-ID: From: Xin Chen To: "'Jari Arkko (LMF)'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Question on Diameter Extensible Authentication Protocol (EAP) App lication Date: Thu, 12 Sep 2002 13:41:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e677f144-ab41-425b-9e6f-51d907626e8e" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-e677f144-ab41-425b-9e6f-51d907626e8e Content-Type: text/plain Dear all, The draft (Diameter Extensible Authentication Protocol (EAP) Application) only defines two messages Diameter-EAP-Request (DER) Command and Diameter-EAP-Answer (DEA) Command between the access device and the Diameter home server. I think that in the case that the EAP client is powered off or out of radio coverage (wireless environment), then we also need a Diameter message sent from the access device to the Diameter home server to terminate this diameter session. The indication of those events can be provided by link layer technologies. If so, is this message specified by this draft or from the base protocol. I have taken a look at the base protocol, there are two which could be used: Disconnect-Peer-Request (sent from access device to Diameter home server) Or Session-Termination-Request (sent from access device to Diameter home server), and I think the latter one is the right one to send. Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 -----Original Message----- From: Jari Arkko (LMF) [mailto:Jari.Arkko@lmf.ericsson.se] Sent: 12 September 2002 07:52 To: 'Xin Chen'; 'ietf-ppp@merit.edu'; 'aaa-wg@merit.edu' Subject: RE: Question on EAP This does not seem to be an EAP related function as such. If the given link layer technology gives you an indication of "power off" in some manner, then the access network or the authenticator can send a RADIUS accounting stop or similar message to the home network. So, I don't think EAP is involved. Both RADIUS accounting and DIAMETER should be able to support such notifications in the AAA space. I'm not sure how well WLAN allows you to detect the power-off of a terminal and distinguish it from temporary radio disturbances. Jari -----Original Message----- From: Xin Chen [mailto:x.chen@fle.fujitsu.com] Sent: 10. syyskuuta 2002 12:33 To: 'ietf-ppp@merit.edu'; 'aaa-wg@merit.edu' Subject: Question on EAP Dear all, Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below, An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided. And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal). The question is does the current WLAN technologies and EAP protocol support this operation. Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 ------=_NextPartTM-000-e677f144-ab41-425b-9e6f-51d907626e8e Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and FLE. ------=_NextPartTM-000-e677f144-ab41-425b-9e6f-51d907626e8e-- From owner-aaa-wg@merit.edu Thu Sep 12 08:47:48 2002 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 IAA21516 for ; Thu, 12 Sep 2002 08:47:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E8A5A91267; Thu, 12 Sep 2002 08:49:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B45B291269; Thu, 12 Sep 2002 08:49: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 A5E9991267 for ; Thu, 12 Sep 2002 08:47:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F74D5DE78; Thu, 12 Sep 2002 08:47:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EE3765DE75 for ; Thu, 12 Sep 2002 08:47:42 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8CBnCG31144; Thu, 12 Sep 2002 04:49:12 -0700 Date: Thu, 12 Sep 2002 04:49:11 -0700 (PDT) From: Bernard Aboba To: "Harri Hakala (LMF)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 365: Revised Extensibility Section In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Should here be mentioned also that if the basic accounting is used > without any mandatory AVPs or new commands, then the base protocol defined > standard accounting application Id (section 2.4) must be used in ACR/ACA > commands. Yes. Have added the following text to the recommended changes for #365: "The creation of a new accounting application should be viewed as a last resort and MUST NOT be used unless a new command is defined with the application, or new mandatory AVPs are added to the ABNF. If a Diameter accounting application requires no new mandatory AVPs and no new commands (only ACR/ACA are used), then the standard accounting application Id (section 2.4) MUST be used in ACR/ACA commands." From owner-aaa-wg@merit.edu Thu Sep 12 08:53:29 2002 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 IAA21637 for ; Thu, 12 Sep 2002 08:53:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41E2391269; Thu, 12 Sep 2002 08:54:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F8FD9126A; Thu, 12 Sep 2002 08:54:55 -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 15C7D91269 for ; Thu, 12 Sep 2002 08:54:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E840B5DE6F; Thu, 12 Sep 2002 08:54:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 78E985DDE9 for ; Thu, 12 Sep 2002 08:54:54 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8CBuM931503; Thu, 12 Sep 2002 04:56:23 -0700 Date: Thu, 12 Sep 2002 04:56:22 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54E3@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Hi Bernard, > > I suggest we follow Eric's advice. > > Does anyone feel that we should add details about how the DiameterIdentity > should be used (as suggested by Eric)? I agree with Eric's suggestion. Here is the suggested fix: 1. Change the following AVPs that use UTF8String to type DiameterIdentity: Origin-Realm AVP (6.4) Destination-Realm AVP (6.6) 2. Change the definition of DiameterIdentity to OctetString. 3. Change the type of IPFilterRule and QoSFilterRule to ASCII instead of UTF-8. From owner-aaa-wg@merit.edu Thu Sep 12 08:54:08 2002 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 IAA21659 for ; Thu, 12 Sep 2002 08:54:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BE319126A; Thu, 12 Sep 2002 08:55:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9A6A9126B; Thu, 12 Sep 2002 08:55:38 -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 DE10E9126A for ; Thu, 12 Sep 2002 08:55:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C45A65DE6F; Thu, 12 Sep 2002 08:55:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5BC3E5DDE9 for ; Thu, 12 Sep 2002 08:55:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8CBv6f31534; Thu, 12 Sep 2002 04:57:06 -0700 Date: Thu, 12 Sep 2002 04:57:06 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 365: Revised Extensibility Section In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54E7@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk To accomodate comments, I've made some slight changes, which will be reflected in the text up on the website. On Thu, 12 Sep 2002 john.loughney@nokia.com wrote: > Hi Bernard, > > Your text seems reasonable here also. > > John From owner-aaa-wg@merit.edu Thu Sep 12 09:02:26 2002 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 JAA21998 for ; Thu, 12 Sep 2002 09:02:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89DC19126C; Thu, 12 Sep 2002 09:03:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 578CC91271; Thu, 12 Sep 2002 09:03: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 4D82D9126C for ; Thu, 12 Sep 2002 09:03:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39DC75DDE6; Thu, 12 Sep 2002 09:03:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8C7635DDB1 for ; Thu, 12 Sep 2002 09:03:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8CC4c332045; Thu, 12 Sep 2002 05:04:38 -0700 Date: Thu, 12 Sep 2002 05:04:38 -0700 (PDT) From: Bernard Aboba To: Stura Marco Cc: aaa-wg@merit.edu, Subject: Re: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've added your suggestions to the text for #365. On Thu, 12 Sep 2002, Stura Marco wrote: > Hi, > > > > if the application requires new AVPs to be present (ABNF mandatory), but > > > does not require the accounting server to understand them (e.g.new AVPs > > > don't have "M" bit set), there are no new commands and there are no > > > additional mechanisms defined (e.g. application state machine); a new > > > application Id is not required and MUST NOT be used. > > Yes sounds like we agree. But it would be nice if you address all of these > topics in the solution to this issue: > > 1- Mandatory AVP (e.g. M bit set) > 2- New command > 3- Application define additional mechanisms (e.g. application state machine) > > In the text you propose for the solution 1 and 2 are fine, it might be good > to add some word also about 3. > I would slightly modify you proposed text as follow: > > "1.2.4 Creating New Accounting Applications > > There are services that only require Diameter accounting. > Such services need to define the AVPs carried in the ACR/ACA messages, > but do not need to define new command codes. An implementation MAY add > arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not set) to any > command defined in an application, including vendor-specific > AVPs, without needing to define a new accounting application. Please > refer to section 11.1.1 for details. > > Application Identifiers are still required for Diameter capability > exchange. Every accounting application MUST have either an IANA > allocated Application Identifier, or a vendor specific Application > Identifier. > > Since every Diameter implementation MUST support accounting, there > is no need to advertise support for the Base accounting application > within the CER/CEA, since this is implicit. This basic accounting > support is sufficient to handle any application that uses the > ACR/ACA commands defined in this document, as long as no new > mandatory AVPs are added. A mandatory AVP is defined as one > which has the "M" bit set when sent within an accounting command, > regardless of whether it is required or optional within the ABNF for > the accounting application. > > The creation of a new accounting application should be viewed as a > last resort and MUST NOT be used unless a new command or additional > mechanisms (e.g. application defined state machine)is defined within > the application, or new mandatory AVPs are added to the ABNF. > > Within an accounting command, setting the "M" bit implies that > the backend billing server or the accounting server it self MUST understand > the AVP in order to compute > a correct bill. If the AVP is not relevant to the billing process, when > the AVP is included within an accounting command, it MUST NOT > have the "M" bit set, even if the "M" bit is set when the same AVP is > used within other Diameter commands (i.e. authentication/authorization > commands). > > When possible, a new Diameter accounting application SHOULD attempt > to reuse existing AVPs, in order to avoid defining multiple AVPs > that carry similar information. > > Every Diameter accounting application specification MUST have an IANA > assigned Application Identifier (see section 2.4) or a vendor specific > Application Identifier. > > If the base accounting is used without any mandatory AVPs, new commands or > additional mechanisms (e.g. application defined state machine), then the > base protocol defined standard accounting application Id (section 2.4) must > be used in ACR/ACA commands." > > Br > Marco > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > From owner-aaa-wg@merit.edu Thu Sep 12 09:06:27 2002 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 JAA22212 for ; Thu, 12 Sep 2002 09:06:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2582D91279; Thu, 12 Sep 2002 09:07:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF94691271; Thu, 12 Sep 2002 09:07:41 -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 DF30091271 for ; Thu, 12 Sep 2002 09:05:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C08935DDE6; Thu, 12 Sep 2002 09:05:18 -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 D3DCB5DDB1 for ; Thu, 12 Sep 2002 09:05:17 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8CD5LU09902 for ; Thu, 12 Sep 2002 16:05:21 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 16:03:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 16:03:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 352 - closed Date: Thu, 12 Sep 2002 16:03:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54F1@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 365: Revised Extensibility Section Thread-Index: AcJaW7Nmy/4lv7NqR32IsDyNy8h+agAAOIew From: To: Cc: X-OriginalArrivalTime: 12 Sep 2002 13:03:13.0389 (UTC) FILETIME=[C08F19D0:01C25A5C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22212 Hi all, Please consider issue 352 to be closed as issue 365 takes care of points raised in it. John From owner-aaa-wg@merit.edu Thu Sep 12 09:06:28 2002 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 JAA22225 for ; Thu, 12 Sep 2002 09:06:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E8F4E91278; Thu, 12 Sep 2002 09:07:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A4199126E; Thu, 12 Sep 2002 09:07:41 -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 C26FD91278 for ; Thu, 12 Sep 2002 09:06:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BC365DDE6; Thu, 12 Sep 2002 09:06:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id F333A5DDB1 for ; Thu, 12 Sep 2002 09:06:04 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8CD61Rb025481; Thu, 12 Sep 2002 15:06:01 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 12 Sep 2002 15:06:00 +0200 Message-ID: From: "Harri Hakala (LMF)" To: "'Jari Arkko'" , Bernard Aboba Cc: marco.stura@nokia.com, john.loughney@nokia.com, "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 360: Accounting standalone Date: Thu, 12 Sep 2002 15:05:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk I but also this ;-) Seriously, I think that in pre-paid case the accounting server should understand at least some of the AVPs ('control' and 'rating' AVPs) in real time (i.e. "M" bit approach makes sense) and but in post-paid case the accounting server does not necessarily need to interpret these AVPs, but even in post-paid case in some point you need an instance (e.g. billing system) which knows the meaning of the AVPs, when it prepares the bill. But in the latter case it depends case by case (based on operators billing policy) which AVPs are mandatory for bill. / Harri > Jari Arkko wrote: > > I think the most serious issue we have in the current specifications > is what Marco brought up, i.e., that credit control -like applications > are not compatible with the disk-writing approach. For this reason, it > makes sense to make it the choice of the application specification > whether or not fallback to "disk-writing" is allowed or not. This is > essentially what deleting the disk-writing text and adding a base > accounting application id accomplishes. > > However, I'm pretty uncertain whether the "M" bit approach is the > right one. Remember that billing is a process inherently guided by > a policy. How would we as accounting-application-writers know whether > a particular field from the SIP protocol is or is not going to be > necessary for printing the bill? The answer is that we do not, and > any information specified in the application standard *could* be > used. Furthermore, the information about whether the AVPs are > mandatory in a specific business case is something that only the > home network knows. Therefore, it is hard for us to do anything > else than to declare most accounting AVPs mandatory, and then > have the client set the bits. According to the rules below > this would lead to the situation where the basic accounting > application is used by almost no one. > > This is undesirable since in many cases the basic accounting > application would in fact be sufficient as long as the > record reached the right server. On the other hand, the combination > of the home domain and the accounting application Id would > act as a convenient routing mechanisms to get to the dial-in/wlan/3g > department accounting servers. > > In conclusion my main concern is that there'll be new applications > and we'll be under the mercy of the negotiation process. And I > need to get vendor X's server to get it to work with their client, > if they chose to invent a new application ID -- even if *I* think > I can handle it with my disk-writing basic accounting mechanism. > > But perhaps there's an easy fix to this. We could require that > all implementations of DIAMETER basic accounting must be > _configurable_ > to advertise a specific accounting application support. > > This would mean that we lose the automatic fallback to disk-writing > server (but for a good reason noted by Marco). Instead, we have > a human-controlled process. > > Jari > > Bernard Aboba wrote: > > > 1. If the application not only requires new AVPs to be > present in the > > application (e.g. ABNF mandates them), but also requires the billing > > server to understand them (e.g. new AVPs have "M" bit set > in accounting > > messages), then a new application ID is required, even if no new > > commands are used, only ACR/ACA. > > > > 2. However, if the application requires new AVPs to be present (ABNF > > mandatory), but does not require the billing server to > understand them > > (e.g. new AVPs don't have "M" bit set) and there are no new > commands, then > > I'd argue that a new application ID is not required and > MUST NOT be used. > > > > If you buy this argument, then I think the indicated fix is: > > > > a. Delete the "disk writing" text. > > > > b. Change the "Extensions" text to indicate that a new accounting > > application ID is needed only when there are new commands, > OR when new > > AVPs defined in the application ABNF have the "M" bit set. > If there are no > > new commands, and new AVPs are non-mandatory, a new > application ID MUST > > NOT be used. > > > > c. Add text to require that in accounting > > commands, the "M" bit is only set when a backend billing server MUST > > support the AVP in order to issue a correct bill. If the > backend billing > > server can ignore the AVP in computing the bill, then the > AVP MUST NOT > > have the "M" bit set within an accounting message, even if > the "M" bit > > was set on that AVP within an authentication message. > > > > d. Add a "standard accounting application" ID so that > accounting can be > > used by itself within Diameter. > > > From owner-aaa-wg@merit.edu Thu Sep 12 09:28:50 2002 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 JAA22807 for ; Thu, 12 Sep 2002 09:28:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1486691271; Thu, 12 Sep 2002 09:30:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2E1B9127C; Thu, 12 Sep 2002 09:30: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 4947A91271 for ; Thu, 12 Sep 2002 09:30:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6B5F5DDB1; Thu, 12 Sep 2002 09:30:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 06D295DD90 for ; Thu, 12 Sep 2002 09:30:01 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g8CDTjVn023970; Thu, 12 Sep 2002 09:29:46 -0400 (EDT) Received: from localhost (tari.research.telcordia.com [207.3.232.66]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA22921; Thu, 12 Sep 2002 09:30:10 -0400 (EDT) Date: Thu, 12 Sep 2002 09:29:42 -0400 To: Bernard Aboba Cc: Stura Marco , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 360: Accounting standalone Message-ID: <20020912132941.GA1503@catfish> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 30 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Sep 11, 2002 at 02:38:21PM -0700, Bernard Aboba wrote: > > All of these AVPs are not mandatory (M bit is not set) but affect the bill > > (e.g SIP-Method, SIP-Media-Info, SIP-From, SIP-To, SIP-Content-Body), > > consequently a billing server capable of generating the bill for the usage > > of SIP services must understand these AVPs or the same accounting > > information in different format (e.g. AVPs translated to CDR ASN.1 coded). > > I'd claim that the SIP/AAA specification has mis-classified these AVPs as > non-mandatory. If the backend billing server MUST understand these AVPs, > then the right thing to do is for them to have the "M" bit set as > generated by the Accounting client. > I agree that "M" bit is needed if an accounting server must be able to process (inside the Diameter protocol) the AVP to support a particular accounting application (e.g., prepaid). However, I don't think "M" bit is needed for a backend billing server to be able to process billing outside the Diameter protocol, since accounting and billing are closely related but they are different things. I think the right thing to do in this case is that the implementation of an accouning server must be able to record all AVPs regardless whether "M" bit is set or not (and regardless of whether it does not support AVPs that do not have "M" bit set), and pass them to the billing server and let the billing server choose whatever AVPs needed for creating appropriate bills. I think this is natural because the accounting server basically does not know which information is used by the billing server. Yoshihiro Ohba From owner-aaa-wg@merit.edu Thu Sep 12 10:48:24 2002 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 KAA25398 for ; Thu, 12 Sep 2002 10:48:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFD0891292; Thu, 12 Sep 2002 10:49:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7476A9128E; Thu, 12 Sep 2002 10:49: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 9E08B91292 for ; Thu, 12 Sep 2002 10:48:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 810C15DE20; Thu, 12 Sep 2002 10:48:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail2.firewall.lucent.com (unknown [192.11.223.163]) by segue.merit.edu (Postfix) with ESMTP id E5FE05DD90 for ; Thu, 12 Sep 2002 10:48:23 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8CEm9Z11537; Thu, 12 Sep 2002 10:48:09 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA15166; Thu, 12 Sep 2002 09:48:08 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H2BYG6-0000RC-00; Thu, 12 Sep 2002 10:48:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15744.43300.81205.949790@gargle.gargle.HOWL> Date: Thu, 12 Sep 2002 09:48:04 -0500 From: Pete McCann To: Cc: , Subject: [AAA-WG]: Issue 352 - closed In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54F1@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A54F1@esebe004.ntc.nokia.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Did we resolve the IANA considerations issue for the experimental (vendor-specific) Application ID allocation? Bernard's text does not directly address this issue. -Pete john.loughney@nokia.com writes: > Hi all, > > Please consider issue 352 to be closed as issue 365 takes care of > points raised in it. > > John From owner-aaa-wg@merit.edu Thu Sep 12 13:17:12 2002 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 NAA29976 for ; Thu, 12 Sep 2002 13:17:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 911C691245; Thu, 12 Sep 2002 13:18:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 509439128C; Thu, 12 Sep 2002 13:18: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 3EFF891245 for ; Thu, 12 Sep 2002 13:18:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C7BB5DE43; Thu, 12 Sep 2002 13:18:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A999F5DDE6 for ; Thu, 12 Sep 2002 13:18:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8CGK0k13638; Thu, 12 Sep 2002 09:20:00 -0700 Date: Thu, 12 Sep 2002 09:20:00 -0700 (PDT) From: Bernard Aboba To: Yoshihiro Ohba Cc: Stura Marco , Subject: Re: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <20020912132941.GA1503@catfish> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think the right > thing to do in this case is that the implementation of an accouning > server must be able to record all AVPs regardless whether "M" bit is > set or not (and regardless of whether it does not support AVPs that do > not have "M" bit set), and pass them to the billing server and let the > billing server choose whatever AVPs needed for creating appropriate > bills. I think this is natural because the accounting server > basically does not know which information is used by the billing > server. However, if the admins of the accounting server do know what the billing system can handle, then they can configure the accounting server with the set of application IDs corresponding to those supported services. That way, they won't accept accounting packets containing unbillable services, which saves headaches down the line (like not getting paid for authorized sessions). From owner-aaa-wg@merit.edu Thu Sep 12 15:06:44 2002 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 PAA03957 for ; Thu, 12 Sep 2002 15:06:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8DD7912D1; Thu, 12 Sep 2002 15:06:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 393D0912D4; Thu, 12 Sep 2002 15:06:25 -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 3770C912D1 for ; Thu, 12 Sep 2002 15:06:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC7F95DE43; Thu, 12 Sep 2002 15:06:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 87B2E5DDE1 for ; Thu, 12 Sep 2002 15:06:16 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g8CJ65Vn020818; Thu, 12 Sep 2002 15:06:05 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA23950; Thu, 12 Sep 2002 15:06:29 -0400 (EDT) Date: Thu, 12 Sep 2002 15:05:56 -0400 To: Bernard Aboba Cc: Yoshihiro Ohba , Stura Marco , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 360: Accounting standalone Message-ID: <20020912190556.GA706@catfish> References: <20020912132941.GA1503@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 28 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Sep 12, 2002 at 09:20:00AM -0700, Bernard Aboba wrote: > > I think the right > > thing to do in this case is that the implementation of an accouning > > server must be able to record all AVPs regardless whether "M" bit is > > set or not (and regardless of whether it does not support AVPs that do > > not have "M" bit set), and pass them to the billing server and let the > > billing server choose whatever AVPs needed for creating appropriate > > bills. I think this is natural because the accounting server > > basically does not know which information is used by the billing > > server. > > However, if the admins of the accounting server do know what the billing > system can handle, then they can configure the accounting server with the > set of application IDs corresponding to those supported services. That > way, they won't accept accounting packets containing unbillable services, > which saves headaches down the line (like not getting paid for authorized > sessions). > I agree that such optimization is possible if the accounting server has some knowledge (by configuration) about billing. But I think this still does not necessarily mean that the billing server should accept only AVPs with "M" bit set. Anyway, I agree with the proposed text for Issue 360. Yoshihiro Ohba From owner-aaa-wg@merit.edu Thu Sep 12 15:23:17 2002 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 PAA04509 for ; Thu, 12 Sep 2002 15:23:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B022912D5; Thu, 12 Sep 2002 15:24:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FEE7912D7; Thu, 12 Sep 2002 15:24: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 468B5912D5 for ; Thu, 12 Sep 2002 15:24:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A9985DE78; Thu, 12 Sep 2002 15:24:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 975BB5DE6F for ; Thu, 12 Sep 2002 15:24:43 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8CIPxi20533; Thu, 12 Sep 2002 11:25:59 -0700 Date: Thu, 12 Sep 2002 11:25:59 -0700 (PDT) From: Bernard Aboba To: Yoshihiro Ohba Cc: Stura Marco , Subject: Re: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: <20020912190556.GA706@catfish> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree that such optimization is possible if the accounting server > has some knowledge (by configuration) about billing. But I think this > still does not necessarily mean that the billing server should accept > only AVPs with "M" bit set. I agree. The accounting server should be able to accept new AVPs without the "M" bit set, since if the Billing Server can't handle them, it is free to ignore them. > > Anyway, I agree with the proposed text for Issue 360. Good. From owner-aaa-wg@merit.edu Fri Sep 13 04:53:14 2002 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 EAA28932 for ; Fri, 13 Sep 2002 04:53:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCE32912EF; Fri, 13 Sep 2002 04:54:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 901F0912F4; Fri, 13 Sep 2002 04:54: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 55B0B912EF for ; Fri, 13 Sep 2002 04:54:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37EEB5DEFB; Fri, 13 Sep 2002 04:54:41 -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 7913F5DE7E for ; Fri, 13 Sep 2002 04:54:40 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8D8sqZ07560 for ; Fri, 13 Sep 2002 11:54:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 11:54:39 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 11:54:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Date: Fri, 13 Sep 2002 11:54:38 +0300 Message-ID: <07A6D72550C5E0459DE676439EE53846E32C5A@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBg From: To: , Cc: X-OriginalArrivalTime: 13 Sep 2002 08:54:38.0977 (UTC) FILETIME=[314A2F10:01C25B03] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28932 Hi! Bernard Aboba wrote: > 1. Change the following AVPs that use UTF8String to type > DiameterIdentity: > > Origin-Realm AVP (6.4) > Destination-Realm AVP (6.6) > > 2. Change the definition of DiameterIdentity to OctetString. Shouldn't DiameterIdentity, i.e. fqdn still be considered "text"? If the fqdn is not UTF-8 encoded I think it should be ASCII encoded. Data contained in AVP-type derived from OctetString does not necessarily contain ASCII encoded data. Or am I missing something here? BR, Mikko From owner-aaa-wg@merit.edu Fri Sep 13 05:17:18 2002 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 FAA29364 for ; Fri, 13 Sep 2002 05:17:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79935912F4; Fri, 13 Sep 2002 05:18:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AD68912F6; Fri, 13 Sep 2002 05:18:46 -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 DD4D0912F4 for ; Fri, 13 Sep 2002 05:18:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC1E35DE31; Fri, 13 Sep 2002 05:18:11 -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 0223B5DE07 for ; Fri, 13 Sep 2002 05:18:10 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8D9IDU15709 for ; Fri, 13 Sep 2002 12:18:14 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 12:16:43 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 12:16:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Date: Fri, 13 Sep 2002 12:16:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5505@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCA= From: To: , Cc: X-OriginalArrivalTime: 13 Sep 2002 09:16:43.0119 (UTC) FILETIME=[468A37F0:01C25B06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA29364 Hi Mikko, > Bernard Aboba wrote: > > 1. Change the following AVPs that use UTF8String to type > > DiameterIdentity: > > > > Origin-Realm AVP (6.4) > > Destination-Realm AVP (6.6) > > > > 2. Change the definition of DiameterIdentity to OctetString. > > > Shouldn't DiameterIdentity, i.e. fqdn still be considered "text"? > > If the fqdn is not UTF-8 encoded I think it should be ASCII encoded. > Data contained in AVP-type derived from OctetString does not > necessarily contain ASCII encoded data. > > Or am I missing something here? From the original message: FQDNs are to be encoded as specified by the Internationalized Domain Name (IDN) specification, not UTF-8. For example, see: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-11.txt and also below are comments from the IESG. Do you seen any interoperability problems with the text Bernard has suggested? John ---------- Forwarded message ---------- Date: Tue, 10 Sep 2002 10:44:32 -0400 From: Eric Brunner-Williams in Portland Maine To: Bernard Aboba Cc: brunner@nic-naa.net Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding Bernard, As an alternative, I suggest the DiameterIdentity type can be left simply as an OctetString AVP, and reference to any charset dropped. If you want to add details to how the DiameterIdentity value is to be used, e.g., case-insensitive character comparison for octets in the range 0-127, that would be consistent with 10[34/35]. The same issue came up recently in dnsext (unknown RDATA formats). The same issue has been present in provreg (character encodings other than UTF-8 (and UTF-16) are allowed by XML, if an encoding attribute, or a byte order mark, or both is present, EPP is specified in XML Schema notation, and is silent on the use of character encodings other than UTF-8 except "in environments where parser encoding support incompatibility might have an impact on interoperability", in which case UTF-8 is RECOMMENDED). Eric From owner-aaa-wg@merit.edu Fri Sep 13 06:11:02 2002 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 GAA00036 for ; Fri, 13 Sep 2002 06:11:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADC9D912F7; Fri, 13 Sep 2002 06:12:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F352912F9; Fri, 13 Sep 2002 06:12: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 48D7A912F7 for ; Fri, 13 Sep 2002 06:12:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2976D5DE3D; Fri, 13 Sep 2002 06:12:30 -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 6D4265DE07 for ; Fri, 13 Sep 2002 06:12:29 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DACWU15862 for ; Fri, 13 Sep 2002 13:12:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 13:09:26 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 13:09:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Date: Fri, 13 Sep 2002 13:09:26 +0300 Message-ID: <07A6D72550C5E0459DE676439EE53846E32C5B@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0A== From: To: , Cc: X-OriginalArrivalTime: 13 Sep 2002 10:09:26.0841 (UTC) FILETIME=[A443E290:01C25B0D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA00036 Hi! John Loughney wrote: > Do you seen any interoperability problems with the text Bernard > has suggested? I'm sorry, but I'm not sure what exactly is the current proposal for the format of DiameterIdentity. Are we mandating that all Diameter-boxes must support IDNs and the encodings described in IDNA-draft? What is the status of IDNA-draft and the related drafts? Can we reference to them from Diameter Base RFC? Then a simple question, just to make sure if I have interpretet all this correctly: Is it still ok to put, for example, host.abc.com ASCII encoded to Origin- and Destination-Host AVPs? I guess it wouldn't hurt to put couple examples of valid contents of DiameterIdentity to the draft. BR, Mikko > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: 13 September, 2002 12:17 > To: Aittola Mikko (NET/Helsinki); aboba@internaut.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) > > > Hi Mikko, > > > Bernard Aboba wrote: > > > 1. Change the following AVPs that use UTF8String to type > > > DiameterIdentity: > > > > > > Origin-Realm AVP (6.4) > > > Destination-Realm AVP (6.6) > > > > > > 2. Change the definition of DiameterIdentity to OctetString. > > > > > > Shouldn't DiameterIdentity, i.e. fqdn still be considered "text"? > > > > If the fqdn is not UTF-8 encoded I think it should be ASCII encoded. > > Data contained in AVP-type derived from OctetString does not > > necessarily contain ASCII encoded data. > > > > Or am I missing something here? > > From the original message: > > FQDNs are to be encoded as specified by the > Internationalized Domain Name > (IDN) specification, not UTF-8. For example, see: > > http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-11.txt > > and also below are comments from the IESG. > > Do you seen any interoperability problems with the text Bernard > has suggested? > > John From owner-aaa-wg@merit.edu Fri Sep 13 08:32:13 2002 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 IAA03041 for ; Fri, 13 Sep 2002 08:32:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 946F491302; Fri, 13 Sep 2002 08:33:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BD45912FF; Fri, 13 Sep 2002 08:33:37 -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 4CBFA91302 for ; Fri, 13 Sep 2002 08:32:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BE395DF02; Fri, 13 Sep 2002 08:32:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1B3475DF01 for ; Fri, 13 Sep 2002 08:32:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8DBXZC13096; Fri, 13 Sep 2002 04:33:35 -0700 Date: Fri, 13 Sep 2002 04:33:35 -0700 (PDT) From: Bernard Aboba To: Stura Marco Cc: yohba@tari.toshiba.com, Subject: Re: [AAA-WG]: Issue 360: Accounting standalone In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I will modify the text for issue #365 to incorporate this. On Fri, 13 Sep 2002, Stura Marco wrote: > Hi, > > sounds good, but perhaps It is better to add some text according to the Jari > Arkko suggestion. > > Jari wrote > > " > But perhaps there's an easy fix to this. We could require that > all implementations of DIAMETER basic accounting must be _configurable_ > to advertise a specific accounting application support." > > Would you agree to update text for the issue #365 as follow? > > Br > Marco From owner-aaa-wg@merit.edu Fri Sep 13 08:47:05 2002 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 IAA03482 for ; Fri, 13 Sep 2002 08:47:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76E5C912FF; Fri, 13 Sep 2002 08:48:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35C9D91303; Fri, 13 Sep 2002 08:48:38 -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 50AD9912FF for ; Fri, 13 Sep 2002 08:46:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FAB95DF01; Fri, 13 Sep 2002 08:46:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8D2F65DE88 for ; Fri, 13 Sep 2002 08:46:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8DBm5e13898; Fri, 13 Sep 2002 04:48:05 -0700 Date: Fri, 13 Sep 2002 04:48:05 -0700 (PDT) From: Bernard Aboba To: mikko.aittola@nokia.com Cc: john.loughney@nokia.com, Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) In-Reply-To: <07A6D72550C5E0459DE676439EE53846E32C5A@esebe012.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk That was my original suggestion, but Eric Brunner-Williams provided us with some background on how this has been handled in the past. Do you have a suggestion for additional text that would make this more clear? ---------- Forwarded message ---------- Date: Tue, 10 Sep 2002 10:44:32 -0400 From: Eric Brunner-Williams in Portland Maine To: Bernard Aboba Cc: brunner@nic-naa.net Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding Bernard, As an alternative, I suggest the DiameterIdentity type can be left simply as an OctetString AVP, and reference to any charset dropped. If you want to add details to how the DiameterIdentity value is to be used, e.g., case-insensitive character comparison for octets in the range 0-127, that would be consistent with 10[34/35]. The same issue came up recently in dnsext (unknown RDATA formats). The same issue has been present in provreg (character encodings other than UTF-8 (and UTF-16) are allowed by XML, if an encoding attribute, or a byte order mark, or both is present, EPP is specified in XML Schema notation, and is silent on the use of character encodings other than UTF-8 except "in environments where parser encoding support incompatibility might have an impact on interoperability", in which case UTF-8 is RECOMMENDED). Eric On Fri, 13 Sep 2002 mikko.aittola@nokia.com wrote: > Hi! > > Bernard Aboba wrote: > > 1. Change the following AVPs that use UTF8String to type > > DiameterIdentity: > > > > Origin-Realm AVP (6.4) > > Destination-Realm AVP (6.6) > > > > 2. Change the definition of DiameterIdentity to OctetString. > > > Shouldn't DiameterIdentity, i.e. fqdn still be considered "text"? > > If the fqdn is not UTF-8 encoded I think it should be ASCII encoded. > Data contained in AVP-type derived from OctetString does not necessarily > contain ASCII encoded data. > > Or am I missing something here? > > > BR, > Mikko > From owner-aaa-wg@merit.edu Fri Sep 13 08:52:56 2002 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 IAA03584 for ; Fri, 13 Sep 2002 08:52:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B177091303; Fri, 13 Sep 2002 08:54:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4046691304; Fri, 13 Sep 2002 08:54: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 2A8E191303 for ; Fri, 13 Sep 2002 08:54:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1930F5DE88; Fri, 13 Sep 2002 08:54:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8D9B45DE07 for ; Fri, 13 Sep 2002 08:54:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8DBthp14257; Fri, 13 Sep 2002 04:55:43 -0700 Date: Fri, 13 Sep 2002 04:55:43 -0700 (PDT) From: Bernard Aboba To: mikko.aittola@nokia.com Cc: john.loughney@nokia.com, Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) In-Reply-To: <07A6D72550C5E0459DE676439EE53846E32C5B@esebe012.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I'm sorry, but I'm not sure what exactly is the current proposal > for the format of DiameterIdentity. > > Are we mandating that all Diameter-boxes must support IDNs > and the encodings described in IDNA-draft? That's not a requirement for Diameter per se. But if you want to use an FQDN that's incompatible with the IDN encoding, then there will be problems. For example, FQDNs encoded with UTF-8 may not be valid. > What is the status of IDNA-draft and the related drafts? Can we > reference to them from Diameter Base RFC? They're Internet drafts (work in progress). We can't have normative references to them without holding up the documents -- and I don't think we need to. > Then a simple question, just to make sure if I have interpretet > all this correctly: > > Is it still ok to put, for example, host.abc.com ASCII encoded > to Origin- and Destination-Host AVPs? Sure. The question is what you'd put into those AVPs if you had registered a machine <"host" translated into Chinese>.abc.com. > I guess it wouldn't hurt to put couple examples of valid > contents of DiameterIdentity to the draft. I think that that would require wading into the IDN swamp. The point is that AVPs of type DiameterIdentity need to be valid FQDNs. From owner-aaa-wg@merit.edu Fri Sep 13 08:55:17 2002 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 IAA03682 for ; Fri, 13 Sep 2002 08:55:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9427F91304; Fri, 13 Sep 2002 08:56:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F47A91305; Fri, 13 Sep 2002 08:56: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 51BB191304 for ; Fri, 13 Sep 2002 08:56:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 370A45DF01; Fri, 13 Sep 2002 08:56:44 -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 7BC515DE88 for ; Fri, 13 Sep 2002 08:56:43 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DCueT22180 for ; Fri, 13 Sep 2002 15:56:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 15:55:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 15:55:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Date: Fri, 13 Sep 2002 15:55:54 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A551D@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJbJK2T/ROTvOtvSKSQWFgL4rs1QQAAB0Vw From: To: Cc: X-OriginalArrivalTime: 13 Sep 2002 12:55:55.0098 (UTC) FILETIME=[E5BAF3A0:01C25B24] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03682 Hi Bernard, I think the text you proposed is sufficient for these purposes. If anyone disagrees, please supply exact text. thanks, John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 13 September, 2002 14:56 > To: Aittola Mikko (NET/Helsinki) > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) > > > > I'm sorry, but I'm not sure what exactly is the current proposal > > for the format of DiameterIdentity. > > > > Are we mandating that all Diameter-boxes must support IDNs > > and the encodings described in IDNA-draft? > > That's not a requirement for Diameter per se. But if you want > to use an > FQDN that's incompatible with the IDN encoding, then there will be > problems. For example, FQDNs encoded with UTF-8 may not be valid. > > > What is the status of IDNA-draft and the related drafts? Can we > > reference to them from Diameter Base RFC? > > They're Internet drafts (work in progress). We can't have normative > references to them without holding up the documents -- and I > don't think > we need to. > > > Then a simple question, just to make sure if I have interpretet > > all this correctly: > > > > Is it still ok to put, for example, host.abc.com ASCII encoded > > to Origin- and Destination-Host AVPs? > > Sure. The question is what you'd put into those AVPs if you > had registered > a machine <"host" translated into Chinese>.abc.com. > > > I guess it wouldn't hurt to put couple examples of valid > > contents of DiameterIdentity to the draft. > > I think that that would require wading into the IDN swamp. > The point is > that AVPs of type DiameterIdentity need to be valid FQDNs. > > > From owner-aaa-wg@merit.edu Fri Sep 13 09:17:56 2002 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 JAA04404 for ; Fri, 13 Sep 2002 09:17:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2538191309; Fri, 13 Sep 2002 09:19:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6F9D91306; Fri, 13 Sep 2002 09:19: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 5F25191305 for ; Fri, 13 Sep 2002 09:19:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 437E25DE35; Fri, 13 Sep 2002 09:19:16 -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 8A9CF5DE07 for ; Fri, 13 Sep 2002 09:19:15 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DDJNZ06535 for ; Fri, 13 Sep 2002 16:19:24 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 16:18:19 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 16:18:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Date: Fri, 13 Sep 2002 16:18:16 +0300 Message-ID: <07A6D72550C5E0459DE676439EE538460126D696@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJbJK2Jyt0fsGzLT+q3u2ldYxLBqwAAvlbg From: To: Cc: X-OriginalArrivalTime: 13 Sep 2002 13:18:18.0588 (UTC) FILETIME=[068341C0:01C25B28] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04404 Hi! Thanks for clarification. The proposed text is fine. BR, Mikko > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 13 September, 2002 14:56 > To: Aittola Mikko (NET/Helsinki) > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) > > > > I'm sorry, but I'm not sure what exactly is the current proposal > > for the format of DiameterIdentity. > > > > Are we mandating that all Diameter-boxes must support IDNs > > and the encodings described in IDNA-draft? > > That's not a requirement for Diameter per se. But if you want > to use an > FQDN that's incompatible with the IDN encoding, then there will be > problems. For example, FQDNs encoded with UTF-8 may not be valid. > > > What is the status of IDNA-draft and the related drafts? Can we > > reference to them from Diameter Base RFC? > > They're Internet drafts (work in progress). We can't have normative > references to them without holding up the documents -- and I > don't think > we need to. > > > Then a simple question, just to make sure if I have interpretet > > all this correctly: > > > > Is it still ok to put, for example, host.abc.com ASCII encoded > > to Origin- and Destination-Host AVPs? > > Sure. The question is what you'd put into those AVPs if you > had registered > a machine <"host" translated into Chinese>.abc.com. > > > I guess it wouldn't hurt to put couple examples of valid > > contents of DiameterIdentity to the draft. > > I think that that would require wading into the IDN swamp. > The point is > that AVPs of type DiameterIdentity need to be valid FQDNs. > > > From owner-aaa-wg@merit.edu Mon Sep 16 09:57:08 2002 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 JAA05408 for ; Mon, 16 Sep 2002 09:57:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D8B9591257; Mon, 16 Sep 2002 09:58:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA87891258; Mon, 16 Sep 2002 09:58:43 -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 4BB8D91257 for ; Mon, 16 Sep 2002 09:58:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C6D75DF51; Mon, 16 Sep 2002 09:58:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id BBD245DD93 for ; Mon, 16 Sep 2002 09:58:40 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g8GDw7uT014329; Mon, 16 Sep 2002 09:58:07 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA02755; Mon, 16 Sep 2002 09:58:28 -0400 (EDT) Date: Mon, 16 Sep 2002 09:57:59 -0400 To: Bernard Aboba Cc: "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 365: Revised Extensibility Section Message-ID: <20020916135759.GA1045@catfish> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 40 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk In order for parser dictionary to deal with the case in which new mandatory AVPs for ACR/ACA commands are added to the ABNF with a new application Id, I think the ABNF should include application-id as well as comomand-id. Otherwise, it would be difficult to handle the case where some of the mandatory AVPs are required part of the commands. So I would like to request for changing the Command Code ABNF specification as follows: header = "<" Diameter-Header:" command-id application-id [r-bit] [p-bit] [e-bit] ">" command-id = 1*DIGIT ; The Command Code assigned to the command application-id = 1*DIGIT ; The Application Id used for the command What do you think? Yoshihiro Ohba On Thu, Sep 12, 2002 at 04:49:11AM -0700, Bernard Aboba wrote: > > Should here be mentioned also that if the basic accounting is used > > without any mandatory AVPs or new commands, then the base protocol defined > > standard accounting application Id (section 2.4) must be used in ACR/ACA > > commands. > > Yes. Have added the following text to the recommended changes for #365: > > "The creation of a new accounting application should be viewed as a > last resort and MUST NOT be used unless a new command is defined with > the application, or new mandatory AVPs are added to the ABNF. If > a Diameter accounting application requires no new mandatory AVPs > and no new commands (only ACR/ACA are used), then the standard > accounting application Id (section 2.4) MUST be used in ACR/ACA commands." > > From owner-aaa-wg@merit.edu Wed Sep 18 05:28:14 2002 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 FAA06728 for ; Wed, 18 Sep 2002 05:28:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BED549126C; Wed, 18 Sep 2002 05:29:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 885E59126E; Wed, 18 Sep 2002 05:29:46 -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 4391B9126C for ; Wed, 18 Sep 2002 05:29:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F8FD5E033; Wed, 18 Sep 2002 05:29:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from emily.fle.fujitsu.com (unknown [193.122.18.249]) by segue.merit.edu (Postfix) with SMTP id 92A005E02D for ; Wed, 18 Sep 2002 05:29:44 -0400 (EDT) Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 10:31:05 +0100 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Sep 2002 10:27:05 +0100 Message-ID: From: Xin Chen To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Policy Control function in Diameter Date: Wed, 18 Sep 2002 10:26:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-34d7aadb-a9e6-4cea-872e-180b765536bf" 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. ------=_NextPartTM-000-34d7aadb-a9e6-4cea-872e-180b765536bf Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25EF5.89D6A820" ------_=_NextPart_001_01C25EF5.89D6A820 Content-Type: text/plain Dear all, Does Diameter provide sort of policy control funcation like COPs for network resource authorization? Is there any paper or RFC to evaluate the policy based adminssion control capability between COPs and Diameter? Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 ------_=_NextPart_001_01C25EF5.89D6A820 Content-Type: text/html Message
Dear all,
 
Does Diameter provide sort of policy control funcation like COPs for network resource authorization? Is there any paper or RFC to evaluate the policy based adminssion control capability between COPs and Diameter?
 
Regards
 
Xin Chen
Mobile Network Architecture
Fujitsu Laboratories of Europe LTD
Tel: +44 (0) 2086064453
Mobile: +44 (0)7775741020
 
------_=_NextPart_001_01C25EF5.89D6A820-- ------=_NextPartTM-000-34d7aadb-a9e6-4cea-872e-180b765536bf Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and FLE. ------=_NextPartTM-000-34d7aadb-a9e6-4cea-872e-180b765536bf-- From owner-aaa-wg@merit.edu Wed Sep 18 15:06:48 2002 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 PAA26636 for ; Wed, 18 Sep 2002 15:06:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEBA79129D; Wed, 18 Sep 2002 15:08:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E3E89129E; Wed, 18 Sep 2002 15:08: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 AF0CF9129D for ; Wed, 18 Sep 2002 15:08:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 931245E0AF; Wed, 18 Sep 2002 15:08:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 142595DE0A for ; Wed, 18 Sep 2002 15:08:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8II9EB25787 for ; Wed, 18 Sep 2002 11:09:14 -0700 Date: Wed, 18 Sep 2002 11:09:14 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 367: Issues with MIP-12 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 367: Issues with MIP-12 Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 13, 2002 Reference: Document: MIP-12 Comment type: E Priority: S Section: many Rationale/Explanation of issue: Overall comments: This draft needs a terminology section. Feel free to steal this from the Diameter Base document. The terminology section should include a definition of the terms "session state" and "transaction state". The terms Mobile Node, Home Agent and Foreign Agent are inconsistently capitalized. The term "key" appears to be used inconsistently within the draft. It would appear that the "keys" distributed by the AAAH to the Mobile Node are fact nonces, which are combined with the long term pre-shared key to generate the session key. Similarly, use of the term "security association" is not always clear, since we have end-to-end SAs, hop-by-hop SAs, and Mobile IP SAs. Specific instances where this occurs are pointed out in the detailed comments on this issue. From owner-aaa-wg@merit.edu Wed Sep 18 15:14:13 2002 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 PAA26928 for ; Wed, 18 Sep 2002 15:14:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDB6891298; Wed, 18 Sep 2002 15:15:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B48691296; Wed, 18 Sep 2002 15:15: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 DB10091298 for ; Wed, 18 Sep 2002 15:15:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89FBF5E0B2; Wed, 18 Sep 2002 15:15:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A81665DE0A for ; Wed, 18 Sep 2002 15:15:09 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8IIG5T26256 for ; Wed, 18 Sep 2002 11:16:05 -0700 Date: Wed, 18 Sep 2002 11:16:05 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Conclusion of AAA WG last call on Diameter Mobile IPv4 application Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has concluded on "Diameter Mobile IPv4 Application", recommended for consideration as a Proposed Standard. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-12.txt Only one comment was received (Issue #367). This comment (and other open and resolved comments) are available for inspection on the Diameter issues list, available at: http://www.drizzle.com/~aboba/AAA/issues.html Since the one comment received was editorial in nature, once the comments are incorporated in draft-ietf-aaa-diameter-mobileip-13.txt, the document will be forwarded to the IESG for consideration as a Proposed Standard, without another WG last call being required. From owner-aaa-wg@merit.edu Thu Sep 19 12:56:39 2002 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 MAA14079 for ; Thu, 19 Sep 2002 12:56:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C9F691216; Thu, 19 Sep 2002 12:58:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A7D5912AB; Thu, 19 Sep 2002 12:58: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 18A5991216 for ; Thu, 19 Sep 2002 12:58:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF70D5E181; Thu, 19 Sep 2002 12:58:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7B5D15E180 for ; Thu, 19 Sep 2002 12:58:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8JFx0p01637 for ; Thu, 19 Sep 2002 08:59:00 -0700 Date: Thu, 19 Sep 2002 08:59:00 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: WG last call status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG has a number of drafts that have recently undergone AAA WG last call. Here is a summary of their current state. Diameter Base Protocol -- Completed AAA WG last call earlier in the month. There are both technical and editorial comments outstanding. An edited version incorporating the comments is expected in the near future and will be submitted to the ADs/IESG. Diameter MobileIPv4 application -- Completed AAA WG last call this week. Both technical and editorial comments outstanding. Once an updated version if received, it will be submitted to the ADs/IESG. For both drafts, see the list of outstanding issues and proposed fixes below: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Fri Sep 20 10:33:57 2002 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 KAA24008 for ; Fri, 20 Sep 2002 10:33:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 356499122C; Fri, 20 Sep 2002 10:33:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F105C9122E; Fri, 20 Sep 2002 10:33:55 -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 A6C979122C for ; Fri, 20 Sep 2002 10:33:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8EA7C5DE96; Fri, 20 Sep 2002 10:33:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9C1095DE0C for ; Fri, 20 Sep 2002 10:33:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8KDYYr07715 for ; Fri, 20 Sep 2002 06:34:34 -0700 Date: Fri, 20 Sep 2002 06:34:34 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 368: Security issues with MIP-12 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 368: Security issues with MIP-12 Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 17, 2002 Reference: Document: MIP-12 Comment type: T Priority: S Section: 5.2, 10 Rationale/Explanation of issue: There is a potential weakness in the generation of MN session keys. The size of the MN-HA long term shared secret is not specified.. Recommend requiring this to be randomly chosen and at least 96-bits. There is also no requirement that the session keys be temporally and globally unique, and since they are only dependent on a 64-bit nonce, the MN IP address, and the long-term secret, they could repeat. While the keys are all encrypted, I'd suggest a larger nonce (128-bits), and some additional mixing (such as by adding the FA IP address to the hash). Specific suggested changes below: Section 5.2: "5.2 Key Material vs. Session Key As described in section 1.6, each mobile IP security association that is generated by the AAAH will be propagated to the mobility agents and the mobile node in two different ways. All security associations destined for the home and foreign agents are sent as session keys, protected by IPSec or TLS as defined in the [DIAMBASE]. If strong authentication and confidentiality of the session keys is required due to involvement of intermediate Diameter agents, it is recommended that the CMS security application [CMS] be used. Since the security associations for the mobile node are propagated through the mobile IPv4 protocol, the security associations are always sent in the form of key material, which the AAAH computes by generating a random [RANDOM] value of at least 64 bits. The mobile node will then use the key material to derive the session key to be used for the security associations. The following is an example of a session creation procedure, which the mobile node has to comply with, using HMAC-MD5 as the hashing algorithm to derive the key (of course the same session creation procedure must also be used by the AAAH for the opposite key sent to the home agent and foreign agent). Additional algorithms are supported, and listed in [MIPKEYS], where also the HMAC-SHA1 algorithm is recommended to be used. key = HMAC-MD5(AAA-key,{Key Material | node-address}) Where: - AAA-Key is the long term secret shared between the mobile node and the AAAH. - Key material is a random [RANDOM] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Some references to CMS need to be cleaned up, and a 64-bit nonce is probably not enough. Reword to: "As described in section 1.6, session keys and nonces are generated by the AAAH and are transmitted to the home agent, foreign agent and mobile node. Security associations destined for the home and foreign agents are established via transmission of session keys and SPIs, protected by transmission-level security as defined in [DIAMBASE]. Where it is necessary to protect the nonces, session keys and SPIs from untrusted Diameter agents, end-to-end security mechanisms are required, such as the CMS application [CMS], a work in progress. The mobile node security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH generates a random [RANDOM] value of at least 128 bits. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys. The session key creation procedure is described below in more detail. HMAC-MD5 is used as the hashing algorithm to enable session keys to be derived from the long term shared secret and the nonce. The same procedure is used by the AAAH for creation of the session keys sent to the home and foreign agent. Additional supported algorithms are listed in [MIPKEYS], where the HMAC-SHA1 algorithm is recommended. (so why is HMAC-MD5 used in the examples?) key = HMAC-MD5(AAA-key,{Nonce | MN-address | FA-address}) Where: - AAA-Key is the pre-shared key between the mobile node and the AAAH. - Nonce is a random [RANDOM] value of at least 128 bits. - FA-address is the address of the foreign agent. - MN-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Section 10, security considerations: " This specification describes the Diameter Application necessary to authenticate and authorize a Mobile IP mobile node. The authentication algorithm used is dependent upon the transforms available by the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys to be used to authenticate Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric due to the fact the keys to the mobile node have to be propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the mobility agent keys are propagated via the Diameter protocol. This means that the keys destined to the mobility agents are always protected by IPSec or TLS as defined in [DIAMBASE], when deployed without any Diameter agents, or protected using the methods defined in [CMS], when deployed in an environment that includes Diameter agents. The keys destined for the mobile node are always sent as key material, which is used to derive the actual keys, which means that it does not expose any data that could be used in an attack aimed at recovering the long term key shared between the mobile node and the home Diameter server. Periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. Therefore, must the long-term shared secret between the mobile node and the home Diameter server also be periodically refreshed, by utilizing some out-of-band mechanism, since this shared secret cannot be refreshed by any in- band mechanism. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the vulnerability of the system." Clarification of vulnerabilities and keying terminology needed. Reword as follows: "This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent upon the transforms used within the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric since communication with the mobile node occurs via the mobile IP protocol [AAAKEY, MOBILEIP], while communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. As required by [DIAMBASE], transmission-level security (IPsec or TLS) MUST be used between Diameter nodes. Where untrusted Diameter agents are present, end-to-end security MUST be used, via mechanisms such as the CMS application [CMS], a work in progress. Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-MD5 one-way function. If the nonces are compromised, then the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits. Since the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce of at least 128 bits is REQUIRED. The long-term secret between the MN and HA MUST be periodically refreshed, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished using out-of-band mechanisms, which are not specified in this document. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the level of vulnerability." From owner-aaa-wg@merit.edu Fri Sep 20 16:23:27 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06879 for ; Fri, 20 Sep 2002 16:23:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F292912C7; Fri, 20 Sep 2002 16:23:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C84C912C8; Fri, 20 Sep 2002 16:23: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 10EDB912C7 for ; Fri, 20 Sep 2002 16:23:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5B455E316; Fri, 20 Sep 2002 16:23:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by segue.merit.edu (Postfix) with ESMTP id 4B3365DE14 for ; Fri, 20 Sep 2002 16:23:40 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.50 2002/08/30 20:04:57 dmccart Exp $) with ESMTP id g8KKLkY15968 for ; Fri, 20 Sep 2002 20:21:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.24 2002/08/30 20:04:21 dmccart Exp $) with SMTP id g8KKKwV20691 for ; Fri, 20 Sep 2002 20:20:58 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002092013260710194 ; Fri, 20 Sep 2002 13:26:07 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 13:23:35 -0700 Message-ID: From: "Qi, Emily H" To: "'Bernard Aboba'" Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 Date: Fri, 20 Sep 2002 13:23:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard, How is this randomly chosen pre-shared key (MN-AAAH) distributed? What kind of out-of-band mechanism do you recommend? Should we have a draft to address this issue? Or is it a deployment issue? Regards, Emily Qi -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Friday, September 20, 2002 6:35 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 368: Security issues with MIP-12 Issue 368: Security issues with MIP-12 Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 17, 2002 Reference: Document: MIP-12 Comment type: T Priority: S Section: 5.2, 10 Rationale/Explanation of issue: There is a potential weakness in the generation of MN session keys. The size of the MN-HA long term shared secret is not specified.. Recommend requiring this to be randomly chosen and at least 96-bits. There is also no requirement that the session keys be temporally and globally unique, and since they are only dependent on a 64-bit nonce, the MN IP address, and the long-term secret, they could repeat. While the keys are all encrypted, I'd suggest a larger nonce (128-bits), and some additional mixing (such as by adding the FA IP address to the hash). Specific suggested changes below: Section 5.2: "5.2 Key Material vs. Session Key As described in section 1.6, each mobile IP security association that is generated by the AAAH will be propagated to the mobility agents and the mobile node in two different ways. All security associations destined for the home and foreign agents are sent as session keys, protected by IPSec or TLS as defined in the [DIAMBASE]. If strong authentication and confidentiality of the session keys is required due to involvement of intermediate Diameter agents, it is recommended that the CMS security application [CMS] be used. Since the security associations for the mobile node are propagated through the mobile IPv4 protocol, the security associations are always sent in the form of key material, which the AAAH computes by generating a random [RANDOM] value of at least 64 bits. The mobile node will then use the key material to derive the session key to be used for the security associations. The following is an example of a session creation procedure, which the mobile node has to comply with, using HMAC-MD5 as the hashing algorithm to derive the key (of course the same session creation procedure must also be used by the AAAH for the opposite key sent to the home agent and foreign agent). Additional algorithms are supported, and listed in [MIPKEYS], where also the HMAC-SHA1 algorithm is recommended to be used. key = HMAC-MD5(AAA-key,{Key Material | node-address}) Where: - AAA-Key is the long term secret shared between the mobile node and the AAAH. - Key material is a random [RANDOM] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Some references to CMS need to be cleaned up, and a 64-bit nonce is probably not enough. Reword to: "As described in section 1.6, session keys and nonces are generated by the AAAH and are transmitted to the home agent, foreign agent and mobile node. Security associations destined for the home and foreign agents are established via transmission of session keys and SPIs, protected by transmission-level security as defined in [DIAMBASE]. Where it is necessary to protect the nonces, session keys and SPIs from untrusted Diameter agents, end-to-end security mechanisms are required, such as the CMS application [CMS], a work in progress. The mobile node security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH generates a random [RANDOM] value of at least 128 bits. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys. The session key creation procedure is described below in more detail. HMAC-MD5 is used as the hashing algorithm to enable session keys to be derived from the long term shared secret and the nonce. The same procedure is used by the AAAH for creation of the session keys sent to the home and foreign agent. Additional supported algorithms are listed in [MIPKEYS], where the HMAC-SHA1 algorithm is recommended. (so why is HMAC-MD5 used in the examples?) key = HMAC-MD5(AAA-key,{Nonce | MN-address | FA-address}) Where: - AAA-Key is the pre-shared key between the mobile node and the AAAH. - Nonce is a random [RANDOM] value of at least 128 bits. - FA-address is the address of the foreign agent. - MN-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Section 10, security considerations: " This specification describes the Diameter Application necessary to authenticate and authorize a Mobile IP mobile node. The authentication algorithm used is dependent upon the transforms available by the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys to be used to authenticate Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric due to the fact the keys to the mobile node have to be propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the mobility agent keys are propagated via the Diameter protocol. This means that the keys destined to the mobility agents are always protected by IPSec or TLS as defined in [DIAMBASE], when deployed without any Diameter agents, or protected using the methods defined in [CMS], when deployed in an environment that includes Diameter agents. The keys destined for the mobile node are always sent as key material, which is used to derive the actual keys, which means that it does not expose any data that could be used in an attack aimed at recovering the long term key shared between the mobile node and the home Diameter server. Periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. Therefore, must the long-term shared secret between the mobile node and the home Diameter server also be periodically refreshed, by utilizing some out-of-band mechanism, since this shared secret cannot be refreshed by any in- band mechanism. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the vulnerability of the system." Clarification of vulnerabilities and keying terminology needed. Reword as follows: "This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent upon the transforms used within the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric since communication with the mobile node occurs via the mobile IP protocol [AAAKEY, MOBILEIP], while communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. As required by [DIAMBASE], transmission-level security (IPsec or TLS) MUST be used between Diameter nodes. Where untrusted Diameter agents are present, end-to-end security MUST be used, via mechanisms such as the CMS application [CMS], a work in progress. Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-MD5 one-way function. If the nonces are compromised, then the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits. Since the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce of at least 128 bits is REQUIRED. The long-term secret between the MN and HA MUST be periodically refreshed, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished using out-of-band mechanisms, which are not specified in this document. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the level of vulnerability." From owner-aaa-wg@merit.edu Fri Sep 20 21:11:24 2002 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 VAA15346 for ; Fri, 20 Sep 2002 21:11:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCBE591240; Fri, 20 Sep 2002 21:12:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94464912CB; Fri, 20 Sep 2002 21:12: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 2D7C691240 for ; Fri, 20 Sep 2002 21:12:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F30D25DE5D; Fri, 20 Sep 2002 21:12:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 886B95DDA5 for ; Fri, 20 Sep 2002 21:12:55 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8L0Dba10460; Fri, 20 Sep 2002 17:13:37 -0700 Date: Fri, 20 Sep 2002 17:13:37 -0700 (PDT) From: Bernard Aboba To: "Qi, Emily H" Cc: aaa-wg@merit.edu, Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > How is this randomly chosen pre-shared key (MN-AAAH) distributed? What kind > of out-of-band mechanism do you recommend? Should we have a draft to address > this issue? Or is it a deployment issue? It's a deployment issue. From owner-aaa-wg@merit.edu Mon Sep 23 14:40:21 2002 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 OAA20161 for ; Mon, 23 Sep 2002 14:40:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9457F912A8; Mon, 23 Sep 2002 14:41:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61CE2912A9; Mon, 23 Sep 2002 14:41: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 51E85912A8 for ; Mon, 23 Sep 2002 14:41:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39D9A5E008; Mon, 23 Sep 2002 14:41:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by segue.merit.edu (Postfix) with ESMTP id F3A275DF40 for ; Mon, 23 Sep 2002 14:41:45 -0400 (EDT) Received: from tonygjo@netscape.net by imo-m06.mx.aol.com (mail_out_v34.10.) id p.b5.46846d9 (22682); Mon, 23 Sep 2002 14:41:38 -0400 (EDT) Received: from netscape.net (mow-m15.webmail.aol.com [64.12.180.131]) by air-in04.mx.aol.com (v88.20) with ESMTP id MAILININ43-0923144138; Mon, 23 Sep 2002 14:41:38 2000 Date: Mon, 23 Sep 2002 14:37:28 -0400 From: tonygjo@netscape.net To: aboba@internaut.com (Bernard Aboba), aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 Message-ID: <2AAF3912.4040E294.00224742@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Bernard, Thanks for the comments and text proposals. Bernard Aboba wrote: >Issue 368: Security issues with MIP-12 >Submitter: Bernard Aboba >Submitter email address: aboba@internaut.com >Date first submitted: September 17, 2002 >Reference: >Document: MIP-12 >Comment type: T >Priority: S >Section: 5.2, 10 >Rationale/Explanation of issue: > >There is a potential weakness in the generation of MN session keys. >The size of the MN-HA long term shared secret is not specified.. Recommend >requiring this to be randomly chosen and at least 96-bits. Very good point. >There is also no requirement that the session keys be temporally and >globally unique, and since they are only dependent on a 64-bit nonce, the >MN IP address, and the long-term secret, they could repeat. > >While the keys are all encrypted, I'd suggest a larger nonce (128-bits), >and some additional mixing (such as by adding the FA IP address to the >hash). To change functionality given in the HMAC-MD5 example (section 5.2), means changes to the draft-ietf-mobileip-aaa-key-09.txt in which the 64-bit nonce (or key material as it is called) and the “mixing” are defined. So, this would be more than editorial changes. May be a recommendation of using a nonce of 128-bits instead of a 64-bits would be enough? /Tony __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-aaa-wg@merit.edu Mon Sep 23 19:57:39 2002 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 TAA29807 for ; Mon, 23 Sep 2002 19:57:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70FCB91283; Mon, 23 Sep 2002 19:59:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C3179128E; Mon, 23 Sep 2002 19:59:15 -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 58EE491283 for ; Mon, 23 Sep 2002 19:59:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 459435E024; Mon, 23 Sep 2002 19:59:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B68875DE9B for ; Mon, 23 Sep 2002 19:59:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8NMxcm19224; Mon, 23 Sep 2002 15:59:39 -0700 Date: Mon, 23 Sep 2002 15:59:38 -0700 (PDT) From: Bernard Aboba To: tonygjo@netscape.net Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 In-Reply-To: <2AAF3912.4040E294.00224742@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > To change functionality given in the HMAC-MD5 example (section 5.2), means > changes to the draft-ietf-mobileip-aaa-key-09.txt in which the 64-bit > nonce (or key material as it is called) and the mixing are > defined. So, this would be more than editorial changes. May be a recommendation > of using a nonce of 128-bits instead of a 64-bits would be enough? The main thing is to make sure the session key is globally and temporally unique. If the nonce can be guaranteed to be globally and temporally unique, then this is sufficient. If not, then additional "mixing" is needed. Creating a globally and temporally unique nonce is not always so easy. It needs to be unique across AAA server reboots; across MNs; across FAs. On average, a nonce of N bits will repeat within 2^(N/2) tries, just due to probability. From owner-aaa-wg@merit.edu Tue Sep 24 10:07:38 2002 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 KAA28457 for ; Tue, 24 Sep 2002 10:07:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9D6591212; Tue, 24 Sep 2002 10:09:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADBBB91213; Tue, 24 Sep 2002 10:09: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 62A3491212 for ; Tue, 24 Sep 2002 10:09:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48E285E0D0; Tue, 24 Sep 2002 10:09:13 -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 7C3D85E0CA for ; Tue, 24 Sep 2002 10:09:12 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8OE94T28561 for ; Tue, 24 Sep 2002 17:09:04 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 24 Sep 2002 17:09:11 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Sep 2002 17:09:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Peer state machine - Diameter base Date: Tue, 24 Sep 2002 17:09:10 +0300 Message-ID: <9E3407CE45911B4097632389B77B2023018701DE@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: AAA WG roadmap Thread-Index: AcIGdnkUVm5KSE5CRweY5c53Lu9EPRdXBMoQ From: To: X-OriginalArrivalTime: 24 Sep 2002 14:09:11.0330 (UTC) FILETIME=[F4A1F820:01C263D3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28457 Hi, I have one query on the peer state machine. There is a difference in handling R-Conn-CER event when the state is R-Open and when the state is I-Open in the base protocol. R-Open R-Conn-CER R-Snd-CEA R-Open R-Reject I-Open R-Conn-CER R-Reject R-Open Can someone please explain why a R-Snd-CEA action is to be performed if R-Conn-CER occurs when the state is R-Open. Thanks in advance. Kishore From owner-aaa-wg@merit.edu Tue Sep 24 15:36:02 2002 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 PAA10098 for ; Tue, 24 Sep 2002 15:36:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7134591269; Tue, 24 Sep 2002 15:37:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40EBE91286; Tue, 24 Sep 2002 15:37: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 166AA91269 for ; Tue, 24 Sep 2002 15:37:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4B395E115; Tue, 24 Sep 2002 15:37:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id A19DE5DDC8 for ; Tue, 24 Sep 2002 15:37:33 -0400 (EDT) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id PAA00025 for ; Tue, 24 Sep 2002 15:37:33 -0400 (EDT) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id PAA03341 for ; Tue, 24 Sep 2002 15:37:32 -0400 (EDT) Date: Tue, 24 Sep 2002 15:37:32 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu Cc: aaa-wg@merit.edu Subject: [AAA-WG]: MIP-MN-AAA-Auth AVP In-Reply-To: <2AAF3912.4040E294.00224742@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The draft "Diameter Mobile IPv4 Application" does not appear to contain a reference as to how the FA is supposed to create the MIP-MN-AAA-Auth AVP. If there is a corresponding Mobile-IPv4 extension then that should be mentioned (I guess it is defined in RFC 3012), as I think it would be impossible to construct that AVP without this extension. Subrata From owner-aaa-wg@merit.edu Wed Sep 25 03:32:59 2002 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 DAA17704 for ; Wed, 25 Sep 2002 03:32:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 452819121B; Wed, 25 Sep 2002 03:34:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04CD191221; Wed, 25 Sep 2002 03:34:26 -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 DECC69121B for ; Wed, 25 Sep 2002 03:34:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCC015E14F; Wed, 25 Sep 2002 03:34:25 -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 005155DEB9 for ; Wed, 25 Sep 2002 03:34:24 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7YCT28594 for ; Wed, 25 Sep 2002 10:34:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:32:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:32:31 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 356- closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:32:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5639@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkw From: To: X-OriginalArrivalTime: 25 Sep 2002 07:32:31.0404 (UTC) FILETIME=[B52F36C0:01C26465] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17704 Hi all, Issue 356 Base-13 Security issues with TLS up-negotiation Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. John From owner-aaa-wg@merit.edu Wed Sep 25 03:38:41 2002 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 DAA17854 for ; Wed, 25 Sep 2002 03:38:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9D2491221; Wed, 25 Sep 2002 03:40:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D7A491224; Wed, 25 Sep 2002 03:40: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 7394D91221 for ; Wed, 25 Sep 2002 03:40:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5703F5E153; Wed, 25 Sep 2002 03:40:15 -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 D5AF85DEB9 for ; Wed, 25 Sep 2002 03:40:09 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7edZ20879 for ; Wed, 25 Sep 2002 10:40:39 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:37:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:37:32 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 357 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:37:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A563A@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50A= From: To: X-OriginalArrivalTime: 25 Sep 2002 07:37:32.0513 (UTC) FILETIME=[68A8CD10:01C26466] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17854 Issue 357 Base-13 Inappropriate UTF-8 Encoding Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:41:02 2002 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 DAA17884 for ; Wed, 25 Sep 2002 03:41:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28DE691224; Wed, 25 Sep 2002 03:42:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8C8591229; Wed, 25 Sep 2002 03:42:38 -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 D889D91224 for ; Wed, 25 Sep 2002 03:42:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B2DA45E158; Wed, 25 Sep 2002 03:42:37 -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 E767E5DEB9 for ; Wed, 25 Sep 2002 03:42:36 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7gRT05107 for ; Wed, 25 Sep 2002 10:42:27 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:39:39 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:39:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:39:38 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 358 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:39:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A563B@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAABEtIA== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:39:39.0089 (UTC) FILETIME=[B41AC410:01C26466] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17884 Issue 358 Base-13 Issues with references Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:42:30 2002 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 DAA17911 for ; Wed, 25 Sep 2002 03:42:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 142D191229; Wed, 25 Sep 2002 03:44:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D41E79128B; Wed, 25 Sep 2002 03:44: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 C5DB791229 for ; Wed, 25 Sep 2002 03:44:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B66F15E159; Wed, 25 Sep 2002 03:44:07 -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 C1B535E158 for ; Wed, 25 Sep 2002 03:44:06 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7iaZ24227 for ; Wed, 25 Sep 2002 10:44:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:44:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:44:05 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 360 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:44:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A563C@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAADskAA== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:44:05.0701 (UTC) FILETIME=[53048750:01C26467] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17911 Issue 360 Base-13 Accounting standalone Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:44:51 2002 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 DAA17970 for ; Wed, 25 Sep 2002 03:44:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75BBE9128B; Wed, 25 Sep 2002 03:45:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3920E91291; Wed, 25 Sep 2002 03:45:20 -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 2D33F9128B for ; Wed, 25 Sep 2002 03:45:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C55485E15E; Wed, 25 Sep 2002 03:45:18 -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 AD7FF5E15A for ; Wed, 25 Sep 2002 03:45:17 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7jlZ25362 for ; Wed, 25 Sep 2002 10:45:47 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:45:13 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:45:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:45:11 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 361 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:45:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A563D@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAEWI4A== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:45:11.0353 (UTC) FILETIME=[7A263A90:01C26467] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17970 Issue 361 Base-13 Support for TLS compression Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:45:07 2002 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 DAA17993 for ; Wed, 25 Sep 2002 03:45:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 859089129E; Wed, 25 Sep 2002 03:46:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5224F9129A; Wed, 25 Sep 2002 03:46: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 3F12F91295 for ; Wed, 25 Sep 2002 03:46:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C844D5E15A; Wed, 25 Sep 2002 03:46:22 -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 AECCB5E158 for ; Wed, 25 Sep 2002 03:46:21 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7k8T06685 for ; Wed, 25 Sep 2002 10:46:08 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:46:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:46:15 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 362 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:46:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A563E@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAE3J4A== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:46:15.0668 (UTC) FILETIME=[A07BEB40:01C26467] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17993 Issue 362 Base-13 Clarification of Proxy, Relay, and Redirect Usage Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:47:49 2002 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 DAA18072 for ; Wed, 25 Sep 2002 03:47:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1830B91291; Wed, 25 Sep 2002 03:49:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFF8F91295; Wed, 25 Sep 2002 03:49:25 -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 DA20091291 for ; Wed, 25 Sep 2002 03:49:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF6D35DD8F; Wed, 25 Sep 2002 03:49:24 -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 C508A5DD8D for ; Wed, 25 Sep 2002 03:49:23 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7nrZ29295 for ; Wed, 25 Sep 2002 10:49:53 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:49:20 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:49:16 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 363 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:49:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A563F@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAGoWUA== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:49:16.0784 (UTC) FILETIME=[0C700700:01C26468] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18072 Issue 363 Pending IANA Considerations issues Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:51:58 2002 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 DAA18219 for ; Wed, 25 Sep 2002 03:51:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C57B91295; Wed, 25 Sep 2002 03:53:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31D459129A; Wed, 25 Sep 2002 03:53: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 E9CD591295 for ; Wed, 25 Sep 2002 03:53:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DCE5B5DD8E; Wed, 25 Sep 2002 03:53:31 -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 21D2D5DD8C for ; Wed, 25 Sep 2002 03:53:31 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7s1Z02579 for ; Wed, 25 Sep 2002 10:54:01 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:53:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:53:28 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 365 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:53:28 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5641@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAI7B8A== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:53:28.0581 (UTC) FILETIME=[A2853350:01C26468] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18219 Issue 365 Pending Revised Extensibility Section Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:54:17 2002 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 DAA18278 for ; Wed, 25 Sep 2002 03:54:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B27A9129A; Wed, 25 Sep 2002 03:55:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC9AB9129B; Wed, 25 Sep 2002 03:55: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 A889C9129A for ; Wed, 25 Sep 2002 03:55:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FC495DD8F; Wed, 25 Sep 2002 03:55:53 -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 C8ACB5DD8C for ; Wed, 25 Sep 2002 03:55:52 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7thT14681 for ; Wed, 25 Sep 2002 10:55:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:50:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:50:12 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 364 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:50:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5640@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAHHCYA== From: To: X-OriginalArrivalTime: 25 Sep 2002 07:50:12.0859 (UTC) FILETIME=[2DDC64B0:01C26468] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18278 Issue 364 Base-13 Revised Introduction and Abstract Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 03:56:32 2002 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 DAA18334 for ; Wed, 25 Sep 2002 03:56:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADD009129B; Wed, 25 Sep 2002 03:58:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 795519129D; Wed, 25 Sep 2002 03:58: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 6D6589129B for ; Wed, 25 Sep 2002 03:58:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F58C5DD92; Wed, 25 Sep 2002 03:58:00 -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 993CE5DD8C for ; Wed, 25 Sep 2002 03:57:59 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P7voT17048 for ; Wed, 25 Sep 2002 10:57:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:57:46 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:57:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:57:46 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Base Issue still open X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:57:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5642@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAGoWUAAAKI2Q From: To: X-OriginalArrivalTime: 25 Sep 2002 07:57:46.0330 (UTC) FILETIME=[3C2693A0:01C26469] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18334 Hi all, Currently, I have the following issue open: Issue 359 Base-13 Terminology and organizational issues Bernard Aboba Issue 366 No Discussion Vendor-Specific-Result AVP Bernard Aboba 359 is simply some editing, so that should be completed shortly. I will try to have the draft submitted by the end of the week & hopefully the WG chairs can send it onto the IESG. thanks, John From owner-aaa-wg@merit.edu Wed Sep 25 04:03:07 2002 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 EAA18464 for ; Wed, 25 Sep 2002 04:03:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 271F79129D; Wed, 25 Sep 2002 04:04:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8CED9129F; Wed, 25 Sep 2002 04:04:43 -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 E2FB69129D for ; Wed, 25 Sep 2002 04:04:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BEE075DD8F; Wed, 25 Sep 2002 04:04:42 -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 04C855DD8C for ; Wed, 25 Sep 2002 04:04:42 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P85BZ10909 for ; Wed, 25 Sep 2002 11:05:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:59:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:59:06 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 366 - closed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 10:59:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5643@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAGoWUAAATqhw From: To: X-OriginalArrivalTime: 25 Sep 2002 07:59:06.0537 (UTC) FILETIME=[6BF53190:01C26469] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA18464 Issue 366 No Discussion Vendor-Specific-Result AVP Bernard Aboba Has now been fixed in the soon to be released Diameter base 13. From owner-aaa-wg@merit.edu Wed Sep 25 04:18:13 2002 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 EAA18870 for ; Wed, 25 Sep 2002 04:18:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 386849120D; Wed, 25 Sep 2002 04:19:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1264091250; Wed, 25 Sep 2002 04:19:48 -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 B3D7D9120D for ; Wed, 25 Sep 2002 04:19:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E4035DD91; Wed, 25 Sep 2002 04:19:46 -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 D6B275DD8C for ; Wed, 25 Sep 2002 04:19:45 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P8KFZ24138 for ; Wed, 25 Sep 2002 11:20:15 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 11:16:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 11:16:54 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 359 - possible reject X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 11:16:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5645@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAGoWUAAA1+dg From: To: X-OriginalArrivalTime: 25 Sep 2002 08:16:54.0386 (UTC) FILETIME=[E8720520:01C2646B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA18870 Hi all, Bernard said (in issue 359) that: > I'd also note that I found it very confusing that section 8.2 (Accounting > State machine) occurs prior to Section 9 (Accounting). I'd recommend that > 8.2 be moved to Section 9.9 (after definition of the AVPs, including > Accounting-Realtime-Required AVP). As this is purely an editorial issue, and I am hesitant to do major section reshuffling (I don't want to introduce cut&paste errors, errors due to renumber sections, etc), would a possible compromise be that a note be added to section 8.2, along the lines of: Section Section 9.7 for Accounting Command Codes and 9.8 for Accounting AVPs. br, John From owner-aaa-wg@merit.edu Wed Sep 25 05:26:26 2002 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 FAA20069 for ; Wed, 25 Sep 2002 05:26:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C775591250; Wed, 25 Sep 2002 05:28:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B2BB9129F; Wed, 25 Sep 2002 05:28:02 -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 1C03B91250 for ; Wed, 25 Sep 2002 05:28:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08D3A5DDA7; Wed, 25 Sep 2002 05:28:01 -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 5BFD15DDA1 for ; Wed, 25 Sep 2002 05:27:55 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8P9SPZ17255 for ; Wed, 25 Sep 2002 12:28:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 12:25:44 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 12:25:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 12:25:44 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: Issue 359 - possible reject X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 12:25:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5649@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0AJWpdkwAAAz50AAAGoWUAAA1+dgAAKDWSA= From: To: X-OriginalArrivalTime: 25 Sep 2002 09:25:44.0119 (UTC) FILETIME=[85F54470:01C26475] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA20069 Hi, > Bernard said (in issue 359) that: > > > I'd also note that I found it very confusing that section > 8.2 (Accounting > > State machine) occurs prior to Section 9 (Accounting). I'd > recommend that > > 8.2 be moved to Section 9.9 (after definition of the AVPs, > including > > Accounting-Realtime-Required AVP). > > As this is purely an editorial issue, and I am hesitant to do > major section > reshuffling (I don't want to introduce cut&paste errors, errors due to > renumber sections, etc), would a possible compromise be that > a note be added > to section 8.2, along the lines of: > > Section Section 9.7 for Accounting Command Codes and 9.8 > for Accounting AVPs. Of course, I meant: See section 9.7 for Accounting Command Codes and 9.8 for Accounting AVPs. From owner-aaa-wg@merit.edu Wed Sep 25 08:01:18 2002 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 IAA22775 for ; Wed, 25 Sep 2002 08:01:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 92EE991220; Wed, 25 Sep 2002 08:02:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AB32912A1; Wed, 25 Sep 2002 08:02: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 8651891220 for ; Wed, 25 Sep 2002 08:02:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 639E95DDF1; Wed, 25 Sep 2002 08:02:10 -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 9A5705DD90 for ; Wed, 25 Sep 2002 08:02:09 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8PC2cZ19952 for ; Wed, 25 Sep 2002 15:02:38 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 15:02:07 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 15:02:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Peer state machine Date: Wed, 25 Sep 2002 15:01:52 +0300 Message-ID: <9E3407CE45911B4097632389B77B2023018701E0@esebe014.ntc.nokia.com> Thread-Topic: Peer state machine Thread-Index: AcJki42DjTmIXslgEdatggAADnz2vQ== From: To: X-OriginalArrivalTime: 25 Sep 2002 12:02:07.0148 (UTC) FILETIME=[5EADDEC0:01C2648B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA22775 Issue 318:Peer state machine bug Submitter name: Ghadiyaram Venkata Kishore Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, Date first submitted: September 25, 2002 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue In the peer state machine specification in the base protocol there is a difference in handling R-Conn-CER event when the state is R-Open and when the state is I-Open. R-Open R-Conn-CER R-Snd-CEA R-Open R-Reject I-Open R-Conn-CER R-Reject R-Open It should not be necessary to send a CEA as the state is already open on another another connection. The incoming R_CONN_CER can be just rejected. Moreover if a CEA is to be sent then which result code should be used by the CEA in this case. Requested Change : Change R-Open Send-Message R-Snd-Message R-Open R-Rcv-Message Process R-Open R-Rcv-DWR Process-DWR, R-Open R-Snd-DWA R-Rcv-DWA Process-DWA R-Open R-Conn-CER R-Snd-CEA R-Open R-Reject Stop R-Snd-DPR Closing R-Rcv-DPR R-Snd-DPA, Closed R-Disc R-Peer-Disc R-Disc Closed R-Rcv-CER R-Snd-CEA R-Open R-Rcv-CEA Process-CEA R-Open To R-Open Send-Message R-Snd-Message R-Open R-Rcv-Message Process R-Open R-Rcv-DWR Process-DWR, R-Open R-Snd-DWA R-Rcv-DWA Process-DWA R-Open R-Conn-CER R-Reject R-Open Stop R-Snd-DPR Closing R-Rcv-DPR R-Snd-DPA, Closed R-Disc R-Peer-Disc R-Disc Closed R-Rcv-CER R-Snd-CEA R-Open R-Rcv-CEA Process-CEA R-Open From owner-aaa-wg@merit.edu Wed Sep 25 09:45:08 2002 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 JAA25948 for ; Wed, 25 Sep 2002 09:45:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15F63912AF; Wed, 25 Sep 2002 09:46:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D79F7912B0; Wed, 25 Sep 2002 09:46: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 E61C6912AF for ; Wed, 25 Sep 2002 09:46:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6BEE5DE21; Wed, 25 Sep 2002 09:46:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 683CB5DE0F for ; Wed, 25 Sep 2002 09:46:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8PCkF102921; Wed, 25 Sep 2002 05:46:15 -0700 Date: Wed, 25 Sep 2002 05:46:15 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Issue 359 - possible reject In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5649@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > to section 8.2, along the lines of: > > > > Section Section 9.7 for Accounting Command Codes and 9.8 > > for Accounting AVPs. > > Of course, I meant: > > See section 9.7 for Accounting Command Codes and 9.8 > for Accounting AVPs. This is fine. From owner-aaa-wg@merit.edu Wed Sep 25 10:59:41 2002 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 KAA28607 for ; Wed, 25 Sep 2002 10:59:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB5599122C; Wed, 25 Sep 2002 11:00:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73275912B0; Wed, 25 Sep 2002 11:00:44 -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 7D36D9122C for ; Wed, 25 Sep 2002 11:00:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64A205DE3A; Wed, 25 Sep 2002 11:00:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 105B45DE31 for ; Wed, 25 Sep 2002 11:00:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8PE0eX07132; Wed, 25 Sep 2002 07:00:40 -0700 Date: Wed, 25 Sep 2002 07:00:40 -0700 (PDT) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Peer state machine In-Reply-To: <9E3407CE45911B4097632389B77B2023018701E0@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue 369. See: http://www.drizzle.com/~aboba/AAA/issues.html On Wed, 25 Sep 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > Issue: Peer state machine bug > Submitter name: Ghadiyaram Venkata Kishore > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > Date first submitted: September 25, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue From owner-aaa-wg@merit.edu Wed Sep 25 19:26:33 2002 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 TAA12659 for ; Wed, 25 Sep 2002 19:26:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 282339123C; Wed, 25 Sep 2002 19:28:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F03429123D; Wed, 25 Sep 2002 19:28: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 D3BF89123C for ; Wed, 25 Sep 2002 19:28:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B898D5DEDC; Wed, 25 Sep 2002 19:28:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imo-r02.mx.aol.com (imo-r02.mx.aol.com [152.163.225.98]) by segue.merit.edu (Postfix) with ESMTP id 513FA5DECD for ; Wed, 25 Sep 2002 19:28:10 -0400 (EDT) Received: from tonygjo@netscape.net by imo-r02.mx.aol.com (mail_out_v34.10.) id p.1b7.2067747 (16215); Wed, 25 Sep 2002 19:28:00 -0400 (EDT) Received: from netscape.net (mow-m10.webmail.aol.com [64.12.184.138]) by air-in01.mx.aol.com (v89.10) with ESMTP id MAILININ13-0925192800; Wed, 25 Sep 2002 19:28:00 -0400 Date: Wed, 25 Sep 2002 19:28:00 -0400 From: tonygjo@netscape.net To: aboba@internaut.com (Bernard Aboba) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 Message-ID: <662D33AE.13DCBF00.00224742@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Bernard Aboba wrote: >> To change functionality given in the HMAC-MD5 example (section 5.2), means >> changes to the draft-ietf-mobileip-aaa-key-09.txt in which the 64-bit >> nonce (or key material as it is called) and the mixing are >> defined. So, this would be more than editorial changes. May be a recommendation >> of using a nonce of 128-bits instead of a 64-bits would be enough? > >The main thing is to make sure the session key is globally and temporally >unique. If the nonce can be guaranteed to be globally and temporally >unique, then this is sufficient. If not, then additional "mixing" is >needed. > >Creating a globally and temporally unique nonce is not always so easy. It >needs to be unique across AAA server reboots; across MNs; across FAs. On >average, a nonce of N bits will repeat within 2^(N/2) tries, just due to >probability. > key = HMAC-MD5(AAA-key,{Key material | node-address}) As defined in [MIPKEY] - the node-address is iether the mobile node's NAI (if no IP address have been specified) or the mobile node's IP address (if IP address have been specified). Isn't this enough? /Tony __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-aaa-wg@merit.edu Wed Sep 25 19:29:55 2002 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 TAA12722 for ; Wed, 25 Sep 2002 19:29:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C8C09123D; Wed, 25 Sep 2002 19:31:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E668912B8; Wed, 25 Sep 2002 19:31: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 83CB79123D for ; Wed, 25 Sep 2002 19:31:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F0E05DEDE; Wed, 25 Sep 2002 19:31:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by segue.merit.edu (Postfix) with ESMTP id 052055DEDC for ; Wed, 25 Sep 2002 19:31:31 -0400 (EDT) Received: from tonygjo@netscape.net by imo-m03.mx.aol.com (mail_out_v34.10.) id a.1b6.2064173 (22682); Wed, 25 Sep 2002 19:29:32 -0400 (EDT) Received: from netscape.net (mow-m11.webmail.aol.com [64.12.184.139]) by air-in04.mx.aol.com (v88.20) with ESMTP id MAILININ43-0925192932; Wed, 25 Sep 2002 19:29:32 -0400 Date: Wed, 25 Sep 2002 19:29:32 -0400 From: tonygjo@netscape.net To: sgoswami@umich.edu ("s. goswami") Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: MIP-MN-AAA-Auth AVP Message-ID: <74BE9B44.7D1E9DDE.00224742@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Subrata, Okay I'll change the reference in section 4.6 From: [MOBILEIP] To: [MOBILEIP, MIPCHAL] Thanks, /Tony "s. goswami" wrote: > >The draft "Diameter Mobile IPv4 Application" does not appear >to contain a reference as to how the FA is supposed to create >the MIP-MN-AAA-Auth AVP. > >If there is a corresponding Mobile-IPv4 extension then that should >be mentioned (I guess it is defined in RFC 3012), as I think >it would be impossible to construct that AVP without this extension. > >Subrata > > > > > __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-aaa-wg@merit.edu Wed Sep 25 19:51:15 2002 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 TAA13103 for ; Wed, 25 Sep 2002 19:51:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2180912B8; Wed, 25 Sep 2002 19:52:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 719C7912D0; Wed, 25 Sep 2002 19:52: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 826D5912B8 for ; Wed, 25 Sep 2002 19:52:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 695CD5DEE8; Wed, 25 Sep 2002 19:52:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E62AE5DEDC for ; Wed, 25 Sep 2002 19:52:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8PMr7H03859; Wed, 25 Sep 2002 15:53:07 -0700 Date: Wed, 25 Sep 2002 15:53:07 -0700 (PDT) From: Bernard Aboba To: tonygjo@netscape.net Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 In-Reply-To: <662D33AE.13DCBF00.00224742@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > key = HMAC-MD5(AAA-key,{Key material | node-address}) > > As defined in [MIPKEY] - the node-address is iether the mobile node's NAI > (if no IP address have been specified) or the mobile node's IP address > (if IP address have been specified). Isn't this enough? The NAI is invariant, so this implies that the session key will repeat if the Nonce ("Key material") repeats anywhere that the MN attaches. If the Nonce is globally and temporally unique, this won't happen -- but it helps to specify how this might be accomplished. For example, one could combine a random quantity with a counter, or NTP time, or a combination of addresses that varies with the attachment point (e.g. CoA, FA address). From owner-aaa-wg@merit.edu Wed Sep 25 20:09:56 2002 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 UAA13517 for ; Wed, 25 Sep 2002 20:09:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAEE1912C9; Wed, 25 Sep 2002 20:11:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A0F4912D0; Wed, 25 Sep 2002 20:11: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 A6AC9912C9 for ; Wed, 25 Sep 2002 20:11:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A1955DEF3; Wed, 25 Sep 2002 20:11:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EBCA05DEF1 for ; Wed, 25 Sep 2002 20:11:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8PNBnD04902; Wed, 25 Sep 2002 16:11:49 -0700 Date: Wed, 25 Sep 2002 16:11:49 -0700 (PDT) From: Bernard Aboba To: tonygjo@netscape.net Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 In-Reply-To: <662D33AE.13DCBF00.00224742@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > key = HMAC-MD5(AAA-key,{Key material | node-address}) > > As defined in [MIPKEY] - the node-address is either the mobile node's >NAI (if no IP address have been specified) or the mobile node's IP >address (if IP address have been specified). Isn't this enough? To be clear, the "Key Material" (e.g. Nonce) is encrypted, so that even if it were to repeat, the attacker would not know this unless they had gained control of one of the endpoints (assuming CMS is used). However, since we *are* talking about a Nonce here (not a true key), it's questionable whether encrypting it is required at any level, especially CMS. As noted in the security considerations section, even if the Nonce is compromised, you can't obtain the Session Key or the Pre-shared key between MN and HA. So I think that is an argument for not getting too wrapped around the CMS axle, at least with respect to Nonces (session keys are another issue). Assuming that the Nonces may be exposed to untrusted proxies, there is value in making sure they are globally and temporally unique. You shouldn't feel bound to explain how implementors will make that happen; after all, RFC 2865 requires that the RADIUS Request Authenticator (128 bits) be globally and temporally unique, yet provides no guidance. But judging by results (most RADIUS clients don't satisfy the requirement), it seems to help to give guidance on how that can be accomplished. This isn't a particularly major issue, so we can probably wait until IETF last call (or longer) to figure it out. In the meantime, let's get a corrected version of -12 on the archive so that we can start the IETF last call process. From owner-aaa-wg@merit.edu Wed Sep 25 20:34:31 2002 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 UAA13816 for ; Wed, 25 Sep 2002 20:34:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3569091217; Wed, 25 Sep 2002 20:36:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1567912C6; Wed, 25 Sep 2002 20:36: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 E105091217 for ; Wed, 25 Sep 2002 20:36:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD3E15DEF9; Wed, 25 Sep 2002 20:36:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imo-m01.mx.aol.com (imo-m01.mx.aol.com [64.12.136.4]) by segue.merit.edu (Postfix) with ESMTP id 89F935DEDC for ; Wed, 25 Sep 2002 20:36:07 -0400 (EDT) Received: from tonygjo@netscape.net by imo-m01.mx.aol.com (mail_out_v34.10.) id p.1b3.2067d1c (16226); Wed, 25 Sep 2002 20:35:40 -0400 (EDT) Received: from netscape.net (mow-d03.webmail.aol.com [205.188.138.67]) by air-in02.mx.aol.com (v88.20) with ESMTP id MAILININ22-0925203540; Wed, 25 Sep 2002 20:35:40 -0400 Date: Wed, 25 Sep 2002 20:32:20 -0400 From: tonygjo@netscape.net To: aboba@internaut.com (Bernard Aboba) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 Message-ID: <0C2E6570.6FEB3A9A.00224742@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Bernard Aboba wrote: ... > >But judging by results (most RADIUS clients don't satisfy the >requirement), it seems to help to give guidance on how that can be >accomplished. This isn't a particularly major issue, so we can probably >wait until IETF last call (or longer) to figure it out. In the meantime, >let's get a corrected version of -12 on the archive so that we can start >the IETF last call process. > Okay, so with hashing / nonce processing as of today in [MIPKEYS].... How about the following (based on your previous text proposal)? "5.2 Key Material vs. Session Key As described in section 1.6, session keys and nonces are generated by the AAAH and are transmitted to the home agent, foreign agent and mobile node. Security associations destined for the home and foreign agents are established via transmission of session keys and SPIs, protected by transmission-level security as defined in [DIAMBASE]. Where it is necessary to protect the nonces, session keys and SPIs from untrusted Diameter agents, end-to-end security mechanisms are required, such as the CMS application [CMS], a work in progress. The mobile node security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH must generate a random [RANDOM] value of at least 64 bits [MIPKEYS], however it is strongly recommended to generate a random [RANDOM] value of at least 128 bits. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys. More details of the MN-HA and the MN-FA session key creation procedure are found in [MIPKEYS]. Recommended hashing algorithms to be use are HMAC-MD5 and HMAC-SHA1, where HMAC-MD5 MUST be supported [MIPKEYS]. Below follows an example, copied from [MIPKEYS], of the key creation procedure using the HMAC-MD5 hashing algorithm. The hashing algorithm is used to enable session keys to be derived from the long term shared secret and the nonce. The same procedure is used by the AAAH for creation of the session keys sent to the home and foreign agent. key = HMAC-MD5(AAA-key,{Key material | node-address}) Where: - AAA-Key is the pre-shared key between the mobile node and the AAAH. - Key material (nonce) is a random [RANDOM] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." and Section 10, security considerations: "This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent upon the transforms used within the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric since communication with the mobile node occurs via the mobile IP protocol [AAAKEY, MOBILEIP], while communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. As required by [DIAMBASE], transmission-level security (IPsec or TLS) MUST be used between Diameter nodes. Where untrusted Diameter agents are present, end-to-end security MUST be used, via mechanisms such as the CMS application [CMS], a work in progress. Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-MD5 one-way function. If the nonces are compromised, then the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits. Since the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce is strongly recommended to be random [RANDOM] value of at least 128 bits. The long-term secret between the MN and HA MUST be periodically refreshed, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished using out-of-band mechanisms, which are not specified in this document. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the level of vulnerability." /Tony __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-aaa-wg@merit.edu Wed Sep 25 21:44:39 2002 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 VAA15251 for ; Wed, 25 Sep 2002 21:44:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E41EB91240; Wed, 25 Sep 2002 21:46:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A710E912C6; Wed, 25 Sep 2002 21:46: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 A31F691240 for ; Wed, 25 Sep 2002 21:46:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 897E95DEBE; Wed, 25 Sep 2002 21:46:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 22B785DE4B for ; Wed, 25 Sep 2002 21:46:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8Q0kFM10112; Wed, 25 Sep 2002 17:46:15 -0700 Date: Wed, 25 Sep 2002 17:46:15 -0700 (PDT) From: Bernard Aboba To: tonygjo@netscape.net Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 368: Security issues with MIP-12 In-Reply-To: <0C2E6570.6FEB3A9A.00224742@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Okay, so with hashing / nonce processing as of today in [MIPKEYS].... > How about the following (based on your previous text proposal)? Looks fine. From owner-aaa-wg@merit.edu Fri Sep 27 06:13:16 2002 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 GAA15628 for ; Fri, 27 Sep 2002 06:13:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD5D791251; Fri, 27 Sep 2002 06:14:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72EE891252; Fri, 27 Sep 2002 06:14: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 4664091251 for ; Fri, 27 Sep 2002 06:14:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2309A5E144; Fri, 27 Sep 2002 06:14:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 0CDD75E004 for ; Fri, 27 Sep 2002 06:14:51 -0400 (EDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id GAA06431; Fri, 27 Sep 2002 06:14:40 -0400 (EDT) From: "Subrata Goswami" To: Subject: [AAA-WG]: Date: Fri, 27 Sep 2002 03:13:28 -0700 Message-ID: <000001c2660e$8b87bfe0$0300a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C265D3.DFF0F2D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C265D3.DFF0F2D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Submitted a new Internet-Draft. Title : DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Author(s) : Subrata Goswami Filename : draft-goswami-aaa-mipv4-wlan-auth-00.txt Abstract This document describes a single way to perform both Mobile-IPv4 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done then it is possible to replace the currently proposed 802.1x Authentication/key-exchange with Diameter Mobile-IPv4 Application. ------=_NextPart_000_0001_01C265D3.DFF0F2D0 Content-Type: text/plain; name="draft-goswami-aaa-mipv4-wlan-auth-00.txt" Content-Disposition: attachment; filename="draft-goswami-aaa-mipv4-wlan-auth-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT Subrata = Goswami Expires February 26, 2003 Independent = Consultant Sept 27, 2002 DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Abstract This document describes a single way to perform both Mobile-IPv4 =20 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done=20 then it is possible to replace the currently proposed 802.1x=20 Authentication/key-exchange with Diameter Mobile-IPv4 Application. 1. Overview and Rationale In the 802.11 wireless lan [WiFi] network an 802.11 client connects to = an 802.11 Access Point (AP) at the link layer. 802.11 provides a mechanism = to=20 achieve handoffs between AP's and the client. A 802.11 client first=20 authenticates and then associates with one AP. When the 802.11 client=20 decides that it is better to move to a second AP, it can do a =20 re-association with the second AP.=20 Similarly when a Mobile-IPv4 (MIP4) client moves from subnet to subnet, = it seeks a Foreign Agent (FA) situated in the subnet and registers with the = FA.=20 The IP packet sent in Registration Message has the Home IP address as = the=20 source, and the destination address can be the FA's IP address or the = "All=20 Mobility Agents" multicast address 224.0.0.11. The FA then responds = with=20 Registration Reply message. The Registration Message also includes=20 Authentication Extensions. A significant hurdle in deployment of MIPv4 = has=20 been the distributon and management of the security association between = MN-HA, FA-HA, and MN-FA. Recently a method, Diameter Mobile IP v4 Application=20 (DIMPA), has been suggested by which all these 3 different keys can be=20 generated dynamically from a single shared secret between the MN and a=20 AAA agent [DIMPA]. This DIMPA provides in addition to its core=20 accounting functionality. As mentioned in a previous draft [SIMIP], there is substantial overlap=20 between what 802.11 and MIPv4 do during their respective registration=20 phases. As pointed out in that draft it is possile to nest these = operations=20 and thus reduce the number of messages that need to be exchnaged between = the MN and the infrastructre. The same issues of overlapping work = between=20 the 802.11i authentication phase and DIMPA registration arises.=20 The situation of non co-located FA is primarily considered here, = although a=20 discussion of co-located FA is also provided. Here we will only=20 consider 802.11 infrastructure mode networks.=20 2. 802.11 Network Architecture. A hypothetical IP over 802.11 network is shown in the following figure.=20 The mobile client, MN, can move from subnet X1 to X3 and from AP2 to = AP3.=20 [FA1]-[AAAF1] | =20 ... [AP1]-------[X1]-| [MN]... | |=09 [AP2]---- |----[X]-----> [HA]---[AAAH] |=09 [AP3/FA3]---[X3]-| | [AAAF3] [MN] - Mobile Node [FA] - Foreign Agent [HA] - Home Agent [AAAH/F] - Home/Foreign AAA Agent [AP] - Access Point [X] - IP Router ... - 802.11 link=20 --- - 802.3 link Figure 1: 802.11 Network with AAA Agents When the MN moves from AP1 to AP2, it first Authenticates with AP2 and = then=20 Dissociates with AP1 at the 802.11 link layer. As the move from AP1 to = AP2=20 occurs within the same subnet, hence the MN is still served by the same = FA=20 and the same AAAF. When the MN moves from AP2 to AP3 it is served by a=20 different set of FA and AAAF, FA3 and AAAF3 respectively. 3. Message Sequence The following figure shows the what happens when MN moves from AP2 to=20 AP3. During the AP1 to AP2 handoff, the MN is in same subnet, hence = MIPv4=20 registration is not required, although 802.1x key-exchange is required. Figure 2 depits the messages exchanged between the MN and the = infrastructure. Here the AAAF is assumed to be a RADIUS entity in addition to being a=20 DIAMETER [DIM] entity. This particular figure depicts the situation when 802.11 pre-authentication is not done.=20 We will first consider the scenario when 802.11 pre-authentication is=20 not done [WiFiTGi]. Then we will discuss the scenario with=20 pre-authentication. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> -- 802.1x EAP Start---------------> <- 802.1x EAP Req-Id--------------- -- 802.1x EAP Res-Id--------------> --RADIUS Acc-Req---> =20 -----------> <-----------=20 <-RADIUS Acc-Cha---- =20 <-- 802.1x EAP Req 1-------------- =20 --- 802.1x EAP Res 1-------------> --RADIUS Acc-Req(1)->=20 <-RADIUS Acc-Res(1)-- . . <-RADIUS Acc-Acp/Rej-- <--802.1x EAP Suc/Fal-------------=20 =09 <-- 802.1x Install Keys----------- -- 802.1x Key Install status-----> -- 802.11 Dissoc-Req----> =20 ----- MIPv4 Reg-Req w/MN-AAA -----------> --AAA AMR-> Session-Id=3Dsid1 --AAA AMR-> sid1 = ---HAR------> sid1 = <--HAA------- sid1 <---AAA AMA- sid1 <-AAA AMA- sid1 <---- MIPv4 Reg-Res--------------------- Figure 2. 802.11 and MIPv4 message sequences in series. 4. No 802.11 Pre-authentication On the surface it looks like the 802.1x based = authentication/key-exchange=20 and DMIPA share a number of common messages. Both message sequences=20 do authentication of the MN first and then do key exchanges. So it = should be possible to combine both of them into a single message sequence. In a = previous draft [SIMIP], it was suggested MIPv4 registration messages can = be=20 carried as Information Elements (IE) in 802.11 Association/Reassociation = frames. =20 Here the same IE's can be used. DIMPA provides an Attribute Value Pair = (AVP)=20 called the MIP-MN-AAA-Auth AVP, which identifies the MN's security = association with the Home AAA agent (AAAH). The MIP-MN-AAA-Auth AVP is constructed from the MIPv4 Registration Request containing the Mobile IP = Authentication=20 extension with the MN-AAA Authentication subtype [MIPCR,DMIPA]. DIMPA = constructs all the MIPv4 keys and distribute them. So it is a simple incremental = task for DIMPA to generate one more key (RC4 40 or 104 bit for TKIP [WiFiTGi]) to = share=20 between MN an AP. The following figure, Figure 3., shows a message = sequence=20 for using DIMPA for both 802.11 and MIPv4 authentication and = key-exchange. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> ----- 802.11 Associate with-------> (MIPv4 Reg-Req w/MN-AAA) ----------> MIPv4 Reg-Req w/MN-AAA --AAA AMR-> Session-Id=3Dsid1 --AAA AMR-> sid1 = ---HAR----> sid1 = <--HAA----- sid1 <---AAA AMA- sid1 <-AAA AMA- sid1 <--------- MIPv4 Reg-Res w/MIPv4 = Auth Extensions <---- MIPv4 Reg-Res--------------------- (MIPv4 Reg-Req w/MIPv4 Auth Extensions) Figure 3. DIMPA based combined 802.11/Mobile-IP authentication 5. With 802.11 Pre-authentication To be added. 6. New IE, AVP, Mobile IP Extensions 6.1 New Information Elements in 802.11 Management Frames No new IE is required except those mentioned in [SIMIP].=20 6.2 New Diameter AVP's A new Diameter AVP is defined for the AP-to-MN key, MIP-AP-to-MN Key.=20 6.3 Mobile IP Extensions=20 No new Mobiel IP Extension is required, but a new sub-type, MN-AP=20 Authentication sub-type is defined. =20 7. Mobile Entity Implications There are some implications for the different mobile entities involved. 7.1 Implications for MN The MN should be capable of passing the MIPv4 information to the 802.11=20 driver and vice-versa. At the instant the MN is ready to send an=20 Association Request it should be able to access the MN's Mobile-IPv4=20 attributes. Similarly, when the MN receives an Association Response = there should be a mechanism to change the Mobile-IPv4 attributes in MN.=20 7.2 Implications for 802.11 AP The 802.11 AP should be able to extract/include the MIPv4-802.11 IE's.=20 7.3 Implications for FA To be added 7.4 Implications for AAAH To be added 7.5 Implications for AAAF To be added 8. Co-located FA To be added. 9. Miscellanious To be added 10. Acknowledgments All the RFC's, ID=C6s, freely available 802.11 standards, and Linux = web-sites. Dr. Bernard Aboba for many useful pointers. Also apologize for submitting a hastily prepared draft.=20 11. References [WiFi] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and=20 Physical Layer (PHY) Specifications", 1999. [MIPv4] Perkins, C., "IP Mobility Support", RFC 3220, January 2002. [WiFiTGi] IEEE, "802.11i Draft 2.3", 2002. [DIM] Calhoun, P et. al., "Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt, July = 2002. [DMIPA] Calhoun, P. et. al., "Diameter Mobile IPv4 Application",=20 draft-ietf-aaa-diameter-mobileip-12.txt, August 2002. [SIMIP] Goswami,S., "Simultaneous Handoff of 802.11 and Mobile IPv4", draft-goswami-mobileip-simultaneous-handoff-v4-01.txt, September = 2002. [MIPCR] Perkins,C., et.al., "Mobile IPv4 Challenge/Response Extensions", = November 2000. 8. Author's Address Subrata Goswami, Ph.D. Independent Consultant Newark, CA 94560 sgoswami@umich.edu This document expires February 25, 2003. ------=_NextPart_000_0001_01C265D3.DFF0F2D0-- From owner-aaa-wg@merit.edu Sun Sep 29 13:34:11 2002 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 NAA06601 for ; Sun, 29 Sep 2002 13:34:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1EC79120C; Sun, 29 Sep 2002 13:35:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A199D91213; Sun, 29 Sep 2002 13:35: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 7EFCB9120C for ; Sun, 29 Sep 2002 13:35:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C4895E261; Sun, 29 Sep 2002 13:35:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from momus.sc.intel.com (momus.sc.intel.com [143.183.152.8]) by segue.merit.edu (Postfix) with ESMTP id E0C315E240 for ; Sun, 29 Sep 2002 13:35:46 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g8THZGV20281 for ; Sun, 29 Sep 2002 17:35:31 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002092910361807357 ; Sun, 29 Sep 2002 10:36:18 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Sep 2002 10:34:50 -0700 Message-ID: From: "Qi, Emily H" To: mobile-ip@sunroof.eng.sun.com, aaa-wg@merit.edu Subject: [AAA-WG]: Is there any Diameter/RADIUS server available for Mobile IPv4 app lication? Date: Sun, 29 Sep 2002 10:34:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C267DE.82F5C260" 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_01C267DE.82F5C260 Content-Type: text/plain; charset="iso-8859-1" Hello, All, Do you know any Diameter/RADIUS server that supports (or is trying to support) Mobile IPv4 application? The draft draft-ietf-aaa-diameter-mobileip-XX.txt is for Diameter Mobile IPv4 application. Is there any draft that discusses RADIUS deployment in Mobile IP? I am planning to implement Mobile Node portion of the draft "AAA Registration Keys for Mobile IP" (draft-ietf-mobileip-aaa-key-09.txt) and looking for AAA servers to coordinate with. Best Regards, Emily Qi ------_=_NextPart_001_01C267DE.82F5C260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello, = All,

 

Do you know any Diameter/RADIUS server that = supports (or is trying to support) Mobile IPv4 application?  The draft draft-ietf-aaa-diameter-mobileip-XX.txt is = for Diameter Mobile IPv4 application. Is there any draft that discusses = RADIUS deployment in Mobile IP?

 

I am planning to implement Mobile Node = portion of the draft "AAA Registration Keys for Mobile IP" (draft-ietf-mobileip-aaa-key-09.txt) and looking for AAA servers to = coordinate with.

 

Best = Regards,

Emily Qi

 

=
------_=_NextPart_001_01C267DE.82F5C260--