From hannes.tschofenig@nsn.com Sun Nov 1 18:06:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32403A687F for ; Sun, 1 Nov 2009 18:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3ZYEO1v6ge3 for ; Sun, 1 Nov 2009 18:06:07 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id BCAC73A680A for ; Sun, 1 Nov 2009 18:06:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nA226M2G000411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2009 03:06:22 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nA226LEb008341 for ; Mon, 2 Nov 2009 03:06:21 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 03:06:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 04:09:35 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501D64FE7@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Agenda Thread-Index: AcpbYYZ7vAS3K4jQToOjBUP1uYTb8Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Nov 2009 02:06:21.0792 (UTC) FILETIME=[12BEA600:01CA5B61] Subject: [Dime] Updated Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 02:06:07 -0000 Hi all,=20 I have updated the agenda:=20 http://www.ietf.org/proceedings/09nov/agenda/dime.txt I have proposed a few presenters. Please let me know if this works for = you. Ciao Hannes --------------- * Status Update (Hannes) * Diameter ERP (S=E9bastien) http://www.ietf.org/id/draft-ietf-dime-erp-02.txt Goal: Discuss open issues.=20 * Realm-Based Redirection In Diameter (Tom) http://www.ietf.org/id/draft-ietf-dime-realm-based-redirect-02.txt Goal: Determine what is needed to finish the document.=20 * The Diameter Capabilities Update Application (Glen) http://www.ietf.org/id/draft-ietf-dime-capablities-update-00.txt Goal: Determine what is needed to finish the document.=20 * Diameter NAT Control Application (Sri Gundavelli) http://www.ietf.org/id/draft-ietf-dime-nat-control-01.txt Goal: Determine what is needed to finish the document.=20 Diameter User-Name and Realm Based Request Routing Clarifications = (Jouni) http://tools.ietf.org/html/draft-ietf-dime-nai-routing-04 Goal: Close remaining open issues. -- NEW / NON-WG DOCUMENTS Goal: Introduce them to the group and solicit feedback about interest in the group * Diameter Extended NAPTR (Jouni) http://tools.ietf.org/id/draft-jones-dime-extended-naptr-00.txt * Diameter Priority AVPs (Ken) http://tools.ietf.org/id/draft-carlberg-dime-priority-avps-00.txt * Diameter PCN (Fortune) http://tools.ietf.org/id/draft-huang-dime-pcn-collection-02.txt * Diameter Parameter Query (Ray) http://tools.ietf.org/id/draft-winterbottom-dime-param-query-01.txt From shwethab@cisco.com Mon Nov 2 08:59:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70BF128C186 for ; Mon, 2 Nov 2009 08:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OamDpZavDk4Z for ; Mon, 2 Nov 2009 08:59:01 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9D2B828C14A for ; Mon, 2 Nov 2009 08:59:01 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACqe7kqrR7H+/2dsb2JhbADGGpZohDwEglaJBg X-IronPort-AV: E=Sophos;i="4.44,668,1249257600"; d="scan'208";a="200584777" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 02 Nov 2009 16:59:21 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA2GxKdM014259; Mon, 2 Nov 2009 16:59:21 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:29:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 22:29:18 +0530 Message-ID: In-reply-to: <1A2514AA-F66C-49BB-AE70-34DF52F2A923@arsc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-nat-control-01.txt Thread-Index: AcpWiiTma6bwrYEbS1Kyq6oXwUFCdACrU9BQ References: <1A2514AA-F66C-49BB-AE70-34DF52F2A923@arsc.edu> From: "Shwetha Bhandari (shwethab)" To: "Melinda Shore" , "Frank Brockners (fbrockne)" , , X-OriginalArrivalTime: 02 Nov 2009 16:59:19.0591 (UTC) FILETIME=[D199FB70:01CA5BDD] Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-nat-control-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:59:02 -0000 Hi Melinda, Thanks for reviewing our draft!=20 We have reviewed other protocols in this space in a separate draft, and this includes MIDCOM and SIMCO: http://tools.ietf.org/html/draft-brockners-nat-control-protocols-review- 00=20 We will rework the security consideration section of our draft. We have refered in Section 11 and Section 5.1 of the draft to use Diameter over IPSec for mutually authenticating Diameter NAT control manager and agent. Adding dime group for suggestions on how we can update the draft to address your concern, as there are other application (e.g. Diameter QoS) that would have similar security considerations. Thanks, Shwetha -----Original Message----- From: Melinda Shore [mailto:shore@arsc.edu]=20 Sent: Tuesday, October 27, 2009 3:48 AM To: Frank Brockners (fbrockne); Shwetha Bhandari (shwethab); vaneeta@mavenir.com; vfajardo@research.telcordia.com Subject: draft-ietf-dime-nat-control-01.txt Hi, all: I enjoyed reading the draft. Because you didn't reference them it wasn't clear to me whether or not you were aware of prior work in this area, including the midcom protocol produced by the midcom working group a few years back (see RFCs 3303, 3304, 4097, 5189, and 5190), or the SIMCO protocol (RFC 4540). I also did a NAT/firewall application over DIAMETER while I was at Cisco a number of years ago but the midcom working group chose SNMP. I think DIAMETER is a fine choice although it may be easier to use a protocol that's already gone through the IETF process and been published as an RFC. Anyway, without going into protocol specifics I think the security considerations section needs to be beefed up quite a bit. In particular, while it's most typically the case that a client will authenticate to a server, for NAT control it's imperative that the server (NAT) authenticate itself to the client. The reason is that a fairly simple attack against a NAT control protocol is to inject a bogus response to a mapping request, which allows the attacker to redirect a data stream when the address is shared using a signaling mechanism (VoIP - I note that you reference the TISPAN work from ETSI). A possible mitigation is to authenticate the data stream in the application, but I do think that the possibility of server authentication should be included for deployments with stricter security requirements. Melinda Shore Arctic Region Supercomputer Center shore@arsc.edu From Hannes.Tschofenig@gmx.net Sun Nov 8 15:10:15 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5B73A683D for ; Sun, 8 Nov 2009 15:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwk5uCMfEuZD for ; Sun, 8 Nov 2009 15:10:13 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DBE903A682E for ; Sun, 8 Nov 2009 15:10:12 -0800 (PST) Received: (qmail invoked by alias); 08 Nov 2009 23:10:36 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp037) with SMTP; 09 Nov 2009 00:10:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/M3PIiu/nMTG97MAR61nM1R57uogQiIx6fiCF/JY j7kYK26l5F/RKl From: "Hannes Tschofenig" To: Date: Mon, 9 Nov 2009 08:13:53 +0900 Message-ID: <045301ca60c9$26842d50$4a3e000a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0454_01CA6114.966BD550" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpfr1heAaJDqCSnLkOcRL4JRUooiwBGbv9A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5,0.5 Subject: [Dime] Webex for Remote Participants X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 23:10:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0454_01CA6114.966BD550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ---------------------------------------------------------------------------- ---------------------------------------------- Topic: DIME WG Meeting Host: Marc Linsner Date and Time: November 9, 2009 9:00 am, Japan Standard Time (Hiroshima, GMT+09:00) Event number: 205 701 835 Event password: ietf ------------------------------------------------------- To join the online event ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/onstage/g.php?d=205701835 &t=a&EA=marc.linsner%40cisco.com&ET=212c0cf1accf7b861ce1b8119874e85f&ETR=de9 c7a3a3d4504f0b30fa77a2a4e3fdc&RT=MiMxMQ==&p 2. Click "Join Now". ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- Cost Savings Tips and Tricks ------------------------------------------------------- - Whenever possible, call the local number (if there is no charge to you). http://www.cisco.com/web/about/doing_business/conferencing/index.html ------------------------------------------------------- For assistance ------------------------------------------------------- You can contact Marc Linsner at: mlinsner@cisco.com The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ciscosales.webex.com/ciscosales/onstage/systemdiagnosis.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. ------=_NextPart_000_0454_01CA6114.966BD550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME WG Webex Attendee Invite
-------------------------------------------------------------------= -------------------------------------------------------

Topic: DIME = WG=20 Meeting
Host: Marc Linsner
Date and Time:
November 9, 2009 9:00 = am,=20 Japan Standard Time (Hiroshima, GMT+09:00)
Event number: 205 701 = 835
Event=20 password:=20 ietf

-------------------------------------------------------
To= join=20 the online=20 event
-------------------------------------------------------
1. = Go to=20 https://ciscosales.webex.com/ciscosales/onstage/g.php?d=3D= 205701835&t=3Da&EA=3Dmarc.linsner%40cisco.com&ET=3D212c0cf1ac= cf7b861ce1b8119874e85f&ETR=3Dde9c7a3a3d4504f0b30fa77a2a4e3fdc&RT=3D= MiMxMQ=3D=3D&p
2.=20 Click "Join=20 Now".

-------------------------------------------------------
T= o join=20 the teleconference=20 only
-------------------------------------------------------

1.= Dial=20 into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html
2.=20 Follow the prompts to enter the Meeting Number (listed above) or Access = Code=20 followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP:=20 +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom:=20 +44.20.8824.0117

India: +91.80.4350.1111 Germany: = +49.619.6773.9002=20

Japan: +81.3.5763.9394 China: +86.10.8515.5666=20

-------------------------------------------------------
Cost = Savings=20 Tips and Tricks =
-------------------------------------------------------=20

- Whenever possible, call the local number (if there is no = charge to=20 you). http://www.cisco.com/web/about/doing_business/conferencing/index.ht= ml=20

-------------------------------------------------------
For=20 assistance
-------------------------------------------------------
= You can=20 contact Marc Linsner at:
mlinsner@cisco.com

The = playback=20 of UCF (Universal Communications Format) rich media files requires = appropriate=20 players. To view this type of rich media files in the meeting, please = check=20 whether you have the players installed on your computer by going to = https://ciscosales.webex.com/ciscosales/onstage/systemdiagnosis.php


http://www.webex.com

= IMPORTANT=20 NOTICE: This WebEx service includes a feature that allows audio and any=20 documents and other materials exchanged or viewed during the session to = be=20 recorded. By joining this session, you automatically consent to such = recordings.=20 If you do not consent to the recording, do not join the session.=20

------=_NextPart_000_0454_01CA6114.966BD550-- From root@core3.amsl.com Sun Nov 8 21:00:02 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 439A628C0F5; Sun, 8 Nov 2009 21:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109050002.439A628C0F5@core3.amsl.com> Date: Sun, 8 Nov 2009 21:00:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol-mib-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol MIB Author(s) : G. Zorn, S. Comerica Filename : draft-ietf-dime-diameter-base-protocol-mib-03.txt Pages : 51 Date : 2009-11-08 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base-protocol-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-diameter-base-protocol-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08204544.I-D@ietf.org> --NextPart-- From bernard_aboba@hotmail.com Mon Nov 9 17:00:43 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE80D3A6959 for ; Mon, 9 Nov 2009 17:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sawga-lYIrpq for ; Mon, 9 Nov 2009 17:00:43 -0800 (PST) Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by core3.amsl.com (Postfix) with ESMTP id C3D413A682A for ; Mon, 9 Nov 2009 17:00:42 -0800 (PST) Received: from BLU137-DS2 ([65.55.116.9]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 17:01:09 -0800 X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'radext mailing list'" , Date: Mon, 9 Nov 2009 17:01:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CA615E.3B77FDA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphoUk7/yU7tggjQrSam6FoJtYnKw== Content-Language: en-us X-OriginalArrivalTime: 10 Nov 2009 01:01:09.0405 (UTC) FILETIME=[4A15C4D0:01CA61A1] Subject: [Dime] Problem with draft-wu-dime-local-keytran X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:00:43 -0000 ------=_NextPart_000_0022_01CA615E.3B77FDA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed draft-wu-dime-local-keytran and found an issue with it. The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP. According to the value of the EAP-Key-Type AVP, the type of key being sent (and therefore the EAP-Key-Name) will change. Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072. RFC 4072 Section 4.1.4 notes: The EAP-Key-Name AVP (Radius Attribute Type 102) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion). As noted in RFC 5247 Section 5.9, the EAP-Key-Name attribute contains the EAP-Session-Id, and followon standards such as IEEE 802.1X-REV depend on this attribute in order to obtain the EAP-Sesssion-Id utilized in subsequent cryptographic calculations. My concerns about this usage include: a. The inclusion of an existing RADIUS attribute within a Diameter Grouped AVP, thereby changing their meaning. The usage of grouping with existing RADIUS attributes has been discussed and rejected in RADEXT as part of the Extended Attributes work, due to concerns about backward compatibility. This document therefore represents an attempt to get around an objection raised in RADEXT via submission of a document in DIME. b. The updating of RFC 5247 by a non-standards track document in a WG that has no charter to revise EAP standards track documents. c. Conflicts between this document and work items on the RADEXT WG charter requested by IEEE 802.1 and referred to in the appendix of IEEE 802.1X-REV. ------=_NextPart_000_0022_01CA615E.3B77FDA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-wu-dime-local-keytran and = found an issue with it.

 

The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP.   According to = the value of the EAP-Key-Type AVP,

the type of key being sent (and therefore the = EAP-Key-Name) will change.

 

Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072.  RFC 4072 Section 4.1.4 = notes:

 

   The EAP-Key-Name AVP (Radius Attribute Type 102) is of = type

   OctetString.  It contains an opaque key identifier (name) = generated

   by the EAP method.  Exactly how this name is used depends on the = link

   layer in question, and is beyond the scope of this document = (see

   [EAPKey] for more discussion).

 

As noted in RFC 5247 Section 5.9, the EAP-Key-Name = attribute contains the EAP-Session-Id, and followon standards such

as IEEE 802.1X-REV depend on this attribute in = order to obtain the EAP-Sesssion-Id utilized in subsequent = cryptographic

calculations.   

 

My concerns about this usage = include:

 

a.       The inclusion of an existing RADIUS attribute = within a Diameter Grouped AVP, thereby changing their meaning.  The usage of grouping = with existing RADIUS attributes has been discussed and rejected in RADEXT as = part of the Extended Attributes work, due to concerns about backward = compatibility.   This document therefore represents an attempt to get around an = objection raised in RADEXT via submission of a document in DIME.

b.      The updating of RFC 5247 by a non-standards = track document in a WG that has no charter to revise EAP standards track = documents.

c.       Conflicts between this document and work items = on the RADEXT WG charter requested by IEEE 802.1 and referred to in the = appendix of IEEE 802.1X-REV.

 

------=_NextPart_000_0022_01CA615E.3B77FDA0-- From gwz@net-zen.net Tue Nov 10 18:40:43 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AFD3A67AF for ; Tue, 10 Nov 2009 18:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgmvtMQj1PAD for ; Tue, 10 Nov 2009 18:40:42 -0800 (PST) Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by core3.amsl.com (Postfix) with SMTP id 4576D3A676A for ; Tue, 10 Nov 2009 18:40:42 -0800 (PST) Received: (qmail 31575 invoked from network); 11 Nov 2009 02:41:10 -0000 Received: from unknown (133.93.114.32) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 11 Nov 2009 02:41:09 -0000 From: "Glen Zorn" To: "'Bernard Aboba'" References: In-Reply-To: Date: Wed, 11 Nov 2009 11:41:03 +0900 Organization: Network Zen Message-ID: <000601ca6278$6af2e020$40d8a060$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA62C3.DADA8820" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphoUk7/yU7tggjQrSam6FoJtYnKwA1L0oA Content-Language: en-us Cc: dime@ietf.org, 'radext mailing list' Subject: Re: [Dime] Problem with draft-wu-dime-local-keytran X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:40:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA62C3.DADA8820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: I have reviewed draft-wu-dime-local-keytran and found an issue with it. The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP. According to the value of the EAP-Key-Type AVP, the type of key being sent (and therefore the EAP-Key-Name) will change. Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072. RFC 4072 Section 4.1.4 notes: The EAP-Key-Name AVP (Radius Attribute Type 102) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion). As noted in RFC 5247 Section 5.9, the EAP-Key-Name attribute contains the EAP-Session-Id, and followon standards such as IEEE 802.1X-REV depend on this attribute in order to obtain the EAP-Sesssion-Id utilized in subsequent cryptographic calculations. My concerns about this usage include: a. The inclusion of an existing RADIUS attribute within a Diameter Grouped AVP, thereby changing their meaning. The usage of grouping with existing RADIUS attributes has been discussed and rejected in RADEXT as part of the Extended Attributes work, due to concerns about backward compatibility. This document therefore represents an attempt to get around an objection raised in RADEXT via submission of a document in DIME. I'm afraid that you are mistaken about this: I'm quite certain that the last thing anyone wants is to extend the RADIUS protocol in any IETF WG. In particular, I have absolutely no interest in any further work on RADIUS: it's dead, and radext is just hammering the final few nails in the coffin. In any case, no problem: it was pointed out in yesterday's dime session that to prefix the AVP names in our draft with "EAP-" is entirely too limiting. Therefore, we will be changing the names and not re-using the Diameter AVP in question. b. The updating of RFC 5247 by a non-standards track document in a WG that has no charter to revise EAP standards track documents. c. Conflicts between this document and work items on the RADEXT WG charter requested by IEEE 802.1 and referred to in the appendix of IEEE 802.1X-REV. ------=_NextPart_000_0007_01CA62C3.DADA8820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes:

I have reviewed draft-wu-dime-local-keytran and = found an issue with it.

 

The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP.   According to = the value of the EAP-Key-Type AVP,

the type of key being sent (and therefore the = EAP-Key-Name) will change.

 

Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072.  RFC 4072 Section 4.1.4 = notes:

 

   The EAP-Key-Name AVP (Radius Attribute Type 102) is of = type

   OctetString.  It contains an opaque key identifier (name) = generated

   by the EAP method.  Exactly how this name is used depends on the = link

   layer in question, and is beyond the scope of this document = (see

   [EAPKey] for more discussion).

 

As noted in RFC 5247 Section 5.9, the EAP-Key-Name = attribute contains the EAP-Session-Id, and followon standards such

as IEEE 802.1X-REV depend on this attribute in = order to obtain the EAP-Sesssion-Id utilized in subsequent = cryptographic

calculations.   

 

My concerns about this usage = include:

 

a.       The inclusion of an existing RADIUS attribute = within a Diameter Grouped AVP, thereby changing their meaning.  The usage of grouping with existing RADIUS attributes has been discussed and rejected = in RADEXT as part of the Extended Attributes work, due to concerns about = backward compatibility.   This document therefore represents an attempt = to get around an objection raised in RADEXT via submission of a document in = DIME.

I'm afraid that you are mistaken about this: I'm quite = certain that the last thing anyone wants is to extend the RADIUS protocol in = any IETF WG.  In particular, I have absolutely no interest in any = further work on RADIUS: it's dead, and radext is just hammering the final few nails = in the coffin.  In any case, no problem: it was pointed out in yesterday's = dime session that to prefix the AVP names in our draft with "EAP-" = is entirely too limiting.  Therefore, we will be changing the names = and not re-using the Diameter AVP in question.

b.      The updating of RFC 5247 by a non-standards = track document in a WG that has no charter to revise EAP standards track = documents.

c.       Conflicts between this document and work items = on the RADEXT WG charter requested by IEEE 802.1 and referred to in the = appendix of IEEE 802.1X-REV.

 

------=_NextPart_000_0007_01CA62C3.DADA8820-- From Hannes.Tschofenig@gmx.net Mon Nov 16 07:10:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DE43A697F for ; Mon, 16 Nov 2009 07:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9wK-nlfT4g2 for ; Mon, 16 Nov 2009 07:10:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B03AD3A6876 for ; Mon, 16 Nov 2009 07:10:56 -0800 (PST) Received: (qmail invoked by alias); 16 Nov 2009 15:10:53 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp046) with SMTP; 16 Nov 2009 16:10:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/90ZRgQPP9tYU8iM+oD2sltES2hNLnIpRcOWe3+D 5xEgtWZ5PsSFUj From: "Hannes Tschofenig" To: Date: Mon, 16 Nov 2009 17:14:12 +0200 Message-ID: <000001ca66cf$75efe580$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpmz3P9Wc3GplghQxeRv+PHZh+w2Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Dime] DIME Meeting Notes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:10:57 -0000 Hi all, Here are the meeting minutes from the DIME WG meeting: http://www.ietf.org/proceedings/09nov/minutes/dime.txt Thanks to Jouni for the writeup. Ciao Hannes From sdecugis@nict.go.jp Mon Nov 16 21:22:09 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD853A689C for ; Mon, 16 Nov 2009 21:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bN8Rmn4RKev for ; Mon, 16 Nov 2009 21:22:08 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 40E573A6858 for ; Mon, 16 Nov 2009 21:22:07 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id nAH5M5hf018541 for ; Tue, 17 Nov 2009 14:22:05 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id nAH5M5LM020647 for ; Tue, 17 Nov 2009 14:22:05 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id nAH5M59V020644 for ; Tue, 17 Nov 2009 14:22:05 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1F9B515FD2 for ; Tue, 17 Nov 2009 14:22:05 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1A2B115F94 for ; Tue, 17 Nov 2009 14:22:05 +0900 (JST) Message-ID: <4B0232F5.3030805@nict.go.jp> Date: Tue, 17 Nov 2009 14:21:57 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Need to know the location of a roaming peer? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 05:22:09 -0000 Hello all, During the last meeting (thanks Hannes and Jouni for the minutes) there was a discussion about the need (or absence of need) to notify the home domain when a peer changes its authenticator in a visited domain. During the discussion on ERP, my understanding of the conclusion was that we should do the re-authentication locally when possible in the visited domain, without going back to home domain. Then, in case new authorization attributes are needed, we have a separate exchange with the home realm to fetch these fresh authorization attributes, after the authentication is performed. Later during the session, a remark on emergency services (related to Diameter Parameter Query draft if I am not mistaken) sent the question back on the table, highlighting that in some contexts we may want to query the home server for the current location of the user. I am wondering, if the peer can move without the home server being notified (we assume server-initiated messages are routed transparently to the correct recipient) then the design of such query mechanism will be affected and complexity added. I would like to ask the list if there is strong concerns with "hiding" the current authenticator of a roaming user to the home server, the result being that the home realm only knows the current location with a granularity of the realm (inter-realm handovers should still have to go to the home realm, AFAIU). PS: I am wondering, in the context of emergency services, if we are really interested by the authenticator or by the point of attachment for the given peer, as I understand there is a difference in some deployment schemes... Thank you for any comment, Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Tue Nov 17 19:43:49 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EBE28C0E3 for ; Tue, 17 Nov 2009 19:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_05=-1.11, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3x5L25Qi4gJ for ; Tue, 17 Nov 2009 19:43:48 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 1C8613A67AE for ; Tue, 17 Nov 2009 19:43:47 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id nAI3hj3M020691 for ; Wed, 18 Nov 2009 12:43:45 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id nAI3hjIG001316 for ; Wed, 18 Nov 2009 12:43:45 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id nAI3hjWt001312 for ; Wed, 18 Nov 2009 12:43:45 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 184F115EF1 for ; Wed, 18 Nov 2009 12:43:45 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id EAF9515ED3 for ; Wed, 18 Nov 2009 12:43:44 +0900 (JST) Message-ID: <4B036D6A.4070202@nict.go.jp> Date: Wed, 18 Nov 2009 12:43:38 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Review of draft-ietf-dime-realm-based-redirect-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:43:49 -0000 Hello all, Here is my review for the realm-based redirect document. My main comment is about the new application Id, I think the document needs more clarification. I have several comments related to this point: - first of all, the advertisement of the application id is a "one hop" mechanism in Diameter, during CER/CEA exchange. It would be useful to clarify if we are limiting the realm-redirect to a single hop. My understanding of RFC3588 redirect is that it will go back to the source of the request, unless some relay interprets the content of the error message (since the E bit is set). I would have assumed the same for realm redirections, but I know some people advocated for a separate application id -- it is just that I don't really understand how it is used. - a corollary of the previous comment is that the document does not specify how the new Application Id is used. My understanding from the abstract is that we advertise the new application id during CER/CEA exchange, inside a Auth-Application-Id AVP (this is a wild guess from me). What happens if the other peer does not advertize the same application, are we still allowed to use the realm-based redirect mechanism ? Do we default to a host-based redirect? What if the peer advertized the relay application ? These questions should be answered by the document. Here is the remaining of my comments, mostly editorial, except for the usage part: In paragraph 2, I think "client" is not appropriate. What about "peer" instead ? In paragraph 3, I think the value of the error code will be allocated by IANA right ? (RFC3588 says IETF consensus, I am not sure what it means). I believe the text should simply contain something like "3xxx TBD". In paragraph 3.1.1, the Redirect-Max-Cache-Time AVP is told to indicate the "scope" and persistance of... but I don't understand the word "scope" here, maybe a remain from previous version ? In same paragraph, "the Result-Code AVP MUST include the Error-Reporting-Host AVP" is erroneous, since Result-Code is not a grouped AVP. I would rephrase to something like "The Error-Reporting-Host AVP must be included in the message along the Result-Code AVP... ". In paragraph 3.1.2, the redirect usage of ALL_REALM. I think this conflicts with the rationale for the document presented in the introduction, where an operator would stop providing a service. In that case, we would more likely need a redirect usage of REALM_AND_APPLICATION or even maybe ALL_APPLICATION, right? So that messages that belong to a different application are still routed to our servers. In paragraph 3.2, I believe the document should mention if several instances of the Redirect-Realm AVP can be present in the same message, and how this situation must be interpreted (probably the same as if several Redirect-Host are present, I would assume...) In paragraph 4, there is a small typo: "Because real-based..." should read "Because realm-based..." In paragraph 5, same comment as paragraph 3, I am not sure the document should already provide some values for the IANA managed registries... That's all I have :) Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Tue Nov 17 23:27:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE03F3A6A6C for ; Tue, 17 Nov 2009 23:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.515 X-Spam-Level: * X-Spam-Status: No, score=1.515 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_05=-1.11, HELO_EQ_JP=1.244, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEJ7deyLjCuO for ; Tue, 17 Nov 2009 23:27:58 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 670203A689A for ; Tue, 17 Nov 2009 23:27:57 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id nAI7Rr7B012262 for ; Wed, 18 Nov 2009 16:27:53 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id nAI7Rr5Q012201 for ; Wed, 18 Nov 2009 16:27:53 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id nAI7RrZn012198 for ; Wed, 18 Nov 2009 16:27:53 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 1EF8C15F3A for ; Wed, 18 Nov 2009 16:27:53 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 18E0015E54 for ; Wed, 18 Nov 2009 16:27:53 +0900 (JST) Message-ID: <4B03A1EE.200@nict.go.jp> Date: Wed, 18 Nov 2009 16:27:42 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Review of draft-ietf-dime-app-design-guide-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 07:27:59 -0000 Hello again, Here is my review of the Application Design Guideline document. The section 6.1. "Adding AVPs to a Command" seems to be mixing the mandatory AVPs (with their M bit set) with the required AVP (from the parent's ABNF), with regards to defining a new application or not. The confusion is increased by the "optional AVP" meaning both an AVP with the M bit cleared, or an AVP specified in the ABNF with the '[' ']' qualifiers. A different wording might help to clarify. Some editorial comments: In 1. Introduction : - first reference to section 1.2 of rfc3588bis should actually be 1.3 (in version -18 of the bis document) - the sentence "All of these choices are design decisions that can done by any..." sounds strange to me, but I am not native. I am wondering anyway if a word is not missing before the 'done' ? - "functionalitiessi" (second bullet by the end of introduction) In 3. Overview : - in the Major Extension definition, the reference to rfc3588bis should also point to 1.3. In 6.1 : - 1st bullet, 2nd sentence, the sentence sounds strange to me (again, I am not native, sorry if my comment is inappropriate) - 2nd bullet: Does the TBD refers to the definition of the optional AVP ? - "A mandatory AVP cannot be added to or deleted from an existing command with defining a new Diameter application." If my understanding is correct, it should read "without" here. In 10, page 10, last paragraph, 5th line: "has to be have a method" the "be" should be removed. That is all my comments; the document is very helpful in my opinion! Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From w52006@huawei.com Wed Nov 25 17:07:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3D43A680C for ; Wed, 25 Nov 2009 17:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.914 X-Spam-Level: * X-Spam-Status: No, score=1.914 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raQsohFiHK14 for ; Wed, 25 Nov 2009 17:07:04 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 333853A67BD for ; Wed, 25 Nov 2009 17:07:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTO00J46Z38KH@szxga04-in.huawei.com> for dime@ietf.org; Thu, 26 Nov 2009 09:06:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTO00MRZZ383R@szxga04-in.huawei.com> for dime@ietf.org; Thu, 26 Nov 2009 09:06:44 +0800 (CST) Received: from w52006e ([10.164.12.19]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTO00D1QZ380Z@szxml06-in.huawei.com> for dime@ietf.org; Thu, 26 Nov 2009 09:06:44 +0800 (CST) Date: Thu, 26 Nov 2009 09:06:43 +0800 From: w52006 In-reply-to: <4B0232F5.3030805@nict.go.jp> To: 'Sebastien Decugis' , dime@ietf.org Message-id: <00eb01ca6e34$b8493280$130ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpnRkI6C9jvkrc8RnmJbRzPOwXXawG7ATEQ Subject: Re: [Dime] Need to know the location of a roaming peer? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:07:05 -0000 Hello Mostly I agree your concern too. Please see one comment as below... B.R. Yungui Wang > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Sebastien Decugis > Sent: Tuesday, November 17, 2009 1:22 PM > To: dime@ietf.org > Subject: [Dime] Need to know the location of a roaming peer? > > Hello all, > > During the last meeting (thanks Hannes and Jouni for the > minutes) there > was a discussion about the need (or absence of need) to > notify the home > domain when a peer changes its authenticator in a visited > domain. During > the discussion on ERP, my understanding of the conclusion was that we > should do the re-authentication locally when possible in the visited > domain, without going back to home domain. > Then, in case new > authorization attributes are needed, we have a separate exchange with > the home realm to fetch these fresh authorization attributes, > after the authentication is performed. As described In section 5.3 of RFC5296, the realm part of keyName-NAI is the local (ER server's) domain name. How can the new NAS know that the authorization attributes should be freshed to the home server? Does other entity (e.g. the ER server) do? In addition, when the peer moves to the new NAS, the old NAS should delete the original authentication session with the home server. In this way, is it acceptable for home server without peer's authentication session while new authorization session is freshed/reserved? > > Later during the session, a remark on emergency services (related to > Diameter Parameter Query draft if I am not mistaken) sent the question > back on the table, highlighting that in some contexts we may want to > query the home server for the current location of the user. I am > wondering, if the peer can move without the home server being notified > (we assume server-initiated messages are routed transparently to the > correct recipient) then the design of such query mechanism will be > affected and complexity added. > > I would like to ask the list if there is strong concerns with "hiding" > the current authenticator of a roaming user to the home server, the > result being that the home realm only knows the current > location with a > granularity of the realm (inter-realm handovers should still > have to go > to the home realm, AFAIU). > > PS: I am wondering, in the context of emergency services, if we are > really interested by the authenticator or by the point of > attachment for > the given peer, as I understand there is a difference in some > deployment > schemes... > > Thank you for any comment, > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From tom111.taylor@bell.net Fri Nov 27 08:45:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA583A684D for ; Fri, 27 Nov 2009 08:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJs2hxHCPhyS for ; Fri, 27 Nov 2009 08:45:09 -0800 (PST) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by core3.amsl.com (Postfix) with ESMTP id 55CF23A6829 for ; Fri, 27 Nov 2009 08:45:09 -0800 (PST) Received: from BLU0-SMTP66 ([65.55.116.73]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 08:45:03 -0800 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP66.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 08:45:03 -0800 Date: Fri, 27 Nov 2009 11:44:58 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sebastien Decugis References: <4B036D6A.4070202@nict.go.jp> In-Reply-To: <4B036D6A.4070202@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2009 16:45:03.0167 (UTC) FILETIME=[F775CCF0:01CA6F80] Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:45:10 -0000 Thanks for your solid review. I'm moving slowly on my post-meeting obligations, as the result of catching a nasty cold on the way back from Japan. I left the "non-functional misery" stage somewhere around last Tuesday, but I'm still looking forward to leaving the "functional misery" stage. Yeah, I'm feeling sorry for myself. Sebastien Decugis wrote: > Hello all, > > Here is my review for the realm-based redirect document. My main comment > is about the new application Id, I think the document needs more > clarification. I have several comments related to this point: > - first of all, the advertisement of the application id is a "one hop" > mechanism in Diameter, during CER/CEA exchange. It would be useful to > clarify if we are limiting the realm-redirect to a single hop. My > understanding of RFC3588 redirect is that it will go back to the source > of the request, unless some relay interprets the content of the error > message (since the E bit is set). I would have assumed the same for > realm redirections, but I know some people advocated for a separate > application id -- it is just that I don't really understand how it is used. > - a corollary of the previous comment is that the document does not > specify how the new Application Id is used. My understanding from the > abstract is that we advertise the new application id during CER/CEA > exchange, inside a Auth-Application-Id AVP (this is a wild guess from > me). What happens if the other peer does not advertize the same > application, are we still allowed to use the realm-based redirect > mechanism ? Do we default to a host-based redirect? What if the peer > advertized the relay application ? These questions should be answered by > the document. > > Here is the remaining of my comments, mostly editorial, except for the > usage part: > In paragraph 2, I think "client" is not appropriate. What about "peer" > instead ? > > In paragraph 3, I think the value of the error code will be allocated by > IANA right ? (RFC3588 says IETF consensus, I am not sure what it means). > I believe the text should simply contain something like "3xxx TBD". > > In paragraph 3.1.1, the Redirect-Max-Cache-Time AVP is told to indicate > the "scope" and persistance of... but I don't understand the word > "scope" here, maybe a remain from previous version ? > In same paragraph, "the Result-Code AVP MUST include the > Error-Reporting-Host AVP" is erroneous, since Result-Code is not a > grouped AVP. I would rephrase to something like "The > Error-Reporting-Host AVP must be included in the message along the > Result-Code AVP... ". > > In paragraph 3.1.2, the redirect usage of ALL_REALM. I think this > conflicts with the rationale for the document presented in the > introduction, where an operator would stop providing a service. In that > case, we would more likely need a redirect usage of > REALM_AND_APPLICATION or even maybe ALL_APPLICATION, right? So that > messages that belong to a different application are still routed to our > servers. > > In paragraph 3.2, I believe the document should mention if several > instances of the Redirect-Realm AVP can be present in the same message, > and how this situation must be interpreted (probably the same as if > several Redirect-Host are present, I would assume...) > > In paragraph 4, there is a small typo: "Because real-based..." should > read "Because realm-based..." > > In paragraph 5, same comment as paragraph 3, I am not sure the document > should already provide some values for the IANA managed registries... > > That's all I have :) > > Best regards, > Sebastien. > From tom111.taylor@bell.net Fri Nov 27 08:49:41 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CB93A684D for ; Fri, 27 Nov 2009 08:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR0V-NbuakIf for ; Fri, 27 Nov 2009 08:49:41 -0800 (PST) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by core3.amsl.com (Postfix) with ESMTP id 0918F3A6784 for ; Fri, 27 Nov 2009 08:49:40 -0800 (PST) Received: from BLU0-SMTP55 ([65.55.116.74]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 08:49:35 -0800 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP55.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 08:49:34 -0800 Date: Fri, 27 Nov 2009 11:49:30 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hannes Tschofenig References: <000001ca66cf$75efe580$03ffa8c0@nsnintra.net> In-Reply-To: <000001ca66cf$75efe580$03ffa8c0@nsnintra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2009 16:49:35.0147 (UTC) FILETIME=[9992A7B0:01CA6F81] Cc: dime@ietf.org Subject: Re: [Dime] DIME Meeting Notes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:49:41 -0000 In the discussion of the ERP draft, didn't we at some point realize that a change of authenticator could be accompanied by a change of service needing authorization? This doesn't change the basic conclusion that authentication and authorization should be separate steps, but should it be mentioned? Maybe change Hannes' initial summary from "home domain does not need to be aware" to "home domain does not need to be aware unless change of service involved". Hannes Tschofenig wrote: > Hi all, > > Here are the meeting minutes from the DIME WG meeting: > http://www.ietf.org/proceedings/09nov/minutes/dime.txt > > Thanks to Jouni for the writeup. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From dromasca@avaya.com Mon Nov 30 07:01:43 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67FE3A695A for ; Mon, 30 Nov 2009 07:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XGbgFiS-H8s for ; Mon, 30 Nov 2009 07:01:42 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 6A3ED3A68E2 for ; Mon, 30 Nov 2009 07:01:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,314,1257138000"; d="scan'208";a="192083033" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Nov 2009 10:01:34 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Nov 2009 10:01:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 16:01:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC4005 (1946) Thread-Index: AcpuHmW5H4bUTBmxSu2WmmiURo0EegDr11kA From: "Romascanu, Dan (Dan)" To: Cc: Ron Bonica Subject: [Dime] FW: [Technical Errata Reported] RFC4005 (1946) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 15:01:43 -0000 DIME WG, Please advice on this errata submitted by Avi Lior.=20 Dan -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Thursday, November 26, 2009 12:26 AM To: pcalhoun@cisco.com; gwz@cisco.com; dspence@computer.org; dmitton@circularnetworks.com; Romascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com; david@mitton.com; john.loughney@nokia.com Cc: avi@bridgewatersystems.com; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC4005 (1946) The following errata report has been submitted for RFC4005, "Diameter Network Access Server Application". -------------------------------------- You may review the report below and at: http://rfc-editor.org/errata_search.php?rfc=3D4005&eid=3D1946 -------------------------------------- Type: Technical Reported by: Avi Lior Section: 9.2 Original Text ------------- If the Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets, or Accounting-Output-Packets AVPs are present, they must be translated to the corresponding RADIUS attributes. If the value of the Diameter AVPs do not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input- Gigawords and Acct-Output-Gigawords must be used. Corrected Text -------------- If the Accounting-Input-Octets,=20 Accounting-Output-Octets, AVPs are present, they must be translated to the corresponding RADIUS attributes. If the value of the Diameter AVPs do not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input- Gigawords and Acct-Output-Gigawords must be used. Notes ----- The last sentence of the original text causes confusion because according to RFC2869, the Acct-Input/Output-Gigawords are only overflows for the Acct-Input/Output-Octet attributes. =20 THE ABOVE CORRECTION BASICALLY DOES NOT PROVIDE FOR OVERFLOW FOR THE PACKET COUNTERS. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC4005 (draft-ietf-aaa-diameter-nasreq-17) -------------------------------------- Title : Diameter Network Access Server Application Publication Date : August 2005 Author(s) : P. Calhoun, G. Zorn, D. Spence, D. Mitton Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG