From dromasca@avaya.com Tue Nov 2 02:41:02 2010 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 CA5D528C146 for ; Tue, 2 Nov 2010 02:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Ld-TIsGOJnqm for ; Tue, 2 Nov 2010 02:40:59 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 14E983A69A9 for ; Tue, 2 Nov 2010 02:40:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFABN5z0zGmAcF/2dsb2JhbACWTYsacaUNAplzgwQIgjkEjXaCUw X-IronPort-AV: E=Sophos;i="4.58,281,1286164800"; d="scan'208";a="43629297" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 02 Nov 2010 05:39:58 -0400 X-IronPort-AV: E=Sophos;i="4.58,281,1286164800"; d="scan'208";a="535578271" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Nov 2010 05:39:56 -0400 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: Tue, 2 Nov 2010 10:39:35 +0100 Message-ID: In-Reply-To: <20101029171414.2767F3A686A@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 Thread-Index: Act3jQd34CI/H4wvREqsKQyNPE6j5QC5C+NA References: <20101029171414.2767F3A686A@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: , , , Cc: housley@vigilsec.com, rbonica@juniper.net, dime@ietf.org, jouni.korhonen@nsn.com Subject: Re: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 09:41:02 -0000 DIME chairs, This IPR filling leads to the need for the community to reconsider the document in the context of the disclosure. My suggestion is to start immediately and in parallel a Working Group Last Call and an IETF Last Call pointing to the fact that the document text is the same as in the last IETF LC, but the community is asked to reconsider the consensus taking into account the IPR disclosure. If we start the Last Calls today we still can make it for the 11/18 IESG telechat.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org]=20 > Sent: Friday, October 29, 2010 7:14 PM > To: gwz@net-zen.net; jari.arkko@piuha.net;=20 > john.loughney@nokia.com; vf0213@gmail.com > Cc: Romascanu, Dan (Dan); rbonica@juniper.net; dime@ietf.org;=20 > lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com;=20 > ipr-announce@ietf.org; housley@vigilsec.com > Subject: IPR Disclosure: Nokia Corporation's Statement about=20 > IPR related to draft-ietf-dime-rfc3588bis-25 >=20 > Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: >=20 > An IPR disclosure that pertains to your Internet-Draft=20 > entitled "Diameter Base Protocol"=20 > (draft-ietf-dime-rfc3588bis) was submitted to the IETF Secretariat on > 2010-10-29 and has been posted on the "IETF Page of=20 > Intellectual Property Rights Disclosures"=20 > (https://datatracker.ietf.org/ipr/1437/). The title of the=20 > IPR disclosure is "Nokia Corporation's Statement about IPR=20 > related to draft-ietf-dime-rfc3588bis-25." >=20 > The IETF Secretariat >=20 >=20 >=20 From jari.arkko@piuha.net Tue Nov 2 02:50:18 2010 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 0B5993A68CF for ; Tue, 2 Nov 2010 02:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 v1Y3tFElw6NI for ; Tue, 2 Nov 2010 02:50:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8F6253A67F7 for ; Tue, 2 Nov 2010 02:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A340F2CC47; Tue, 2 Nov 2010 11:50:19 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cv-gbxzEcZG; Tue, 2 Nov 2010 11:50:18 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B0C162CC32; Tue, 2 Nov 2010 11:50:18 +0200 (EET) Message-ID: <4CCFDEDA.6010200@piuha.net> Date: Tue, 02 Nov 2010 11:50:18 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20101029171414.2767F3A686A@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbonica@juniper.net, housley@vigilsec.com, dime@ietf.org, jouni.korhonen@nsn.com Subject: Re: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 09:50:18 -0000 Hmm... I'll note that RFC 3588 had IPR from Nokia as well: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3588 But I have not looked at the details. Is this a re-statement of the same IPR with same conditions, of have things really changed? If just a re-statement, perhaps it would be enough to point out to the working group that the disclosure has been filed (and the WG has already gotten a message), and respond to the IETF Last Call message stating the same. Jari Romascanu, Dan (Dan) kirjoitti: > DIME chairs, > > This IPR filling leads to the need for the community to reconsider the > document in the context of the disclosure. My suggestion is to start > immediately and in parallel a Working Group Last Call and an IETF Last > Call pointing to the fact that the document text is the same as in the > last IETF LC, but the community is asked to reconsider the consensus > taking into account the IPR disclosure. If we start the Last Calls today > we still can make it for the 11/18 IESG telechat. > > Thanks and Regards, > > Dan > > > >> -----Original Message----- >> From: IETF Secretariat [mailto:ietf-ipr@ietf.org] >> Sent: Friday, October 29, 2010 7:14 PM >> To: gwz@net-zen.net; jari.arkko@piuha.net; >> john.loughney@nokia.com; vf0213@gmail.com >> Cc: Romascanu, Dan (Dan); rbonica@juniper.net; dime@ietf.org; >> lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com; >> ipr-announce@ietf.org; housley@vigilsec.com >> Subject: IPR Disclosure: Nokia Corporation's Statement about >> IPR related to draft-ietf-dime-rfc3588bis-25 >> >> Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: >> >> An IPR disclosure that pertains to your Internet-Draft >> entitled "Diameter Base Protocol" >> (draft-ietf-dime-rfc3588bis) was submitted to the IETF Secretariat on >> 2010-10-29 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1437/). The title of the >> IPR disclosure is "Nokia Corporation's Statement about IPR >> related to draft-ietf-dime-rfc3588bis-25." >> >> The IETF Secretariat >> >> >> >> > > From jouni.korhonen@nsn.com Tue Nov 2 02:55:16 2010 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 EE3BE3A6872 for ; Tue, 2 Nov 2010 02:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 i5WAHhV0aDVf for ; Tue, 2 Nov 2010 02:55:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 528E03A68BC for ; Tue, 2 Nov 2010 02:55:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oA29t7Xh030327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Nov 2010 10:55:07 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oA29t3XO019470; Tue, 2 Nov 2010 10:55:07 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 10:54:56 +0100 Received: from 10.144.240.63 ([10.144.240.63]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc024.nsn-intra.net ([10.159.32.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Nov 2010 09:54:55 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Tue, 02 Nov 2010 11:54:54 +0200 From: Jouni Korhonen To: ext Jari Arkko , "Romascanu, Dan (Dan)" Message-ID: Thread-Topic: IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 Thread-Index: Act6c/+zdJ2Ij7S16Ui2El4TxRH8fQ== In-Reply-To: <4CCFDEDA.6010200@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Nov 2010 09:54:56.0746 (UTC) FILETIME=[0156ECA0:01CB7A74] Cc: rbonica@juniper.net, housley@vigilsec.com, dime@ietf.org Subject: Re: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 09:55:16 -0000 This new declaration and the older one from 2004 are for the same EP patent. - Jouni On 11/2/10 11:50 AM, "ext Jari Arkko" wrote: > Hmm... I'll note that RFC 3588 had IPR from Nokia as well: > > https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3588 > > But I have not looked at the details. Is this a re-statement of the same > IPR with same conditions, of have things really changed? If just a > re-statement, perhaps it would be enough to point out to the working > group that the disclosure has been filed (and the WG has already gotten > a message), and respond to the IETF Last Call message stating the same. > > Jari > > Romascanu, Dan (Dan) kirjoitti: >> DIME chairs, >> >> This IPR filling leads to the need for the community to reconsider the >> document in the context of the disclosure. My suggestion is to start >> immediately and in parallel a Working Group Last Call and an IETF Last >> Call pointing to the fact that the document text is the same as in the >> last IETF LC, but the community is asked to reconsider the consensus >> taking into account the IPR disclosure. If we start the Last Calls today >> we still can make it for the 11/18 IESG telechat. >> >> Thanks and Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: IETF Secretariat [mailto:ietf-ipr@ietf.org] >>> Sent: Friday, October 29, 2010 7:14 PM >>> To: gwz@net-zen.net; jari.arkko@piuha.net; >>> john.loughney@nokia.com; vf0213@gmail.com >>> Cc: Romascanu, Dan (Dan); rbonica@juniper.net; dime@ietf.org; >>> lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com; >>> ipr-announce@ietf.org; housley@vigilsec.com >>> Subject: IPR Disclosure: Nokia Corporation's Statement about >>> IPR related to draft-ietf-dime-rfc3588bis-25 >>> >>> Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: >>> >>> An IPR disclosure that pertains to your Internet-Draft >>> entitled "Diameter Base Protocol" >>> (draft-ietf-dime-rfc3588bis) was submitted to the IETF Secretariat on >>> 2010-10-29 and has been posted on the "IETF Page of >>> Intellectual Property Rights Disclosures" >>> (https://datatracker.ietf.org/ipr/1437/). The title of the >>> IPR disclosure is "Nokia Corporation's Statement about IPR >>> related to draft-ietf-dime-rfc3588bis-25." >>> >>> The IETF Secretariat >>> >>> >>> >>> >> >> > From dromasca@avaya.com Tue Nov 2 02:59:19 2010 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 282033A68BC for ; Tue, 2 Nov 2010 02:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UiRRnUA5bO4U for ; Tue, 2 Nov 2010 02:59:13 -0700 (PDT) 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 48A6728C0E3 for ; Tue, 2 Nov 2010 02:59:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAMJ9z0yHCzI1/2dsb2JhbACWTYsacaUAApl2gwQIgjkEjXaCUw X-IronPort-AV: E=Sophos;i="4.58,281,1286164800"; d="scan'208";a="248020901" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Nov 2010 05:59:16 -0400 X-IronPort-AV: E=Sophos;i="4.58,281,1286164800"; d="scan'208";a="532549025" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Nov 2010 05:59:15 -0400 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: Tue, 2 Nov 2010 10:59:13 +0100 Message-ID: In-Reply-To: <4CCFDEDA.6010200@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 Thread-Index: Act6c163rF6TO1yVRJWWHfl4Vhd4/wAAJoyg References: <20101029171414.2767F3A686A@core3.amsl.com> <4CCFDEDA.6010200@piuha.net> From: "Romascanu, Dan (Dan)" To: "Jari Arkko" Cc: rbonica@juniper.net, housley@vigilsec.com, dime@ietf.org, jouni.korhonen@nsn.com Subject: Re: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 09:59:19 -0000 The patent number in the new disclosure is one of the many present in the disclosure related to 3588, but the text related to the licensing conditions is not identical. A different disclosure is a different disclosure, and I think it is safer to have the community look at the new disclosure.=20 Dan > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, November 02, 2010 11:50 AM > To: Romascanu, Dan (Dan) > Cc: gwz@net-zen.net; john.loughney@nokia.com;=20 > vf0213@gmail.com; rbonica@juniper.net; dime@ietf.org;=20 > lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com;=20 > housley@vigilsec.com > Subject: Re: IPR Disclosure: Nokia Corporation's Statement=20 > about IPR related to draft-ietf-dime-rfc3588bis-25 >=20 > Hmm... I'll note that RFC 3588 had IPR from Nokia as well: >=20 > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc > _search=3D3588 >=20 > But I have not looked at the details. Is this a re-statement=20 > of the same IPR with same conditions, of have things really=20 > changed? If just a re-statement, perhaps it would be enough=20 > to point out to the working group that the disclosure has=20 > been filed (and the WG has already gotten a message), and=20 > respond to the IETF Last Call message stating the same. >=20 > Jari >=20 > Romascanu, Dan (Dan) kirjoitti: > > DIME chairs, > > > > This IPR filling leads to the need for the community to=20 > reconsider the=20 > > document in the context of the disclosure. My suggestion is=20 > to start=20 > > immediately and in parallel a Working Group Last Call and=20 > an IETF Last=20 > > Call pointing to the fact that the document text is the=20 > same as in the=20 > > last IETF LC, but the community is asked to reconsider the=20 > consensus=20 > > taking into account the IPR disclosure. If we start the Last Calls=20 > > today we still can make it for the 11/18 IESG telechat. > > > > Thanks and Regards, > > > > Dan > > =20 > > > > =20 > >> -----Original Message----- > >> From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > >> Sent: Friday, October 29, 2010 7:14 PM > >> To: gwz@net-zen.net; jari.arkko@piuha.net;=20 > john.loughney@nokia.com;=20 > >> vf0213@gmail.com > >> Cc: Romascanu, Dan (Dan); rbonica@juniper.net; dime@ietf.org;=20 > >> lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com;=20 > >> ipr-announce@ietf.org; housley@vigilsec.com > >> Subject: IPR Disclosure: Nokia Corporation's Statement about IPR=20 > >> related to draft-ietf-dime-rfc3588bis-25 > >> > >> Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: > >> > >> An IPR disclosure that pertains to your Internet-Draft entitled=20 > >> "Diameter Base Protocol" > >> (draft-ietf-dime-rfc3588bis) was submitted to the IETF=20 > Secretariat on > >> 2010-10-29 and has been posted on the "IETF Page of Intellectual=20 > >> Property Rights Disclosures" > >> (https://datatracker.ietf.org/ipr/1437/). The title of the IPR=20 > >> disclosure is "Nokia Corporation's Statement about IPR related to=20 > >> draft-ietf-dime-rfc3588bis-25." > >> > >> The IETF Secretariat > >> > >> > >> > >> =20 > > > > =20 >=20 >=20 From dromasca@avaya.com Tue Nov 2 03:03:22 2010 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 7B7953A68CD for ; Tue, 2 Nov 2010 03:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8KH4AICRG3O2 for ; Tue, 2 Nov 2010 03:03:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 40BD53A67F7 for ; Tue, 2 Nov 2010 03:03:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAO9+z0yHCzI1/2dsb2JhbACWTYsacaUIApl2gwQIgjkEjXaCUw X-IronPort-AV: E=Sophos;i="4.58,281,1286164800"; d="scan'208";a="216625293" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2010 06:03:23 -0400 X-IronPort-AV: E=Sophos;i="4.58,281,1286164800"; d="scan'208";a="532550599" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Nov 2010 06:03:21 -0400 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: Tue, 2 Nov 2010 11:03:17 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 Thread-Index: Act6c/+zdJ2Ij7S16Ui2El4TxRH8fQAANZbA References: <4CCFDEDA.6010200@piuha.net> From: "Romascanu, Dan (Dan)" To: "Jouni Korhonen" , "ext Jari Arkko" Cc: rbonica@juniper.net, housley@vigilsec.com, dime@ietf.org Subject: Re: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 10:03:22 -0000 Hi Jouni, The my response to Jari. There were more than one patent mentioned in the 3588 disclosure and the licensing text is different. Maybe it leads to the same conditions, but IANAL and WeANL to make this assessment. I think that it would be better to reissue the LC.=20 Dan =20 > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.korhonen@nsn.com]=20 > Sent: Tuesday, November 02, 2010 11:55 AM > To: ext Jari Arkko; Romascanu, Dan (Dan) > Cc: gwz@net-zen.net; john.loughney@nokia.com;=20 > vf0213@gmail.com; rbonica@juniper.net; dime@ietf.org;=20 > lionel.morand@orange-ftgroup.com; housley@vigilsec.com > Subject: Re: IPR Disclosure: Nokia Corporation's Statement=20 > about IPR related to draft-ietf-dime-rfc3588bis-25 >=20 > This new declaration and the older one from 2004 are for the=20 > same EP patent. >=20 > - Jouni >=20 >=20 > On 11/2/10 11:50 AM, "ext Jari Arkko" wrote: >=20 > > Hmm... I'll note that RFC 3588 had IPR from Nokia as well: > >=20 > >=20 > = https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search=3D= > > 3588 > >=20 > > But I have not looked at the details. Is this a re-statement of the=20 > > same IPR with same conditions, of have things really=20 > changed? If just=20 > > a re-statement, perhaps it would be enough to point out to=20 > the working=20 > > group that the disclosure has been filed (and the WG has already=20 > > gotten a message), and respond to the IETF Last Call=20 > message stating the same. > >=20 > > Jari > >=20 > > Romascanu, Dan (Dan) kirjoitti: > >> DIME chairs, > >>=20 > >> This IPR filling leads to the need for the community to reconsider=20 > >> the document in the context of the disclosure. My suggestion is to=20 > >> start immediately and in parallel a Working Group Last Call and an=20 > >> IETF Last Call pointing to the fact that the document text is the=20 > >> same as in the last IETF LC, but the community is asked to=20 > reconsider=20 > >> the consensus taking into account the IPR disclosure. If=20 > we start the=20 > >> Last Calls today we still can make it for the 11/18 IESG telechat. > >>=20 > >> Thanks and Regards, > >>=20 > >> Dan > >> =20 > >>=20 > >> =20 > >>> -----Original Message----- > >>> From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > >>> Sent: Friday, October 29, 2010 7:14 PM > >>> To: gwz@net-zen.net; jari.arkko@piuha.net;=20 > john.loughney@nokia.com;=20 > >>> vf0213@gmail.com > >>> Cc: Romascanu, Dan (Dan); rbonica@juniper.net; dime@ietf.org;=20 > >>> lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com;=20 > >>> ipr-announce@ietf.org; housley@vigilsec.com > >>> Subject: IPR Disclosure: Nokia Corporation's Statement about IPR=20 > >>> related to draft-ietf-dime-rfc3588bis-25 > >>>=20 > >>> Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: > >>>=20 > >>> An IPR disclosure that pertains to your Internet-Draft entitled=20 > >>> "Diameter Base Protocol" > >>> (draft-ietf-dime-rfc3588bis) was submitted to the IETF=20 > Secretariat=20 > >>> on > >>> 2010-10-29 and has been posted on the "IETF Page of Intellectual=20 > >>> Property Rights Disclosures" > >>> (https://datatracker.ietf.org/ipr/1437/). The title of the IPR=20 > >>> disclosure is "Nokia Corporation's Statement about IPR related to=20 > >>> draft-ietf-dime-rfc3588bis-25." > >>>=20 > >>> The IETF Secretariat > >>>=20 > >>>=20 > >>>=20 > >>> =20 > >>=20 > >> =20 > >=20 >=20 >=20 From jouni.nospam@gmail.com Tue Nov 2 03:39:52 2010 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 545AE28C121 for ; Tue, 2 Nov 2010 03:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9ZX7nZjqmMm5 for ; Tue, 2 Nov 2010 03:39:51 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E72A128C124 for ; Tue, 2 Nov 2010 03:39:49 -0700 (PDT) Received: by bwz12 with SMTP id 12so5812780bwz.31 for ; Tue, 02 Nov 2010 03:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1HguK4Lp+1Tt/YrkYXc+JlPSzmxJkanbkCBTpU7WGpw=; b=ggpRC6SqZ5i/93i5rqXtOo85VFYiQsLc0TM2KW5sQ/hshL5Sq+B2uUg53gzh8BxskS 0WSIEmknwdu9Zu18GSl4NGY9/Ovr6KmQm0ztzBxhvR93T9Z23fNCajF9EzXdt+Ou3sZR /2lSc+l+3iwIK5Kli5JhrruVAWQvW2mZcMKgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=OocAIccSulonwCkDKO3PwC3T9h65kYkPkhxrHuc60qRHQY/eZW4v2OydZoTAyTILgc 8m2HBkZN5NNhemlWGrAQp44UgPcC8LgADiq5/BIE8xGt1prDShUwSh9qi7pifdgTB0KL 1aioZFhKVpEN2al6I29pnMbE8sr71Po8RRhX0= Received: by 10.204.76.79 with SMTP id b15mr1336835bkk.168.1288694392448; Tue, 02 Nov 2010 03:39:52 -0700 (PDT) Received: from a88-114-170-81.elisa-laajakaista.fi (a88-114-170-81.elisa-laajakaista.fi [88.114.170.81]) by mx.google.com with ESMTPS id d12sm4416638bkw.19.2010.11.02.03.39.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 03:39:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20101029171414.2767F3A686A@core3.amsl.com> Date: Tue, 2 Nov 2010 12:39:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7FED2B-1CBD-4186-B8D5-EDA81B9BAF55@gmail.com> References: <20101029171414.2767F3A686A@core3.amsl.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Cc: rbonica@juniper.net, dime-chairs@tools.ietf.org Subject: [Dime] WGLC announcement for draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 10:39:52 -0000 Folks, Due to very late IPR announcement against draft-ietf-dime-rfc3588bis-25 = we have decided to re-run the two weeks WGLC for the I-D. WGLC starts = today 2-Nov-2010 and ends 16-Nov-2010 23:59 (CET+1). So if you have = concerns, especially related to the IPR, speak up. See also the earlier = IPRs against RFC3588 https://datatracker.ietf.org/ipr/323/ - chairs On Oct 29, 2010, at 8:14 PM, IETF Secretariat wrote: > Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Diameter Base > Protocol" (draft-ietf-dime-rfc3588bis) was submitted to the IETF = Secretariat on > 2010-10-29 and has been posted on the "IETF Page of Intellectual = Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1437/). The title of = the IPR > disclosure is "Nokia Corporation's Statement about IPR related to > draft-ietf-dime-rfc3588bis-25." >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Tue Nov 2 03:44:09 2010 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 26B3D3A69AF for ; Tue, 2 Nov 2010 03:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gBb+OX0Rxy3M for ; Tue, 2 Nov 2010 03:44:08 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C652D3A69AA for ; Tue, 2 Nov 2010 03:44:06 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 413608580BD; Tue, 2 Nov 2010 11:47:49 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1131A8581FE; Tue, 2 Nov 2010 11:13:13 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 11:09:01 +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: Tue, 2 Nov 2010 11:09:00 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 Thread-Index: Act6c/+zdJ2Ij7S16Ui2El4TxRH8fQAANZbAAAAjTvA= References: <4CCFDEDA.6010200@piuha.net> From: To: , , X-OriginalArrivalTime: 02 Nov 2010 10:09:01.0412 (UTC) FILETIME=[F8CCBA40:01CB7A75] Cc: rbonica@juniper.net, housley@vigilsec.com, dime@ietf.org Subject: Re: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 10:44:09 -0000 I think that the ouput will be exactly the same than the last time but I = agree with Dan that we need to "officially" reconsider the draft based = on this "new" disclosure in a new LC, at least to acknowledge the fact = that we have considered it. Lionel > -----Message d'origine----- > De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Envoy=E9 : mardi 2 novembre 2010 11:03 > =C0 : Jouni Korhonen; ext Jari Arkko > Cc : gwz@net-zen.net; john.loughney@nokia.com;=20 > vf0213@gmail.com; rbonica@juniper.net; dime@ietf.org; MORAND=20 > Lionel RD-CORE-ISS; housley@vigilsec.com > Objet : RE: IPR Disclosure: Nokia Corporation's Statement=20 > about IPR related to draft-ietf-dime-rfc3588bis-25 >=20 > Hi Jouni, >=20 > The my response to Jari. There were more than one patent=20 > mentioned in the 3588 disclosure and the licensing text is=20 > different. Maybe it leads to the same conditions, but IANAL=20 > and WeANL to make this assessment. I think that it would be=20 > better to reissue the LC.=20 >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: Jouni Korhonen [mailto:jouni.korhonen@nsn.com] > > Sent: Tuesday, November 02, 2010 11:55 AM > > To: ext Jari Arkko; Romascanu, Dan (Dan) > > Cc: gwz@net-zen.net; john.loughney@nokia.com; vf0213@gmail.com;=20 > > rbonica@juniper.net; dime@ietf.org;=20 > lionel.morand@orange-ftgroup.com;=20 > > housley@vigilsec.com > > Subject: Re: IPR Disclosure: Nokia Corporation's Statement=20 > about IPR=20 > > related to draft-ietf-dime-rfc3588bis-25 > >=20 > > This new declaration and the older one from 2004 are for=20 > the same EP=20 > > patent. > >=20 > > - Jouni > >=20 > >=20 > > On 11/2/10 11:50 AM, "ext Jari Arkko" wrote: > >=20 > > > Hmm... I'll note that RFC 3588 had IPR from Nokia as well: > > >=20 > > >=20 > >=20 > = https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search=3D= > > > 3588 > > >=20 > > > But I have not looked at the details. Is this a=20 > re-statement of the=20 > > > same IPR with same conditions, of have things really > > changed? If just > > > a re-statement, perhaps it would be enough to point out to > > the working > > > group that the disclosure has been filed (and the WG has already=20 > > > gotten a message), and respond to the IETF Last Call > > message stating the same. > > >=20 > > > Jari > > >=20 > > > Romascanu, Dan (Dan) kirjoitti: > > >> DIME chairs, > > >>=20 > > >> This IPR filling leads to the need for the community to=20 > reconsider=20 > > >> the document in the context of the disclosure. My=20 > suggestion is to=20 > > >> start immediately and in parallel a Working Group Last=20 > Call and an=20 > > >> IETF Last Call pointing to the fact that the document=20 > text is the=20 > > >> same as in the last IETF LC, but the community is asked to > > reconsider > > >> the consensus taking into account the IPR disclosure. If > > we start the > > >> Last Calls today we still can make it for the 11/18 IESG=20 > telechat. > > >>=20 > > >> Thanks and Regards, > > >>=20 > > >> Dan > > >> =20 > > >>=20 > > >> =20 > > >>> -----Original Message----- > > >>> From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > > >>> Sent: Friday, October 29, 2010 7:14 PM > > >>> To: gwz@net-zen.net; jari.arkko@piuha.net; > > john.loughney@nokia.com; > > >>> vf0213@gmail.com > > >>> Cc: Romascanu, Dan (Dan); rbonica@juniper.net; dime@ietf.org;=20 > > >>> lionel.morand@orange-ftgroup.com; jouni.korhonen@nsn.com;=20 > > >>> ipr-announce@ietf.org; housley@vigilsec.com > > >>> Subject: IPR Disclosure: Nokia Corporation's Statement=20 > about IPR=20 > > >>> related to draft-ietf-dime-rfc3588bis-25 > > >>>=20 > > >>> Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: > > >>>=20 > > >>> An IPR disclosure that pertains to your Internet-Draft entitled=20 > > >>> "Diameter Base Protocol" > > >>> (draft-ietf-dime-rfc3588bis) was submitted to the IETF > > Secretariat > > >>> on > > >>> 2010-10-29 and has been posted on the "IETF Page of=20 > Intellectual=20 > > >>> Property Rights Disclosures" > > >>> (https://datatracker.ietf.org/ipr/1437/). The title of the IPR=20 > > >>> disclosure is "Nokia Corporation's Statement about IPR=20 > related to=20 > > >>> draft-ietf-dime-rfc3588bis-25." > > >>>=20 > > >>> The IETF Secretariat > > >>>=20 > > >>>=20 > > >>>=20 > > >>> =20 > > >>=20 > > >> =20 > > >=20 > >=20 > >=20 >=20 From victor.pascual.avila@gmail.com Tue Nov 2 03:54:13 2010 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 099743A6987 for ; Tue, 2 Nov 2010 03:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 Z+Orz-kqTCeA for ; Tue, 2 Nov 2010 03:54:11 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 04B693A68B1 for ; Tue, 2 Nov 2010 03:54:10 -0700 (PDT) Received: by bwz12 with SMTP id 12so5822166bwz.31 for ; Tue, 02 Nov 2010 03:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=j1vTUi2idNTCw3Jr1pkCUgNdOgdozwspqk4J2qDRFbc=; b=wCd3tk/QCUjxTd+apVUhiwtojMfMlGJixXUeK+ilJ2FobhstSmCqCuGGyPE58clXt6 JICNjfBLM/MBYsnKpg14tez9P1t/xOLFQ5cDfCSr2DuTjEMEznCp/DOuJ1wUmDLCUqMH U6ccqB/RQoaizH5MFQJjtJk7iL+ylGSRefrTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=M6HESnP+O25W6gd2hKq4c4eGzdoieS5lIByfVPPDezHW2p26r6vy6/e9g2PhUGuu8e BG7d/2Mlr4QuViZaHaoxgYqoZitbQtnGeOspJVV313p0skNzodH/RggbmhHZtSBYXWlN 1inBWSHFI5rNicWhCt99WzdNdrJ2DPuVvQiQI= MIME-Version: 1.0 Received: by 10.204.122.8 with SMTP id j8mr6241086bkr.135.1288695250764; Tue, 02 Nov 2010 03:54:10 -0700 (PDT) Received: by 10.204.81.76 with HTTP; Tue, 2 Nov 2010 03:54:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Nov 2010 11:54:10 +0100 Message-ID: From: Victor Pascual Avila To: dime@ietf.org Content-Type: multipart/alternative; boundary=0016e6deea8ca5460704940fbe74 Subject: Re: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport 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, 02 Nov 2010 10:54:13 -0000 --0016e6deea8ca5460704940fbe74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Any additional comment on this? On Thu, Oct 21, 2010 at 5:27 PM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > Hello, > > If you don't mind I have some comments on draft-ietf-dime-rfc3588bis > and SCTP transport. Making the long story short, I believe RFC3588bis > shall discuss the implications of using Diameter over SCTP transport > and its associated security mechanisms. > > There are some aspects I'd like to discuss: > > -SCTP USAGE- > > 1) SCTP Payload Protocol Identifier for Diameter: IMO no SCTP > identifier needs to be defined for Diameter messages. Therefore, the > PPI in SCTP DATA chunks transporting Diameter messages MUST be set to > zero. I think this should be documented > > 2) Mapping of Diameter messages into SCTP Streams: the current version > of the draft states that "All Diameter nodes SHOULD utilize all SCTP > streams available to the association to prevent head-of-the-line > blocking". Well, mapping diameter messages into different SCTP streams > could be one way to prevent HOL blocking but some increase of > processing delay might be incurred. However, sending every Diameter > message via the SCTP Stream ID zero with the =E2=80=9Cunordered=E2=80=9D = flag set may > lead to improved performance and simplicity. > I'd suggest something like: "Diameter messages need to be mapped into > SCTP streams in a way that avoids Head Of the Line (HOL) blocking. > Among the different ways of performing the mapping that fulfill this > requirement, the simplest alternative is proposed; a Diameter entity > SHOULD send every Diameter message (request or response) over stream > zero with the unordered flag set. On the receiving side, a Diameter > entity MUST be ready to receive Diameter messages over any stream. > Although both sides of the SCTP association SHOULD use stream 0 for > Diameter requests and responses if they follow this recommendation, if > a Diameter request arrives over a particular stream, the server is > free to return responses over a different stream. This way, both > sides manage the available streams in the sending direction, > independently of the streams chosen by the other side to send a > particular Diameter message. This avoids undesirable collisions when > seizing a particular stream". This is how SIP over SCTP works. > > -SECURITY MECHANISMS- > > 3) According to draft-ietf-dime-rfc3588bis, the use of a secured > transport for exchanging Diameter messages is mandatory, being TLS the > primary method and IPsec a > secondary alternative. However, it is assumed that TLS is run on top > of TCP when it is used, leaving IPsec as the only mechanism to secure > Diameter messages. Is that the expected outcome? > > 4) TLS over SCTP usage: As exposed in draft-ietf-tsvwg-dtls-for-sctp, > TLS over SCTP (RFC3436) has some serious limitations. In order to > overcome these limitations, I believe Diameter over DTLS/SCTP shall be > proposed as an alternative to TLS/SCTP. To my best knowledge, the IESG > has recently approved DTLS over SCTP as a Proposed Standard and it > will be published as a Standards Track RFC. However, I'd agree that > until DTLS/SCTP gets widely adopted by the industry, we'll find IPsec > as the common deployed mechanism to secure Diameter messages (please, > see comment 6). > > 5) If draft-ietf-tsvwg-dtls-for-sctp gets adopted as a security > mechanism for Diameter: > > 5.1) it should be documented somewhere that no SCTP identifier needs > to be defined for Diameter messages over DTLS. Therefore, the Payload > Protocol Identifier in SCTP DATA chunks transporting DTLS-based > Diameter messages MUST be set to zero > 5.2) a port number should be assigned > 5.3) the S-NAPTR Application Protocol Tag for DTLS/SCTP (say, > diameter.dtls.sctp) should be registered > > 6) Diameter over SCTP over IPsec usage: I believe some guidelines on > this would be beneficial. Would it be ok to create an association and > SPD selector for each SCTP IP Address and port involved in an > association, treating SCTP as any other layer above IP, and thus > potentially creating multiple entries for a single SCTP association? > IMO implementations MUST at least support this mode (if they support > Diameter over SCTP over IPsec). I believe RFC3554 (SCTP with IPsec) is > unnecessary for Diameter applications, both because of the relatively > low number of Diameter connections per system, and because one of the > main advantages of SCTP is multi-homing across interfaces which makes > RFC3554 potentially impossible to implement. > > > I'm planning to put these ideas together in a short draft, but would > like to hear your take on them. > > Many thanks in advance, > > Victor Pascual > --=20 Victor Pascual =C3=81vila --0016e6deea8ca5460704940fbe74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Any additional comment on this?

On Thu, Oct 21, 2010 at 5:27 PM, Victor Pascual = Avila <victor.pascual.avila@gmail.com> wrote:
Hello,

If you don't m= ind I have some comments on draft-ietf-dime-rfc3588bis
and SCTP transpor= t. Making the long story short, I believe RFC3588bis
shall discuss the implications of using Diameter over SCTP transport
and= its associated security mechanisms.

There are some aspects I'd = like to discuss:

-SCTP USAGE-

1) SCTP Payload Protocol Identi= fier for Diameter: IMO no SCTP
identifier needs to be defined for Diameter messages. Therefore, the
PPI= in SCTP DATA chunks transporting Diameter messages MUST be set to
zero.= I think this should be documented

2) Mapping of Diameter messages i= nto SCTP Streams: the current version
of the draft states that "All Diameter nodes SHOULD utilize all SCTPstreams available to the association to prevent head-of-the-line
block= ing". Well, mapping diameter messages into different SCTP streams
could be one way to prevent HOL blocking but some increase of
processing= delay might be incurred. However, sending every Diameter
message via th= e SCTP Stream ID zero with the =E2=80=9Cunordered=E2=80=9D flag set may
= lead to improved performance and simplicity.
I'd suggest something like: "Diameter messages need to be mapped i= nto
SCTP streams in a way that avoids Head Of the Line (HOL) blocking.Among the different ways of performing the mapping that fulfill this
requirement, the simplest alternative is proposed; a Diameter entity
SHO= ULD send every Diameter message (request or response) over stream
zero w= ith the unordered flag set. =C2=A0On the receiving side, a Diameter
enti= ty MUST be ready to receive Diameter messages over any stream.
Although both sides of the SCTP association SHOULD use stream 0 for
Diam= eter requests and responses if they follow this recommendation, if
a Dia= meter request arrives over a particular stream, the server is
free to re= turn responses over a different stream. =C2=A0This way, both
sides manage the available streams in the sending direction,
independent= ly of the streams chosen by the other side to send a
particular Diameter= message. =C2=A0This avoids undesirable collisions when
seizing a partic= ular stream". This is how SIP over SCTP works.

-SECURITY MECHANISMS-

3) According to draft-ietf-dime-rfc3588bis= , the use of a secured
transport for exchanging Diameter messages is man= datory, being TLS the
primary method and IPsec a
secondary alternativ= e. =C2=A0However, it is assumed that TLS is run on top
of TCP when it is used, leaving IPsec as the only mechanism to secure
Di= ameter messages. Is that the expected outcome?

4) TLS over SCTP usag= e: As exposed in draft-ietf-tsvwg-dtls-for-sctp,
TLS over SCTP (RFC3436)= has some serious limitations. In order to
overcome these limitations, I believe Diameter over DTLS/SCTP shall be
p= roposed as an alternative to TLS/SCTP. To my best knowledge, the IESG
ha= s recently approved DTLS over SCTP as a Proposed Standard and it
will be= published as a Standards Track RFC. However, I'd agree that
until DTLS/SCTP gets widely adopted by the industry, we'll find IPsecas the common deployed mechanism to secure Diameter messages (please,
= see comment 6).

5) If draft-ietf-tsvwg-dtls-for-sctp gets adopted as= a security
mechanism for Diameter:

5.1) it should be documented somewhere that = no SCTP identifier needs
to be defined for Diameter messages over DTLS. = Therefore, the Payload
Protocol Identifier in SCTP DATA chunks transport= ing DTLS-based
Diameter messages MUST be set to zero
5.2) a port number should be assig= ned
5.3) the S-NAPTR Application Protocol Tag for DTLS/SCTP (say,
dia= meter.dtls.sctp) should be registered

6) Diameter over SCTP over IPs= ec usage: I believe some guidelines on
this would be beneficial. Would it be ok to create an association and
SP= D selector for each SCTP IP Address and port involved in an
association,= treating SCTP as any other layer above IP, and thus
potentially creatin= g multiple entries for a single SCTP association?
IMO implementations MUST at least support this mode (if they support
Dia= meter over SCTP over IPsec). I believe RFC3554 (SCTP with IPsec) is
unne= cessary for Diameter applications, both because of the relatively
low nu= mber of Diameter connections per system, and because one of the
main advantages of SCTP is multi-homing across interfaces which makes
RF= C3554 potentially impossible to implement.


I'm planning to p= ut these ideas together in a short draft, but would
like to hear your ta= ke on them.

Many thanks in advance,

Victor Pascual



--
Victor Pascual= =C3=81vila
--0016e6deea8ca5460704940fbe74-- From victor.pascual.avila@gmail.com Tue Nov 2 03:57:53 2010 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 4422728C0E7 for ; Tue, 2 Nov 2010 03:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 EqZPruFBqSeP for ; Tue, 2 Nov 2010 03:57:52 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D9E693A68B1 for ; Tue, 2 Nov 2010 03:57:51 -0700 (PDT) Received: by bwz12 with SMTP id 12so5824770bwz.31 for ; Tue, 02 Nov 2010 03:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YPkQdaXuxrtvDVvVfR5YVyPFSeGGSCQ8DzRXrIEJ2s0=; b=DUEVF/JoVEXNQclpuSNE75DNu4VLkaLvlYEE3VcENv7RsfCcWPBIgUq5jiXHI7NWq/ GUH7KPMfHQtsjQqiKE7wclrg8oZpnICZIKoqsV2T9iauMlIli+zuTKtfwqDgux60aOC0 09FRfb26BteVhp2CnhsOxkpFqUEDqk/8X+1ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lPHRsjYeoYpRfAku7mNDhbsMl87vV1waeeh7X+GhB4hYimUlL9FQP2EHLlVsZa9hfX qzkJqcc7Q6LgeXNi89LJcyvqJkHfzJwgMXZodYyWxOU8ZceDobhgVWgrtn489iCArFvW jzDpDWaRtQFOoCRoc8gAeTkxhcme7nDoahZ9o= MIME-Version: 1.0 Received: by 10.204.66.12 with SMTP id l12mr13172915bki.81.1288695473271; Tue, 02 Nov 2010 03:57:53 -0700 (PDT) Received: by 10.204.81.76 with HTTP; Tue, 2 Nov 2010 03:57:53 -0700 (PDT) In-Reply-To: <4C7FED2B-1CBD-4186-B8D5-EDA81B9BAF55@gmail.com> References: <20101029171414.2767F3A686A@core3.amsl.com> <4C7FED2B-1CBD-4186-B8D5-EDA81B9BAF55@gmail.com> Date: Tue, 2 Nov 2010 11:57:53 +0100 Message-ID: From: Victor Pascual Avila To: jouni korhonen Content-Type: multipart/alternative; boundary=001636c5c088e8739604940fcbc3 Cc: rbonica@juniper.net, dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC announcement for draft-ietf-dime-rfc3588bis-25 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, 02 Nov 2010 10:57:53 -0000 --001636c5c088e8739604940fcbc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Some comments on draft-ietf-dime-rfc3588bis and SCTP transport: http://www.ietf.org/mail-archive/web/dime/current/msg04522.html Many thanks in advance, -Victor On Tue, Nov 2, 2010 at 11:39 AM, jouni korhonen wro= te: > Folks, > > Due to very late IPR announcement against draft-ietf-dime-rfc3588bis-25 w= e > have decided to re-run the two weeks WGLC for the I-D. WGLC starts today > 2-Nov-2010 and ends 16-Nov-2010 23:59 (CET+1). So if you have concerns, > especially related to the IPR, speak up. See also the earlier IPRs agains= t > RFC3588 https://datatracker.ietf.org/ipr/323/ > > - chairs > > > > On Oct 29, 2010, at 8:14 PM, IETF Secretariat wrote: > > > Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: > > > > An IPR disclosure that pertains to your Internet-Draft entitled "Diamet= er > Base > > Protocol" (draft-ietf-dime-rfc3588bis) was submitted to the IETF > Secretariat on > > 2010-10-29 and has been posted on the "IETF Page of Intellectual Proper= ty > Rights > > Disclosures" (https://datatracker.ietf.org/ipr/1437/). The title of the > IPR > > disclosure is "Nokia Corporation's Statement about IPR related to > > draft-ietf-dime-rfc3588bis-25." > > > > The IETF Secretariat > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --=20 Victor Pascual =C3=81vila --001636c5c088e8739604940fcbc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
Some comments on draft-ietf-dime-rfc3588bis and SCTP transport: http:= //www.ietf.org/mail-archive/web/dime/current/msg04522.html
=C2=A0
Many thanks in advance,
-Victor
On Tue, Nov 2, 2010 at 11:39 AM, jouni korhonen = <jouni.nospa= m@gmail.com> wrote:
Folks,

Due to very late I= PR announcement against draft-ietf-dime-rfc3588bis-25 we have decided to re= -run the two weeks WGLC for the I-D. WGLC starts today 2-Nov-2010 and ends = 16-Nov-2010 23:59 (CET+1). So if you have concerns, especially related to t= he IPR, speak up. See also the earlier IPRs against RFC3588 https://datatracker.ie= tf.org/ipr/323/

- chairs



On Oct 29, 2010, at 8:14 PM, IETF Secretariat w= rote:

> Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo= :
>
> An IPR disclosure that pertains to your Internet-Draft en= titled "Diameter Base
> Protocol" (draft-ietf-dime-rfc3588bis) was submitted to the IETF = Secretariat on
> 2010-10-29 and has been posted on the "IETF Pag= e of Intellectual Property Rights
> Disclosures" (https://datatracker.= ietf.org/ipr/1437/). The title of the IPR
> disclosure is "Nokia Corporation's Statement about IPR relate= d to
> draft-ietf-dime-rfc3588bis-25."
>
> The IETF = Secretariat
>
>
> _______________________________________= ________
> DiME mailing list
> DiME@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dime

________= _______________________________________
DiME mailing list
DiME@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dime



--
Victor Pascual =C3=81vila
--001636c5c088e8739604940fcbc3-- From lionel.morand@orange-ftgroup.com Tue Nov 2 07:44:43 2010 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 C917F3A6876 for ; Tue, 2 Nov 2010 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 F9mubAMw8IhM for ; Tue, 2 Nov 2010 07:44:42 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id E90183A69BE for ; Tue, 2 Nov 2010 07:44:41 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3AD1FFC4003; Tue, 2 Nov 2010 15:44:45 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 2EBC8FC4006; Tue, 2 Nov 2010 15:44:45 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 15:44:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7A9C.7C920FE2" Date: Tue, 2 Nov 2010 15:44:43 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport Thread-Index: Act6fE37uRJ0b26NTp+vKdN1Xn/SZAAHyvTg References: From: To: , X-OriginalArrivalTime: 02 Nov 2010 14:44:45.0281 (UTC) FILETIME=[7DB6CD10:01CB7A9C] Subject: Re: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport 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, 02 Nov 2010 14:44:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7A9C.7C920FE2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Victor pascual, =20 Just to let you know that your mail has been considered and this point = will be addressed during the DIME WG meeting the next week. Of course, it doesn't preclude further exchange on the mailing list = meanwhile. =20 Lionel ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de = Victor Pascual Avila Envoy=E9 : mardi 2 novembre 2010 11:54 =C0 : dime@ietf.org Objet : Re: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP = transport =09 =09 Any additional comment on this? =09 =09 On Thu, Oct 21, 2010 at 5:27 PM, Victor Pascual Avila = wrote: =09 Hello, =09 If you don't mind I have some comments on draft-ietf-dime-rfc3588bis and SCTP transport. Making the long story short, I believe RFC3588bis shall discuss the implications of using Diameter over SCTP transport and its associated security mechanisms. =09 There are some aspects I'd like to discuss: =09 -SCTP USAGE- =09 1) SCTP Payload Protocol Identifier for Diameter: IMO no SCTP identifier needs to be defined for Diameter messages. Therefore, the PPI in SCTP DATA chunks transporting Diameter messages MUST be set to zero. I think this should be documented =09 2) Mapping of Diameter messages into SCTP Streams: the current version of the draft states that "All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking". Well, mapping diameter messages into different SCTP streams could be one way to prevent HOL blocking but some increase of processing delay might be incurred. However, sending every Diameter message via the SCTP Stream ID zero with the "unordered" flag set may lead to improved performance and simplicity. I'd suggest something like: "Diameter messages need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking. Among the different ways of performing the mapping that fulfill this requirement, the simplest alternative is proposed; a Diameter entity SHOULD send every Diameter message (request or response) over stream zero with the unordered flag set. On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream. Although both sides of the SCTP association SHOULD use stream 0 for Diameter requests and responses if they follow this recommendation, if a Diameter request arrives over a particular stream, the server is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. This avoids undesirable collisions when seizing a particular stream". This is how SIP over SCTP works. =09 -SECURITY MECHANISMS- =09 3) According to draft-ietf-dime-rfc3588bis, the use of a secured transport for exchanging Diameter messages is mandatory, being TLS the primary method and IPsec a secondary alternative. However, it is assumed that TLS is run on top of TCP when it is used, leaving IPsec as the only mechanism to secure Diameter messages. Is that the expected outcome? =09 4) TLS over SCTP usage: As exposed in draft-ietf-tsvwg-dtls-for-sctp, TLS over SCTP (RFC3436) has some serious limitations. In order to overcome these limitations, I believe Diameter over DTLS/SCTP shall be proposed as an alternative to TLS/SCTP. To my best knowledge, the IESG has recently approved DTLS over SCTP as a Proposed Standard and it will be published as a Standards Track RFC. However, I'd agree that until DTLS/SCTP gets widely adopted by the industry, we'll find IPsec as the common deployed mechanism to secure Diameter messages (please, see comment 6). =09 5) If draft-ietf-tsvwg-dtls-for-sctp gets adopted as a security mechanism for Diameter: =09 5.1) it should be documented somewhere that no SCTP identifier needs to be defined for Diameter messages over DTLS. Therefore, the Payload Protocol Identifier in SCTP DATA chunks transporting DTLS-based Diameter messages MUST be set to zero 5.2) a port number should be assigned 5.3) the S-NAPTR Application Protocol Tag for DTLS/SCTP (say, diameter.dtls.sctp) should be registered =09 6) Diameter over SCTP over IPsec usage: I believe some guidelines on this would be beneficial. Would it be ok to create an association and SPD selector for each SCTP IP Address and port involved in an association, treating SCTP as any other layer above IP, and thus potentially creating multiple entries for a single SCTP association? IMO implementations MUST at least support this mode (if they support Diameter over SCTP over IPsec). I believe RFC3554 (SCTP with IPsec) is unnecessary for Diameter applications, both because of the relatively low number of Diameter connections per system, and because one of the main advantages of SCTP is multi-homing across interfaces which makes RFC3554 potentially impossible to implement. =09 =09 I'm planning to put these ideas together in a short draft, but would like to hear your take on them. =09 Many thanks in advance, =09 Victor Pascual =09 --=20 Victor Pascual =C1vila =09 ------_=_NextPart_001_01CB7A9C.7C920FE2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Victor pascual,
 
Just to let you know that your mail has been = considered and=20 this point will be addressed during the DIME WG meeting the next=20 week.
Of course, it doesn't preclude further exchange = on the=20 mailing list meanwhile.
 
Lionel

De : dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] De la part de Victor Pascual=20 Avila
Envoy=E9 : mardi 2 novembre 2010 = 11:54
=C0 :=20 dime@ietf.org
Objet : Re: [Dime] Comments on=20 draft-ietf-dime-rfc3588bis and SCTP transport

Any additional comment on this?

On Thu, Oct 21, 2010 at 5:27 PM, Victor = Pascual Avila=20 <victor.pascual.avila@gmail= .com>=20 wrote:
Hello,

If=20 you don't mind I have some comments on = draft-ietf-dime-rfc3588bis
and=20 SCTP transport. Making the long story short, I believe = RFC3588bis
shall=20 discuss the implications of using Diameter over SCTP = transport
and its=20 associated security mechanisms.

There are some aspects I'd = like to=20 discuss:

-SCTP USAGE-

1) SCTP Payload Protocol = Identifier for=20 Diameter: IMO no SCTP
identifier needs to be defined for Diameter = messages. Therefore, the
PPI in SCTP DATA chunks transporting = Diameter=20 messages MUST be set to
zero. I think this should be = documented

2)=20 Mapping of Diameter messages into SCTP Streams: the current = version
of=20 the draft states that "All Diameter nodes SHOULD utilize all = SCTP
streams=20 available to the association to prevent = head-of-the-line
blocking". Well,=20 mapping diameter messages into different SCTP streams
could be = one way to=20 prevent HOL blocking but some increase of
processing delay might = be=20 incurred. However, sending every Diameter
message via the SCTP = Stream ID=20 zero with the =93unordered=94 flag set may
lead to improved = performance and=20 simplicity.
I'd suggest something like: "Diameter messages need = to be=20 mapped into
SCTP streams in a way that avoids Head Of the Line = (HOL)=20 blocking.
Among the different ways of performing the mapping that = fulfill=20 this
requirement, the simplest alternative is proposed; a = Diameter=20 entity
SHOULD send every Diameter message (request or response) = over=20 stream
zero with the unordered flag set.  On the receiving = side, a=20 Diameter
entity MUST be ready to receive Diameter messages over = any=20 stream.
Although both sides of the SCTP association SHOULD use = stream 0=20 for
Diameter requests and responses if they follow this = recommendation,=20 if
a Diameter request arrives over a particular stream, the = server=20 is
free to return responses over a different stream.  This = way,=20 both
sides manage the available streams in the sending=20 direction,
independently of the streams chosen by the other side = to send=20 a
particular Diameter message.  This avoids undesirable = collisions=20 when
seizing a particular stream". This is how SIP over SCTP=20 works.

-SECURITY MECHANISMS-

3) According to=20 draft-ietf-dime-rfc3588bis, the use of a secured
transport for = exchanging=20 Diameter messages is mandatory, being TLS the
primary method and = IPsec=20 a
secondary alternative.  However, it is assumed that TLS is = run on=20 top
of TCP when it is used, leaving IPsec as the only mechanism = to=20 secure
Diameter messages. Is that the expected outcome?

4) = TLS=20 over SCTP usage: As exposed in = draft-ietf-tsvwg-dtls-for-sctp,
TLS over=20 SCTP (RFC3436) has some serious limitations. In order to
overcome = these=20 limitations, I believe Diameter over DTLS/SCTP shall be
proposed = as an=20 alternative to TLS/SCTP. To my best knowledge, the IESG
has = recently=20 approved DTLS over SCTP as a Proposed Standard and it
will be = published=20 as a Standards Track RFC. However, I'd agree that
until DTLS/SCTP = gets=20 widely adopted by the industry, we'll find IPsec
as the common = deployed=20 mechanism to secure Diameter messages (please,
see comment = 6).

5)=20 If draft-ietf-tsvwg-dtls-for-sctp gets adopted as a = security
mechanism=20 for Diameter:

5.1) it should be documented somewhere that no = SCTP=20 identifier needs
to be defined for Diameter messages over DTLS.=20 Therefore, the Payload
Protocol Identifier in SCTP DATA chunks=20 transporting DTLS-based
Diameter messages MUST be set to = zero
5.2) a=20 port number should be assigned
5.3) the S-NAPTR Application = Protocol Tag=20 for DTLS/SCTP (say,
diameter.dtls.sctp) should be = registered

6)=20 Diameter over SCTP over IPsec usage: I believe some guidelines = on
this=20 would be beneficial. Would it be ok to create an association = and
SPD=20 selector for each SCTP IP Address and port involved in = an
association,=20 treating SCTP as any other layer above IP, and thus
potentially = creating=20 multiple entries for a single SCTP association?
IMO = implementations MUST=20 at least support this mode (if they support
Diameter over SCTP = over=20 IPsec). I believe RFC3554 (SCTP with IPsec) is
unnecessary for = Diameter=20 applications, both because of the relatively
low number of = Diameter=20 connections per system, and because one of the
main advantages of = SCTP is=20 multi-homing across interfaces which makes
RFC3554 potentially = impossible=20 to implement.


I'm planning to put these ideas together in = a short=20 draft, but would
like to hear your take on them.

Many = thanks in=20 advance,

Victor=20 Pascual



-- =
Victor=20 Pascual =C1vila
------_=_NextPart_001_01CB7A9C.7C920FE2-- From jouni.nospam@gmail.com Sat Nov 6 05:06:24 2010 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 38EAA3A68AC for ; Sat, 6 Nov 2010 05:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XyhyNrqUnpRd for ; Sat, 6 Nov 2010 05:06:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 434723A6879 for ; Sat, 6 Nov 2010 05:06:23 -0700 (PDT) Received: by iwn40 with SMTP id 40so3952752iwn.31 for ; Sat, 06 Nov 2010 05:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=Mxn+7zFNUGsAU+NEZv5AiqJoz7/XuXg6WX5jJ/eH5FQ=; b=iIGx94AnoSkIJn1h2G0EDYKtQnBgyXLcINhjMBMfspogpr54+ibwHgO9suWn7gZCiu hQL8eJNb07j+dgLVCDL+2unhKnmwTME5EAHhc+IO5tIGHii+ANoUEYj0MhY+K/mOQS10 7/ValJ8kcIuTav1pBH7FdcXaoSPL4b+ZyCEIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=n5aNuqsWdOHYojYHtZ8R5eDgFtK+JD5IK+ux51eZXUNTZxZra+o5OCqTb5oKbMaxKq qlujXgxpT4Y5vQK81/Le3/eZtEeGDpjqPMOmZwjBTUy4HplpiZQ5MHnNFhRM2ujqnV8j d58a4nbKPDtYK+HDPi8w2K7Ct9Cxh8twjN8+Y= Received: by 10.231.15.13 with SMTP id i13mr2514298iba.0.1289045196824; Sat, 06 Nov 2010 05:06:36 -0700 (PDT) Received: from [130.129.64.179] ([130.129.64.179]) by mx.google.com with ESMTPS id 34sm2846111ibi.14.2010.11.06.05.06.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 05:06:35 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 6 Nov 2010 14:06:31 +0200 Message-Id: <8763E6A0-0486-4676-83F2-5D461E733354@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Dime agenda updated 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: Sat, 06 Nov 2010 12:06:24 -0000 Folks, The agenda has been updated: http://www.ietf.org/proceedings/79/agenda/dime.txt - chairs From victor.pascual.avila@gmail.com Mon Nov 8 04:32:01 2010 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 1EC8F28C11E for ; Mon, 8 Nov 2010 04:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 pBYjHHNO48p1 for ; Mon, 8 Nov 2010 04:32:00 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D4D253A69C3 for ; Mon, 8 Nov 2010 04:31:59 -0800 (PST) Received: by bwz12 with SMTP id 12so5273125bwz.31 for ; Mon, 08 Nov 2010 04:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=EwE7fBq35oN/4ooXfsCNxMuOGePu/6FvNHbpUN2rY/M=; b=m1kfC0ERkLF2fMu6xE3YkVC4iZDoKXD/SLLn/NSKTuenu6s+QjGwJAhnLYzM7aM3Ob 1URWRpj4A4T3IQGPAxtfP4tVZsorh54qwdyhLJnCPX1Av/uEojEfVI+qY+7cVh5VHd3/ tmecfQ6nCTl2tRVv0yX7f1SQEvf9fJHiydrPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Ckiyz5ZsHILFJun/nFKXL+mfAnUuDBoqgvl8cNDxM0ypdzWkd6Fxn1KZGXBYkTRbTT lKTCmF053PnAjvzUYMQf6Bfs0zM7Bg9LMNRiv1vo1BAPSAK6l8EUTtsOhH37ETIfuO4A /B8lf5YrO7vErj11SeW6Xc4vmFFBOe94CBoH0= MIME-Version: 1.0 Received: by 10.204.123.141 with SMTP id p13mr4829233bkr.189.1289219539952; Mon, 08 Nov 2010 04:32:19 -0800 (PST) Received: by 10.204.81.76 with HTTP; Mon, 8 Nov 2010 04:32:19 -0800 (PST) Date: Mon, 8 Nov 2010 13:32:19 +0100 Message-ID: From: Victor Pascual Avila To: dime@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: "gonzalo.camarillo" Subject: [Dime] I-D Action:draft-pascual-dime-sctp-00.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, 08 Nov 2010 12:32:01 -0000 Hi Folks, Being related to some recent discussion (http://www.ietf.org/mail-archive/web/dime/current/msg04545.html) we have just submitted a draft on the usage of Diameter over SCTP. Filename: draft-pascual-dime-sctp Version: 00 URL: http://tools.ietf.org/id/draft-pascual-dime-sctp-00.txt Title: The Stream Control Transmission Protocol (SCTP) as a Transport for the Diameter Protocol Abstract: This document provides the guidelines for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between Diameter entities. Author(s): Victor Pascual, VPascual@acmepacket.com Gonzalo Camarillo, Gonzalo.Camarillo@ericsson.com Comments are welcome! Cheers, -Victor From Internet-Drafts@ietf.org Mon Nov 8 12:15:03 2010 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 1BE563A6834; Mon, 8 Nov 2010 12:15:03 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -99.229 X-Spam-Level: X-Spam-Status: No, score=-99.229 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, SARE_BOUNDARY_LC=1.666, USER_IN_WHITELIST=-100] 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 HRKWBmNDtgib; Mon, 8 Nov 2010 12:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CF43A692E; Mon, 8 Nov 2010 12:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextpart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101108201502.2890.27215.idtracker@localhost> Date: Mon, 08 Nov 2010 12:15:02 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-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, 08 Nov 2010 20:15:03 -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 Extended NAPTR Author(s) : M. Jones, J. Korhonen Filename : draft-ietf-dime-extended-naptr-03.txt Pages : 10 Date : 2010-11-08 The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanism do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node in order to discover which one supports a required application. This document describes an improvement using an extended format for the Straightfoward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-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-extended-naptr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08121245.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Nov 8 18:16:45 2010 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 5684428C21F; Mon, 8 Nov 2010 18:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uKXNb45VeO-q; Mon, 8 Nov 2010 18:16:44 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7723A6A24; Mon, 8 Nov 2010 18:15:41 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109021541.26008.96199.idtracker@localhost> Date: Mon, 08 Nov 2010 18:15:41 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-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: Tue, 09 Nov 2010 02:16:45 -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 Extended NAPTR Author(s) : M. Jones, J. Korhonen Filename : draft-ietf-dime-extended-naptr-03.txt Pages : 10 Date : 2010-11-08 The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanism do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node in order to discover which one supports a required application. This document describes an improvement using an extended format for the Straightfoward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-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-extended-naptr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08121245.I-D@ietf.org> --NextPart-- From sdecugis@nict.go.jp Tue Nov 9 01:16:26 2010 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 527673A6921 for ; Tue, 9 Nov 2010 01:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 tjMUWdcF5uto for ; Tue, 9 Nov 2010 01:16:25 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 93A3A3A68CC for ; Tue, 9 Nov 2010 01:16:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 6B68B94100 for ; Tue, 9 Nov 2010 10:16:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-NyY5VpgIdi for ; Tue, 9 Nov 2010 10:16:37 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 1BA2B940E7 for ; Tue, 9 Nov 2010 10:16:35 +0100 (CET) Message-ID: <4CD9116F.6070806@nict.go.jp> Date: Tue, 09 Nov 2010 18:16:31 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] I-D Action:draft-pascual-dime-sctp-00.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: Tue, 09 Nov 2010 09:16:26 -0000 Hi Victor, I have a few comments on this draft. First of all, thank you for putting this together, I believe it is very useful :) To comment on the "Editor's note" in section 3.1: I don't know the exact difference, but in my experience using the destination port number is an efficient way to track the exchange in a protocol analyzer. I am not sure of the value added by the PPID. In case there is such value, I guess 2 PPID are needed, one for plain Diameter and one for Diameter over DTLS? Section 3.3 (port number): I don't understand the purpose of this paragraph. Also, should a different port be attributed to DTLS/SCTP ? Would it be the same as TLS/TCP ? Or using PPID is better and we reserve only one port for Diameter/SCTP ? Edit: after reading 5.3, I got to understand. Maybe a little more wording to specify that section 3 concerns the case Diameter over IPsec would be useful. Section 4. (DTLS instead of TLS) Is it not better to deprecate the use of TLS -- easy because it was never clearly required anyway -- and recommend the use of DTLS as the only available mechanism? Or is it your intention to say that both mechanisms (TLS and DTLS) are possible ? In that case, how does an implementation know which one to use if both mechanisms are allowed -- do we need to reserve 2 different ports to distinguish TLS and DTLS? Section 5. "SCTP over IPsec is the RECOMMENDED solution for securing Diameter messages until..." I am not sure that this sentence is useful at all, I would rather not have it. But, I am maybe missing something here. My rationale is that using (D)TLS allows the Diameter application to have control over the credentials used to protect the connection and bind these credentials (such as subject of the certificate) to the Diameter Identity advertized by the remote peer. IPsec does not allow to do this as easily (e.g. a Diameter peer could impersonate another peer in that case). Therefore, I believe that (D)TLS should be recommended over IPsec, and not the other way around as the proposed text suggest. But I agree that the lack of deployment might be an issue -- the same as the lack of support for SCTP at all, actually... 5.2 (ordering) There are a few rare cases where the messages actually have to be ordered. For example, if a message is sent immediatly after a CEA (might happen after a connection is restored) but received before this CEA, it will be discarded, as per the connection state machine. With playing with different streams it is possible to work around this. The same applies probably to unordered delivery (I have not checked). For example, unordered delivery should not be used until a message has been received from the remote peer after CEA has been sent. Another such race condition is possible with DPR/DPA exchange (if DPR is received before the last message, although it was sent after). For this one I am not sure what the correct workaround could be -- maybe just don't send a DPR "too soon" after a message. 5.3. Ok, this explains and answers my comment on 3.3. A little more wording in that section would help understanding, maybe -- or it is just me ^^ Best regards, and good work! Sebastien. Le 08/11/2010 21:32, Victor Pascual Avila a écrit : > Hi Folks, > > Being related to some recent discussion > (http://www.ietf.org/mail-archive/web/dime/current/msg04545.html) we > have just submitted a draft on the usage of Diameter over SCTP. > > > Filename: draft-pascual-dime-sctp > > Version: 00 > > URL: http://tools.ietf.org/id/draft-pascual-dime-sctp-00.txt > > Title: The Stream Control Transmission Protocol (SCTP) as a Transport > for the Diameter Protocol > > Abstract: This document provides the guidelines for usage of SCTP (the > Stream Control Transmission Protocol) as the transport mechanism > between Diameter entities. > > Author(s): > Victor Pascual, VPascual@acmepacket.com > Gonzalo Camarillo, Gonzalo.Camarillo@ericsson.com > > Comments are welcome! > > Cheers, > -Victor > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From victor.pascual.avila@gmail.com Tue Nov 9 21:34:40 2010 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 806DC3A67D1 for ; Tue, 9 Nov 2010 21:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GuSS3LoGuTuB for ; Tue, 9 Nov 2010 21:34:29 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B1F253A67A3 for ; Tue, 9 Nov 2010 21:34:26 -0800 (PST) Received: by bwz12 with SMTP id 12so394813bwz.31 for ; Tue, 09 Nov 2010 21:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jTNmN6mF+Lxd7hRut9bnv7gMQRflyR0t/EK0hfjO6oM=; b=jb8P9rCOs2/IK0x6fWdK7riDUxIL4JMKuBgDgMCATSfSJ8bP9v7/3LLXKF0cvJBitT NcoLtGXHPRSOW4YGxTRvhEwJHm8gazuzNtxOuO0GViSeQsrp9/agh/FFtnKUnpdn0FA9 wt2j3n9/Rwv+IyJjDJReBjTN7cNZ82ZYH15kE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GRgVHIEF9aPgVEjxRvAkr+Xr88kmwivf+ytM1I6Nm5cHVyXIfWuJ9hMQ76a2DZ6XJb uUHBJZOYRRaILVzG57FxoUDSCuhYG0oAEHp/gTgNUd5gU3mKT5EBiLbRZo1c3zI48wh4 vx5j0jz/e/ccl60gNGwYsf3RTvzAdxby7DLHo= MIME-Version: 1.0 Received: by 10.204.122.8 with SMTP id j8mr7479363bkr.135.1289367292122; Tue, 09 Nov 2010 21:34:52 -0800 (PST) Received: by 10.204.81.76 with HTTP; Tue, 9 Nov 2010 21:34:52 -0800 (PST) In-Reply-To: <4CD9116F.6070806@nict.go.jp> References: <4CD9116F.6070806@nict.go.jp> Date: Wed, 10 Nov 2010 06:34:52 +0100 Message-ID: From: Victor Pascual Avila To: Sebastien Decugis Content-Type: text/plain; charset=UTF-8 Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-pascual-dime-sctp-00.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: Wed, 10 Nov 2010 05:34:40 -0000 Hi Sebastien, thanks for your comments. Answers to a couple of points inline... On Tue, Nov 9, 2010 at 10:16 AM, Sebastien Decugis wrote: > Section 4. (DTLS instead of TLS) > Is it not better to deprecate the use of TLS -- easy because it was > never clearly required anyway -- and recommend the use of DTLS as the > only available mechanism? Or is it your intention to say that both > mechanisms (TLS and DTLS) are possible ? In that case, how does an > implementation know which one to use if both mechanisms are allowed I'd say - For TCP: TLS is the primary method for securing Diameter and IPsec is a secondary alternative - For SCTP: DTLS is the primary method for securing Diameter and IPsec is a secondary alternative > 5.2 (ordering) > There are a few rare cases where the messages actually have to be > ordered. For example, if a message is sent immediatly after a CEA (might > happen after a connection is restored) but received before this CEA, it > will be discarded, as per the connection state machine. With playing > with different streams it is possible to work around this. The same > applies probably to unordered delivery (I have not checked). For > example, unordered delivery should not be used until a message has been > received from the remote peer after CEA has been sent. > Another such race condition is possible with DPR/DPA exchange (if DPR is > received before the last message, although it was sent after). > For this one I am not sure what the correct workaround could be -- maybe > just don't send a DPR "too soon" after a message. AFAIU the ordering is provided at the application level and there is no need to handle this at the transport layer. As you mention, there could be exceptions like CER/CEA or STR/STA but I believe this is something that could be worked around in the implementation. Cheers, -Victor From trac@tools.ietf.org Mon Nov 15 15:44:54 2010 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 A188728C151 for ; Mon, 15 Nov 2010 15:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 aFCUbtpTPi6g for ; Mon, 15 Nov 2010 15:44:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2059628C13F for ; Mon, 15 Nov 2010 15:44:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PI8jm-0004EV-Uj; Mon, 15 Nov 2010 15:45:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Mon, 15 Nov 2010 23:45:26 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/15 Message-ID: <074.30ef73da117fb2a3a15f19ffe0385b3a@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] extended-naptr #15 (new): review of extended NAPTR draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 23:44:54 -0000 #15: review of extended NAPTR draft As promised, here is my feedback based on the last version of the draft. Mainly, it is more a question of readability/clarification than technical comment. The only "issue" depending of the feeling of the WG would be about discussing "experimental" format in this specification, that should be just for information and not normative. BR, Lionel ****************** Abstract The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanism do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node in order to discover which one supports a required application. This document describes an improvement using an extended format for the Straightfoward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [LM] the following sentence should be removed. "A peer outside the realm would have to perform a Diameter capability exchange with every node in order to discover which one supports a required application." CER/CEA exhange will not be performed with "every node". Such assertion is not required anyway. The only thing that we can say that there is no way for the peer to know the Diameter node to contact for a given application. Default behaviour is outside the current scope of RFC3588 and should be left outside. [LM] ****************** 3. Extended NAPTR Service Field Format The NAPTR Service Field format defined by the S-NAPTR DDDS application in [RFC3958] consists of a S-NAPTR Application Service tag and a S-NAPTR Application Protocol tag delimited by a single colon (":") character. [LM] In the RFC 3958, it is said: "the Service Parameters may consist of an empty string, an app- service, or an app-service with one or more app-protocol specifications separated by the ":" symbol." so, app-service + app-protocol is only one of the possible formats. Therefore, the wording should be: "The NAPTR Service Field format defined by the S-NAPTR DDDS in [RFC3958] may consists of a S-NAPTR Application Service tag and a S-NAPTR Application Protocol tag delimited by a single colon (":") character." For illustration, a copy/paste of the format given in RFC 3958 can also be added: "service-parms = [ [app-service] *(":" app-protocol)]" [LM] ******************* " The S-NAPTR Application Service Tag ABNF specification for the discovery of Diameter agents supporting a specific Diameter application is shown below." [LM] s/application is shown below/application is defined below ***************************** appln-svc-tag = iana-appln-tag / experimental-appln-tag iana-appln-tag = "aaa+ap" appln-id experimental-appln-tag = "x-aaa+ap" appln-id appln-id = *DIGIT ; Application identifier expressed as a ; decimal integer. [LM] Why this specific notation for appl-service? Why not reuse instead the same notation as in RFC 3958, that would mean: app-service = iana-appln-tag / experimental-appln-tag [LM] ************************** "As stated in [RFC3958], application service tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk. The S-NAPTR Application Protocol Tag ABNF specification for the discovery of Diameter agents supporting a specific Diameter transport protocol is shown below." [LM] if something starting by "x-" is experimental, why do we have to indicate any specific format in this specification? At least, one example for illustration can be provided, as possible way to handle it (especially for other SDOs e.g. 3GPP), but there is no specific reason for further detailed info. [LM] **************************************** appln-protocol-tag = "diameter." app-protocol app-protocol = "tcp" / "sctp" / "tls.tcp" [LM] same comment applies but raises another comment: "app-protocol" is already used in RFC 3958 as component of the "service-parms": "service-parms = [ [app-service] *(":" app-protocol)]". So some people can get confuse when reading both RFC 3403 and this specification. *********************************** "The maximum length of the NAPTR service field is 256 octets including one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 of [RFC1035]). DNS administrators SHOULD also provision legacy RFC 3588 style NAPTR records [RFC2915] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers. If the DNS administrator provisions both extended S-NAPTR records as defined in this specification and legacy RFC 3588 NAPTR records, then the extended S-NAPTR records MUST have higher priority (e.g. lower order and/or preference values) than legacy NAPTR records." [LM] the text related to support request from legacy nodes should be put in a separate section, just to highlight the specific content. There is nothing to do with S-NAPTR format. Moreover, even if obvious, a sentence should be added to detail the behaviour of leagcy nodes receiving DNS responses with both type of S-NATPT records, to show that there is no compatible issue. [LM] [LM] based on my previous comment, I would propose to modify the content of the section 3 as put at the end *********************************************** 4. Extended NAPTR-based Diameter Peer Discovery The Diameter Peer Discovery principles are described in Section 5.2 of [RFC3588]. This specification updates the NAPTR query procedure in the Diameter peer discovery mechanism by allowing the querying node to determine which applications are supported by resolved Diameter peers. The extended format NAPTR records provide a mapping from a domain, to [LM] s/a domain, to/a domain to [LM] *********** a. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know in advance which realm to look for a Diameter agent in and which Application Identifier it is interested in. The realm could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on. [LM] I know that it is a copy/paste frm RFC3588 and maybe it is due to my poor english but i felt to undersand the last sentence [LM] ********************** 5. Usage Guidelines Diameter is a peer to peer protocol whereas most of the applications that extend the base protocol behave like client/server applications. The role of the peer is not advertised in the NAPTR tags and not even communicated during Diameter capability negotiation (CER/CEA). For this reason, NAPTR-based Diameter peer discovery for an application defining client/server roles should only be used by a client to discover servers. [LM] Should we clarify that the DNS responses can provide records for a proxy and redirect agents and not only "servers", or it is too obvious? [LM] ******************* 6.1. IETF Diameter Application Service Tags IANA is requested to reserve the following S-NAPTR Application Service Tags for existing IETF Diameter applications: +------------------+----------------------------+ | Tag | Diameter Application | +------------------+----------------------------+ | aaa+ap1 | NASREQ [RFC3588] | | aaa+ap2 | Mobile IPv4 [RFC4004] | | aaa+ap3 | Base Accounting [RFC3588] | | aaa+ap4 | Credit Control [RFC4006] | | aaa+ap5 | EAP [RFC4072] | | aaa+ap6 | SIP [RFC4740] | | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | | aaa+ap9 | QoS [RFC5866] | | aaa+ap4294967295 | Relay [RFC3588] | +------------------+----------------------------+ Future IETF Diameter applications MUST reserve the S-NAPTR Application Service Tag corresponding to the allocated Diameter Application ID. [LM] should indicate that the IANA registration process is defined in RFC3958 [LM] ************* proposal for section 3 ************************* - begin - 3. Extended NAPTR Service Field Format As described in RFC 3958 [RFC3958], Service Parameters for S-NAPTR take the form of a string of characters that follow this ABNF: service-parms = [ [app-service] *(":" app-protocol)] app-service = experimental-service / iana-registered-service app-protocol = experimental-protocol / iana-registered-protocol experimental-service = "x-" 1*30ALPHANUMSYM experimental-protocol = "x-" 1*30ALPHANUMSYM iana-registered-service = ALPHA *31ALPHANUMSYM iana-registered-protocol = ALPHA *31ALPHANUMSYM ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." ALPHANUMSYM = ALPHA / DIGIT / SYM ; The app-service and app-protocol tags are limited to 32 ; characters and must start with an alphabetic character. ; The service-parms are considered case-insensitive. The maximum length of the NAPTR service field is 256 octets including one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 of [RFC1035]). Section 3.1 defines S-NAPTR Application Service and Application Procotol Tag values that permit the discovery of Diameter peers that support a standard- track Diameter application and transport protocol. Section 3.2 provides informational guidelines for the definition of S-NAPTR Application Service Tag values that permit the discovery of Diameter peers that support a standard-track Diameter application and transport protocol. 3.1 New iana-registered Application service and application protocol values This specification defines a new iana-registered-service value for the "app-service" field: iana-registered-service = "aaa+ap" appln-id appln-id = *DIGIT Expressed as a decimal integer, the "appln-id" is used here to identify a diameter application identifier as assigned by IANA. This specification defines a new iana-registered-protocol value for the "app-protocol" field: app-protocol = "diameter." app-transport app-transport = "tcp" / "sctp" / "tls.tcp" 3.2 Use of Extended NAPTR Service Field Format for standard-track applications It MUST be possible to use extended S-NAPTR Application Service Tag for dynamic discovery of Diameter agent supporting standard-track applications. Therefore, every IETF Standard-track Diameter application MUST be associated with the iana-registered- service value defined in this specification. For example, a NAPTR service field value of: 'aaa+ap6:diameter.sctp' will mean that the Diameter node in the SRV or A/AAAA record supports the Diameter Session Initiation Protocol (SIP) Application ('6') and SCTP as the transport protocol. 3.3 Options for use of S-NAPTR Application Service Tag for vendor-specific applications S-NAPTR Application Service and Application Procotol Tag values can also be used to discover Diameter peers that support a vendor-specific Diameter application. In such a case, there are two alternatives when using the Application Service tag. 3.3.1 Use of iana-registered-service value Vendor-specific Diameter applications MAY be associated with the iana-registered-service value defined in this specification. In such a case, extended NAPTR Application Service tag for vendor-specific application will have the same format than for standard-track application. For example, a NAPTR service field value of: 'aaa+ap16777251:diameter.sctp' will mean that the Diameter node in the SRV or A/AAAA record supports the Diameter S6a Application ('16777251') and SCTP as the transport protocol. However, such use of iana-registered-service value would require the publication of an RFC (of any category) as mandated by the IANA policy defined in [RFC3958, and this may not be desired by vendors/SDOs. 3.3.2 Use of experimental-service value Instead of resorting to the constraining iana-registrered Appication Service tag, vendors/SDOs may rather rely on the experimental-service value as authorized by the format of Application service field. In such a case, this specification recommends the following format for the "app-service" field: experimental-service = "x-aaa+ap" appln-id appln-id = *DIGIT Expressed as a decimal integer, the "appln-id" is used here to identify a vendor-specific application identifier as assigned by IANA. As stated in [RFC3958], application service tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk. It is therefore the responsability of each vendor/SDO to define the exact values of S-NAPTR Application Service Tags associated with vendor- specific Diameter applications. For example, a NAPTR service field value of: 'aaa+ap16777251:diameter.sctp' would mean that the Diameter node in the SRV or A/AAAA record supports the 3GPP-specific Diameter S6a Application ('16777251') and SCTP as the transport protocol. The use of this experimental-service value is strongly discouraged when considering standard-track applications, as standard values are assigned by IANA. - end - -- ----------------------------------------------+----------------------------- Reporter: lionel.morand@… | Owner: lionel.morand@… Type: enhancement | Status: new Priority: major | Milestone: Component: extended-naptr | Version: Severity: In WG Last Call | Keywords: ----------------------------------------------+----------------------------- Ticket URL: dime From Internet-Drafts@ietf.org Mon Nov 15 22:46:30 2010 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 284E53A6DAB; Mon, 15 Nov 2010 22:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bl4p1S73WRpb; Mon, 15 Nov 2010 22:45:59 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927653A6C66; Mon, 15 Nov 2010 22:45:11 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101116064508.5338.54575.idtracker@localhost> Date: Mon, 15 Nov 2010 22:45:08 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc4005bis-02.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: Tue, 16 Nov 2010 06:46:30 -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 Network Access Server Application Author(s) : G. Zorn Filename : draft-ietf-dime-rfc4005bis-02.txt Pages : 65 Date : 2010-11-15 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-02.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-rfc4005bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-15224213.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Nov 23 03:00:02 2010 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 9F2BD3A68EB; Tue, 23 Nov 2010 03:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8IzysmgCEkG6; Tue, 23 Nov 2010 03:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21943A68E4; Tue, 23 Nov 2010 03:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101123110001.20483.66005.idtracker@localhost> Date: Tue, 23 Nov 2010 03:00:01 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-lr-02.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: Tue, 23 Nov 2010 11: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 Support for Proxy Mobile IPv6 Localized Routing Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-pmip6-lr-02.txt Pages : 13 Date : 2010-11-23 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly by the MAG without involving the LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of localized routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-02.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-pmip6-lr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-23025224.I-D@ietf.org> --NextPart-- From violeta.cakulev@alcatel-lucent.com Tue Nov 23 11:21:58 2010 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 E488328C11B for ; Tue, 23 Nov 2010 11:21:57 -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 ywvQiITszkTV for ; Tue, 23 Nov 2010 11:21:56 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1F10528C19A for ; Tue, 23 Nov 2010 11:21:54 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id oANJMosH016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Nov 2010 13:22:51 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oANJMnnB001373 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 23 Nov 2010 13:22:50 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 23 Nov 2010 13:22:50 -0600 From: "Cakulev, Violeta (Violeta)" To: "dime@ietf.org" Date: Tue, 23 Nov 2010 13:22:49 -0600 Thread-Topic: draft-ietf-dime-ikev2-psk-diameter open issues Thread-Index: AcuLQ9CxAqrvWsfWTOCST+oPB8lq0A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [Dime] draft-ietf-dime-ikev2-psk-diameter open issues 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, 23 Nov 2010 19:21:58 -0000 As discussed in Beijing meeting, there are 2 open issues. These open issues= and their respective solutions are summarized below. ---------------------------------------------------------------------------= ------------- Issue 1. Is there any need for Auth-Request-Type AVP in the request if only= Authorize-Only (value 2) is used in this application? What should be the b= ehavior of the receiver if the Auth-Request-Type AVP is set to the value 1 = or 3, which are valid values? What is the error code send back to the sende= r? Solution to issue 1: Keep Auth-Request-Type AVP in the request with only Au= thorize-Only (value 2) allowed. If values 1 or 3 are received send Result-C= ode AVP set to DIAMETER_INVALID_AVP_VALUE and include the Auth-Request-AVP = in the Failed-AVP AVP. DIAMETER_INVALID_AVP_VALUE is a permanent failure, t= herefore the peer is informed that the request failed, and should not be at= tempted again. Values 1 and 3 are valid values in Diameter based protocol, = however they are invalid values in this I-D, therefore there are no problem= s to send DIAMETER_INVALID_AVP_VALUE if 1 or 3 are received. ---------------------------------------------------------------------------= ------------- Issue 2: When IKEv2 Server requests the key it may use SPI to help AAA dete= rmine which key needs to be returned. How is this SPI transported to AAA? This issue has multiple solutions. Some of the solutions are outlined below= . Interested parties are invited to indicate preferred solution. Solution 1: SPI is contained in Key AVP specified in draft-ietf-dime-local-= keytran. Key AVP sent in the request contains only SPI AVP. In this case, d= raft-ietf-dime-local-keytran is modified such that Keying-Material AVP is o= ptional AVP. Solution 2: SPI is contained in Key AVP specified in draft-ietf-dime-local-= keytran. Key AVP sent in the request contains both Keying-Material AVP and = SPI AVP. Keying-Material AVP is populated with all 0s and/or is ignored by = AAA. In this case, no changes to draft-ietf-dime-local-keytran are needed. Solution 3: Do not use draft-ietf-dime-local-keytran and specify all AVPs i= n this I-D. Solution 4: Specify SPI AVP in this I-D and send it separately in the reque= st. Use Key AVP specified in draft-ietf-dime-local-keytran in the response. ---------------------------------------------------------------------------= -------------- Best regards, -Violeta From sdecugis@nict.go.jp Tue Nov 23 17:43:13 2010 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 DDA693A69E5 for ; Tue, 23 Nov 2010 17:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 yvrFQ3gMOKKf for ; Tue, 23 Nov 2010 17:43:12 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 9CDC33A69E6 for ; Tue, 23 Nov 2010 17:43:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 9BF1C9423C for ; Wed, 24 Nov 2010 02:44:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOAccAV90lV9 for ; Wed, 24 Nov 2010 02:43:57 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 2A4749404B for ; Wed, 24 Nov 2010 02:43:55 +0100 (CET) Message-ID: <4CEC6DD4.2060507@nict.go.jp> Date: Wed, 24 Nov 2010 10:43:48 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] draft-ietf-dime-ikev2-psk-diameter open issues 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, 24 Nov 2010 01:43:14 -0000 Hello, I think the solution to issue 1 is reasonable. About issue 2, is there a reason why you are not considering a "solution 5" that was proposed during Beijing meeting, as follow: Solution 5: Use Key-SPI AVP defined in draft-ietf-dime-local-keytran for the request. Use Key AVP in the answer. (you'll have to precise which AVPs must be present in this grouped AVP in the answer in you application, like for example Key-SPI AVP). Best regards, Sebastien. Le 24/11/2010 04:22, Cakulev, Violeta (Violeta) a écrit : > As discussed in Beijing meeting, there are 2 open issues. These open issues and their respective solutions are summarized below. > > ---------------------------------------------------------------------------------------- > Issue 1. Is there any need for Auth-Request-Type AVP in the request if only Authorize-Only (value 2) is used in this application? What should be the behavior of the receiver if the Auth-Request-Type AVP is set to the value 1 or 3, which are valid values? What is the error code send back to the sender? > > Solution to issue 1: Keep Auth-Request-Type AVP in the request with only Authorize-Only (value 2) allowed. If values 1 or 3 are received send Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE and include the Auth-Request-AVP in the Failed-AVP AVP. DIAMETER_INVALID_AVP_VALUE is a permanent failure, therefore the peer is informed that the request failed, and should not be attempted again. Values 1 and 3 are valid values in Diameter based protocol, however they are invalid values in this I-D, therefore there are no problems to send DIAMETER_INVALID_AVP_VALUE if 1 or 3 are received. > ---------------------------------------------------------------------------------------- > > Issue 2: When IKEv2 Server requests the key it may use SPI to help AAA determine which key needs to be returned. How is this SPI transported to AAA? > This issue has multiple solutions. Some of the solutions are outlined below. Interested parties are invited to indicate preferred solution. > > Solution 1: SPI is contained in Key AVP specified in draft-ietf-dime-local-keytran. Key AVP sent in the request contains only SPI AVP. In this case, draft-ietf-dime-local-keytran is modified such that Keying-Material AVP is optional AVP. > > Solution 2: SPI is contained in Key AVP specified in draft-ietf-dime-local-keytran. Key AVP sent in the request contains both Keying-Material AVP and SPI AVP. Keying-Material AVP is populated with all 0s and/or is ignored by AAA. In this case, no changes to draft-ietf-dime-local-keytran are needed. > > Solution 3: Do not use draft-ietf-dime-local-keytran and specify all AVPs in this I-D. > > Solution 4: Specify SPI AVP in this I-D and send it separately in the request. Use Key AVP specified in draft-ietf-dime-local-keytran in the response. > ----------------------------------------------------------------------------------------- > > > Best regards, > -Violeta > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Tue Nov 23 20:00:31 2010 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 EF2A628C100 for ; Tue, 23 Nov 2010 20:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1Ud1iwH8Q9or for ; Tue, 23 Nov 2010 20:00:31 -0800 (PST) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 29F1628C0EE for ; Tue, 23 Nov 2010 20:00:31 -0800 (PST) Received: (qmail 26565 invoked from network); 24 Nov 2010 04:01:29 -0000 Received: from unknown (110.168.99.145) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 24 Nov 2010 04:01:28 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4CEC6DD4.2060507@nict.go.jp> In-Reply-To: <4CEC6DD4.2060507@nict.go.jp> Date: Wed, 24 Nov 2010 11:01:20 +0700 Organization: Network Zen Message-ID: <000001cb8b8c$42fab500$c8f01f00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuLeRr4/PVAiilAShicfBal8ZIANgAEvdaw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-ikev2-psk-diameter open issues 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, 24 Nov 2010 04:00:32 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello, > > I think the solution to issue 1 is reasonable. > > About issue 2, is there a reason why you are not considering a "solution > 5" that was proposed during Beijing meeting, Good question! > as follow: > > Solution 5: Use Key-SPI AVP defined in draft-ietf-dime-local-keytran for > the request. Use Key AVP in the answer. (you'll have to precise which > AVPs must be present in this grouped AVP in the answer in you > application, like for example Key-SPI AVP). > ... Love is never safe. It is fierce and unpredictable and impossible to domesticate. You can't make it your slave because it is simply bigger than you. ~ Susan Piver From jouni.nospam@gmail.com Fri Nov 26 13:38:14 2010 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 E12C83A68E8 for ; Fri, 26 Nov 2010 13:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 V5cQYDWN+EEn for ; Fri, 26 Nov 2010 13:38:14 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id F252428C0F1 for ; Fri, 26 Nov 2010 13:38:10 -0800 (PST) Received: by fxm9 with SMTP id 9so1977960fxm.31 for ; Fri, 26 Nov 2010 13:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=ZmWh3NXXPjbkjvYnKVasyhC44FVAxP7oCawhxlRlbG0=; b=qAQaWycX73N1BSeRmb0hqPHkxL7lO4dcA0g/k+xo33xb/c5qXoFng/uMRrrJsOXZuh IsBXa2sjuMZAH/iQQxgsBxfgbrvBwfAj0W2TbZxq+pPL9HdoirTn+2qpG1HLbHEOGKYb gq1ny0ThW7QFtvq7Z5cgujQ0AydzFq2h5tsYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=LYMTTj6UtXmdtyYihQYgyeJjKxE7Pbg2OWhLwF7VXmLqfhgvubiuzsKX4MUF0AErTB ylc2vDTmohS3F8kukAu7ELEBGHO++O/EPrFHt2F5RPdZ+PM+7OsAdWkqEXse7FI1UMJW lNPq/vagD2HVHfo60dQjEhU0Mt/XemjrnVa2c= Received: by 10.223.101.131 with SMTP id c3mr2626607fao.95.1290807553410; Fri, 26 Nov 2010 13:39:13 -0800 (PST) Received: from a88-114-173-239.elisa-laajakaista.fi (a88-114-173-239.elisa-laajakaista.fi [88.114.173.239]) by mx.google.com with ESMTPS id n26sm565379fam.13.2010.11.26.13.39.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Nov 2010 13:39:12 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Nov 2010 23:39:10 +0200 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] IETF#79 draft meeting minutes uploaded 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, 26 Nov 2010 21:38:15 -0000 Folks, Draft meeting minutes can be found here: http://www.ietf.org/proceedings/79/minutes/dime.txt - Jouni & Lionel From mark@azu.ca Mon Nov 29 06:17:18 2010 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 C46253A6BCC for ; Mon, 29 Nov 2010 06:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 oMVkFUMRSf11 for ; Mon, 29 Nov 2010 06:17:17 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 96C633A6BC1 for ; Mon, 29 Nov 2010 06:17:16 -0800 (PST) Received: by qwg5 with SMTP id 5so3381944qwg.31 for ; Mon, 29 Nov 2010 06:18:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.251.82 with SMTP id mr18mr5039547qcb.43.1291040305803; Mon, 29 Nov 2010 06:18:25 -0800 (PST) Received: by 10.229.229.141 with HTTP; Mon, 29 Nov 2010 06:18:25 -0800 (PST) In-Reply-To: <074.30ef73da117fb2a3a15f19ffe0385b3a@tools.ietf.org> References: <074.30ef73da117fb2a3a15f19ffe0385b3a@tools.ietf.org> Date: Mon, 29 Nov 2010 09:18:25 -0500 Message-ID: From: Mark Jones To: lionel.morand@orange-ftgroup.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] [dime] extended-naptr #15 (new): review of extended NAPTR draft 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, 29 Nov 2010 14:17:19 -0000 Thanks for the comprehensive review, Lionel. Comments/questions inline prefixed by [mj] Regards Mark On Mon, Nov 15, 2010 at 6:45 PM, dime issue tracker w= rote: > #15: review of extended NAPTR draft > > =A0As promised, here is my feedback based on the last version of the draf= t. > =A0Mainly, it is more a question of readability/clarification than techni= cal > =A0comment. The only "issue" depending of the feeling of the WG would be > =A0about discussing "experimental" format in this specification, that sho= uld > =A0be just for information and not normative. > > =A0BR, > > =A0Lionel > > =A0****************** > =A0Abstract > > =A0 =A0The Diameter base protocol specifies mechanisms whereby a given re= alm > =A0 =A0may advertise Diameter nodes and the supported transport protocol. > =A0 =A0However, these mechanism do not reveal the Diameter applications t= hat > =A0 =A0each node supports. =A0A peer outside the realm would have to perf= orm a > =A0 =A0Diameter capability exchange with every node in order to discover > =A0 =A0which one supports a required application. =A0This document descri= bes > =A0 =A0an improvement using an extended format for the Straightfoward-NAP= TR > =A0 =A0(S-NAPTR) Application Service Tag that allows for discovery of the > =A0 =A0supported applications without doing Diameter capability exchange > =A0 =A0beforehand. > > > =A0[LM] the following sentence should be removed. > > =A0 "A peer outside the realm would have to perform a > =A0 =A0Diameter capability exchange with every node in order to discover > =A0 =A0which one supports a required application." > > =A0CER/CEA exhange will not be performed with "every node". Such assertio= n is > =A0not required anyway. The only thing that we can say that there is no w= ay > =A0for the peer to know the Diameter node to contact for a given applicat= ion. > =A0Default behaviour is outside the current scope of RFC3588 and should b= e > =A0left outside. [LM] > [mj] Ok but a CER/CEA may be required with "every node" until the peer loc= ates one supporting the required application. I would prefer to keep this sente= nce as it helps explain the benefit but reword as "A peer outside the realm wo= uld have to perform a Diameter capability exchange with each node until it discovers one that supports the required application." > =A0****************** > > =A03. Extended NAPTR Service Field Format > > =A0 =A0The NAPTR Service Field format defined by the S-NAPTR DDDS > =A0 =A0application in [RFC3958] consists of a S-NAPTR Application Service > =A0 =A0tag and a S-NAPTR Application Protocol tag delimited by a single > =A0 =A0colon (":") character. > > =A0[LM] > =A0In the RFC 3958, it is said: > > =A0 =A0"the Service Parameters may consist of an empty string, an app- > =A0 =A0service, or an app-service with one or more app-protocol > =A0 =A0specifications separated by the ":" symbol." > > =A0so, app-service + app-protocol is only one of the possible formats. > =A0Therefore, the wording should be: > > =A0 =A0"The NAPTR Service Field format defined by the S-NAPTR DDDS in > =A0 =A0[RFC3958] may consists of a S-NAPTR Application Service tag and a > =A0S-NAPTR > =A0 =A0Application Protocol tag delimited by a single colon (":") charact= er." > > =A0For illustration, a copy/paste of the format given in RFC 3958 can als= o be > =A0added: "service-parms =3D [ [app-service] *(":" app-protocol)]" > > =A0[LM] > [mj] Agreed but I'd prefer to keep the RFC3958 text that you quote. > =A0******************* > > =A0 " The S-NAPTR Application Service Tag ABNF specification for the > =A0 =A0discovery of Diameter agents supporting a specific Diameter > =A0 =A0application is shown below." > > =A0[LM] s/application is shown below/application is defined below > [mj] Agreed. > =A0***************************** > > =A0 =A0 =A0 =A0appln-svc-tag =A0 =A0 =A0 =A0 =A0 =3D iana-appln-tag / exp= erimental-appln-tag > =A0 =A0 =A0 =A0iana-appln-tag =A0 =A0 =A0 =A0 =A0=3D "aaa+ap" appln-id > =A0 =A0 =A0 =A0experimental-appln-tag =A0=3D "x-aaa+ap" appln-id > =A0 =A0 =A0 =A0appln-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D *DIGIT > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; Appl= ication identifier expressed as a > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; deci= mal integer. > > =A0[LM] Why this specific notation for appl-service? Why not reuse instea= d > =A0the same notation as in RFC 3958, that would mean: > > =A0 =A0 =A0 =A0app-service =A0 =A0 =A0 =A0 =A0 =A0 =3D iana-appln-tag / e= xperimental-appln-tag > =A0[LM] > [mj] Agreed > =A0************************** > > =A0 =A0"As stated in [RFC3958], application service tags that start with = "x-" > =A0 =A0are considered experimental, and no provision is made to prevent > =A0 =A0duplicate use of the same string. =A0Implementors use them at thei= r own > =A0 =A0risk. > > =A0 =A0The S-NAPTR Application Protocol Tag ABNF specification for the > =A0 =A0discovery of Diameter agents supporting a specific Diameter transp= ort > =A0 =A0protocol is shown below." > > > =A0[LM] if something starting by "x-" is experimental, why do we have to > =A0indicate any specific format in this specification? At least, one exam= ple > =A0for illustration can be provided, as possible way to handle it (especi= ally > =A0for other SDOs e.g. 3GPP), but there is no specific reason for further > =A0detailed info. [LM] > [mj] After further consideration, I agree we can not indicate a specific f= ormat for the experimental namespace. We have no idea what is out there already in experimental land so can not guarantee that our recommendations are unique. In addition, removing all references to the experimental-appln-tag would simplify the draft (and remove the need for some of the subsections you are proposing in the section 3 re-org). As you point out, there are many possible ways to handle it and no real value is defining a specific format. > =A0**************************************** > > =A0 =A0 =A0 =A0appln-protocol-tag =A0=3D "diameter." app-protocol > =A0 =A0 =A0 =A0app-protocol =A0 =A0 =A0 =A0=3D "tcp" / "sctp" / "tls.tcp" > > =A0[LM] same comment applies but raises another comment: "app-protocol" i= s > =A0already used in RFC 3958 as component of the "service-parms": > =A0"service-parms =3D [ [app-service] *(":" app-protocol)]". So some peop= le can > =A0get confuse when reading both RFC 3403 and this specification. > mj] Agreed. I'll keep it consistent with the RFC3958 labels. > =A0*********************************** > > =A0 =A0"The maximum length of the NAPTR service field is 256 octets inclu= ding > =A0 =A0one octet length field (see Section 4.1 of RFC 3403 and Section 3.= 3 > =A0 =A0of [RFC1035]). =A0DNS administrators SHOULD also provision legacy = RFC > =A0 =A03588 style NAPTR records [RFC2915] in order to guarantee backwards > =A0 =A0compatibility with legacy RFC 3588 compliant Diameter peers. =A0If= the > =A0 =A0DNS administrator provisions both extended S-NAPTR records as defi= ned > =A0 =A0in this specification and legacy RFC 3588 NAPTR records, then the > =A0 =A0extended S-NAPTR records MUST have higher priority (e.g. lower ord= er > =A0 =A0and/or preference values) than legacy NAPTR records." > > =A0[LM] the text related to support request from legacy nodes should be p= ut > =A0in a separate section, just to highlight the specific content. There i= s > =A0nothing to do with S-NAPTR format. Moreover, even if obvious, a senten= ce > =A0should be added to detail the behaviour of leagcy nodes receiving DNS > =A0responses with both type of S-NATPT records, to show that there is no > =A0compatible issue. [LM] > [mj] I will move to a new "Backwards Compatibility" section. Legacy nodes applying the RFC3588 query procedure are simply going to ignore the entries formatted as "aaa+apX:Y". Is that the sentence that you think is missing? > =A0[LM] based on my previous comment, I would propose to modify the conte= nt > =A0of the section 3 as put at the end > > =A0*********************************************** > =A04. Extended NAPTR-based Diameter Peer Discovery > > > =A0 =A0The Diameter Peer Discovery principles are described in Section 5.= 2 > =A0 =A0of [RFC3588]. =A0This specification updates the NAPTR query proced= ure > =A0 =A0in the Diameter peer discovery mechanism by allowing the querying > =A0 =A0node to determine which applications are supported by resolved > =A0 =A0Diameter peers. > > =A0 =A0The extended format NAPTR records provide a mapping from a domain,= to > > =A0[LM] s/a domain, to/a domain to [LM] > [mj] Agreed > =A0*********** > > =A0 =A0a. The Diameter implementation performs a NAPTR query for a server= in > =A0 =A0 =A0 a particular realm. =A0The Diameter implementation has to kno= w in > =A0 =A0 =A0 advance which realm to look for a Diameter agent in and which > =A0 =A0 =A0 Application Identifier it is interested in. =A0The realm coul= d be > =A0 =A0 =A0 deduced, for example, from the 'realm' in a NAI that a Diamet= er > =A0 =A0 =A0 implementation needed to perform a Diameter operation on. > > =A0[LM] I know that it is a copy/paste frm RFC3588 and maybe it is due to= my > =A0poor english but i felt to undersand the last sentence [LM] > [mj] I think I understand it but the whole paragraph is worded bizarrely. As it is just an example, the last sentence could be reworded as "For example, the realm could be deduced from the NAI in the User-Name AVP or extracted from the Destination-Realm AVP." > =A0********************** > > =A05. Usage Guidelines > > > =A0 =A0Diameter is a peer to peer protocol whereas most of the applicatio= ns > =A0 =A0that extend the base protocol behave like client/server applicatio= ns. > =A0 =A0The role of the peer is not advertised in the NAPTR tags and not e= ven > =A0 =A0communicated during Diameter capability negotiation (CER/CEA). =A0= For > =A0 =A0this reason, NAPTR-based Diameter peer discovery for an applicatio= n > =A0 =A0defining client/server roles should only be used by a client to > =A0 =A0discover servers. > > =A0[LM] Should we clarify that the DNS responses can provide records for = a > =A0proxy and redirect agents and not only "servers", or it is too obvious= ? > =A0[LM] > [mj] I originally considered this as obvious. To the client, an agent is st= ill acting in the server role. > =A0******************* > > =A06.1. IETF Diameter Application Service Tags > > > =A0 =A0IANA is requested to reserve the following S-NAPTR Application > =A0 =A0Service Tags for existing IETF Diameter applications: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------------+--------------------------= --+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0| Tag =A0 =A0 =A0 =A0 =A0 =A0 =A0| Diameter Ap= plication =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------------+--------------------------= --+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap1 =A0 =A0 =A0 =A0 =A0| NASREQ [RFC3588= ] =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap2 =A0 =A0 =A0 =A0 =A0| Mobile IPv4 [RF= C4004] =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap3 =A0 =A0 =A0 =A0 =A0| Base Accounting= [RFC3588] =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap4 =A0 =A0 =A0 =A0 =A0| Credit Control = [RFC4006] =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap5 =A0 =A0 =A0 =A0 =A0| EAP [RFC4072] = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap6 =A0 =A0 =A0 =A0 =A0| SIP [RFC4740] = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap7 =A0 =A0 =A0 =A0 =A0| Mobile IPv6 IKE= [RFC5778] =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap8 =A0 =A0 =A0 =A0 =A0| Mobile IPv6 Aut= h [RFC5778] | > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap9 =A0 =A0 =A0 =A0 =A0| QoS [RFC5866] = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0| aaa+ap4294967295 | Relay [RFC3588] =A0 =A0 = =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------------+--------------------------= --+ > > =A0 =A0Future IETF Diameter applications MUST reserve the S-NAPTR > =A0 =A0Application Service Tag corresponding to the allocated Diameter > =A0 =A0Application ID. > > =A0[LM] should indicate that the IANA registration process is defined in > =A0RFC3958 [LM] > [mj] Agreed. I'll add a reference to this section. > =A0************* proposal for section 3 ************************* [mj] There are some good suggestions in this proposal. I have some questions/comments inline below. > =A0- begin - > > =A03. =A0Extended NAPTR Service Field Format > > =A0 =A0As described in RFC 3958 [RFC3958], Service Parameters for S-NAPTR= take > =A0the form of a > =A0 =A0string of characters that follow this ABNF: > > =A0 =A0 =A0 service-parms =3D [ [app-service] *(":" app-protocol)] > =A0 =A0 =A0 app-service =A0 =3D experimental-service =A0/ iana-registered= -service > =A0 =A0 =A0 app-protocol =A0=3D experimental-protocol / iana-registered-p= rotocol > =A0 =A0 =A0 experimental-service =A0 =A0 =A0=3D "x-" 1*30ALPHANUMSYM > =A0 =A0 =A0 experimental-protocol =A0 =A0 =3D "x-" 1*30ALPHANUMSYM > =A0 =A0 =A0 iana-registered-service =A0 =3D ALPHA *31ALPHANUMSYM > =A0 =A0 =A0 iana-registered-protocol =A0=3D ALPHA *31ALPHANUMSYM > =A0 =A0 =A0 ALPHA =A0 =A0 =A0 =A0 =3D =A0%x41-5A / %x61-7A =A0 ; A-Z / a-= z > =A0 =A0 =A0 DIGIT =A0 =A0 =A0 =A0 =3D =A0%x30-39 ; 0-9 > =A0 =A0 =A0 SYM =A0 =A0 =A0 =A0 =A0 =3D =A0%x2B / %x2D / %x2E =A0; "+" / = "-" / "." > =A0 =A0 =A0 ALPHANUMSYM =A0 =3D =A0ALPHA / DIGIT / SYM > =A0 =A0 =A0 ; The app-service and app-protocol tags are limited to 32 > =A0 =A0 =A0 ; characters and must start with an alphabetic character. > =A0 =A0 =A0 ; The service-parms are considered case-insensitive. > [mj] Agreed. It is useful to repeat the ABNF from RFC3958 because then it is more obvious what we are overriding. > =A0 =A0The maximum length of the NAPTR service field is 256 octets includ= ing > =A0 =A0one octet length field (see Section 4.1 of RFC 3403 and Section 3.= 3 > =A0 =A0of [RFC1035]). > > =A0 =A0Section 3.1 defines S-NAPTR Application Service and Application > =A0Procotol Tag values > =A0 =A0that permit the discovery of Diameter peers that support a standar= d- > =A0track Diameter > =A0 =A0application and transport protocol. > > =A0 =A0Section 3.2 provides informational guidelines for the definition o= f > =A0S-NAPTR > =A0 =A0Application Service Tag values that permit the discovery of Diamet= er > =A0peers that > =A0 =A0support a standard-track Diameter application and transport protoc= ol. > > =A03.1 =A0New iana-registered Application service and application protoco= l > =A0values > [mj] But this draft is only concerned with iana-registered values. If SDOs/vendors want to play in the x- namespace then it is out of scope. > =A0 =A0This specification defines a new iana-registered-service value for= the > =A0"app-service" field: > > =A0 =A0 =A0 =A0iana-registered-service =3D "aaa+ap" appln-id > =A0 =A0 =A0 =A0appln-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D *DIGIT > > =A0 =A0Expressed as a decimal integer, the "appln-id" is used here to ide= ntify > =A0 =A0a diameter application identifier as assigned by IANA. > > =A0 =A0This specification defines a new iana-registered-protocol value fo= r the > =A0"app-protocol" field: > > =A0 =A0 =A0 =A0app-protocol =A0 =3D "diameter." app-transport > =A0 =A0 =A0 =A0app-transport =A0=3D "tcp" / "sctp" / "tls.tcp" > > =A03.2 Use of Extended NAPTR Service Field Format for standard-track > =A0applications > > =A0 =A0It MUST be possible to use extended S-NAPTR Application Service Ta= g for > =A0dynamic discovery of > =A0 =A0Diameter agent supporting standard-track applications. [mj] Can you clarify what "MUST be possible" means here? > Therefore, every IETF Standard-track > =A0 =A0Diameter application MUST be associated with the iana-registered- > =A0service value defined in > =A0 =A0this specification. > [mj] Agreed. This is a missing requirement in RFC3588 and why this draft is needed to update it. > =A0 =A0For example, a NAPTR service field value of: > > =A0 =A0 =A0 =A0'aaa+ap6:diameter.sctp' > > =A0 =A0will mean that the Diameter node in the SRV or A/AAAA record suppo= rts > =A0 =A0the Diameter Session Initiation Protocol (SIP) Application ('6') > =A0 =A0and SCTP as the transport protocol. > > =A03.3 Options for use of S-NAPTR Application Service Tag for vendor-spec= ific > =A0applications > > =A0 =A0S-NAPTR Application Service and Application Procotol Tag values ca= n > =A0 =A0also be used to discover Diameter peers that support a vendor-spec= ific > =A0 =A0Diameter application. In such a case, there are two alternatives w= hen > =A0 =A0using the Application Service tag. > [mj] Only one alternative is in scope of this draft if we are only concerne= d with iana-registered service values. > =A03.3.1 Use of iana-registered-service value > > =A0 =A0Vendor-specific Diameter applications MAY be associated > =A0 =A0with the iana-registered-service value defined in this specificati= on. > =A0 =A0In such a case, extended NAPTR Application Service tag for > =A0 =A0vendor-specific application will have the same format than for > =A0standard-track application. > > =A0 =A0For example, a NAPTR service field value of: > > =A0 =A0 =A0 =A0'aaa+ap16777251:diameter.sctp' > > =A0 =A0will mean that the Diameter node in the SRV or A/AAAA record suppo= rts > =A0 =A0the Diameter S6a Application ('16777251') and SCTP as the transpor= t > =A0 =A0protocol. > > =A0 =A0However, such use of iana-registered-service value would require t= he > =A0 =A0publication of an RFC (of any category) as mandated by the IANA po= licy > =A0 =A0defined in [RFC3958, and this may not be desired by vendors/SDOs. > > =A03.3.2 Use of experimental-service value > [mj] Earlier in the review, you'd questioned the addition of recommendati= ons on the usage of the experimental namespace. Why did you change your mind? > =A0 =A0Instead of resorting to the constraining iana-registrered Appicati= on > =A0Service tag, > =A0 =A0vendors/SDOs may rather rely on the experimental-service value as > =A0authorized by > =A0 =A0the format of Application service field. > > =A0 =A0In such a case, this specification recommends the following format= for > =A0the "app-service" field: > > =A0 =A0 =A0 =A0experimental-service =3D "x-aaa+ap" appln-id > =A0 =A0 =A0 =A0appln-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D *DIGIT > > =A0 =A0 =A0 =A0Expressed as a decimal integer, the "appln-id" is used her= e to > =A0identify > =A0 =A0 =A0 =A0a vendor-specific application identifier as assigned by IA= NA. > > =A0 =A0As stated in [RFC3958], application service tags that start with "= x-" > =A0 =A0are considered experimental, and no provision is made to prevent > =A0 =A0duplicate use of the same string. =A0Implementors use them at thei= r own > =A0 =A0risk. It is therefore the responsability of each vendor/SDO to def= ine > =A0the exact > =A0 =A0values of S-NAPTR Application Service Tags associated with vendor- > =A0specific > =A0 =A0Diameter applications. > > =A0 =A0For example, a NAPTR service field value of: > > =A0 =A0 =A0 =A0'aaa+ap16777251:diameter.sctp' > > =A0 =A0would mean that the Diameter node in the SRV or A/AAAA record supp= orts > =A0 =A0the 3GPP-specific Diameter S6a Application ('16777251') and SCTP a= s the > =A0 =A0transport protocol. > > =A0 =A0The use of this experimental-service value is strongly discouraged= when > =A0 =A0considering standard-track applications, as standard values are > =A0assigned > =A0 =A0by IANA. > > =A0- end - > > -- > ----------------------------------------------+--------------------------= --- > =A0Reporter: =A0lionel.morand@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 =A0 Owner: =A0lionel.morand@=85 > =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | =A0 =A0 =A0Status: =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | =A0 Milestone: > Component: =A0extended-naptr =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0= =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0Keywords: > ----------------------------------------------+--------------------------= --- > > Ticket URL: > dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >