From dime-bounces@ietf.org Sat Nov 1 12:08:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ABD3A6880; Sat, 1 Nov 2008 12:08:16 -0700 (PDT) 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 5B6093A6869 for ; Sat, 1 Nov 2008 12:08:15 -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 j++S4sRn4BPp for ; Sat, 1 Nov 2008 12:08:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8C8D63A66B4 for ; Sat, 1 Nov 2008 12:08:14 -0700 (PDT) Received: (qmail invoked by alias); 01 Nov 2008 19:01:31 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp037) with SMTP; 01 Nov 2008 20:01:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fMhtfJrHf5ni2YxEqjldylWZJN6bPsNcToRnS3Z hIFu1A2MJ9C2xN From: "Hannes Tschofenig" To: "'ext Romascanu, Dan \(Dan\)'" , References: Date: Sat, 1 Nov 2008 21:01:32 +0200 Message-ID: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: aaa-doctors@ietf.org Subject: Re: [Dime] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dan, Thanks for your very detailed review! >Hi, > >This is the AD review of dime-qos-parameters-06.txt. I believe >that the document needs more work before it can be sent to >IETF Last Call. I am placing it in Revised ID Needed. > >1. Although it is the work of the DIME Working Group, the >document includes in its scope according to the Introduction >section the >definition of parameters that can be reused for conveying QoS >information within RADIUS and Diameter. I believe that there >is a need to add text that shows how specifically these >parameters will be used in each of the two protocols. The description can be found in documents using this specification. For Diameter a description can be found in http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/ > Is there >a need for any supplementary documents to describe protocol >specific mapping and IANA allocations? I guess you refer to the IANA consideration section and the ability to specify new parameters. Right? > >2. Was the document reviewed by the RADIUS WG? We have sent the WGLC announcements to DIME, RADEXT, NSIS, and TSVWG (and to other SDOs). > >3. This document will trigger again the issue of exceeding the >AAA scope of DIAMETER as described by RFC 3588, raised in a >number of previous occasions, last by Brian Carpenter in his >GenART review for draft-sun-dime-itu-t-rw. I suggest to put >text in the Introduction section mentioning the issue of scope >and referring to rfc3588bis as an Informational Reference. No, this document doesn't. When used as described in http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/ then it is totally in line with the scope of Diameter. However, when used in http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt then there are again the same issues as previously raised already. > >4. There are several places in the document where the authors >seem to write requirements about the behavior and mode of >provisioning of a QoS enabled network. I do not think that an >AAA parameters document is a good place for such requirements. >I would strongly prefer that the document focuses on >describing the QoS parameters carried by AAA protocols, and if >examples of usage are left, they be marked clearly as examples. This was indeed not the intention. I will search through the document to fix these Cases. > >5. Section 3.2 - Path PLR and Path PER are defined on packet >basis, so the claim that they describe the desired bit error >rate seems odd. Fixed. > >6. Same -'where the PLR is defined to be the PLR added by each >such node' and 'the PER is defined to be the PER added by each >such node' >seem to be broken as definitions - maybe that was intended to >be define is 'the Path PLR' and 'the Path PER' respectively. Fixed. > >7. Section 3.3 - See comment #4 - certainly RFC 2119 keywords >usage seems unjustified here. Fixed. > >8. Section 4.1 and following - it would be good to mention >that Length all over this document is expressed in 32-bit words. > Fixed. >9. It is not clear why there is a need to defined both TMOD-1 >and TMOD-2. I suggest to add an explanation. > >10. Section 4.2 - I suggest to add a normative reference to >IEEE 754 when referring the first time to single-precision >IEEE floating point format. It's a good moment, as the IEEE >standard was updated in June 2008, after more than two decades >of usage of the precedent version (but this does not affect >the way it is used here as far as I can tell) Do you have a reference to the new standard? > >11. The first phrase in 4.3 should appear also in 4.2 as the >two TMOD parameters have similar semantics. > >12. Section 4.5 - there is no reference for the semantic of >the Path Jitter parameter value - probably section 3.4 in RFC2215 > >13. I do not understand what is the reason to include Path >Jitter STAT4 (Reserved). The format was copied from NSIS specifications. I will ask on the NSIS mailing list for reasons why these parameters got included. > >14. Section 4.6 - I do not believe that a AAA document should >include statements like 'The total PLR added across all QoS >aware nodes can range as high as 10^-1.' Fixed. > >15. Section 4.7 - in the first phrase s/PLR/PER/ > Fixed. >16. Section 4.7 - I do not believe that a AAA document should >include statements like 'The total PER added across all QoS >aware nodes can range as high as 10^-1.' Fixed. > >17. Section 4.8 - I see no reason to refer here to [RFC2212] RFC 2212 defines the slack term. > >18. Section 4.8 - s/Path PLR/Slack Term/ Fixed. > >19. Section 4.11 - I am not sure that quoting RFC4412 as a >reference for the semantic of the parameter value is fully >accurate. It may be good at most to say that what is referred >here is the resource-priority policy element RFC 4412 creates the registry this document refers to. [I-D.ietf-tsvwg-emergency-rsvp] converts the values in that registry from a textual representation (in the form of, for example, 'dsn.flash') to numerical values. We had a long discussion between NSIS and TSVWG on who should create that registry. I did not have an opinion about that issue. > >20. Section 4.11 - This I-D defines similarly ALRP parameter >as draft-ietf-tswg-emergency-rsvp and the two documents quote >each other with the apparent intent to keep the definitions in >sync. However draft-ietf-tswg-emergency-rsvp defines a policy >object which is a list of ALRPs, while here there is only one >instance. Why the difference? We only reference the registry. When one wants to convey multiple values within RADIUS or Diameter for an authorization request (as an example) then two separate objects have to be used. > >21. Section 4.11 - if the intent is to keep the definitions >here and in draft-ietf-tswg-emergency-rsvp as close as >possible what are the ALRP Priority and Reserved octets >positions inversed in the two definitions? When we wrote our document that was the format used in the NSIS documents. At that time we referenced the NSIS documents and only later the format was changed. It seems that we have to align it now as well. > >22. Section 4.12 should have a reference to the IANA registry >required to be defined for this parameter in Section 6.3. Fixed. > >23. Section 4.12 - what is 'the QoS Desired' object defined here? > >24. Section 4.12 includes text about the behavior of the >network that looks mis-placed in an AAA document. Your feedback about Section 4.12 is good. Based on what you said I wonder whether it wouldn't have been cleaner to put the functionality of the Excess Treatment Parameter into the QoS attribute draft instead. I will need to check this with the group. > >25. Section 4.13 could use a reorganization of the >description. The 16-bits in the payload have different >structure according to the PHB class type - they would better >get one generic name and specific descriptions for the three >cases covered by the object. I re-organized the section to make it more readable. > >26. Section 4.14 - the semantic described in this section is >not identical with the one in RFC 4124 which is provided as >reference. 4124 says 0 is a reserved value - what semantics >does it have here? It is also not clear why this parameter was >defined to have an 8-bit representation I will have to check with the NSIS group on this issue as the parameter encoding is taken from there. > >27. Section 4.15 - I strongly advice against presenting the >usages of the QoS Class parameters here especially in such >firm terms as here. >Actually ITU-T Y.1541 Tables 2 and 3 make clear that these >class usages are only guidance (classes 1 to 5) and >provisional (classes 6,7). This is completely lost here. I >would prefer to just provide a pointer to the ITU-T document >and take out all the classes descriptions, or move them in an >Appendix, with all necessary description of their guidance and >provisional status. Sounds good to me. > >28. Section 5 should provide a reference to the IANA registry >for Enterprise Numbers Done. > >29. Section 6.4 - It is not clear why there is a need to >create a registry for DSTE Class Type Parameters. If IETF WGs >or individuals writing RFCs and running them through the IETF >process will be allowed to add or modify values by Standards >Actions, this would modify the semantics defined in Section >4.14, which does not include any mention of extensibility for >these parameters. You are entirely correct. > >30. Section 6.5 - It is not clear why there is a need to >create a registry for Y.1541 Class Parameters. Who would take >the responsibility of running the Standard Action to modify or >add Object class values? In what conditions? When Y.1541 >changes? In any case, this would modify the semantics defined >in Section 4.14, which does not include any mention of >extensibility for these parameters. Correct as well. > >31. Section 7 - I disagree that this document does not raise >any security concerns. Actually the modification or >mis-configuration of the QoS parameters carries security >threats similar with the configuration operations that would >be performed for example in case the objects would be >configured by using a protocol like SNMP. QoS degradation may >lead to degradation of service that can make access to the >network resources difficult or impossible, or running >real-time applications impossible. >We need text that explains what are the sensitive parameters, >and the recommended operational and deployment measures to >protect against security threats. We were planning to have that text in the QoS attribute draft rather than in this draft. > >32. The description of the [Y.1541] and [Y/1571] references >are incomplete. I messed it up in the XML2RFC description of the reference. Ciao Hannes > >Thanks and Regards, > >Dan > > > >_______________________________________________ >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 From dime-bounces@ietf.org Sat Nov 1 12:11:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46103A66B4; Sat, 1 Nov 2008 12:11:07 -0700 (PDT) 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 989FC3A66B4 for ; Sat, 1 Nov 2008 12:11:06 -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=[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 pnSObvzkFNsk for ; Sat, 1 Nov 2008 12:11:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5C74B3A635F for ; Sat, 1 Nov 2008 12:11:04 -0700 (PDT) Received: (qmail invoked by alias); 01 Nov 2008 19:11:02 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp015) with SMTP; 01 Nov 2008 20:11:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19T6y003ZhTf23vj1q50WtzLFPuhmtbg3xGY2CUe2 7K3swFo5b5zvYS From: "Hannes Tschofenig" To: "'Jan Engelhardt'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: Date: Sat, 1 Nov 2008 21:11:03 +0200 Message-ID: <00fe01c93c55$960ed150$04ffa8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack76TgELTWhKhwNQwSX3g6PKI+UZgAbBowg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jan, The terminology is a bit challenging, I know. We cannot change the term "Mandatory AVP" anymore since everyone is pretty much used to it already. For the required AVP we still have the chance to pick whatever we want but it is important to have a different name for the two as they are very different concepts. So, what name would you suggest instead of "Required AVP"? Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Jan Engelhardt >Sent: 01 November, 2008 06:23 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: dime@ietf.org >Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt > > >>I should have been more precise: "... MUST parse and understand the >>semantic of the AVP including its content". > >I would not call it Mandatory AVP then, because mandatory is >close to required, if you look that up in a thesaurus, but >required-to-be-present is different from required-to-be-understood. >_______________________________________________ >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 From dime-bounces@ietf.org Sun Nov 2 01:43:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB6F3A6998; Sun, 2 Nov 2008 01:43:57 -0700 (PDT) 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 262673A6781; Sun, 2 Nov 2008 01:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 KMIR7BufmC+f; Sun, 2 Nov 2008 01:43:55 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 11A633A6998; Sun, 2 Nov 2008 01:43:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,529,1220241600"; d="scan'208";a="140656154" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 02 Nov 2008 03:43:52 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Nov 2008 03:43:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Nov 2008 09:43:49 +0100 Message-ID: In-Reply-To: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvA= References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> From: "Romascanu, Dan (Dan)" To: "Hannes Tschofenig" , Cc: aaa-doctors@ietf.org Subject: Re: [Dime] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > -----Original Message----- > >10. Section 4.2 - I suggest to add a normative reference to >IEEE 754 when referring the first time to single-precision >IEEE floating point format. It's a good moment, as the IEEE >standard was updated in June 2008, after more than two decades >of usage of the precedent version (but this does not affect >the way it is used here as far as I can tell) Do you have a reference to the new standard? http://grouper.ieee.org/groups/754/ Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 2 03:16:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECA53A68A8; Sun, 2 Nov 2008 03:16:36 -0800 (PST) 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 21F503A6846 for ; Sun, 2 Nov 2008 03:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 3lGwsJHPyZP8 for ; Sun, 2 Nov 2008 03:16:34 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B2AA628C101 for ; Sun, 2 Nov 2008 03:16:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,529,1220241600"; d="scan'208";a="149613982" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 02 Nov 2008 06:15:41 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Nov 2008 06:15:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Nov 2008 12:15:39 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] diameter-api draft comparison Thread-Index: Ack76UIw/nj73UrmQM++sAu9A/fnkQA8fZqQ References: From: "Romascanu, Dan (Dan)" To: "Jan Engelhardt" , Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jan, I cannot find any comment from you on the list concerning draft-ietf-dime-diameter-api neither during the month of July or during the IETF Last Call. If I missed something please point me to your messages. It certainly does not suffices to just say 'I am in disagreement' - you need to provide detailed comments and arguments about what aspects (technical or editorial) you find as problematic. Please try to do so as soon as possible, as this document is planned to be submitted for review and approval to the IESG after the publication of the I-D revision following the IETF Last Call. Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Jan Engelhardt > Sent: Saturday, November 01, 2008 6:23 AM > To: dave@frascone.com > Cc: dime@ietf.org > Subject: [Dime] diameter-api draft comparison > > > I have monitored this list before but I did not quite see a > reason for taking part until I finished our implementation of > Diameter and WebAuth. > > I see that my earlier disagreement mail about > draft-ietf-dime-diameter-api-06 from July has not been > forwarded here; but it probably suffices to say that I am at > a disagreement with that draft, both from a technical > standpoint, and not less from a cosmetical one. While > camelcase is something one can debate infinitely, I have to > condemn the silly use of typedefs and long names. Some > specified functions like AAAValueFromAVPCode do not make any > sense at all. > > Our API, which actually goes in line with an actual > implementation around it, is described in its Developers > Guide; a web copy is at > http://circum.sf.net/circum_devguide.pdf . I especially > encourage the draft's authors to compare. > _______________________________________________ > 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 From dime-bounces@ietf.org Sun Nov 2 05:54:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F8A3A6933; Sun, 2 Nov 2008 05:54:11 -0800 (PST) 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 3A3DE3A6933 for ; Sun, 2 Nov 2008 05:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 7OmLg5HDIH2B for ; Sun, 2 Nov 2008 05:54:06 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 46B703A6927 for ; Sun, 2 Nov 2008 05:54:06 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mA2Ds08x033895; Sun, 2 Nov 2008 08:54:00 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <490DB0F7.7050308@tari.toshiba.com> Date: Sun, 02 Nov 2008 08:53:59 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Hannes Tschofenig References: <48C92258.6050008@gmx.net> In-Reply-To: <48C92258.6050008@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)] 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, I've incorporated majority of the editorial items you mentioned below. Others I've commented below. The changes here should be incorporated into draft*-13.txt > s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and > > SCTP [RFC2960] transport protocols./The base Diameter protocol is run on > port > > 3868 of both TCP [RFC793] and SCTP [RFC2960]. > > Delete "Future versions of this specification MAY > mandate that clients support SCTP." > > I also do not understand why we require that agents and servers must > support > > SCTP. That does not sound realistic if I consider our interop testing > > experience. > It seems expected that during the interop most folks would support TCP since that would be the easiest/most natural to implement first. I could not remember if there was consensus for requiring SCTP for servers was impractical. I would think that at this point (a few years after the interop) SCTP support would be generally supported (??) by most diameter implementations. I'm ok with relaxing the rule if folks think that required support for SCTP is really cumbersome. AFAIK, supporting SCTP should be readily available on most stacks and socket APIs. > 2.8.1. Relay Agents > > s/ > Relays MAY be used to aggregate requests from multiple Network Access > Servers (NASes) within a common geographical area (POP). > / > Relays may, for example, be used to aggregate requests from multiple > > Network Access Servers (NASes) within a common geographical area (POP). > > > I think we can delete this sentence since it essentially reflects the > which sentence ? > definition of a relay: > > Relays SHOULD NOT maintain session state but MUST maintain > transaction state. > If you meant the example, then it maybe better to keep it to have a clear re-enforcement of the relay definition; i.e. giving examples is helpful. > > > > Proxies that wish to limit resources MUST maintain session state. > All proxies MUST maintain transaction state. > > I don't really understand what the first sentence should tell us and the > 2nd > > one is essentially already described with the definition of the proxy. > Agree. I've removed it. > Some AVPs MAY be listed more than once. The effect of such an AVP is > specific, and is specified in each case by the AVP description. > > > There is something wrong with this sentence. > Agree. Not sure what exactly its trying to say but its implying something really vague ... better remove it. > 4.3. Derived AVP Data Formats > > In addition to using the Basic AVP Data Formats, applications may > define data formats derived from the Basic AVP Data Formats. An > application that defines new AVP Derived Data Formats MUST include > them in a section entitled "AVP Derived Data Formats", using the same > format as the definitions below. Each new definition MUST be either > defined or listed with a reference to the RFC that defines the > format. > > > This is sort of interesting, particularly when you look at the > IPFilterRule, > > as the boundary between Derived AVP Data Formats and AVP definitions is > sort > > of fuzzy. > > Does any other Diameter document ever tried to define new derived Data > > Formats? > Not sure. Low probability that other docs would have a derived Data format section. > 4.4. Grouped AVP Values > > However, the encapsulated AVPs with 'M' (mandatory) bit set MUST > belong to the Diameter application the Grouped APV is used in. > > I don't quite understand that sentence. Could you explain it a bit? > This was Lionels description. If I'm translating correctly I think it meant that inner AVPs with M-bit set must be defined or at the least known by the Diameter application using the grouped avp. Does this mean the app has the possibility of not recognizing the parent AVP but it has knowledge about the children AVPs ? Would it be better to just make this 'M' bit check relevant to the root Grouped-AVP ? > 3. If no NAPTR records are found, the requester queries for those > address records for the destination address, > '_diameter._sctp'.realm or '_diameter._tcp'.realm. > > Why is it necessary to specify two mechanisms to query the DNS? > > I will distribute a separate mail about the domain certificate stuff. > Ok. > > > 5.3.5. Host-IP-Address AVP > > > The Host-IP-Address AVP (AVP Code 257) is of type Address and is used > to inform a Diameter peer of the sender's IP address. All source > addresses that a Diameter node expects to use with SCTP [RFC2960] > MUST be advertised in the CER and CEA messages by including a > Host-IP- Address AVP for each address. This AVP MUST ONLY be used in > the CER and CEA messages. > > s/Host-IP- Address/Host-IP-Address > > I wonder why there is the last sentence in there? It is fine to use the AVP > > in the CER and CEA message but why is there a need to say that it must only > > be used there? That does not make a lot of sense. > good point. it should be removed. > 5.3.6. Supported-Vendor-Id AVP > > Multiple instances of this AVP containing the same value SHOULD NOT > be sent. > > Why not MUST NOT be sent? > agree as well. it should be MUST NOT. > > I was also wondering why only a selection of AVPs is listed in Section 5.3 > > instead of all of them? Any special reason? > I think all of the AVPs in 5.3 maybe represented/listed but just spread throughtout the document. > > > 5.5.4. Failover and Failback Procedures > > Shouldn't it actually read "Fallback" instead of failback? > > > AFAIK, I think it the term for service restoration has always been failback. > 6.1.2. Sending a Request > > When sending a request, originated either locally, or as the result > of a forwarding or routing operation, the following procedures MUST > be followed: > > o the Hop-by-Hop Identifier should be set to a locally unique value. > > s/should/SHOULD > > o The message should be saved in the list of pending requests. > > s/should/SHOULD > > > Given that the introductory sentence says "MUST be followed" I was > wondering > > whether SHOULD is actually too weak here. > Then I think the introductory sentence should be set to SHOULD instead of MUST because these recommendations have obvious "preference " constraints from the implementor; i.e. implementations my choose not to store all pending request because of storage constraints. > 6.7.2. Proxy-Info AVP > > > The description for the AVP does not describe the semantic. > Ok. How about modifying the 1st paragraph to: "The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP contains the identity and local state information of Diameter node that creates and adds it to a message. The Grouped Data field has the following ABNF grammar:" > 6.7.4. Proxy-State AVP > > s/ > > The Proxy-State AVP (AVP Code 33) is of type OctetString, and > contains state local information, and MUST be treated as opaque data. > > / > > The Proxy-State AVP (AVP Code 33) is of type OctetString, and > is created by the Diameter server and passed on to the Diameter > client. It contains state information that would otherwise be stored at > the Diameter. > As such, this AVP MUST be treated as opaque data by entities other > than the Diameter server that created it. > Proxy-State AVP can be created and inserted by proxies as well (not only servers). So we should rephrase the 1st sentence of your suggestion to: "The Proxy-State AVP (AVP Code 33) is of type OctetString. It contains state information that would otherwise be stored at the Diameter entity that created it. As such, this AVP MUST be treated as opaque data by entities other Diameter entities." > 6.8. Auth-Application-Id AVP > > The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and > is used in order to advertise support of the Authentication and > Authorization portion of an application (see Section 2.4). If > present in a message other than CER and CEA, the value of the Auth- > Application-Id AVP MUST match the Application Id present in the > Diameter message header. > > If it always matches then does it make a lot of sense? > Yes. This has a lot of history at the interop since there's confusion on what these Id's really represent or what its purpose was given that there's already and id in the header. Since there is no specified concept of a command carrying multiple apps ids we decided to make it the same as the header if it is present (for compatibility purposes). > This AVP MUST also be present as the first AVP in all experimental > commands defined in the vendor-specific application. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > > "This" in the above two sentences refers to the > Vendor-Specific-Application-Id AVP. Right? > Yes. I've cleaned them up. > If a Vendor-Specific-Application-Id is received that contains both > Auth-Application-Id and Acct-Application-Id, then the recipient > SHOULD issue an answer with Result-Code set to > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer SHOULD also include a > Failed-AVP which MUST contain the received Auth-Application-Id AVP > and Acct-Application-Id AVP. > > Why are these only SHOULD level requirements? What happens in the other > cases? > Yes your right. > > 6.14. Redirect-Max-Cache-Time AVP > > > > > This AVP contains the maximum number of seconds the peer and route > table entries, created as a result of the Redirect-Host, will be > cached. Note that once a host created due to a redirect indication > is no longer reachable, any associated peer and routing table entries > MUST be deleted. > > > "will be cached" does not provide a good indication how the value provided > by this AVP should actually be treated. Is this > * MUST be cached > * SHOULD cached > * MAY be cached > Agree. Let's set it to SHOULD be cached ... implementations can have room for other techniques. > I think that the semantic is a bit weak. What can the sender really expect > when it provides a value with AVP to the receiver? > In this case, the sender does not have any expectation of what the receiver eventually decides to do since it is only a passive entity (i.e. it never carries state). The redirect agent is similar to a "sign post", it provides information but the receiver eventually has to decide how to route the message. > Diameter may also be used for services that cannot be easily > categorized as authentication, authorization or accounting (e.g., > certain 3GPP IMS interfaces). In such cases, the finite state > machine defined in subsequent sections may not be applicable. > Therefore, the applications itself MAY need to define its own finite > state machine. However, such application specific state machines > MUST comply with general Diameter user session requirements such co- > relating all message exchanges via Session-Id AVP. > > What specifically is meant by saying that such applications must comply > with the > general Diameter user session requirements? > Hmm... I think that should be re-phrased to: "However, such application specific state machines SHOULD follow the general state machine framework outlined in this document such as the use of Session-Id AVPs and the us of STR/STA, ASR/ASA messages for stateful sessions." > 8.6. Inferring Session Termination from Origin-State-Id > > this section is a bit confusing as it talks about CER/CEA and the > hop-by-hop processing > but then refers to end-to-end processing as well. > I've re-factored the section to: "The Origin-State-Id is used to allow detection of terminated sessions for which no STR would have been issued, due to unanticipated shutdown of an access device. A Diameter client or access device increments the value of the Origin-State-Id every time it is started or powered-up. The new Origin-State-Id is then sent in the CER/CEA message immediately upon connection to the server. The Diameter server receiving the new Origin-State-Id can determine whether the sending Diameter client had abrubtly shutdown by comparing the old value of the Origin-State-Id it has kept for that specific client is less than the new value and whether it has un-terminated sessions originating from that client. An access device can also include the Origin-State-Id in request messages other than CER if there are relays or proxies in between the access device and the server. In this case, however, the server cannot discover that the access device has been restarted unless and until it receives a new request from it. Therefore this mechanism is more opportunistic across proxies and relays. The Diameter server may assume that all sessions that were active prior to detection of a client restart have been terminated. The Diameter server MAY clean up all session state associated with such lost sessions, and MAY also issues STRs for all such lost sessions that were authorized on upstream servers, to allow session state to be cleaned up globally." > > > 8.7. Auth-Request-Type AVP > > The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is > included in application-specific auth requests to inform the peers > whether a user is to be authenticated only, authorized only or both. > Note any value other than both MAY cause RADIUS interoperability > issues. > > What are the RADIUS interoperability issues? > > ... have to investigate > > 8.9. Authorization-Lifetime AVP > > > This is typically used in cases where multiple > authentication methods are used, and a successful auth response with > this AVP set to zero is used to signal that the next authentication > method is to be immediately initiated. > > Where is this used? > The description is really bad. I'm guessing the original intent is when you have multiple EAPs for a single auth session. I think this text is just confusing. Multiple auth's are built into the diameter app exchanges so the generic base protocol fsm should not concern itself with such details. We should just remove that text. > > This AVP MAY be provided by the client as a hint of the maximum > lifetime that it is willing to accept. However, the server MAY > return a value that is equal to, or smaller, than the one provided by > the client. > > > There are many MAYs in there. Does it mean that a value that is larger > can also be provided by the server? > If not, then shouldn't the second sentence say MUST? > Yes your right. the second sentence should say MUST otherwise the negotiation does not make sense. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 2 08:16:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB68E3A6AD6; Sun, 2 Nov 2008 08:16:30 -0800 (PST) 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 8BEBC3A6AFC for ; Sun, 2 Nov 2008 08:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 gFSLnoFvRa8v for ; Sun, 2 Nov 2008 08:16:28 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 1194A3A6816 for ; Sun, 2 Nov 2008 08:15:35 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mA2GFUSg036385; Sun, 2 Nov 2008 11:15:30 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <490DD222.6080505@tari.toshiba.com> Date: Sun, 02 Nov 2008 11:15:30 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Hannes Tschofenig References: <48CD625D.1000605@gmx.net> In-Reply-To: <48CD625D.1000605@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis review (2/3) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes As with the 1st part of the review, editorial are ok. Other comments inline. Changes are incorporated in draft-*13.txt: > Here is the 2nd part of my review: > > 9.2. Protocol Messages > > A Diameter node that receives a successful authentication and/or > authorization messages from the Home AAA server MUST collect > accounting information for the session. > > s/Home AAA server/Diameter server > > I wonder why there is this MUST statement here. Why is there MUST > regarding the > collection of accounting information. > I'm guessing this is historical remnants that is no longer valid in the way we use Diameter today. We should relax this to a SHOULD. > > > Each Diameter Accounting protocol message MAY be compressed, in order > to reduce network bandwidth usage. If TLS is used to secure the > Diameter session, then TLS compression [RFC4346] MAY be used. > > I wonder why this compression aspect is mentioned as there is nothing in > Diameter itself > to provide this compression. Compression is provided by TLS for all > Diameter > messages. > Ok. I suggest we remove it as it does not add value in anyway. > > 9.3. Accounting Application Extension and Requirements > > Each Diameter application (e.g., NASREQ, MobileIP), MUST define their > Service-Specific AVPs that MUST be present in the Accounting-Request > message in a section entitled "Accounting AVPs". > > I wonder why this is a MUST requirement. > Probably the same reason as above. Lets relax to a SHOULD. > > > 9.6. Correlation of Accounting Records > > The Diameter protocol's Session-Id AVP, which is globally unique (see > Section 8.8), is used during the authorization phase to identify a > particular session. > > > Services that do not require any authorization > still use the Session-Id AVP to identify sessions. > > > Why is the authorization exchange mentioned here explicitly. Session-IDs > are used > throught Diameter and there is nothing specifial about the authorization > phase. > Same as above. It seems like 9.6 is binding accounting specifically to authz only. We should re-phrase the 1st paragraph to: "If an application uses accounting messages, it can correlate accounting records with a specific application session by using the Session-Id of the particular application session in the accounting messages. Accounting messages MAY also use a different Session-Id from that of the application sessions in which case other session related information is needed to perform correlation." > > > Accounting > messages MAY use a different Session-Id from that sent in > authorization messages. Specific applications MAY require different > a Session-ID for accounting messages. > > These two sentences essentially say the same thing. Maybe it would be > useful to say > when the session ID is different. > See above. > > > However, there are certain applications that require multiple > accounting sub-sessions. Such applications would send messages with > a constant Session-Id AVP, but a different Accounting-Sub-Session-Id > AVP. In these cases, correlation is performed using the Session-Id. > > The last sentence essentially says what the sentence said previously. > > It is important to note that receiving a STOP_RECORD with no > Accounting-Sub-Session-Id AVP when sub-sessions were originally used > in the START_RECORD messages implies that all sub-sessions are > terminated. > Let's re-phrase this entire paragraph with: "In cases where an application requires multiple accounting sub-session, an Accounting-Sub-Session-Id AVP is used to differentiate each sub-session. The Session-Id would remain constant for all sub-sessions and is be used to correlate all sub-sessions to a particular application session. Note that receiving a STOP_RECORD with no Accounting-Sub-Session-Id AVP when sub-sessions were originally used in the START_RECORD messages implies that all sub-sessions are terminated." > Furthermore, there are certain applications where a user receives > service from different access devices (e.g., Mobile IPv4), each with > their own unique Session-Id. > > I am not sure is meant with the Mobile IPv4 example here. > Is this referring to the case that a user might, as part of their > service usage, > trigger multiple Diameter exchanges from different Diameter clients, > such as from > the NAS and also from an application server? > > In such cases, the Acct-Multi-Session- > Id AVP is used for correlation. > > I would move this sentence after the subsequent paragraph. > > During authorization, a server that > determines that a request is for an existing session SHOULD include > the Acct-Multi-Session-Id AVP, which the access device MUST include > in all subsequent accounting messages. > How about re-phrasing the whole paragraph to: "There are also cases where an application needs to correlate multiple application sessions into a single accounting record; the accounting record may span multiple different Diameter applications and sessions used by the same user at a given time. In such cases, the Acct-Multi-Session- Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD be signalled by the server to the access device (typically during authorization) when it determines that a request belongs to an existing session. The access device MUST then include the Acct-Multi-Session-Id AVP in all subsequent accounting messages." > > > 10.1. Base Protocol Command AVP Table > > > There are a couple of AVPs in the table that do not appear in any command. > I wonder whether it makes sense to actually list them in the table at all. > Instead, one could argue that they are rather defined in this document > since > they are of general usage for applications. > > I'm not sure how we can represent these dangling AVPs. Maybe a separate list for them ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 2 09:30:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B507B3A67D0; Sun, 2 Nov 2008 09:30:02 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E72473A67D0; Sun, 2 Nov 2008 09:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081102173001.E72473A67D0@core3.amsl.com> Date: Sun, 2 Nov 2008 09:30:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-13.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-13.txt Pages : 160 Date : 2008-11-02 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-13.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-rfc3588bis-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-02092306.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Sun Nov 2 10:34:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E343A68B4; Sun, 2 Nov 2008 10:34:10 -0800 (PST) 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 B0E0E3A6842 for ; Sun, 2 Nov 2008 10:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_93=0.6] 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 yxEIZCB3HSWR for ; Sun, 2 Nov 2008 10:34:07 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 5BF693A67F7 for ; Sun, 2 Nov 2008 10:34:07 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 94952188501F4; Sun, 2 Nov 2008 19:34:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 8A4681C0788BD; Sun, 2 Nov 2008 19:34:01 +0100 (CET) Date: Sun, 2 Nov 2008 19:34:01 +0100 (CET) From: Jan Engelhardt To: "Romascanu, Dan (Dan)" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Ck9uIFN1bmRheSAyMDA4LTExLTAyIDEyOjE1LCBSb21hc2NhbnUsIERhbiAoRGFuKSB3cm90ZToK Cj5JdCBjZXJ0YWlubHkgZG9lcyBub3Qgc3VmZmljZXMgdG8ganVzdCBzYXkgJ0kgYW0gaW4gZGlz YWdyZWVtZW50JyAtIHlvdSAKPm5lZWQgdG8gcHJvdmlkZSBkZXRhaWxlZCBjb21tZW50cyBhbmQg YXJndW1lbnRzIGFib3V0IHdoYXQgYXNwZWN0cyAKPih0ZWNobmljYWwgb3IgZWRpdG9yaWFsKSB5 b3UgZmluZCBhcyBwcm9ibGVtYXRpYy4KCkZvbGxvd2luZyBpcyBxdW90aW5nIHRoZSBhcGktMDcg dGV4dCBkb2N1bWVudC4KCj5UaGUgY2FsbGJhY2tzIGltcGxlbWVudCB0aGUgYXBwbGljYXRpb24g cHJvZmlsZSBwcm9jZXNzaW5nIGZvcgo+aW5jb21pbmcgbWVzc2FnZXMuICBGb3Igb3V0Z29pbmcg Y2FsbHMsIHRoZSBDIEFQSSBwcm92aWRlcyBhbgo+YXN5bmNocm9ub3VzIG1vZGVsLCBsZWF2aW5n IHByb2Nlc3Npbmcgb2YgdGhlIHJldHVybiBtZXNzYWdlIHRvIHRoZQo+Y2FsbGJhY2tzLgoKVGhp cyBkZWNpc2lvbiBoYXMgKnJlYWxseSogcHV6emxlZCBtZS4gSXQgc2VlbXMgbGlrZSB5b3UgYXJl IHRyeWluZwp0byBwdXQgaW4gc2VydmVyLXNwZWNpZmljIHN0dWZmIGludG8gdGhlIGJhc2UgbGli cmFyeSwgYW5kIHRoaXMKYXR0ZW1wdCBsb29rZWQgd3JvbmcgdG8gbWUuIFdlbGwgYWZ0ZXIgcmVy ZWFkaW5nLCBhc3luY2hyb25vdXMKcHJvY2Vzc2luZyBzZWVtcyB0byBoYXZlIGEgcGxhY2UuIEJ1 dCBJIHN0aWxsIHRoaW5rIGl0IGlzIG5vdCB0aGF0CmFwcHJvcHJpYXRlLgoKMS4gWW91IGhhdmUg dG8gY3JlYXRlIGEgZnVuY3Rpb24gZm9yIGV2ZXJ5IGNvbW1hbmQgeW91IGFyZSBpbnRlcmVzdGVk CmluLgoKMi4gRm9yIGEgc2VydmVyLCBhc3luY2hyb25vdXMtaXR5IG1heSBtYWtlIHNlbnNlLCBi dXQgZm9yIGNsaWVudHMsCnRoaXMgaXMgbGVzcyBvZiBhIGNhc2UuIFRoZSBmYWN0IHRoYXQgb3Vy IGNvdXJzZSdzIGltcGxlbWVudGF0aW9uCmZhcmVzIHBlcmZlY3RseSB3ZWxsIHdpdGggc3luY2hy b25vdXMgZXhjaGFuZ2UuIEVzcGVjaWFsbHkgc2luY2UgSQpkbyBub3Qgc2VlIHdoYXQgYSBjbGll bnQgaXMgc3VwcG9zZWQgdG8gYXN5bmNocm9ub3VzbHkgZG8gYWZ0ZXIKaGF2aW5nIHNlbnQgYSBw YWNrZXQgYW5kIHdhaXRpbmcgZm9yIGEgcmVwbHkuCgozLiBDYWxsYmFja3MgYXMgdXNlZCBpbiB0 aGUgZHJhZnQga2lsbCBhbnkgInRocmVhZCBzYWZldHkgdmFyaWV0eSIuCkNvbnNpZGVyOgoKCWJh cigpIHsKCQl1bnJlZ2lzdGVyX2NiKGNvbW1hbmQ9Zm9vKQoJCWRvX3NvbWV0aGluZy4uCgl9CgoJ Lyogc2VlIHRvIGl0IHRoYXQgd2UgZ2V0IG5vdGlmaWVkIG9mIGZvbyAqLwoJcmVnaXN0ZXJfY2Io Y29tbWFuZD1mb28sIHB0cj1iYXIpOwoJc2VuZF9wYWNrZXQoKTsKCgkKVGhlIG1vbWVudCB5b3Ug cmVnaXN0ZXIgYSBDQiBtZWFucyB0aGF0IHRoZSBDQiB3aWxsIGdldCB0cmlnZ2VyZWQKd2hlbmV2 ZXIgYSBwYWNrZXQgaGFwcGVucyB0byBjb21lIGluLiBUaGlzIGlzIGJhZCB3aGVuIHlvdSBvbmx5 CndhbnQgdG8gcHJvY2VzcyBhICJmb28iIGZvciBleGFjdGx5IG9uZSBzcGVjaWZpYyBwYWNrZXQu CihOb3RpbmcgdGhhdCB0aGUgYWJvdmUgcHNldWRvY29kZSBzbmlwcGV0IGlzIHRvdGFsbHkgTVQt cmFjZSB1bnNhZmUuKQoKPkZvciB0aGUgbW9zdCBwYXJ0LCB0aGUgQVBJIGhpZGVzIHRoZSBkZXRh aWxzIG9mIGVzdGFibGlzaGluZyBwZWVyaW5nCj5hbmQgcmVkaXJlY3QgY29ubmVjdGlvbnMsIHBh cnNpbmcgYW5kIGNyZWF0aW5nIERpYW1ldGVyIG1lc3NhZ2VzLAo+YW5kIG90aGVyIHdvcmsgbmVj ZXNzYXJ5IHRvIHNldCB1cCBhbmQgbWFpbnRhaW4gYSByZWRpcmVjdCBvcgo+cGVlcmluZyBzZXNz aW9uLiAgVGhlIGFwcGxpY2F0aW9uIHByb2ZpbGUgY29kZSBuZWVkIG9ubHkgYmUKPmNvbmNlcm5l ZCB3aXRoIHByb2Nlc3Npbmcgb2YgdGhlIEFWUHMgZGVmaW5lZCBpbiB0aGUgYXBwbGljYXRpb24K PnByb2ZpbGUuCgpJIHdvdWxkIHJhdGhlciB3YW50IHRvIGhhdmUgY29udHJvbCBvdmVyIGNvbm5l Y3Rpb24gZXN0YWJsaXNobWVudCwKaS5lLsKgd2hlbiBpdCBoYXBwZW5zLiBUaGlzIHNlZW1zIHRv IGJlIGFic2VudCBmcm9tIHRoaXMgZHJhZnQuCgo+Mi4zLiAgU3RyaW5nIEZvcm1hdAo+Cj5DIEFQ SSBjbGllbnRzIGFyZSByZXF1aXJlZCB0byBmb3JtYXQgc3RyaW5ncyBhcyBVVEYtOCBpZiB0aGUg c3RyaW5nCj5jb250YWlucyAxNiBiaXQgY2hhcmFjdGVycy4gIFNpbmNlIHRoZSBBU0NJSSBjaGFy YWN0ZXJzIGFuZCB0aGUKPlVURi04IDggYml0IGNoYXJhY3RlcnMgaGF2ZSB0aGUgc2FtZSBjb2Rl cywgQVNDSUkgY2FuIGJlIHVzZWQgZm9yCj5VVEYtOCBpZiBubyB3aWRlIGNoYXJhY3RlcnMgYXJl IGluIHRoZSBzdHJpbmcuICBBbGwgc3RyaW5ncyBwYXNzZWQKPnRocm91Z2ggdGhlIEMgQVBJIGFy ZSBzdGFuZGFyZCBudWxsLXRlcm1pbmF0ZWQgQyBzdHJpbmdzLiAKPlByb2Nlc3NpbmcgdG8gcmVt b3ZlIHRoZSBudWxsIHRlcm1pbmF0b3IgZm9yIHRyYW5zbWlzc2lvbiBvbiB0aGUKPndpcmUgaXMg ZG9uZSBieSB0aGUgbGlicmFyeS4KClRoaXMgc291bmRzIGJvZ3VzLiBDIHN0cmluZ3MgKGluIGNv bW1vbiBzeXN0ZW1zIGF0IGxlYXN0KSBuZXZlciBhcmUKMTYgYml0IChidXQgbW9yZSBsaWtlIENI QVJfQklUPTgpLiBTbyBpZiBteSBzdHJpbmcgaXMgaW4gSVNPLTg4NTktMTUKZW5jb2RpbmcsIEkg ZG8gbm90IGhhdmUgYW55IDE2LWJpdCBjaGFyYWN0ZXJzIGluIGl0LCBhbmQgcGVyIHRoZQpkcmFm dCwgSSBhbSBub3QgcmVxdWlyZWQgdG8gZm9ybWF0IGFzIFVURi04LsKg4oCUIFNlZT8KCj4zLjEu ICBDb25zdGFudCBUeXBlcwo+Cj4zLjEuMS4gIElQIEFkZHJlc3MgYW5kIFBvcnQKPgo+ICAgdHlw ZWRlZiBzdHJ1Y3Qgc29ja2FkZHJfc3RvcmFnZSBBQUFfSVBfQUREUjsKPgo+ICAgQUFBX0lQX0FE RFIgcHJvdmlkZXMgYSB3YXkgb2YgcmVmZXJyaW5nIHRvIGFuIElQdjQgYWRkcmVzcywgSVB2Ngo+ ICAgYWRkcmVzcywgYW5kIElQIHBvcnQuICBUaGUgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiAoc2hv d24gaGVyZSkgaXMKPiAgIGRlZmluZWQgaW4gdGhlIEJhc2ljIFNvY2tldCBJbnRlcmZhY2UgRXh0 ZW5zaW9ucyBmb3IgSVB2NiBbUkZDMzQ5M10KClR5cGVkZWZzIGFyZSBJTUhPIHBvaW50bGVzcyBm b3Igc2ltcGxlIHR5cGVzICh3aGVuIHRoZXkgZG8gbm90IGNvbnZleSBhCnNwZWNpYWwgcHVycG9z ZSBsaWtlIHRoZSBMaW51eCBrZXJuZWwncyBwbWRfdCksIGFuZCBzdHJ1Y3RzLiBJdCBhbHNvIGNy ZWF0ZXMKdW5uZWNlc3NhcnkgY29tcGlsYXRpb24gZGVsYXlzLgoKU2VlIGh0dHA6Ly9sa21sLm9y Zy9sa21sLzIwMDYvMTEvMjEvMzQKCihGdW5jdGlvbiBwb2ludGVycyBhcmUgbm90IGNvbnNpZGVy ZWQgInNpbXBsZSIuKQoKSnVzdCB3cml0ZSAic3RydWN0IHNvY2thZGRyX3N0b3JhZ2UiLgoKSWYg dGhlIG5hbWUgc2hvdWxkIGJlIEFBQV9JUF9BRERSLCBlaXRoZXIgdXNlICJzdHJ1Y3QgQUFBX0lQ X0FERFIiIG9yIHdyaXRlCkMrKy9KYXZhIGluc3RlYWQuIERvIG5vdCB0cnkgdG8gYmUgc21hcnQg aW4gaGlkaW5nIHR5cGVzIC0gQyBpcyBub3QgbWVhbnQgZm9yCnRoaXMuIEp1c3QgYmVjYXVzZSBv bmUgaXMgYWxsb3dlZCB0byBkbyB3aGF0ZXZlciBzdHJhbmdlIHRoaW5ncyBjYW4gYmUgZG9uZQp3 aXRoIEMgZG9lcyBub3QgbWVhbiBpdCBzaG91bGQgYmUgZG9uZS4KCihUaGUgQUFBIHByZWZpeCBp cy4uLiBtaCAtIGNvdWxkIG5vdCBoYXZlIGNvbWUgdXAgd2l0aCBzb21ldGhpbmcKYmV0dGVyPykK CkFsc28gdGhpcyBjYW1lbC1jYXNlIGlzIHNvbWV0aGluZyB5b3Ugd291bGQgc2VlIGluIEMrKy0s IEphdmEtIG9yCk1pY3Jvc29mdC1jZW50cmljIHN0dWZmLiBBbGwgdGhlIGdvb2Qgb25lcywgbWFu eSBhIExpbnV4LCBCU0QgYW5kClNvbGFyaXMgY29kZSBkb2VzIHdpdGhvdXQgdGhhdC4gV2hlbiB3 ZSBlbmNvdW50ZXIgQUFBX0FWUCwgSSBhbG1vc3QKdGhpbmtpbmcgSSBnZXQgc2NyZWFtZWQgYXQ7 IGl0IGlzIHVwcGVyIGNhc2UgbGV0dGVycyB0aHJvdWdob3V0wqDigJQKdmVyeSByZW1pbmlzY2ll bnQgb2YgbGVnYWwgZGlzY2xhaW1lcnMgYW5kIDx3aW5kb3dzLmg+IHNvdXJjZS4KClRvZ2V0aGVy IHdpdGggdGhlIHR5cGVkZWZzIHRoaXMgaXMgdGhlIG1haW4gcmVhc29uIEkgd291bGQgbmV2ZXIg d2FudAp0byB1c2UgdGhpcyBBUEkuIENvZGUgbGlrZSB0aGF0IGp1c3QgYWluJ3QgcmVhZGFibGUg Zm9yIG1lLgoKPjMuMS41LiAgQXR0cmlidXRlL1ZhbHVlIFBhaXIgQ29kZQo+Cj4gICB0eXBlZGVm IHVpbnQzMl90IEFBQV9BVlBDb2RlOwoKV2hhdCBpcyB0aGUgcG9pbnQgaGVyZT8gSWYgdGhlIHR5 cGVkZWYgaXMgdXNlZCBiZWNhdXNlIHlvdSB0aGluayB5b3UKY291bGQgdHJhbnNwYXJlbnRseSBj aGFuZ2UgdGhlIHVuZGVybHlpbmcgaW1wbGVtZW50YXRpb24sIHRoZW4gdGhpcwppcyBhIHdyb25n IGJlbGllZi4gVGhlIEFCSSB3b3VsZCBjaGFuZ2XCoHdoZW4gbW92aW5nIHRvIGUuZy7CoHVpbnQ2 NF90LAphbmQgdGhlIHJlcXVpcmVkIGFjY2VzcyBzeW50YXggY2hhbmdlcyB3aGVuIG1vdmluZyB0 byBlLmcuwqBhIHN0cnVjdC4KClRoZSBuYW1pbmcgc2NoZW1lIGlzIGluY29uc2lzdGVudCBhdCBi ZXN0LiBVbmRlcnNjb3JlIGdvZXMgYmV0d2VlbgpBQUEgYW5kIEFWUCAoYWxzbyBpbiBvdGhlciBw bGFjZXMgbGlrZSBlbnVtIEFBQV9BVlBGbGFnKSwgYnV0IG5vdCBmb3IKQUFBX1NlcnZlcj8KCj4z LjEuNy4gIFZhbHVlIFR5cGUgSWRlbnRpZmllcgo+Cj4gICB0eXBlZGVmIHZvaWQgQUFBU2VydmVy Owo+Cj4gICBBQUFTZXJ2ZXIgaXMgYW4gaWRlbnRpZmllciBmb3IgYSBwYXJ0aWN1bGFyIHNlcnZp bmcgcGVlci4gIEl0IGlzIHVzZWQKPiAgIGluIHRoZSBzZXJ2ZXIgYWNjZXNzIGZ1bmN0aW9ucy4K ClN1Y2ggYSB0eXBlZGVmIGlzICpzbyogbWlzbGVhZGluZy4gU29tZW9uZSB3aG8gdHJpZXMgdG8g ZGVjbGFyZQoKCUFBQVNlcnZlciBmb287Cgp3aWxsIG9ubHkgZ2V0ICJzdG9yYWdlIHNpemUgb2Yg Zm9vIGlzIG5vdCBrbm93biIgY29tcGlsZXIgZXJyb3IuCkVzcGVjaWFsbHkgY29uc2lkZXJpbmcg dGhpczoKCglBQUFTZXJ2ZXIgbXlfZnVuY3Rpb24oY2hhciAqZG9fc29tZXRoaW5nKQoJewoJCS8q IHJldHVybiBzb21ldGhpbmcgb3Igbm90PyAqLwoJCS8qIGl0J3MganVzdCBub3Qgb2J2aW91cyB3 aGV0aGVyIGl0IGlzIHZvaWQgKi8KCX0KCkJlY2F1c2UgSSB3b3VsZCByYXRoZXIgYXNzdW1lIGl0 IHdhcyB0eXBlZGVmZWQgdG8gYSBzdHJ1Y3Qgb3Igc29tZQppbnRlZ3JhbCB0eXBlLgoKPjMuMS4x MS4gIEFwcGxpY2F0aW9uIElkZW50aWZpZXIKPgo+ICAgdHlwZWRlZiB2b2lkKiBBQUFBcHBsaWNh dGlvbklkOwoKUG9pbnRlcnMgaW4gdHlwZWRlZnMgYXJlIHNvIGZyb3duZWQgdXBvbi4gTWljcm9z b2Z0IGRpZCB0aGF0IHdpdGgKdGhlaXIgTFBDU1RSIHR5cGVkZWYgZm9yIGV4YW1wbGUuIEl0IGNv bmZ1c2VzIHRoZSBoZWxsIG91dCBvZgpldmVyeW9uZSwgc2luY2UgeW91IGRvIG5vdCBrbm93LCBi eSBqdXN0IGxvb2tpbmcgYXQgdGhlIG5hbWUsIHdoZXRoZXIKaXQgaXMgYSBwb2ludGVyIG9yIG5v dCAtIGFuZCBJJ2QgcmF0aGVyIGFzc3VtZSBpdCB3YXMgdGhlIGxhdHRlciwgYW5kCmxldCdzIHNh eSBJIHdhbnRlZCB0byBpbmNyZWFzZSB0aGUgaWQgYnkgb25lOgoKCXZvaWQgZm9vKEFBQUEvKmhv dyBtYW55IEFzIHdhcyB0aGF0PyovcHBsaWNhdGlvbklkIGJhcikKCXsKCQkrK2JhcjsKCX0KCmJ1 dCB0aGF0IHdvdWxkIGRvIHRoZSB3cm9uZyB0aGluZyBpbnN0ZWFkIG9mIHdoYXQgSSBpbnRlbmRl ZC4gSGVuY2UKcGxlYXNlIGRvIG5vdCB1c2UgaW5kaXJlY3Rpb25zIGluIHR5cGVkZWZzICh0aGUg b25lIGV4Y2VwdGlvbiBpcyBhCmZ1bmN0aW9uIHBvaW50ZXIgd2hlcmUgdGhpcyBpcyBuZWNlc3Nh cnkpLgoKPjMuMS4xMi4gIEFQSSBSZXR1cm4gQ29kZXMKPgo+ICAgVGhlIGZvbGxvd2luZyBzdGF0 dXMgY29kZXMgYXJlIHJldHVybmVkIGJ5IGZ1bmN0aW9ucyBpbiB0aGUgQUFBIEFQSToKPgo+ICAg ICAgICAgICB0eXBlZGVmIGVudW0gewo+ICAgICAgICAgICAgICAgICBBQUFfRVJSX05PVF9GT1VO RCA9ICAgICAgIC0yLAo+ICAgICAgICAgICAgICAgICBBQUFfRVJSX0ZBSUxVUkUgPSAgICAgICAg IC0xLAo+ICAgICAgICAgICAgICAgICBBQUFfRVJSX1NVQ0NFU1MgPSAgICAgICAgICAwLAo+ICAg ICAgICAgICAgICAgICBBQUFfRVJSX05PTUVNLAo+ICAgICAgICAgICAgICAgICBBQUFfRVJSX1BS T1RPLAoKSXQgd291bGQgaGF2ZSBiZWVuIHByZWZlcmFibGUgdG8gcmV1c2UgZXJybm8gYXMgbXVj aCBhcyBwb3NzaWJsZS4KCj4zLjEuMTQuICBBVlAgRGF0YSBUeXBlIENvZGVzCj4KPiAgIFRoZSBm b2xsb3dpbmcgYXJlIEFWUCBkYXRhIHR5cGUgY29kZXMuICBUaGV5IGNvcnJlc3BvbmQgZGlyZWN0 bHkgdG8KPiAgIHRoZSBBVlAgZGF0YSB0eXBlcyBvdXRsaW5lIGluIHRoZSBEaWFtZXRlciBzcGVj aWZpY2F0aW9uIFtSRkMzNTg4XToKPgo+ICAgICAgICAgICB0eXBlZGVmIGVudW0gewo+ICAgICAg ICAgICAgICAgIEFBQV9BVlBfU1RSSU5HX1RZUEUsCj4gICAgICAgICAgICAgICAgQUFBX0FWUF9B RERSRVNTX1RZUEUsCj4gICAgICAgICAgICAgICAgQUFBX0FWUF9PQ1RFVF9TVFJJTkdfVFlQRSwK PiAgICAgICAgICAgICAgICBBQUFfQVZQX0lOVEVHRVIzMl9UWVBFLAo+ICAgICAgICAgICAgICAg IEFBQV9BVlBfSU5URUdFUjY0X1RZUEUsCj4gICAgICAgICAgICAgICAgQUFBX0FWUF9VTlNJR05F RDMyX1RZUEUsCj4gICAgICAgICAgICAgICAgQUFBX0FWUF9VTlNJR05FRDY0X1RZUEUsCj4gICAg ICAgICAgICAgICAgQUFBX0FWUF9GTE9BVDMyX1RZUEUsCj4gICAgICAgICAgICAgICAgQUFBX0FW UF9GTE9BVDY0X1RZUEUsCj4gICAgICAgICAgIH0gQUFBX0FWUERhdGFUeXBlOwoKV2hlcmUgaXMg dGhlIEdST1VQIGFuZCB0aGUgInVuc3BlY2lmaWVkIiB0eXBlwqDigJQgb3IgYXJlIGdyb3VwcyBv ZiB0eXBlClNUUklORz8KCj4zLjEuMTYuICBEb21haW4gSW50ZXJjb25uZWN0aW9uIFR5cGVzCj4K PiAgICAgICAgICAgdHlwZWRlZiBlbnVtIHsKPiAgICAgICAgICAgICAgQUFBX0RPTUFJTl9MT0NB TCwKPiAgICAgICAgICAgICAgQUFBX0RPTUFJTl9QUk9YWSwKPiAgICAgICAgICAgICAgQUFBX0RP TUFJTl9CUk9LRVIsCj4gICAgICAgICAgICAgIEFBQV9ET01BSU5fRk9SV0FSRAo+ICAgICAgICAg ICB9IEFBQURvbWFpbkludGVyY29ubmVjdDsKCihEZXRlY3RlZCBtYXJrZXRzcGVhayBpbnRydXNp b24gKCJicm9rZXIiKS4gSXMgbm90IHRoZXJlIHNvbWUKcmVzZWFyY2gvLmVkdS1saWtlIHRlcm0g Zm9yIHRoYXQ/KQoKPjMuMS4xOS4gIFNlYXJjaCBEaXJlY3Rpb24gVHlwZQo+Cj4gICBUaGUgZm9s bG93aW5nIHR5cGUgYWxsb3dzIHRoZSBjbGllbnQgdG8gc3BlY2lmeSB3aGljaCBkaXJlY3Rpb24g dG8KPiAgIHNlYXJjaCBmb3IgYW4gQVZQIGluIHRoZSBBVlAgbGlzdDoKPgo+ICAgICAgICAgICB0 eXBlZGVmIGVudW0gewo+ICAgICAgICAgICAgICBBQUFfRk9SV0FSRF9TRUFSQ0ggPSAwLAo+ICAg ICAgICAgICAgICBBQUFfQkFDS1dBUkRfU0VBUkNICj4gICAgICAgICAgIH0gQUFBU2VhcmNoVHlw ZTsKClRob3VnaCB0aGVyZSBpcyBhIHBhcnRpY3VsYXIgQVZQIG9yZGVyIG1hbmRhdGVkIGJ5IHRo ZSBSRkMsIHRoaXMKZXhwb3NlcyBpbXBsZW1lbnRhdGlvbiBpbnRlcm5hbHPCoOKAlCBzb21ldGhp bmcgdG8gYmUgdXN1YWxseSBhdm9pZGVkLgoKPjMuMi4xLgo+Cj4gICAgICAgICAgIHR5cGVkZWYg c3RydWN0IGRpY3Rpb25hcnlFbnRyeSB7Cj4gICAgICAgICAgICAgIEFBQV9BVlBDb2RlICAgICBh dnBDb2RlOwo+ICAgICAgICAgICAgICBjaGFyKiAgICAgICAgICAgYXZwTmFtZTsKPiAgICAgICAg ICAgICAgQUFBX0FWUERhdGFUeXBlIGF2cFR5cGU7Cj4gICAgICAgICAgICAgIEFBQVZlbmRvcklk ICAgICB2ZW5kb3JJZDsKPiAgICAgICAgICAgICAgQUFBX0FWUEZsYWcgICAgIGZsYWdzOwo+ICAg ICAgICAgICB9IEFBQURpY3Rpb25hcnlFbnRyeTsKCklmIHlvdSB3YW50IHRvIGhpZGUgdGhlIGZh Y3QgdGhhdCBzb21ldGhpbmcgaXMgb2YgYSBwYXJ0aWN1bGFyIHR5cGUsCmRvIG5vdCB1c2UgQy4g VGhhdCBiZWluZyBzYWlkLCAqaWZmKiB5b3UgZ28gZG93biB0aGUgdHlwZWRlZiByb3V0ZSwKd2h5 IGdpdmUgdGhlIHN0cnVjdCBhIG5hbWU/IEl0IGNyZWF0ZXMgY29uZnVzaW9uIG9uIHRoZSBkZXZl bG9wZXJzIC0Kc29tZSB3aWxsIHVzZSAic3RydWN0IGRpY3Rpb25hcnlFbnRyeSIgaW4gdGhlaXIg cHJvZ3JhbXMsIHNvbWUgd2lsbAp1c2UgIkFBQURpY3Rpb25hcnlFbnRyeSIsIGFuZCB3aGF0IHlv dSBoYXZlIGdhaW5lZCBpcyBhIGRvdWJsZS1zaWRlZApBUEksIGFuZCBhIHBvdGVudGlhbCBuYW1l IGNsYXNoIGluIHRoZSBzdHJ1Y3QgbmFtZXNwYWNlLiBBbmQgd2UgYWxsCmFncmVlIHRoYXQgYW4g QVBJIHNob3VsZCBvbmx5IGJlICJhcyBiaWcgYXMgbmVjZXNzYXJ5IGJ1dCBhcyBzbWFsbCBhcwpw b3NzaWJsZSIsIHNob3VsZCBub3QgaXQ/IE5vdCB0byBtZW50aW9uICJkaWN0aW9uYXJ5RW50cnki IGlzIHJlYWwKbmFtZXNwYWNlIHBvbGx1dGlvbi4KCj4zLjIuMi4gIEFWUCBEZWZpbml0aW9uCj4K PiAgIFRoZSBmb2xsb3dpbmcgc3RydWN0dXJlIGNvbnRhaW5zIGEgbWVzc2FnZSBBVlAgaW4gcGFy c2VkIGZvcm06Cj4KPiAgICAgICAgICAgIHR5cGVkZWYgc3RydWN0IGF2cCB7Cj4gICAgICAgICAg ICAgICAgICAgIGVudW0gewo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFBQV9SQURJVVMs Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBX0RJQU1FVEVSCj4gICAgICAgICAgICAg ICAgICAgIH0gcGFja2V0VHlwZTsKPiAgICAgICAgICAgICAgICAgICAgQUFBX0FWUENvZGUgY29k ZTsKPiAgICAgICAgICAgICAgICAgICAgdWludDE2X3QgbGVuZ3RoOwoKPHNhcmNhc20+T2ggbm9l cy4gQW4gKEFBQS1wcm92aWRlZCkgdHlwZWRlZiBpcwptaXNzaW5nIGZvciAibGVuZ3RoIiE8L3Nh cmNhc20+Cgo+My4yLjMuICBBVlAgTGlzdAo+ICAgICAgICAgICAgdHlwZWRlZiBzdHJ1Y3QgYXZw TGlzdHsKPiAgICAgICAgICAgICAgICAgICAgQUFBX0FWUCAqaGVhZDsKPiAgICAgICAgICAgICAg ICAgICAgQUFBX0FWUCAqdGFpbDsKPiAgICAgICAgICAgIH0gQUFBX0FWUF9MSVNUOwoKQWxsLXVw cGVyY2FzZSBpcyBjb21tb25seSB1c2VkIGZvciBwcmVwcm9jZXNzb3IgbWFjcm9zIG9ubHkuCihQ ZXJoYXBzICJzdHJ1Y3QgYWFhX2F2cF9saXN0IiB3YXMgaW50ZW5kZWQgaW5zdGVhZCE/KQoKPjMu My4gIE1hY3JvcyBhbmQgUHJlcHJvY2Vzc29yIERlZmluaXRpb25zCj4KPiAgIFRoZSBmb2xsb3dp bmcgZGVmaW5pdGlvbiByZXNlcnZlcyB0aGUgdmVuZG9yIGlkIG9mIDA6Cj4KPiAgICNkZWZpbmUg QUFBX05PX1ZFTkRPUl9JRCAwCgpVc2UgYW4gZW51bSB7IEFBQV9OT19WRU5ET1JfSUQgPSAwIH0g aW5zdGVhZD8KCj4zLjQuMi4xLiAgQUFBUmVnaXN0ZXJDb21tYW5kQ2FsbGJhY2soKQo+Cj4gICBU aGUgZm9sbG93aW5nIGZ1bmN0aW9uIGlzIHVzZWQgdG8gcmVnaXN0ZXIgY29tbWFuZCBjYWxsYmFj a3MgZm9yCj4gICBwcm9jZXNzaW5nIEFBQSBjb21tYW5kczoKPgo+ICAgICAgICAgQUFBQ2FsbGJh Y2tIYW5kbGUgKgo+ICAgICAgICAgQUFBUmVnaXN0ZXJDb21tYW5kQ2FsbGJhY2soQUFBQ29tbWFu ZENvZGUgY29tbWFuZENvZGUsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB QUFWZW5kb3JJZCB2ZW5kb3JJZCwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNoYXIgKmNvbW1hbmROYW1lLAo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QUFBRXh0ZW5zaW9uSWQgZXh0ZW5zaW9uSWQsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBQUFDYWxsYmFjayBjYWxsYmFjaywKPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEFBQUNhbGxiYWNrTG9jYXRpb24gcG9zaXRpb24pOwoKc3BhZ2hldHRpLWxvbmcg ZnVuY3Rpb24gbmFtZXMgKGFuZCB0eXBlcyB0b28pLgoKV2h5IGRvIG5vdCB5b3UgdXNlIGNvbnN0 IGNoYXLCoCo/IEFyZSBsaWJyYXJpZXMgc3VwcG9zZWQgdG8gZWRpdAp0aGUgY29tbWFuZCBuYW1l PyBUaGF0IG1lYW5zIGNhbGxlciBjb2RlIHdpbGwgaGF2ZSB0byBjYXN0IGF3YXkKY29uc3RuZXNz IHdhcm5pbmdzLCBhbmQgZWgsIGNhc3RzIGl0c2VsZiBhcmUgYmFkLgoKQWRkaW5nIGEgcG9zaXRp b24gaXMgbm8gZ29vZCwgYmVjYXVzZSBvdXQtb2Ytb3JkZXIgY2FsbGVycyBtaWdodAppbnNlcnQg Q0JzIHRoYXQgc3RlYWwgdGhlIG1lc3NhZ2UuIEFuZCBpZiBub3QgdGhhdCwgdGhlcmUgaXMKYSBk ZXBlbmRlbmN5IG9mIHRoaXJkLXBhcnR5IG9uIHRoZSBwYXJ0aWN1bGFyIHBvc2l0aW9uIHVzZWQu IEhvdyB0bwpzYXk7IHlvdXIgbGliZm9vIHVzZXMgcmVnX2NiKHBvcz0xMCksIHRoZW4gdGhlIDNy ZCBwYXJ0eSBsaWJiYXIgd2lsbAp1c2UgcmVnX2NiKHBvcz05KSB0byBnZXQgaXRzIGpvYiBkb25l LCBhbmQgdGhlbiB0aGUgbGliZm9vIGRldmVsb3BlcgpkZWNpZGVzIHRvIHVzZSBwb3M9NSBpbnN0 ZWFkIGFuZCBldmVyeXRoaW5nIGZhbGxzIGFwYXJ0IGJlY2F1c2UKbGliYmFyIGlzIHN0aWxsIGF0 IHBvcz0xMCBhbmQsIGxldCdzIHNheSwgY2Fubm90IGdvIHRvIHBvcz00IGJlY2F1c2UKaXQgd291 bGQgYWxzbyBjcmVhdGUgcHJvYmxlbXMgZm9yIGxpYmJhci4KCj4zLjQuMi4yLiAgQUFBUmVnaXN0 ZXJOb25jb21tYW5kQ2FsbGJhY2soKQo+Cj4gICBUaGUgZm9sbG93aW5nIGNhbGxiYWNrIHJlZ2lz dGVycyBhbiBBQUEgY2FsbGJhY2sgdG8gcHJvY2VzcyBhbGwKPiAgIG1lc3NhZ2VzLiAgVGhlIGNh bGxiYWNrIGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggYW55IGNvbW1hbmQsIGJ1dAo+ICAgcmF0aGVy IHdpbGwgcHJvY2VzcyBhbGwgbWVzc2FnZXMgYXMgdGhleSBjb21lIGRvd24gdGhlIGNhbGxiYWNr Cj4gICBjaGFpbjoKPgo+ICAgICAgICAgQUFBQ2FsbGJhY2tIYW5kbGUKPiAgICAgICAgIEFBQVJl Z2lzdGVyTm9uY29tbWFuZENhbGxiYWNrKEFBQUNhbGxiYWNrIGNhbGxiYWNrLAoKV2h5IG5vdCBy ZXVzZSBhYWFyZWdjYiB3aXRoIGEgY29tbWFuZCBudW1iZXIgb2YgMD8KCj4zLjQuMy43LiAgQUFB R2V0RG9tYWluSW50ZXJjb25uZWN0VHlwZSgpCj4KPiAgIFRoZSBmb2xsb3dpbmcgZnVuY3Rpb24g cmV0dXJucyB0aGUgZG9tYWluIGludGVyY29ubmVjdCB0eXBlIGZvciBhCj4gICBwYXJ0aWN1bGFy IGRvbWFpbiBuYW1lIGFuZCB0eXBlIG9mIHNlcnZpY2U6Cj4KPiAgICAgICAgIEFBQVJlc3VsdENv ZGUKPiAgICAgICAgIEFBQUdldERvbWFpbkludGVyY29ubmVjdFR5cGUoQUFBTWVzc2FnZSAqbWVz c2FnZSwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqZG9tYWlu TmFtZSwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqdHlwZSk7 CgpBQUFSZXR1cm5Db2RlIC0tLSBBQUFSZXN1bHRDb2RlLCB0aGlzIGlzIGEgNzclIHNpbWlsYXJp dHksIGFuZApzb21ldGhpbmcgZWFzaWx5IG92ZXJzZWVuLgoKPjMuNC40LjYuICBBQUFHZXRDb21t YW5kQ29kZSgpCj4KPiAgIFRoaXMgZnVuY3Rpb24gcmV0dXJucyB0aGUgY29tbWFuZCBjb2RlIGFu ZCB2ZW5kb3IgaWQgYmFzZWQgb24gYQo+ICAgc3RyaW5nOgo+Cj4gICAgICAgICBib29sZWFuX3QK PiAgICAgICAgIEFBQUdldENvbW1hbmRDb2RlKGNoYXIgKmNvbW1hbmROYW1lLAo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgQUFBQ29tbWFuZENvZGUgKmNvbW1hbmRDb2RlLAo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgQUFBVmVuZG9ySWQgKnZlbmRvcklkKTsKCkkgYW0gYWxtb3N0IGNy eWluZyB3aGVuIEkgc2VlIHRoaXMuIGJvb2xlYW5fdCBpcyBub3QgZXZlbiBhIGtub3duCnR5cGXC oOKAlCBpbiBDIGF0IGxlYXN0LiBBbmQgSSByZW1lbWJlciB0aGlzIGRyYWZ0IHdhcyBmb3IgQywg d2FzIG5vdAppdD8KCj4zLjQuNS4xNS4gIEFBQUdldFByZXZBVlAoKQo+Cj4gICBUaGlzIGZ1bmN0 aW9uIHJldHVybnMgYSBwb2ludGVyIHRvIHRoZSBwcmV2aW91cyBBVlAgaW4gdGhlIGxpc3Q6Cj4K PiAgICAgICAgIEFBQV9BVlAgKgo+ICAgICAgICAgQUFBR2V0UHJldkFWUChBQUFfQVZQICphdnAp OwoKSHlwb3RoZXNpczogVGhpcyBBUEkgaXMgb3ZlcmRlc2lnbmVkLgoKT3ZlcmRlc2lnbiBpcyB3 aGVuIGEgZnVuY3Rpb24gaXMgYWRkZWQgdGhhdCBpcyBfdGhvdWdodF8gbWlnaHQgYmUKdXNlZnVs LCBidXQgYWN0dWFsbHkgaXMgbm90LiBVbmxlc3MgdGhlcmUgaXMgZW1waXJpY2FsIGRhdGEgdGhh dApzaG93cyB0aGVyZSBBUkUgYWN0dWFsbHkgdXNlcnMgb2YgdGhpcyBmdW5jdGlvbiAoYW5kIGp1 c3QgdHdvIHdvbid0CmN1dCBpdCksIGl0IGlzIGp1c3QgYmxvYXQuCgpBbHNvLCB0aGVyZSBpcyBu byBtZW1iZXIgaW4gdGhlIHN0cnVjdF5XLCBwYXJkb24tbW9pLCB0eXBlZGVmLCB0aGF0CnBvaW50 cyB0byB0aGUgcHJldmlvdXMgQVZQIGluIGEgbGlzdC4gVGhlIHNhbWUgZ29lcyBmb3IKYWFhX2dl dF9uZXh0X2F2cC4gU28gdGhlcmUgaXMgbm8gd2F5IHRvIGV2ZW4gaW1wbGVtZW50IHRoaXMgd2l0 aCB0aGUKZ2l2ZW4gZHJhZnQuIEFnYWluIEkgbG9va2VkIGF0IFNVTidzIHByb3RvdHlwZSBmcm9t IDIwMDIgYW5kCm92ZXJsYXlpbmcgaXQgd2l0aCBBQUFfWEFWUCBpcyB1bmRlc2NyaWJhYmx5IHVn bHkgYW5kIGNhbGxzIGZvcgpzZWdmYXVsdHMuCgo+My40LjMuMS4gIEFBQVN0YXJ0U2Vzc2lvbigp Cj4KPiAgIFRoZSBmb2xsb3dpbmcgZnVuY3Rpb24gYWxsb3dzIGEgY2xpZW50IHRvIHN0YXJ0IGEg c2Vzc2lvbiBhbmQKPiAgIGlkZW50aWZ5IGl0Ogo+Cj4gICAgICAgICBBQUFSZXR1cm5Db2RlCj4g ICAgICAgICBBQUFTdGFydFNlc3Npb24oQUFBU2Vzc2lvbklkICoqc2Vzc2lvbklkLAo+ICAgICAg ICAgICAgICAgICAgICAgICAgIEFBQUFwcGxpY2F0aW9uSWQgYXBwSGFuZGxlLAo+ICAgICAgICAg ICAgICAgICAgICAgICAgIGNoYXIgKnVzZXJOYW1lLAo+ICAgICAgICAgICAgICAgICAgICAgICAg IEFBQUNhbGxiYWNrIGFib3J0Q2FsbGJhY2spOwoKV2h5IHRoZSB1c2VyIG5hbWU/IEkgZG8gbm90 IHNlZSBpdCBiZWluZyByZXF1aXJlZCBieSB0aGUgUkZDLgoKPjMuNC4zLjIuICBBQUFSZWdpc3Rl clBlZXJTZXNzaW9uKCkKCkl0IGlzIG5vdCBjbGVhciBpbiB3aGF0IG9yZGVyIGFueSBvZiB0aGVz ZSBmdW5jdGlvbnMgYXJlIHN1cHBvc2VkIHRvCmJlIGNhbGxlZC4KCj4zLjQuMy41LiAgQUFBTG9v a3VwU2VydmVyKCkKPgo+VGhlIGZ1bmN0aW9uIGxvb2tzIHVwIHRoZSBBQUEgc2VydmVyIGJhc2Vk IG9uIElQIGFkZHJlc3MgYW5kIHBvcnQKPm51bWJlci4gU2VydmVyIGNvbm5lY3Rpb25zIGFyZSBj cmVhdGVkIGZyb20gdGhlIGNvbmZpZ3VyYXRpb24gZmlsZToKPgo+QUFBU2VydmVyICpBQUFMb29r dXBTZXJ2ZXIoQUFBX0lQX0FERFIgaXBBZGRyKTsKPgo+VGhlIHJldHVybiB2YWx1ZSBpcyBlaXRo ZXIgYSB2YWxpZCBzZXJ2ZXIgcG9pbnRlciBvciB0aGUgTlVMTCBpZgo+dGhlIHNlcnZlciBjYW4n dCBiZSBmb3VuZC4KCiJTZXJ2ZXIgcG9pbnRlciIgaXMgdG9vIHNwYXJzZS4gSXQncyBhbG1vc3Qg bGlrZSBJIGNvdWxkIHJldHVybgomaXBhZGRyIGFnYWluLiBBbHNvLCB0aGVyZSBpcyBubyB3YXkg dG8gZGV0ZXJtaW5lIHdoYXQgbDNwcm90bwp0aGUgaXBhZGRyIGlzIHN1cHBvc2VkIHRvLiAoVGhl cmUgaXMsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIGFuCmltcGxlbWVudGF0aW9uIGRldGFpbCBvZiBs aWJzb2NrLikKCkFuZCB3aHkgd291bGQgYSBzZXJ2ZXIgbG9va3VwIGJlIG5lZWRlZD8gVGhlIGlw IGFkZHJlc3MgaXMgZW5vdWdoIHRvCmNvbm5lY3QgdG8gaXQuCgo+My40LjQuNC4gIEFBQVZhbHVl RnJvbUFWUENvZGUoKQo+Cj5UaGlzIGZ1bmN0aW9uIGxvb2tzIHVwIGFuIEFWUCB2YWx1ZSB1c2lu ZyB0aGUgQVZQIGlkIGFuZCB2ZW5kb3IKPmlkLCBhbmQgdGhlIHZhbHVlIG5hbWU6Cj4KPkFBQVZh bHVlIEFBQVZhbHVlRnJvbUFWUENvZGUoQUFBX0FWUENvZGUgYXZwQ29kZSwKPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQUFBVmVuZG9ySWQgdmVuZG9ySWQsIGNoYXIgKnZhbHVlTmFtZSk7 CgpJIGV2ZW4gaGFkIHRvIGxvb2sgaW50byBTVU4ncyB5ZWFyLW9sZCBmcmVlZGlhbWV0ZXIgdG8g ZmlndXJlIG91dApqdXN0IHdoYXQgdGhpcyB3YXMgc3VwcG9zZWQgdG8gZG8uIFRoaXMgc2hvdWxk IGNhcnJ5IHRoZSB3b3JkIEFWUAoiZW51bSIgc29tZXdoZXJlIGF0IGxlYXN0LgoKPjMuNC40LjYu ICBBQUFHZXRDb21tYW5kQ29kZSgpCj4gICAgICAgICBib29sZWFuX3QgWy4uLl0KPiAgIFRoZSBy ZXR1cm4gdmFsdWUgaXMgX0JfVFJVRSBpZiB0aGUgY29tbWFuZCB3YXMgZm91bmQuCgpUaGVyZSBp dCBpcyBhZ2Fpbi4gKlRoZXJlIGlzIG5vIGJvb2xlYW5fdCBhbmQgbm8gX0JfVFJVRSogaW4gdGhl IEMKc3RhbmRhcmQhCgo+My40LjUuMS4gIEFBQU5ld01lc3NhZ2UoKQo+QUFBTWVzc2FnZSAqQUFB TmV3TWVzc2FnZShBQUFDb21tYW5kQ29kZSBjb21tYW5kQ29kZSwKPiAgICAgICAgICAgICAgICAg ICAgICAgICAgQUFBVmVuZG9ySWQgdmVuZG9ySWQsCj4gICAgICAgICAgICAgICAgICAgICAgICAg IEFBQVNlc3Npb25JZCAqc2Vzc2lvbklkLAo+ICAgICAgICAgICAgICAgICAgICAgICAgICBBQUFF eHRlbnNpb25JZCBleHRlbnNpb25JZCwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBTWVz c2FnZSAqcmVxdWVzdCk7Cj5leHRlbnNpb25JZDogIFRoZSBleHRlbnNpb24gaWRlbnRpZmllci4K CldoYXQgaXMgYW4gZXh0ZW5zaW9uIGlkZW50aWZpZXI/Cgo+My40LjUuMi4gIEFBQUZyZWVNZXNz YWdlKCkKPgo+VGhpcyBmdW5jdGlvbiBmcmVlcyBhIG1lc3NhZ2UgYWxsb2NhdGVkIHRocm91Z2gg QUFBTmV3TWVzc2FnZSgpOgo+Cj5BQUFSZXR1cm5Db2RlIEFBQUZyZWVNZXNzYWdlKEFBQU1lc3Nh Z2UgKiptZXNzYWdlKTsKPgo+bWVzc2FnZTogQSBwb2ludGVyIHRvIGEgcG9pbnRlciB0byB0aGUg YWxsb2NhdGVkIG1lc3NhZ2UuCgpKdXN0IHVzZSBhIHNpbmdsZSBwb2ludGVyIGxpa2UgZnJlZSgp IGRvZXMuIFRoZSBzYW1lIGFwcGxpZXMgdG8KYWFhX2ZyZWVfYXZwLgoKPjMuNC41LjE2LiAgQUFB Q29udmVydEFWUFRvU3RyaW5nKCkKPgo+VGhpcyBmdW5jdGlvbiBjb252ZXJ0cyB0aGUgZGF0YSBp biB0aGUgQVZQIHRvIGEgZm9ybWF0IHN1aXRhYmxlIGZvcgo+bG9nIG9yIGRpc3BsYXkgZnVuY3Rp b25zLgo+Cj5jaGFyICpBQUFDb252ZXJ0QVZQVG9TdHJpbmcoQUFBX0FWUCAqYXZwLCBjaGFyICpk ZXN0LCBzaXplX3QgZGVzdExlbik7Cj4KPlRoZSByZXR1cm4gdmFsdWUgaXMgdGhlIHBhc3NlZCBp biBkZXN0aW5hdGlvbiBidWZmZXIuCgpUaGUgcmV0dXJuIHZhbHVlwqDigJQgd2hpY2ggaXMgYSAi bG9uZyItc2l6ZWQgcG9pbnRlciAoaS5lLiAyLCA0IG9yIDgKYnl0ZXMsIGRlcGVuZGluZyBvbiBj b21waWxlciBtb2RlKS4gQW5kIHRoaXMgcG9pbnRlciBpcyBwYXNzZWQgaW4gdGhlCmRlc3RpbmF0 aW9uIGJ1ZmZlciwgdWhtLCBzbyB0aGF0IHNvdW5kcyBsaWtlLCB0byBnZXQgbXkgcmV0dXJuIHZh bHVlLApJIG5lZWQgdG8gdXNlOgoKCW15cmV0dXJudmFsdWUgPSAqKGNoYXIgKiopZGVzdDsKClRo ZW4sIHdoYXQgaXMgdGhlIHJldHVybiB2YWx1ZSBnb29kIGZvciBpZiBpdCBpcyByZXR1cm5lZCBp biB0aGUKYnVmZmVyIGFueXdheS4KCj4zLjQuNi4xLiAgQUFBU2V0U2VydmVyKCkKPgo+VGhpcyBm dW5jdGlvbiBzZXRzIHRoZSBzZXJ2ZXIgdG8gd2hpY2ggdGhlIG1lc3NhZ2UgaXMgc2VudDoKPgo+ QUFBUmV0dXJuQ29kZSBBQUFTZXRTZXJ2ZXIoQUFBTWVzc2FnZSAqbWVzc2FnZSwgQUFBX0lQX0FE RFIgaG9zdCk7CgpTb21laG93IEkgZmVlbCB0aGF0IHRoZSBkZXN0aW5hdGlvbiBmb3IgYSBtZXNz YWdlIGlzIG5vdCBhIG1lc3NhZ2UKcHJvcGVydHkuLi4gV2hhdCBpZiBJIHdhbnQgdG8gc2VuZCB0 aGUgc2FtZSBtZXNzYWdlIHRvIG11bHRpcGxlCmRlc3RpbmF0aW9ucz8gSSB3b3VsZCBoYXZlIHRv CgoJc2V0c2VydmVyKG1zZywgImxvY2FsaG9zdCIpOwoJbXlfc2VuZChtc2cpOwoJc2V0c2VydmVy KG1zZywgInJlbW90ZWhvc3QiKTsKCW15X3NlbmQobXNnKTsKCmJ1dCBpdCBpcyBtdWNoIHNtYXJ0 ZXIgdG8gbm90IGhhdmUgaXQgYXMgYSBwZXItbWVzc2FnZSBwcm9wZXJ0eSwgSU9XOgoKCW15X3Nl bmQobXNnLCAibG9jYWxob3N0Iik7CglteV9zZW5kKG1zZywgInJlbW90ZWhvc3QiKTsKCkZvciBh ZGRlZCB3aW4sIEkgY2FuIGV2ZW4gY2FsbCBteV9zZW5kKCkgYXN5bmNocm9ub3VzbHkgYW5kIGhh dmUgdGhlbQpydW4gY29uY3VycmVudGx5LCBlLmcuIGJ5IHNwYXduaW5nIGV4dHJhIHRocmVhZHMs IHdpdGhvdXQgaGF2aW5nIHRvCndvcnJ5IGFib3V0IHNlcmlhbGl6YXRpb24gaXNzdWVzLiBXaXRo IHRoZSBicm9rZW4gQUFBU2V0U2VydmVyLCBvbmUKd291bGQgaGF2ZSB0by4KClByZWZlcmFibHkg dGhvdWdoLCBJIGhhdmUgdHdvIHByZXZpb3VzbHktZXN0YWJsaXNoZWQgY29ubmVjdGlvbnM6CgoJ c3RydWN0IGNvbm4gKmMxLCAqYzI7IC8qIGFzc3VtZSBpbml0aWFsaXplZCAqLwoJc2VuZChjMSwg bXNnKTsKCXNlbmQoYzIsIG1zZyk7Cgp3aGljaCB3b3VsZCBJTUhPIGJlIGEgc2FuZSBhcHByb2Fj aC4KCj5pcFZlcnNpb246IFRoZSB2ZXJzaW9uIG51bWJlciBvZiB0aGUgSVAgYWRkcmVzcy4KClRo aXMgcGFyYW1ldGVyIGRvZXMgbm90IGV2ZW4gYXBwZWFyIGluIHRoZSBmdW5jdGlvbiBzaWduYXR1 cmUuCgoKPkFBQV9FUlJfTk9UX0ZPVU5EOiBJZiB0aGUgc2VydmVyIHdhcyBub3QgZm91bmQuCgpU aGVyZSBpcyBhIGxhY2sgb2YgRUNPTk5SRUZVU0VEOiBzZXJ2ZXIgZm91bmQgYnV0IGNvbm5lY3Rp b24gcmVmdXNlZC4KCj4zLjYuICBHcm91cGVkIEFWUHMKPgo+SW4gb3JkZXIgdG8gY3JlYXRlIGdy b3VwZWQgQVZQcywgYW4gYXBwbGljYXRpb24gY3JlYXRlcyBhbgo+QUFBX0FWUF9MSVNUIHRoYXQg aXMgbm90IGF0dGFjaGVkIHRvIGFuIEFBQU1lc3NhZ2Ugc3RydWN0dXJlIChhbHNvCj5rbm93biBh cyBhbiBvcnBoYW5lZCBBQUFfQVZQX0xJU1QpLiBBbGwgb2YgdGhlIG5lY2Vzc2FyeSBBVlBzIHdp dGhpbgo+dGhlIEdyb3VwIGFyZSBhZGRlZCB0byB0aGUgb3JwaGFuZWQgQUFBX0FWUF9MSVNUIHVz aW5nIHRoZSBleGlzdGluZwo+bGlzdCBtYW5pcHVsYXRpb24gZnVuY3Rpb25zLiBMYXN0bHksIHRo ZSBncm91cGVkIEFWUCBpcyBhZGRlZCB0byB0aGUKPkFBQU1lc3NhZ2Ugc3RydWN0dXJlLgo+Cj5U aGUgZm9sbG93aW5nIGlzIGFuIGV4YW1wbGUgdGhhdCBhZGRzIGEgUHJveHktU3RhdGUgR3JvdXBl ZCBBVlAgdG8KPmFuIGV4aXN0aW5nIEFBQU1lc3NhZ2Ugc3RydWN0dXJlLgo+Cj5hZGRQcm94eVN0 YXRlKEFBQU1lc3NhZ2UgKm1lc3NhZ2UsIGlwYWRkcl90ICpvdXJBZGRyZXNzLAo+ICAgIHZvaWQg KnN0YXRlLCBzaXplX3Qgc3RhdGVMZW4pCgpNaXNzaW5nIHJldHVybiB0eXBlLgoKPnsKPiAgICAg ICAgQUFBX0FWUF9MSVNUICphdnBMaXN0ID0gTlVMTDsKPgo+ICAgICAgICBpZiAoQUFBQ3JlYXRl QW5kQWRkQVZQVG9MaXN0KCZhdnBMaXN0LAo+ICAgICAgICAgICAgRElBTV9BVlBfUFJPWFlfQURE UkVTUywgQUFBX0FWUElfRkxBR19OT05FLAo+ICAgICAgICAgICAgTk9fVkVORE9SX0lELCAoY2hh ciAqKSBvdXJBZGRyZXNzLAo+ICAgICAgICAgICAgc2l6ZW9mIChpcGFkZHJfdCkpKSB7Cj4gICAg ICAgICAgICAgICAgcmV0dXJuIChBQUFfRVJSX0ZBSUxVUkUpOwo+ICAgICAgICB9Cj4gICAgICAg IGlmIChBQUFDcmVhdGVBbmRBZGRBVlBUb0xpc3QoJmF2cExpc3QsCj4gICAgICAgICAgICBESUFN X0FWUF9QUk9YWV9JTkZPLCBBQUFfQVZQSV9GTEFHX05PTkUsCj4gICAgICAgICAgICBOT19WRU5E T1JfSUQsIHN0YXRlLCBzdGF0ZUxlbikpIHsKPiAgICAgICAgICAgICAgICByZXR1cm4gKEFBQV9F UlJfRkFJTFVSRSk7Cj4gICAgICAgIH0KPiAgICAgICAgaWYgKEFBQUNyZWF0ZUFuZEFkZEFWUFRv TGlzdCgmbWVzc2FnZS0+YXZwTGlzdCwKPiAgICAgICAgICAgIERJQU1fQVZQX1BST1hZX1NUQVRF LCBBQUFfQVZQSV9GTEFHX05PTkUsCj4gICAgICAgICAgICBOT19WRU5ET1JfSUQsIChjaGFyICop YXZwTGlzdCwKPiAgICAgICAgICAgIEFBQV9BVlBfR1JPVVBFRF9MRU5HVEgpKSB7Cj4gICAgICAg ICAgICAgICAgcmV0dXJuIChBQUFfRVJSX0ZBSUxVUkUpOwo+ICAgICAgICB9Cj4KPiAgICAgICAg cmV0dXJuIChBQUFfRVJSX1NVQ0NFU1MpOwo+fQoKV2hhdCBpcyBBQUFfQVZQX0dST1VQRURfTEVO R1RIPyBUaGUgbGVuZ3RoIHVzdWFsbHkgZGVwZW5kcyBvbiB0aGUKZ3JvdXAsIHlvdSBjYW5ub3Qg dXNlIGFueSBzdGF0aWMgbnVtYmVyLiBOb3Qgd2hlbiBpdCBpcyByZWNvcmRlZAphcyBhIEFBQV9B VlBUWVBFX1NUUklORy4KCldoYXQgaXMgQUFBX0FWUElfRkxBR19OT05FPyBJdCBpcyB1bmRvY3Vt ZW50ZWQuCgpXaGF0IGlzIERJQU1fQVZQX1BST1hZX1NUQVRFPyBBbHNvIHVuZG9jdW1lbnRlZC4K CkFuZCBOT19WRU5ET1JfSUQ/IFByb2JhYmx5IHNob3VsZCBiZSBBQUFfTk9fVkVORE9SX0lELgoK SnVzdCB0byBwdXQgdGhhdCBpbnRvIGNvbnRyYXN0LCB0aGlzIGlzIGxpYmNpcmN1bSAoYWR2ZXJ0 aXNlZCBhcwpiZWluZyBjbGVhbmVyIGFuZCB1c2luZyBsZXNzIHNjcmVhbWluZyBsZXR0ZXJzKToK CmJvb2wgYWRkX3Byb3h5X3N0YXRlKHN0cnVjdCBhM19wYWNrZXQgKm1zZywgY29uc3QgaXBhZGRy X3QgKm91cmFkZHIsCiAgICBjb25zdCB2b2lkICpzdGF0ZSwgdW5zaWduZWQgaW50IHN0YXRlbGVu KQp7CglzdHJ1Y3QgYTNfYXZwICphdnAgPQoJCWEzX3BrdF9hZGRfYXZwKG1zZywgIlByb3h5LUlu Zm8iLCBOVUxMLCAwKTsKCWlmIChhdnAgPT0gTlVMTCkKCQlyZXR1cm4gZmFsc2U7CgoJaWYgKGEz X3BrdF9hZGRfYXZwKGF2cCwgIlByb3h5LUhvc3QiLCBvdXJhZGRyZXNzLCBzaXplb2YoaXBhZGRy X3QpKSA9PSBOVUxMKQoJCXJldHVybiBmYWxzZTsKCWlmIChhM19wa3RfYWRkX2F2cChhdnAsICJQ cm94eS1TdGF0ZSIsIHN0YXRlLCBzdGF0ZWxlbikgPT0gTlVMTCkKCQlyZXR1cm4gZmFsc2U7Cgly ZXR1cm4gdHJ1ZTsKfQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpEaU1FIG1haWxpbmcgbGlzdApEaU1FQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQo= From dime-bounces@ietf.org Sun Nov 2 10:38:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CFE3A6A21; Sun, 2 Nov 2008 10:38:53 -0800 (PST) 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 861633A6842 for ; Sun, 2 Nov 2008 10:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=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 r+6qgf4EsnSi for ; Sun, 2 Nov 2008 10:38:51 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id B3AC23A680C for ; Sun, 2 Nov 2008 10:38:51 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 1663F188501F4; Sun, 2 Nov 2008 19:38:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 091B61C0788CE; Sun, 2 Nov 2008 19:38:47 +0100 (CET) Date: Sun, 2 Nov 2008 19:38:46 +0100 (CET) From: Jan Engelhardt To: Victor Fajardo In-Reply-To: <490DB0F7.7050308@tari.toshiba.com> Message-ID: References: <48C92258.6050008@gmx.net> <490DB0F7.7050308@tari.toshiba.com> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Sunday 2008-11-02 14:53, Victor Fajardo wrote: > Hi Hannes, > > I've incorporated majority of the editorial items you mentioned below. Others > I've commented below. The changes here should be incorporated into > draft*-13.txt So let me chime in here then, because I have noticed a number of oddities too. >> s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] >> and SCTP [RFC2960] transport protocols./The base Diameter protocol is >> run on port 3868 of both TCP [RFC793] and SCTP [RFC2960]. >> >> Delete "Future versions of this specification MAY >> mandate that clients support SCTP." >> >> I also do not understand why we require that agents and servers must >> support SCTP. That does not sound realistic if I consider our interop >> testing experience. > > It seems expected that during the interop most folks would support TCP > since that would be the easiest/most natural to implement first. I > could not remember if there was consensus for requiring SCTP for > servers was impractical. The only problem I see here is operating systems lacking support for SCTP right now. Windows might fall under that. To my knowledge, Solaris (10) does too somewhat -- because it does not seem to autoload the module like a Linux kernel would do. Mac OS X I do not know, but if it has, autoload is not happening either. And then of course every Linux kernel installation which has SCTP compiled out. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 2 10:43:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003A63A680C; Sun, 2 Nov 2008 10:43:13 -0800 (PST) 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 4EA8E3A680C for ; Sun, 2 Nov 2008 10:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=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 w8q39SOvD+YX for ; Sun, 2 Nov 2008 10:43:10 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 8368A3A67AB for ; Sun, 2 Nov 2008 10:43:10 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 8FBB7188501F4; Sun, 2 Nov 2008 19:43:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 84E281C0788CE; Sun, 2 Nov 2008 19:43:07 +0100 (CET) Date: Sun, 2 Nov 2008 19:43:07 +0100 (CET) From: Jan Engelhardt To: Hannes Tschofenig In-Reply-To: <00fe01c93c55$960ed150$04ffa8c0@nsnintra.net> Message-ID: References: <00fe01c93c55$960ed150$04ffa8c0@nsnintra.net> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Saturday 2008-11-01 20:11, Hannes Tschofenig wrote: > >The terminology is a bit challenging, I know. > >We cannot change the term "Mandatory AVP" anymore since everyone is pretty >much used to it already. > >For the required AVP we still have the chance to pick whatever we want but >it is important to have a different name for the two as they are very >different concepts. > >So, what name would you suggest instead of "Required AVP"? Too hard when Mandatory is fixated. Something along the lines of "Required-Presence AVP" maybe? (sounds odd though.) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 2 14:08:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C9D3A6A4C; Sun, 2 Nov 2008 14:08:45 -0800 (PST) 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 07A453A6A32 for ; Sun, 2 Nov 2008 14:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.082, 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 70EmIHmR7Gdk for ; Sun, 2 Nov 2008 14:08:44 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 269C73A6930 for ; Sun, 2 Nov 2008 14:08:44 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id aHeq1a0020lTkoCA6N7PNR; Sun, 02 Nov 2008 22:07:44 +0000 Received: from gwzPC ([67.170.96.151]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id aN721a00Y3FxqkK8QN78c3; Sun, 02 Nov 2008 22:07:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=tAngdaBMeSu-BETXKv8A:9 a=vz21Z7RmiptOuWINO4WaAsn_mSQA:4 a=bAv3psboLzYA:10 a=Mz_smNXqyOQA:10 From: "Glen Zorn" To: "'Jan Engelhardt'" References: In-Reply-To: Date: Sun, 2 Nov 2008 14:06:45 -0800 Message-ID: <006a01c93d37$4c562760$e5027620$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ack9GZiSY9+wzAIITn2kIuWmuxHNngAHLxJA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jan Engelhardt [mailto://jengelh@medozas.de] writes: ... > > 2. For a server, asynchronous-ity may make sense, but for clients, > this is less of a case. The fact that our course's implementation > fares perfectly well with synchronous exchange. Especially since I > do not see what a client is supposed to asynchronously do after > having sent a packet and waiting for a reply. Diameter IS NOT a client/server protocol; the terms are used only as a convenience. If you are writing code that assumes that it _is_ a client-server protocol, then a) you're going to a lot more trouble than you need to & b) your design is by definition broken since it is based upon invalid assumptions (irrespective of whether it seems to "work" in certain limited situations). ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 2 22:34:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4385B3A6905; Sun, 2 Nov 2008 22:34:55 -0800 (PST) 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 1C6723A68C6 for ; Sun, 2 Nov 2008 22:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=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 Mg40B2Llnhoj for ; Sun, 2 Nov 2008 22:34:53 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 5247A3A68B0 for ; Sun, 2 Nov 2008 22:34:52 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 10D6018097884; Mon, 3 Nov 2008 07:34:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 028071C05DF76; Mon, 3 Nov 2008 07:34:48 +0100 (CET) Date: Mon, 3 Nov 2008 07:34:48 +0100 (CET) From: Jan Engelhardt To: Glen Zorn In-Reply-To: <006a01c93d37$4c562760$e5027620$@net> Message-ID: References: <006a01c93d37$4c562760$e5027620$@net> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Sunday 2008-11-02 23:06, Glen Zorn wrote: >> >> 2. For a server, asynchronous-ity may make sense, but for clients, >> this is less of a case. The fact that our course's implementation >> fares perfectly well with synchronous exchange. Especially since I >> do not see what a client is supposed to asynchronously do after >> having sent a packet and waiting for a reply. > >Diameter IS NOT a client/server protocol; the terms are used only as >a convenience. So what IS it? Some freeform packet flooder like netbios broadcasts? What I want to point out here is that with CBs, it seems impossible to match an incoming message to its previously corresponding message, at least in cases like AA. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 3 00:45:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3C528C0DB; Mon, 3 Nov 2008 00:45:05 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 23B743A6903; Mon, 3 Nov 2008 00:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103084502.23B743A6903@core3.amsl.com> Date: Mon, 3 Nov 2008 00:45:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-07.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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 : Quality of Service Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-07.txt Pages : 20 Date : 2008-11-03 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-07.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-qos-parameters-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03003706.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Nov 3 01:35:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0C23A69EB; Mon, 3 Nov 2008 01:35:12 -0800 (PST) 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 62C6E3A69EB for ; Mon, 3 Nov 2008 01:35:11 -0800 (PST) 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 CWs71zaIu2nO for ; Mon, 3 Nov 2008 01:35:10 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 689443A695B for ; Mon, 3 Nov 2008 01:35:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3998D90021 for ; Mon, 3 Nov 2008 04:35:05 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07987-04 for ; Mon, 3 Nov 2008 04:35:04 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 3 Nov 2008 04:35:04 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 04:35:04 -0500 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 15:05:00 +0530 From: Sarkar Biplab To: dime Date: Mon, 03 Nov 2008 15:04:59 +0530 Message-Id: <1225704899.6186.17.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1 X-OriginalArrivalTime: 03 Nov 2008 09:35:00.0256 (UTC) FILETIME=[71094A00:01C93D97] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] RFC3858: Dimeter Election Process X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1993205923==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1993205923== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aBDLdJsatISeRQUhnydO" --=-aBDLdJsatISeRQUhnydO Content-Type: multipart/alternative; boundary="=-O2wFT3dK246t1b4ySoYv" --=-O2wFT3dK246t1b4ySoYv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello All, Can someone please clearity the following paragraph from the RFC3588-bis-13? =3D=3D=3D=3D=3D=3D=3D=3D=3D Internet-Draft Diameter Base Protocol November 2008 5.6.4. The Election Process The election is performed on the responder. The responder compares the Origin-Host received in the CER with its own Origin-Host as two streams of octets. If the local Origin-Host lexicographically succeeds the received Origin-Host a Win-Election event is issued locally. Diameter identities are in ASCII form therefore the lexical comparison is consistent with DNS case insensitivity where octets that fall in the ASCII range 'a' through 'z' MUST compare equally to their upper-case counterparts between 'A' and 'Z'. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Name (IDNs). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I believe we are dealing with a "Case-insensitve lexicographically" comparison here. How does it deal with un-equal similar names? e.g originHost and OriginHostName?=20 Can someone please throw some light on this? Thanks & Regards Biplab --=-O2wFT3dK246t1b4ySoYv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hello All,

Can someone please clearity the following paragraph from the  RFC3588-= bis-13?


=3D=3D=3D=3D=3D=3D=3D=3D=3D
Internet-Draft           = Diameter Base Protocol         = ;   November 2008


5.6.4.  The Election Process

   The election is performed on the responder.  The responde= r compares
   the Origin-Host received in the CER with its own Origin-Host a= s two
   streams of octets.  If the local Origin-Host lexicographi= cally
   succeeds the received Origin-Host a Win-Election event is issu= ed
   locally.  Diameter identities are in ASCII form therefore= the lexical
   comparison is consistent with DNS case insensitivity where oct= ets
   that fall in the ASCII range 'a' through 'z' MUST compare equa= lly to
   their upper-case counterparts between 'A' and 'Z'.  See A= ppendix D
   for interactions between the Diameter protocol and Internation= alized
   Domain Name (IDNs).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I believe we are dealing with a "Case-insensitve lexicographically&quo= t; comparison here.

How does it deal with un-equal similar names?
e.g  originHost  and OriginHostName?

Can someone please throw some light on this?

Thanks & Regards
Biplab --=-O2wFT3dK246t1b4ySoYv-- --=-aBDLdJsatISeRQUhnydO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJDsXD3rQBTW1UPu4RAo+GAJ4lE8w5bSuEBc+3rKceR59agqk28QCePVnX ScvK3dUVVchYFG0CiUr69Dc= =Ya8i -----END PGP SIGNATURE----- --=-aBDLdJsatISeRQUhnydO-- --===============1993205923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1993205923==-- From dime-bounces@ietf.org Mon Nov 3 01:51:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5493A6B5A; Mon, 3 Nov 2008 01:51:40 -0800 (PST) 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 BDA143A68A5 for ; Mon, 3 Nov 2008 01:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_93=0.6] 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 XYes0RpB+1rI for ; Mon, 3 Nov 2008 01:51:37 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 882033A6B72 for ; Mon, 3 Nov 2008 01:51:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,535,1220241600"; d="scan'208";a="149670385" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 03 Nov 2008 04:51:03 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Nov 2008 04:51:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Nov 2008 10:51:01 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] diameter-api draft comparison Thread-Index: Ack9GZYeHsBZ99DySmevckTKPABasQAfzTqw References: From: "Romascanu, Dan (Dan)" To: "Jan Engelhardt" Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SmFuLAoKVGhhbmsgeW91IGZvciB5b3VyIGlucHV0LiBGWUksIEkgYW0gdGhlIGNvLWFyZWEgZGly ZWN0b3Igb2YgdGhlIE9QUyBhcmVhIHJlc3BvbnNpYmxlIGZvciB0aGUgRElNRSBXRywgYW5kIG5v dCBhbiBlZGl0b3Igb2YgdGhpcyBkb2N1bWVudC4gRnJhbmtseSBpdCB3b3VsZCBoYXZlIGJlZW4g YmV0dGVyIGZvciBzdWNoIGRldGFpbGVkIHJldmlldyBsZXZlbCBhbmQgY29tbWVudHMgdG8gYmUg c3VibWl0dGVkIGVhcmxpZXIgaW4gdGhlIHByb2Nlc3MgYW5kIG5vdCB0aHJlZSBtb250aHMgYWZ0 ZXIgdGhlIElFVEYgTGFzdCBDYWxsLCBidXQgd2Ugc2hhbGwgbm90IGJlIHRvbyBmb3JtYWwgaGVy ZS4gSSB3aWxsIG5vdCBzdWJtaXQgdGhpcyBkb2N1bWVudCB0byB0aGUgSUVTRyByZXZpZXcgeWV0 IGFuZCB3aWxsIHByb3ZpZGUgdGhlIGRvY3VtZW50IGVkaXRvcnMgYW5kIHRoZSByZXN0IG9mIHRo ZSB3b3JraW5nIGdyb3VwIHRoZSBvcHBvcnR1bml0eSB0byByZXZpZXcgYW5kIGRpc2N1c3MgeW91 ciBjb21tZW50cy4gCgpEYW4KCiAgCgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJv bTogamVuZ2VsaEBzb3ZlcmVpZ24uY29tcHV0ZXJnbWJoLmRlIAo+IFttYWlsdG86amVuZ2VsaEBz b3ZlcmVpZ24uY29tcHV0ZXJnbWJoLmRlXSBPbiBCZWhhbGYgT2YgSmFuIEVuZ2VsaGFyZHQKPiBT ZW50OiBTdW5kYXksIE5vdmVtYmVyIDAyLCAyMDA4IDg6MzQgUE0KPiBUbzogUm9tYXNjYW51LCBE YW4gKERhbikKPiBDYzogZGF2ZUBmcmFzY29uZS5jb207IGRpbWVAaWV0Zi5vcmcKPiBTdWJqZWN0 OiBSRTogW0RpbWVdIGRpYW1ldGVyLWFwaSBkcmFmdCBjb21wYXJpc29uCj4gCj4gCj4gT24gU3Vu ZGF5IDIwMDgtMTEtMDIgMTI6MTUsIFJvbWFzY2FudSwgRGFuIChEYW4pIHdyb3RlOgo+IAo+ID5J dCBjZXJ0YWlubHkgZG9lcyBub3Qgc3VmZmljZXMgdG8ganVzdCBzYXkgJ0kgYW0gaW4gCj4gZGlz YWdyZWVtZW50JyAtIHlvdSAKPiA+bmVlZCB0byBwcm92aWRlIGRldGFpbGVkIGNvbW1lbnRzIGFu ZCBhcmd1bWVudHMgYWJvdXQgd2hhdCBhc3BlY3RzIAo+ID4odGVjaG5pY2FsIG9yIGVkaXRvcmlh bCkgeW91IGZpbmQgYXMgcHJvYmxlbWF0aWMuCj4gCj4gRm9sbG93aW5nIGlzIHF1b3RpbmcgdGhl IGFwaS0wNyB0ZXh0IGRvY3VtZW50Lgo+IAo+ID5UaGUgY2FsbGJhY2tzIGltcGxlbWVudCB0aGUg YXBwbGljYXRpb24gcHJvZmlsZSBwcm9jZXNzaW5nIAo+IGZvciBpbmNvbWluZyAKPiA+bWVzc2Fn ZXMuICBGb3Igb3V0Z29pbmcgY2FsbHMsIHRoZSBDIEFQSSBwcm92aWRlcyBhbiBhc3luY2hyb25v dXMgCj4gPm1vZGVsLCBsZWF2aW5nIHByb2Nlc3Npbmcgb2YgdGhlIHJldHVybiBtZXNzYWdlIHRv IHRoZSBjYWxsYmFja3MuCj4gCj4gVGhpcyBkZWNpc2lvbiBoYXMgKnJlYWxseSogcHV6emxlZCBt ZS4gSXQgc2VlbXMgbGlrZSB5b3UgYXJlIAo+IHRyeWluZyB0byBwdXQgaW4gc2VydmVyLXNwZWNp ZmljIHN0dWZmIGludG8gdGhlIGJhc2UgbGlicmFyeSwgCj4gYW5kIHRoaXMgYXR0ZW1wdCBsb29r ZWQgd3JvbmcgdG8gbWUuIFdlbGwgYWZ0ZXIgcmVyZWFkaW5nLCAKPiBhc3luY2hyb25vdXMgcHJv Y2Vzc2luZyBzZWVtcyB0byBoYXZlIGEgcGxhY2UuIEJ1dCBJIHN0aWxsIAo+IHRoaW5rIGl0IGlz IG5vdCB0aGF0IGFwcHJvcHJpYXRlLgo+IAo+IDEuIFlvdSBoYXZlIHRvIGNyZWF0ZSBhIGZ1bmN0 aW9uIGZvciBldmVyeSBjb21tYW5kIHlvdSBhcmUgCj4gaW50ZXJlc3RlZCBpbi4KPiAKPiAyLiBG b3IgYSBzZXJ2ZXIsIGFzeW5jaHJvbm91cy1pdHkgbWF5IG1ha2Ugc2Vuc2UsIGJ1dCBmb3IgCj4g Y2xpZW50cywgdGhpcyBpcyBsZXNzIG9mIGEgY2FzZS4gVGhlIGZhY3QgdGhhdCBvdXIgY291cnNl J3MgCj4gaW1wbGVtZW50YXRpb24gZmFyZXMgcGVyZmVjdGx5IHdlbGwgd2l0aCBzeW5jaHJvbm91 cyAKPiBleGNoYW5nZS4gRXNwZWNpYWxseSBzaW5jZSBJIGRvIG5vdCBzZWUgd2hhdCBhIGNsaWVu dCBpcyAKPiBzdXBwb3NlZCB0byBhc3luY2hyb25vdXNseSBkbyBhZnRlciBoYXZpbmcgc2VudCBh IHBhY2tldCBhbmQgCj4gd2FpdGluZyBmb3IgYSByZXBseS4KPiAKPiAzLiBDYWxsYmFja3MgYXMg dXNlZCBpbiB0aGUgZHJhZnQga2lsbCBhbnkgInRocmVhZCBzYWZldHkgdmFyaWV0eSIuCj4gQ29u c2lkZXI6Cj4gCj4gCWJhcigpIHsKPiAJCXVucmVnaXN0ZXJfY2IoY29tbWFuZD1mb28pCj4gCQlk b19zb21ldGhpbmcuLgo+IAl9Cj4gCj4gCS8qIHNlZSB0byBpdCB0aGF0IHdlIGdldCBub3RpZmll ZCBvZiBmb28gKi8KPiAJcmVnaXN0ZXJfY2IoY29tbWFuZD1mb28sIHB0cj1iYXIpOwo+IAlzZW5k X3BhY2tldCgpOwo+IAo+IAkKPiBUaGUgbW9tZW50IHlvdSByZWdpc3RlciBhIENCIG1lYW5zIHRo YXQgdGhlIENCIHdpbGwgZ2V0IAo+IHRyaWdnZXJlZCB3aGVuZXZlciBhIHBhY2tldCBoYXBwZW5z IHRvIGNvbWUgaW4uIFRoaXMgaXMgYmFkIAo+IHdoZW4geW91IG9ubHkgd2FudCB0byBwcm9jZXNz IGEgImZvbyIgZm9yIGV4YWN0bHkgb25lIHNwZWNpZmljIHBhY2tldC4KPiAoTm90aW5nIHRoYXQg dGhlIGFib3ZlIHBzZXVkb2NvZGUgc25pcHBldCBpcyB0b3RhbGx5IE1ULXJhY2UgdW5zYWZlLikK PiAKPiA+Rm9yIHRoZSBtb3N0IHBhcnQsIHRoZSBBUEkgaGlkZXMgdGhlIGRldGFpbHMgb2YgZXN0 YWJsaXNoaW5nIHBlZXJpbmcgCj4gPmFuZCByZWRpcmVjdCBjb25uZWN0aW9ucywgcGFyc2luZyBh bmQgY3JlYXRpbmcgRGlhbWV0ZXIgCj4gbWVzc2FnZXMsIGFuZCAKPiA+b3RoZXIgd29yayBuZWNl c3NhcnkgdG8gc2V0IHVwIGFuZCBtYWludGFpbiBhIHJlZGlyZWN0IG9yIHBlZXJpbmcgCj4gPnNl c3Npb24uICBUaGUgYXBwbGljYXRpb24gcHJvZmlsZSBjb2RlIG5lZWQgb25seSBiZSBjb25jZXJu ZWQgd2l0aCAKPiA+cHJvY2Vzc2luZyBvZiB0aGUgQVZQcyBkZWZpbmVkIGluIHRoZSBhcHBsaWNh dGlvbiBwcm9maWxlLgo+IAo+IEkgd291bGQgcmF0aGVyIHdhbnQgdG8gaGF2ZSBjb250cm9sIG92 ZXIgY29ubmVjdGlvbiAKPiBlc3RhYmxpc2htZW50LCBpLmUuoHdoZW4gaXQgaGFwcGVucy4gVGhp cyBzZWVtcyB0byBiZSBhYnNlbnQgCj4gZnJvbSB0aGlzIGRyYWZ0Lgo+IAo+ID4yLjMuICBTdHJp bmcgRm9ybWF0Cj4gPgo+ID5DIEFQSSBjbGllbnRzIGFyZSByZXF1aXJlZCB0byBmb3JtYXQgc3Ry aW5ncyBhcyBVVEYtOCBpZiB0aGUgc3RyaW5nIAo+ID5jb250YWlucyAxNiBiaXQgY2hhcmFjdGVy cy4gIFNpbmNlIHRoZSBBU0NJSSBjaGFyYWN0ZXJzIGFuZCB0aGUKPiA+VVRGLTggOCBiaXQgY2hh cmFjdGVycyBoYXZlIHRoZSBzYW1lIGNvZGVzLCBBU0NJSSBjYW4gYmUgdXNlZCBmb3IKPiA+VVRG LTggaWYgbm8gd2lkZSBjaGFyYWN0ZXJzIGFyZSBpbiB0aGUgc3RyaW5nLiAgQWxsIHN0cmluZ3Mg cGFzc2VkIAo+ID50aHJvdWdoIHRoZSBDIEFQSSBhcmUgc3RhbmRhcmQgbnVsbC10ZXJtaW5hdGVk IEMgc3RyaW5ncy4KPiA+UHJvY2Vzc2luZyB0byByZW1vdmUgdGhlIG51bGwgdGVybWluYXRvciBm b3IgdHJhbnNtaXNzaW9uIG9uIAo+IHRoZSB3aXJlIAo+ID5pcyBkb25lIGJ5IHRoZSBsaWJyYXJ5 Lgo+IAo+IFRoaXMgc291bmRzIGJvZ3VzLiBDIHN0cmluZ3MgKGluIGNvbW1vbiBzeXN0ZW1zIGF0 IGxlYXN0KSBuZXZlciBhcmUKPiAxNiBiaXQgKGJ1dCBtb3JlIGxpa2UgQ0hBUl9CSVQ9OCkuIFNv IGlmIG15IHN0cmluZyBpcyBpbiAKPiBJU08tODg1OS0xNSBlbmNvZGluZywgSSBkbyBub3QgaGF2 ZSBhbnkgMTYtYml0IGNoYXJhY3RlcnMgaW4gCj4gaXQsIGFuZCBwZXIgdGhlIGRyYWZ0LCBJIGFt IG5vdCByZXF1aXJlZCB0byBmb3JtYXQgYXMgVVRGLTguoJcgU2VlPwo+IAo+ID4zLjEuICBDb25z dGFudCBUeXBlcwo+ID4KPiA+My4xLjEuICBJUCBBZGRyZXNzIGFuZCBQb3J0Cj4gPgo+ID4gICB0 eXBlZGVmIHN0cnVjdCBzb2NrYWRkcl9zdG9yYWdlIEFBQV9JUF9BRERSOwo+ID4KPiA+ICAgQUFB X0lQX0FERFIgcHJvdmlkZXMgYSB3YXkgb2YgcmVmZXJyaW5nIHRvIGFuIElQdjQgYWRkcmVzcywg SVB2Ngo+ID4gICBhZGRyZXNzLCBhbmQgSVAgcG9ydC4gIFRoZSBkZWZhdWx0IGltcGxlbWVudGF0 aW9uIChzaG93biBoZXJlKSBpcwo+ID4gICBkZWZpbmVkIGluIHRoZSBCYXNpYyBTb2NrZXQgSW50 ZXJmYWNlIEV4dGVuc2lvbnMgZm9yIElQdjYgCj4gW1JGQzM0OTNdCj4gCj4gVHlwZWRlZnMgYXJl IElNSE8gcG9pbnRsZXNzIGZvciBzaW1wbGUgdHlwZXMgKHdoZW4gdGhleSBkbyAKPiBub3QgY29u dmV5IGEgc3BlY2lhbCBwdXJwb3NlIGxpa2UgdGhlIExpbnV4IGtlcm5lbCdzIHBtZF90KSwgCj4g YW5kIHN0cnVjdHMuIEl0IGFsc28gY3JlYXRlcyB1bm5lY2Vzc2FyeSBjb21waWxhdGlvbiBkZWxh eXMuCj4gCj4gU2VlIGh0dHA6Ly9sa21sLm9yZy9sa21sLzIwMDYvMTEvMjEvMzQKPiAKPiAoRnVu Y3Rpb24gcG9pbnRlcnMgYXJlIG5vdCBjb25zaWRlcmVkICJzaW1wbGUiLikKPiAKPiBKdXN0IHdy aXRlICJzdHJ1Y3Qgc29ja2FkZHJfc3RvcmFnZSIuCj4gCj4gSWYgdGhlIG5hbWUgc2hvdWxkIGJl IEFBQV9JUF9BRERSLCBlaXRoZXIgdXNlICJzdHJ1Y3QgCj4gQUFBX0lQX0FERFIiIG9yIHdyaXRl Cj4gQysrL0phdmEgaW5zdGVhZC4gRG8gbm90IHRyeSB0byBiZSBzbWFydCBpbiBoaWRpbmcgdHlw ZXMgLSBDIGlzIG5vdCAKPiBDKyttZWFudCBmb3IKPiB0aGlzLiBKdXN0IGJlY2F1c2Ugb25lIGlz IGFsbG93ZWQgdG8gZG8gd2hhdGV2ZXIgc3RyYW5nZSAKPiB0aGluZ3MgY2FuIGJlIGRvbmUgd2l0 aCBDIGRvZXMgbm90IG1lYW4gaXQgc2hvdWxkIGJlIGRvbmUuCj4gCj4gKFRoZSBBQUEgcHJlZml4 IGlzLi4uIG1oIC0gY291bGQgbm90IGhhdmUgY29tZSB1cCB3aXRoIHNvbWV0aGluZwo+IGJldHRl cj8pCj4gCj4gQWxzbyB0aGlzIGNhbWVsLWNhc2UgaXMgc29tZXRoaW5nIHlvdSB3b3VsZCBzZWUg aW4gQysrLSwgCj4gSmF2YS0gb3IgTWljcm9zb2Z0LWNlbnRyaWMgc3R1ZmYuIEFsbCB0aGUgZ29v ZCBvbmVzLCBtYW55IGEgCj4gTGludXgsIEJTRCBhbmQgU29sYXJpcyBjb2RlIGRvZXMgd2l0aG91 dCB0aGF0LiBXaGVuIHdlIAo+IGVuY291bnRlciBBQUFfQVZQLCBJIGFsbW9zdCB0aGlua2luZyBJ IGdldCBzY3JlYW1lZCBhdDsgaXQgaXMgCj4gdXBwZXIgY2FzZSBsZXR0ZXJzIHRocm91Z2hvdXSg lyB2ZXJ5IHJlbWluaXNjaWVudCBvZiBsZWdhbCAKPiBkaXNjbGFpbWVycyBhbmQgPHdpbmRvd3Mu aD4gc291cmNlLgo+IAo+IFRvZ2V0aGVyIHdpdGggdGhlIHR5cGVkZWZzIHRoaXMgaXMgdGhlIG1h aW4gcmVhc29uIEkgd291bGQgCj4gbmV2ZXIgd2FudCB0byB1c2UgdGhpcyBBUEkuIENvZGUgbGlr ZSB0aGF0IGp1c3QgYWluJ3QgcmVhZGFibGUgZm9yIG1lLgo+IAo+ID4zLjEuNS4gIEF0dHJpYnV0 ZS9WYWx1ZSBQYWlyIENvZGUKPiA+Cj4gPiAgIHR5cGVkZWYgdWludDMyX3QgQUFBX0FWUENvZGU7 Cj4gCj4gV2hhdCBpcyB0aGUgcG9pbnQgaGVyZT8gSWYgdGhlIHR5cGVkZWYgaXMgdXNlZCBiZWNh dXNlIHlvdSAKPiB0aGluayB5b3UgY291bGQgdHJhbnNwYXJlbnRseSBjaGFuZ2UgdGhlIHVuZGVy bHlpbmcgCj4gaW1wbGVtZW50YXRpb24sIHRoZW4gdGhpcyBpcyBhIHdyb25nIGJlbGllZi4gVGhl IEFCSSB3b3VsZCAKPiBjaGFuZ2Wgd2hlbiBtb3ZpbmcgdG8gZS5nLqB1aW50NjRfdCwgYW5kIHRo ZSByZXF1aXJlZCBhY2Nlc3MgCj4gc3ludGF4IGNoYW5nZXMgd2hlbiBtb3ZpbmcgdG8gZS5nLqBh IHN0cnVjdC4KPiAKPiBUaGUgbmFtaW5nIHNjaGVtZSBpcyBpbmNvbnNpc3RlbnQgYXQgYmVzdC4g VW5kZXJzY29yZSBnb2VzIAo+IGJldHdlZW4gQUFBIGFuZCBBVlAgKGFsc28gaW4gb3RoZXIgcGxh Y2VzIGxpa2UgZW51bSAKPiBBQUFfQVZQRmxhZyksIGJ1dCBub3QgZm9yIEFBQV9TZXJ2ZXI/Cj4g Cj4gPjMuMS43LiAgVmFsdWUgVHlwZSBJZGVudGlmaWVyCj4gPgo+ID4gICB0eXBlZGVmIHZvaWQg QUFBU2VydmVyOwo+ID4KPiA+ICAgQUFBU2VydmVyIGlzIGFuIGlkZW50aWZpZXIgZm9yIGEgcGFy dGljdWxhciBzZXJ2aW5nIHBlZXIuIAo+ICBJdCBpcyB1c2VkCj4gPiAgIGluIHRoZSBzZXJ2ZXIg YWNjZXNzIGZ1bmN0aW9ucy4KPiAKPiBTdWNoIGEgdHlwZWRlZiBpcyAqc28qIG1pc2xlYWRpbmcu IFNvbWVvbmUgd2hvIHRyaWVzIHRvIGRlY2xhcmUKPiAKPiAJQUFBU2VydmVyIGZvbzsKPiAKPiB3 aWxsIG9ubHkgZ2V0ICJzdG9yYWdlIHNpemUgb2YgZm9vIGlzIG5vdCBrbm93biIgY29tcGlsZXIg ZXJyb3IuCj4gRXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGlzOgo+IAo+IAlBQUFTZXJ2ZXIgbXlf ZnVuY3Rpb24oY2hhciAqZG9fc29tZXRoaW5nKQo+IAl7Cj4gCQkvKiByZXR1cm4gc29tZXRoaW5n IG9yIG5vdD8gKi8KPiAJCS8qIGl0J3MganVzdCBub3Qgb2J2aW91cyB3aGV0aGVyIGl0IGlzIHZv aWQgKi8KPiAJfQo+IAo+IEJlY2F1c2UgSSB3b3VsZCByYXRoZXIgYXNzdW1lIGl0IHdhcyB0eXBl ZGVmZWQgdG8gYSBzdHJ1Y3Qgb3IgCj4gc29tZSBpbnRlZ3JhbCB0eXBlLgo+IAo+ID4zLjEuMTEu ICBBcHBsaWNhdGlvbiBJZGVudGlmaWVyCj4gPgo+ID4gICB0eXBlZGVmIHZvaWQqIEFBQUFwcGxp Y2F0aW9uSWQ7Cj4gCj4gUG9pbnRlcnMgaW4gdHlwZWRlZnMgYXJlIHNvIGZyb3duZWQgdXBvbi4g TWljcm9zb2Z0IGRpZCB0aGF0IAo+IHdpdGggdGhlaXIgTFBDU1RSIHR5cGVkZWYgZm9yIGV4YW1w bGUuIEl0IGNvbmZ1c2VzIHRoZSBoZWxsIAo+IG91dCBvZiBldmVyeW9uZSwgc2luY2UgeW91IGRv IG5vdCBrbm93LCBieSBqdXN0IGxvb2tpbmcgYXQgCj4gdGhlIG5hbWUsIHdoZXRoZXIgaXQgaXMg YSBwb2ludGVyIG9yIG5vdCAtIGFuZCBJJ2QgcmF0aGVyIAo+IGFzc3VtZSBpdCB3YXMgdGhlIGxh dHRlciwgYW5kIGxldCdzIHNheSBJIHdhbnRlZCB0byBpbmNyZWFzZSAKPiB0aGUgaWQgYnkgb25l Ogo+IAo+IAl2b2lkIGZvbyhBQUFBLypob3cgbWFueSBBcyB3YXMgdGhhdD8qL3BwbGljYXRpb25J ZCBiYXIpCj4gCXsKPiAJCSsrYmFyOwo+IAl9Cj4gCj4gYnV0IHRoYXQgd291bGQgZG8gdGhlIHdy b25nIHRoaW5nIGluc3RlYWQgb2Ygd2hhdCBJIGludGVuZGVkLiAKPiBIZW5jZSBwbGVhc2UgZG8g bm90IHVzZSBpbmRpcmVjdGlvbnMgaW4gdHlwZWRlZnMgKHRoZSBvbmUgCj4gZXhjZXB0aW9uIGlz IGEgZnVuY3Rpb24gcG9pbnRlciB3aGVyZSB0aGlzIGlzIG5lY2Vzc2FyeSkuCj4gCj4gPjMuMS4x Mi4gIEFQSSBSZXR1cm4gQ29kZXMKPiA+Cj4gPiAgIFRoZSBmb2xsb3dpbmcgc3RhdHVzIGNvZGVz IGFyZSByZXR1cm5lZCBieSBmdW5jdGlvbnMgaW4gCj4gdGhlIEFBQSBBUEk6Cj4gPgo+ID4gICAg ICAgICAgIHR5cGVkZWYgZW51bSB7Cj4gPiAgICAgICAgICAgICAgICAgQUFBX0VSUl9OT1RfRk9V TkQgPSAgICAgICAtMiwKPiA+ICAgICAgICAgICAgICAgICBBQUFfRVJSX0ZBSUxVUkUgPSAgICAg ICAgIC0xLAo+ID4gICAgICAgICAgICAgICAgIEFBQV9FUlJfU1VDQ0VTUyA9ICAgICAgICAgIDAs Cj4gPiAgICAgICAgICAgICAgICAgQUFBX0VSUl9OT01FTSwKPiA+ICAgICAgICAgICAgICAgICBB QUFfRVJSX1BST1RPLAo+IAo+IEl0IHdvdWxkIGhhdmUgYmVlbiBwcmVmZXJhYmxlIHRvIHJldXNl IGVycm5vIGFzIG11Y2ggYXMgcG9zc2libGUuCj4gCj4gPjMuMS4xNC4gIEFWUCBEYXRhIFR5cGUg Q29kZXMKPiA+Cj4gPiAgIFRoZSBmb2xsb3dpbmcgYXJlIEFWUCBkYXRhIHR5cGUgY29kZXMuICBU aGV5IGNvcnJlc3BvbmQgCj4gZGlyZWN0bHkgdG8KPiA+ICAgdGhlIEFWUCBkYXRhIHR5cGVzIG91 dGxpbmUgaW4gdGhlIERpYW1ldGVyIHNwZWNpZmljYXRpb24gCj4gW1JGQzM1ODhdOgo+ID4KPiA+ ICAgICAgICAgICB0eXBlZGVmIGVudW0gewo+ID4gICAgICAgICAgICAgICAgQUFBX0FWUF9TVFJJ TkdfVFlQRSwKPiA+ICAgICAgICAgICAgICAgIEFBQV9BVlBfQUREUkVTU19UWVBFLAo+ID4gICAg ICAgICAgICAgICAgQUFBX0FWUF9PQ1RFVF9TVFJJTkdfVFlQRSwKPiA+ICAgICAgICAgICAgICAg IEFBQV9BVlBfSU5URUdFUjMyX1RZUEUsCj4gPiAgICAgICAgICAgICAgICBBQUFfQVZQX0lOVEVH RVI2NF9UWVBFLAo+ID4gICAgICAgICAgICAgICAgQUFBX0FWUF9VTlNJR05FRDMyX1RZUEUsCj4g PiAgICAgICAgICAgICAgICBBQUFfQVZQX1VOU0lHTkVENjRfVFlQRSwKPiA+ICAgICAgICAgICAg ICAgIEFBQV9BVlBfRkxPQVQzMl9UWVBFLAo+ID4gICAgICAgICAgICAgICAgQUFBX0FWUF9GTE9B VDY0X1RZUEUsCj4gPiAgICAgICAgICAgfSBBQUFfQVZQRGF0YVR5cGU7Cj4gCj4gV2hlcmUgaXMg dGhlIEdST1VQIGFuZCB0aGUgInVuc3BlY2lmaWVkIiB0eXBloJcgb3IgYXJlIGdyb3VwcyAKPiBv ZiB0eXBlIFNUUklORz8KPiAKPiA+My4xLjE2LiAgRG9tYWluIEludGVyY29ubmVjdGlvbiBUeXBl cwo+ID4KPiA+ICAgICAgICAgICB0eXBlZGVmIGVudW0gewo+ID4gICAgICAgICAgICAgIEFBQV9E T01BSU5fTE9DQUwsCj4gPiAgICAgICAgICAgICAgQUFBX0RPTUFJTl9QUk9YWSwKPiA+ICAgICAg ICAgICAgICBBQUFfRE9NQUlOX0JST0tFUiwKPiA+ICAgICAgICAgICAgICBBQUFfRE9NQUlOX0ZP UldBUkQKPiA+ICAgICAgICAgICB9IEFBQURvbWFpbkludGVyY29ubmVjdDsKPiAKPiAoRGV0ZWN0 ZWQgbWFya2V0c3BlYWsgaW50cnVzaW9uICgiYnJva2VyIikuIElzIG5vdCB0aGVyZSBzb21lIAo+ IHJlc2VhcmNoLy5lZHUtbGlrZSB0ZXJtIGZvciB0aGF0PykKPiAKPiA+My4xLjE5LiAgU2VhcmNo IERpcmVjdGlvbiBUeXBlCj4gPgo+ID4gICBUaGUgZm9sbG93aW5nIHR5cGUgYWxsb3dzIHRoZSBj bGllbnQgdG8gc3BlY2lmeSB3aGljaCBkaXJlY3Rpb24gdG8KPiA+ICAgc2VhcmNoIGZvciBhbiBB VlAgaW4gdGhlIEFWUCBsaXN0Ogo+ID4KPiA+ICAgICAgICAgICB0eXBlZGVmIGVudW0gewo+ID4g ICAgICAgICAgICAgIEFBQV9GT1JXQVJEX1NFQVJDSCA9IDAsCj4gPiAgICAgICAgICAgICAgQUFB X0JBQ0tXQVJEX1NFQVJDSAo+ID4gICAgICAgICAgIH0gQUFBU2VhcmNoVHlwZTsKPiAKPiBUaG91 Z2ggdGhlcmUgaXMgYSBwYXJ0aWN1bGFyIEFWUCBvcmRlciBtYW5kYXRlZCBieSB0aGUgUkZDLCAK PiB0aGlzIGV4cG9zZXMgaW1wbGVtZW50YXRpb24gaW50ZXJuYWxzoJcgc29tZXRoaW5nIHRvIGJl IAo+IHVzdWFsbHkgYXZvaWRlZC4KPiAKPiA+My4yLjEuCj4gPgo+ID4gICAgICAgICAgIHR5cGVk ZWYgc3RydWN0IGRpY3Rpb25hcnlFbnRyeSB7Cj4gPiAgICAgICAgICAgICAgQUFBX0FWUENvZGUg ICAgIGF2cENvZGU7Cj4gPiAgICAgICAgICAgICAgY2hhciogICAgICAgICAgIGF2cE5hbWU7Cj4g PiAgICAgICAgICAgICAgQUFBX0FWUERhdGFUeXBlIGF2cFR5cGU7Cj4gPiAgICAgICAgICAgICAg QUFBVmVuZG9ySWQgICAgIHZlbmRvcklkOwo+ID4gICAgICAgICAgICAgIEFBQV9BVlBGbGFnICAg ICBmbGFnczsKPiA+ICAgICAgICAgICB9IEFBQURpY3Rpb25hcnlFbnRyeTsKPiAKPiBJZiB5b3Ug d2FudCB0byBoaWRlIHRoZSBmYWN0IHRoYXQgc29tZXRoaW5nIGlzIG9mIGEgCj4gcGFydGljdWxh ciB0eXBlLCBkbyBub3QgdXNlIEMuIFRoYXQgYmVpbmcgc2FpZCwgKmlmZiogeW91IGdvIAo+IGRv d24gdGhlIHR5cGVkZWYgcm91dGUsIHdoeSBnaXZlIHRoZSBzdHJ1Y3QgYSBuYW1lPyBJdCAKPiBj cmVhdGVzIGNvbmZ1c2lvbiBvbiB0aGUgZGV2ZWxvcGVycyAtIHNvbWUgd2lsbCB1c2UgInN0cnVj dCAKPiBkaWN0aW9uYXJ5RW50cnkiIGluIHRoZWlyIHByb2dyYW1zLCBzb21lIHdpbGwgdXNlIAo+ ICJBQUFEaWN0aW9uYXJ5RW50cnkiLCBhbmQgd2hhdCB5b3UgaGF2ZSBnYWluZWQgaXMgYSAKPiBk b3VibGUtc2lkZWQgQVBJLCBhbmQgYSBwb3RlbnRpYWwgbmFtZSBjbGFzaCBpbiB0aGUgc3RydWN0 IAo+IG5hbWVzcGFjZS4gQW5kIHdlIGFsbCBhZ3JlZSB0aGF0IGFuIEFQSSBzaG91bGQgb25seSBi ZSAiYXMgCj4gYmlnIGFzIG5lY2Vzc2FyeSBidXQgYXMgc21hbGwgYXMgcG9zc2libGUiLCBzaG91 bGQgbm90IGl0PyAKPiBOb3QgdG8gbWVudGlvbiAiZGljdGlvbmFyeUVudHJ5IiBpcyByZWFsIG5h bWVzcGFjZSBwb2xsdXRpb24uCj4gCj4gPjMuMi4yLiAgQVZQIERlZmluaXRpb24KPiA+Cj4gPiAg IFRoZSBmb2xsb3dpbmcgc3RydWN0dXJlIGNvbnRhaW5zIGEgbWVzc2FnZSBBVlAgaW4gcGFyc2Vk IGZvcm06Cj4gPgo+ID4gICAgICAgICAgICB0eXBlZGVmIHN0cnVjdCBhdnAgewo+ID4gICAgICAg ICAgICAgICAgICAgIGVudW0gewo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBX1JB RElVUywKPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFBQV9ESUFNRVRFUgo+ID4gICAg ICAgICAgICAgICAgICAgIH0gcGFja2V0VHlwZTsKPiA+ICAgICAgICAgICAgICAgICAgICBBQUFf QVZQQ29kZSBjb2RlOwo+ID4gICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IGxlbmd0aDsKPiAK PiA8c2FyY2FzbT5PaCBub2VzLiBBbiAoQUFBLXByb3ZpZGVkKSB0eXBlZGVmIGlzIG1pc3Npbmcg Zm9yIAo+ICJsZW5ndGgiITwvc2FyY2FzbT4KPiAKPiA+My4yLjMuICBBVlAgTGlzdAo+ID4gICAg ICAgICAgICB0eXBlZGVmIHN0cnVjdCBhdnBMaXN0ewo+ID4gICAgICAgICAgICAgICAgICAgIEFB QV9BVlAgKmhlYWQ7Cj4gPiAgICAgICAgICAgICAgICAgICAgQUFBX0FWUCAqdGFpbDsKPiA+ICAg ICAgICAgICAgfSBBQUFfQVZQX0xJU1Q7Cj4gCj4gQWxsLXVwcGVyY2FzZSBpcyBjb21tb25seSB1 c2VkIGZvciBwcmVwcm9jZXNzb3IgbWFjcm9zIG9ubHkuCj4gKFBlcmhhcHMgInN0cnVjdCBhYWFf YXZwX2xpc3QiIHdhcyBpbnRlbmRlZCBpbnN0ZWFkIT8pCj4gCj4gPjMuMy4gIE1hY3JvcyBhbmQg UHJlcHJvY2Vzc29yIERlZmluaXRpb25zCj4gPgo+ID4gICBUaGUgZm9sbG93aW5nIGRlZmluaXRp b24gcmVzZXJ2ZXMgdGhlIHZlbmRvciBpZCBvZiAwOgo+ID4KPiA+ICAgI2RlZmluZSBBQUFfTk9f VkVORE9SX0lEIDAKPiAKPiBVc2UgYW4gZW51bSB7IEFBQV9OT19WRU5ET1JfSUQgPSAwIH0gaW5z dGVhZD8KPiAKPiA+My40LjIuMS4gIEFBQVJlZ2lzdGVyQ29tbWFuZENhbGxiYWNrKCkKPiA+Cj4g PiAgIFRoZSBmb2xsb3dpbmcgZnVuY3Rpb24gaXMgdXNlZCB0byByZWdpc3RlciBjb21tYW5kIGNh bGxiYWNrcyBmb3IKPiA+ICAgcHJvY2Vzc2luZyBBQUEgY29tbWFuZHM6Cj4gPgo+ID4gICAgICAg ICBBQUFDYWxsYmFja0hhbmRsZSAqCj4gPiAgICAgICAgIEFBQVJlZ2lzdGVyQ29tbWFuZENhbGxi YWNrKEFBQUNvbW1hbmRDb2RlIGNvbW1hbmRDb2RlLAo+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBQUFWZW5kb3JJZCB2ZW5kb3JJZCwKPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY2hhciAqY29tbWFuZE5hbWUsCj4gPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFBQUV4dGVuc2lvbklkIGV4dGVuc2lvbklkLAo+ID4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBQUFDYWxsYmFjayBjYWxsYmFjaywKPiA+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBQ2FsbGJhY2tMb2NhdGlvbiBwb3Np dGlvbik7Cj4gCj4gc3BhZ2hldHRpLWxvbmcgZnVuY3Rpb24gbmFtZXMgKGFuZCB0eXBlcyB0b28p Lgo+IAo+IFdoeSBkbyBub3QgeW91IHVzZSBjb25zdCBjaGFyoCo/IEFyZSBsaWJyYXJpZXMgc3Vw cG9zZWQgdG8gCj4gZWRpdCB0aGUgY29tbWFuZCBuYW1lPyBUaGF0IG1lYW5zIGNhbGxlciBjb2Rl IHdpbGwgaGF2ZSB0byAKPiBjYXN0IGF3YXkgY29uc3RuZXNzIHdhcm5pbmdzLCBhbmQgZWgsIGNh c3RzIGl0c2VsZiBhcmUgYmFkLgo+IAo+IEFkZGluZyBhIHBvc2l0aW9uIGlzIG5vIGdvb2QsIGJl Y2F1c2Ugb3V0LW9mLW9yZGVyIGNhbGxlcnMgCj4gbWlnaHQgaW5zZXJ0IENCcyB0aGF0IHN0ZWFs IHRoZSBtZXNzYWdlLiBBbmQgaWYgbm90IHRoYXQsIAo+IHRoZXJlIGlzIGEgZGVwZW5kZW5jeSBv ZiB0aGlyZC1wYXJ0eSBvbiB0aGUgcGFydGljdWxhciAKPiBwb3NpdGlvbiB1c2VkLiBIb3cgdG8g c2F5OyB5b3VyIGxpYmZvbyB1c2VzIHJlZ19jYihwb3M9MTApLCAKPiB0aGVuIHRoZSAzcmQgcGFy dHkgbGliYmFyIHdpbGwgdXNlIHJlZ19jYihwb3M9OSkgdG8gZ2V0IGl0cyAKPiBqb2IgZG9uZSwg YW5kIHRoZW4gdGhlIGxpYmZvbyBkZXZlbG9wZXIgZGVjaWRlcyB0byB1c2UgcG9zPTUgCj4gaW5z dGVhZCBhbmQgZXZlcnl0aGluZyBmYWxscyBhcGFydCBiZWNhdXNlIGxpYmJhciBpcyBzdGlsbCBh dCAKPiBwb3M9MTAgYW5kLCBsZXQncyBzYXksIGNhbm5vdCBnbyB0byBwb3M9NCBiZWNhdXNlIGl0 IHdvdWxkIAo+IGFsc28gY3JlYXRlIHByb2JsZW1zIGZvciBsaWJiYXIuCj4gCj4gPjMuNC4yLjIu ICBBQUFSZWdpc3Rlck5vbmNvbW1hbmRDYWxsYmFjaygpCj4gPgo+ID4gICBUaGUgZm9sbG93aW5n IGNhbGxiYWNrIHJlZ2lzdGVycyBhbiBBQUEgY2FsbGJhY2sgdG8gcHJvY2VzcyBhbGwKPiA+ICAg bWVzc2FnZXMuICBUaGUgY2FsbGJhY2sgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCBhbnkgY29tbWFu ZCwgYnV0Cj4gPiAgIHJhdGhlciB3aWxsIHByb2Nlc3MgYWxsIG1lc3NhZ2VzIGFzIHRoZXkgY29t ZSBkb3duIHRoZSBjYWxsYmFjawo+ID4gICBjaGFpbjoKPiA+Cj4gPiAgICAgICAgIEFBQUNhbGxi YWNrSGFuZGxlCj4gPiAgICAgICAgIEFBQVJlZ2lzdGVyTm9uY29tbWFuZENhbGxiYWNrKEFBQUNh bGxiYWNrIGNhbGxiYWNrLAo+IAo+IFdoeSBub3QgcmV1c2UgYWFhcmVnY2Igd2l0aCBhIGNvbW1h bmQgbnVtYmVyIG9mIDA/Cj4gCj4gPjMuNC4zLjcuICBBQUFHZXREb21haW5JbnRlcmNvbm5lY3RU eXBlKCkKPiA+Cj4gPiAgIFRoZSBmb2xsb3dpbmcgZnVuY3Rpb24gcmV0dXJucyB0aGUgZG9tYWlu IGludGVyY29ubmVjdCB0eXBlIGZvciBhCj4gPiAgIHBhcnRpY3VsYXIgZG9tYWluIG5hbWUgYW5k IHR5cGUgb2Ygc2VydmljZToKPiA+Cj4gPiAgICAgICAgIEFBQVJlc3VsdENvZGUKPiA+ICAgICAg ICAgQUFBR2V0RG9tYWluSW50ZXJjb25uZWN0VHlwZShBQUFNZXNzYWdlICptZXNzYWdlLAo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoYXIgKmRvbWFpbk5hbWUsCj4g PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqdHlwZSk7Cj4gCj4g QUFBUmV0dXJuQ29kZSAtLS0gQUFBUmVzdWx0Q29kZSwgdGhpcyBpcyBhIDc3JSBzaW1pbGFyaXR5 LCAKPiBhbmQgc29tZXRoaW5nIGVhc2lseSBvdmVyc2Vlbi4KPiAKPiA+My40LjQuNi4gIEFBQUdl dENvbW1hbmRDb2RlKCkKPiA+Cj4gPiAgIFRoaXMgZnVuY3Rpb24gcmV0dXJucyB0aGUgY29tbWFu ZCBjb2RlIGFuZCB2ZW5kb3IgaWQgYmFzZWQgb24gYQo+ID4gICBzdHJpbmc6Cj4gPgo+ID4gICAg ICAgICBib29sZWFuX3QKPiA+ICAgICAgICAgQUFBR2V0Q29tbWFuZENvZGUoY2hhciAqY29tbWFu ZE5hbWUsCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEFBQUNvbW1hbmRDb2RlICpjb21t YW5kQ29kZSwKPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBVmVuZG9ySWQgKnZlbmRv cklkKTsKPiAKPiBJIGFtIGFsbW9zdCBjcnlpbmcgd2hlbiBJIHNlZSB0aGlzLiBib29sZWFuX3Qg aXMgbm90IGV2ZW4gYSAKPiBrbm93biB0eXBloJcgaW4gQyBhdCBsZWFzdC4gQW5kIEkgcmVtZW1i ZXIgdGhpcyBkcmFmdCB3YXMgZm9yIAo+IEMsIHdhcyBub3QgaXQ/Cj4gCj4gPjMuNC41LjE1LiAg QUFBR2V0UHJldkFWUCgpCj4gPgo+ID4gICBUaGlzIGZ1bmN0aW9uIHJldHVybnMgYSBwb2ludGVy IHRvIHRoZSBwcmV2aW91cyBBVlAgaW4gdGhlIGxpc3Q6Cj4gPgo+ID4gICAgICAgICBBQUFfQVZQ ICoKPiA+ICAgICAgICAgQUFBR2V0UHJldkFWUChBQUFfQVZQICphdnApOwo+IAo+IEh5cG90aGVz aXM6IFRoaXMgQVBJIGlzIG92ZXJkZXNpZ25lZC4KPiAKPiBPdmVyZGVzaWduIGlzIHdoZW4gYSBm dW5jdGlvbiBpcyBhZGRlZCB0aGF0IGlzIF90aG91Z2h0XyAKPiBtaWdodCBiZSB1c2VmdWwsIGJ1 dCBhY3R1YWxseSBpcyBub3QuIFVubGVzcyB0aGVyZSBpcyAKPiBlbXBpcmljYWwgZGF0YSB0aGF0 IHNob3dzIHRoZXJlIEFSRSBhY3R1YWxseSB1c2VycyBvZiB0aGlzIAo+IGZ1bmN0aW9uIChhbmQg anVzdCB0d28gd29uJ3QgY3V0IGl0KSwgaXQgaXMganVzdCBibG9hdC4KPiAKPiBBbHNvLCB0aGVy ZSBpcyBubyBtZW1iZXIgaW4gdGhlIHN0cnVjdF5XLCBwYXJkb24tbW9pLCAKPiB0eXBlZGVmLCB0 aGF0IHBvaW50cyB0byB0aGUgcHJldmlvdXMgQVZQIGluIGEgbGlzdC4gVGhlIHNhbWUgCj4gZ29l cyBmb3IgYWFhX2dldF9uZXh0X2F2cC4gU28gdGhlcmUgaXMgbm8gd2F5IHRvIGV2ZW4gCj4gaW1w bGVtZW50IHRoaXMgd2l0aCB0aGUgZ2l2ZW4gZHJhZnQuIEFnYWluIEkgbG9va2VkIGF0IFNVTidz IAo+IHByb3RvdHlwZSBmcm9tIDIwMDIgYW5kIG92ZXJsYXlpbmcgaXQgd2l0aCBBQUFfWEFWUCBp cyAKPiB1bmRlc2NyaWJhYmx5IHVnbHkgYW5kIGNhbGxzIGZvciBzZWdmYXVsdHMuCj4gCj4gPjMu NC4zLjEuICBBQUFTdGFydFNlc3Npb24oKQo+ID4KPiA+ICAgVGhlIGZvbGxvd2luZyBmdW5jdGlv biBhbGxvd3MgYSBjbGllbnQgdG8gc3RhcnQgYSBzZXNzaW9uIGFuZAo+ID4gICBpZGVudGlmeSBp dDoKPiA+Cj4gPiAgICAgICAgIEFBQVJldHVybkNvZGUKPiA+ICAgICAgICAgQUFBU3RhcnRTZXNz aW9uKEFBQVNlc3Npb25JZCAqKnNlc3Npb25JZCwKPiA+ICAgICAgICAgICAgICAgICAgICAgICAg IEFBQUFwcGxpY2F0aW9uSWQgYXBwSGFuZGxlLAo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg Y2hhciAqdXNlck5hbWUsCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICBBQUFDYWxsYmFjayBh Ym9ydENhbGxiYWNrKTsKPiAKPiBXaHkgdGhlIHVzZXIgbmFtZT8gSSBkbyBub3Qgc2VlIGl0IGJl aW5nIHJlcXVpcmVkIGJ5IHRoZSBSRkMuCj4gCj4gPjMuNC4zLjIuICBBQUFSZWdpc3RlclBlZXJT ZXNzaW9uKCkKPiAKPiBJdCBpcyBub3QgY2xlYXIgaW4gd2hhdCBvcmRlciBhbnkgb2YgdGhlc2Ug ZnVuY3Rpb25zIGFyZSAKPiBzdXBwb3NlZCB0byBiZSBjYWxsZWQuCj4gCj4gPjMuNC4zLjUuICBB QUFMb29rdXBTZXJ2ZXIoKQo+ID4KPiA+VGhlIGZ1bmN0aW9uIGxvb2tzIHVwIHRoZSBBQUEgc2Vy dmVyIGJhc2VkIG9uIElQIGFkZHJlc3MgYW5kIHBvcnQgCj4gPm51bWJlci4gU2VydmVyIGNvbm5l Y3Rpb25zIGFyZSBjcmVhdGVkIGZyb20gdGhlIGNvbmZpZ3VyYXRpb24gZmlsZToKPiA+Cj4gPkFB QVNlcnZlciAqQUFBTG9va3VwU2VydmVyKEFBQV9JUF9BRERSIGlwQWRkcik7Cj4gPgo+ID5UaGUg cmV0dXJuIHZhbHVlIGlzIGVpdGhlciBhIHZhbGlkIHNlcnZlciBwb2ludGVyIG9yIHRoZSBOVUxM IGlmIHRoZSAKPiA+c2VydmVyIGNhbid0IGJlIGZvdW5kLgo+IAo+ICJTZXJ2ZXIgcG9pbnRlciIg aXMgdG9vIHNwYXJzZS4gSXQncyBhbG1vc3QgbGlrZSBJIGNvdWxkIAo+IHJldHVybiAmaXBhZGRy IGFnYWluLiBBbHNvLCB0aGVyZSBpcyBubyB3YXkgdG8gZGV0ZXJtaW5lIHdoYXQgCj4gbDNwcm90 byB0aGUgaXBhZGRyIGlzIHN1cHBvc2VkIHRvLiAoVGhlcmUgaXMsIGJ1dCB0aGF0IHNlZW1zIAo+ IHRvIGJlIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCBvZiBsaWJzb2NrLikKPiAKPiBBbmQgd2h5 IHdvdWxkIGEgc2VydmVyIGxvb2t1cCBiZSBuZWVkZWQ/IFRoZSBpcCBhZGRyZXNzIGlzIAo+IGVu b3VnaCB0byBjb25uZWN0IHRvIGl0Lgo+IAo+ID4zLjQuNC40LiAgQUFBVmFsdWVGcm9tQVZQQ29k ZSgpCj4gPgo+ID5UaGlzIGZ1bmN0aW9uIGxvb2tzIHVwIGFuIEFWUCB2YWx1ZSB1c2luZyB0aGUg QVZQIGlkIGFuZCAKPiB2ZW5kb3IgaWQsIGFuZCAKPiA+dGhlIHZhbHVlIG5hbWU6Cj4gPgo+ID5B QUFWYWx1ZSBBQUFWYWx1ZUZyb21BVlBDb2RlKEFBQV9BVlBDb2RlIGF2cENvZGUsCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQUFBVmVuZG9ySWQgdmVuZG9ySWQsIGNoYXIgKnZhbHVl TmFtZSk7Cj4gCj4gSSBldmVuIGhhZCB0byBsb29rIGludG8gU1VOJ3MgeWVhci1vbGQgZnJlZWRp YW1ldGVyIHRvIGZpZ3VyZSAKPiBvdXQganVzdCB3aGF0IHRoaXMgd2FzIHN1cHBvc2VkIHRvIGRv LiBUaGlzIHNob3VsZCBjYXJyeSB0aGUgCj4gd29yZCBBVlAgImVudW0iIHNvbWV3aGVyZSBhdCBs ZWFzdC4KPiAKPiA+My40LjQuNi4gIEFBQUdldENvbW1hbmRDb2RlKCkKPiA+ICAgICAgICAgYm9v bGVhbl90IFsuLi5dCj4gPiAgIFRoZSByZXR1cm4gdmFsdWUgaXMgX0JfVFJVRSBpZiB0aGUgY29t bWFuZCB3YXMgZm91bmQuCj4gCj4gVGhlcmUgaXQgaXMgYWdhaW4uICpUaGVyZSBpcyBubyBib29s ZWFuX3QgYW5kIG5vIF9CX1RSVUUqIGluIAo+IHRoZSBDIHN0YW5kYXJkIQo+IAo+ID4zLjQuNS4x LiAgQUFBTmV3TWVzc2FnZSgpCj4gPkFBQU1lc3NhZ2UgKkFBQU5ld01lc3NhZ2UoQUFBQ29tbWFu ZENvZGUgY29tbWFuZENvZGUsCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBVmVuZG9y SWQgdmVuZG9ySWQsCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBU2Vzc2lvbklkICpz ZXNzaW9uSWQsCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBRXh0ZW5zaW9uSWQgZXh0 ZW5zaW9uSWQsCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgQUFBTWVzc2FnZSAqcmVxdWVz dCk7Cj4gPmV4dGVuc2lvbklkOiAgVGhlIGV4dGVuc2lvbiBpZGVudGlmaWVyLgo+IAo+IFdoYXQg aXMgYW4gZXh0ZW5zaW9uIGlkZW50aWZpZXI/Cj4gCj4gPjMuNC41LjIuICBBQUFGcmVlTWVzc2Fn ZSgpCj4gPgo+ID5UaGlzIGZ1bmN0aW9uIGZyZWVzIGEgbWVzc2FnZSBhbGxvY2F0ZWQgdGhyb3Vn aCBBQUFOZXdNZXNzYWdlKCk6Cj4gPgo+ID5BQUFSZXR1cm5Db2RlIEFBQUZyZWVNZXNzYWdlKEFB QU1lc3NhZ2UgKiptZXNzYWdlKTsKPiA+Cj4gPm1lc3NhZ2U6IEEgcG9pbnRlciB0byBhIHBvaW50 ZXIgdG8gdGhlIGFsbG9jYXRlZCBtZXNzYWdlLgo+IAo+IEp1c3QgdXNlIGEgc2luZ2xlIHBvaW50 ZXIgbGlrZSBmcmVlKCkgZG9lcy4gVGhlIHNhbWUgYXBwbGllcyAKPiB0byBhYWFfZnJlZV9hdnAu Cj4gCj4gPjMuNC41LjE2LiAgQUFBQ29udmVydEFWUFRvU3RyaW5nKCkKPiA+Cj4gPlRoaXMgZnVu Y3Rpb24gY29udmVydHMgdGhlIGRhdGEgaW4gdGhlIEFWUCB0byBhIGZvcm1hdCAKPiBzdWl0YWJs ZSBmb3IgbG9nIAo+ID5vciBkaXNwbGF5IGZ1bmN0aW9ucy4KPiA+Cj4gPmNoYXIgKkFBQUNvbnZl cnRBVlBUb1N0cmluZyhBQUFfQVZQICphdnAsIGNoYXIgKmRlc3QsIHNpemVfdCAKPiBkZXN0TGVu KTsKPiA+Cj4gPlRoZSByZXR1cm4gdmFsdWUgaXMgdGhlIHBhc3NlZCBpbiBkZXN0aW5hdGlvbiBi dWZmZXIuCj4gCj4gVGhlIHJldHVybiB2YWx1ZaCXIHdoaWNoIGlzIGEgImxvbmciLXNpemVkIHBv aW50ZXIgKGkuZS4gMiwgNCAKPiBvciA4IGJ5dGVzLCBkZXBlbmRpbmcgb24gY29tcGlsZXIgbW9k ZSkuIEFuZCB0aGlzIHBvaW50ZXIgaXMgCj4gcGFzc2VkIGluIHRoZSBkZXN0aW5hdGlvbiBidWZm ZXIsIHVobSwgc28gdGhhdCBzb3VuZHMgbGlrZSwgCj4gdG8gZ2V0IG15IHJldHVybiB2YWx1ZSwg SSBuZWVkIHRvIHVzZToKPiAKPiAJbXlyZXR1cm52YWx1ZSA9ICooY2hhciAqKilkZXN0Owo+IAo+ IFRoZW4sIHdoYXQgaXMgdGhlIHJldHVybiB2YWx1ZSBnb29kIGZvciBpZiBpdCBpcyByZXR1cm5l ZCBpbiAKPiB0aGUgYnVmZmVyIGFueXdheS4KPiAKPiA+My40LjYuMS4gIEFBQVNldFNlcnZlcigp Cj4gPgo+ID5UaGlzIGZ1bmN0aW9uIHNldHMgdGhlIHNlcnZlciB0byB3aGljaCB0aGUgbWVzc2Fn ZSBpcyBzZW50Ogo+ID4KPiA+QUFBUmV0dXJuQ29kZSBBQUFTZXRTZXJ2ZXIoQUFBTWVzc2FnZSAq bWVzc2FnZSwgQUFBX0lQX0FERFIgaG9zdCk7Cj4gCj4gU29tZWhvdyBJIGZlZWwgdGhhdCB0aGUg ZGVzdGluYXRpb24gZm9yIGEgbWVzc2FnZSBpcyBub3QgYSAKPiBtZXNzYWdlIHByb3BlcnR5Li4u IFdoYXQgaWYgSSB3YW50IHRvIHNlbmQgdGhlIHNhbWUgbWVzc2FnZSAKPiB0byBtdWx0aXBsZSBk ZXN0aW5hdGlvbnM/IEkgd291bGQgaGF2ZSB0bwo+IAo+IAlzZXRzZXJ2ZXIobXNnLCAibG9jYWxo b3N0Iik7Cj4gCW15X3NlbmQobXNnKTsKPiAJc2V0c2VydmVyKG1zZywgInJlbW90ZWhvc3QiKTsK PiAJbXlfc2VuZChtc2cpOwo+IAo+IGJ1dCBpdCBpcyBtdWNoIHNtYXJ0ZXIgdG8gbm90IGhhdmUg aXQgYXMgYSBwZXItbWVzc2FnZSBwcm9wZXJ0eSwgSU9XOgo+IAo+IAlteV9zZW5kKG1zZywgImxv Y2FsaG9zdCIpOwo+IAlteV9zZW5kKG1zZywgInJlbW90ZWhvc3QiKTsKPiAKPiBGb3IgYWRkZWQg d2luLCBJIGNhbiBldmVuIGNhbGwgbXlfc2VuZCgpIGFzeW5jaHJvbm91c2x5IGFuZCAKPiBoYXZl IHRoZW0gcnVuIGNvbmN1cnJlbnRseSwgZS5nLiBieSBzcGF3bmluZyBleHRyYSB0aHJlYWRzLCAK PiB3aXRob3V0IGhhdmluZyB0byB3b3JyeSBhYm91dCBzZXJpYWxpemF0aW9uIGlzc3Vlcy4gV2l0 aCB0aGUgCj4gYnJva2VuIEFBQVNldFNlcnZlciwgb25lIHdvdWxkIGhhdmUgdG8uCj4gCj4gUHJl ZmVyYWJseSB0aG91Z2gsIEkgaGF2ZSB0d28gcHJldmlvdXNseS1lc3RhYmxpc2hlZCBjb25uZWN0 aW9uczoKPiAKPiAJc3RydWN0IGNvbm4gKmMxLCAqYzI7IC8qIGFzc3VtZSBpbml0aWFsaXplZCAq Lwo+IAlzZW5kKGMxLCBtc2cpOwo+IAlzZW5kKGMyLCBtc2cpOwo+IAo+IHdoaWNoIHdvdWxkIElN SE8gYmUgYSBzYW5lIGFwcHJvYWNoLgo+IAo+ID5pcFZlcnNpb246IFRoZSB2ZXJzaW9uIG51bWJl ciBvZiB0aGUgSVAgYWRkcmVzcy4KPiAKPiBUaGlzIHBhcmFtZXRlciBkb2VzIG5vdCBldmVuIGFw cGVhciBpbiB0aGUgZnVuY3Rpb24gc2lnbmF0dXJlLgo+IAo+IAo+ID5BQUFfRVJSX05PVF9GT1VO RDogSWYgdGhlIHNlcnZlciB3YXMgbm90IGZvdW5kLgo+IAo+IFRoZXJlIGlzIGEgbGFjayBvZiBF Q09OTlJFRlVTRUQ6IHNlcnZlciBmb3VuZCBidXQgY29ubmVjdGlvbiByZWZ1c2VkLgo+IAo+ID4z LjYuICBHcm91cGVkIEFWUHMKPiA+Cj4gPkluIG9yZGVyIHRvIGNyZWF0ZSBncm91cGVkIEFWUHMs IGFuIGFwcGxpY2F0aW9uIGNyZWF0ZXMgYW4gCj4gQUFBX0FWUF9MSVNUIAo+ID50aGF0IGlzIG5v dCBhdHRhY2hlZCB0byBhbiBBQUFNZXNzYWdlIHN0cnVjdHVyZSAoYWxzbyBrbm93biBhcyBhbiAK PiA+b3JwaGFuZWQgQUFBX0FWUF9MSVNUKS4gQWxsIG9mIHRoZSBuZWNlc3NhcnkgQVZQcyB3aXRo aW4gdGhlIAo+IEdyb3VwIGFyZSAKPiA+YWRkZWQgdG8gdGhlIG9ycGhhbmVkIEFBQV9BVlBfTElT VCB1c2luZyB0aGUgZXhpc3RpbmcgbGlzdCAKPiBtYW5pcHVsYXRpb24gCj4gPmZ1bmN0aW9ucy4g TGFzdGx5LCB0aGUgZ3JvdXBlZCBBVlAgaXMgYWRkZWQgdG8gdGhlIEFBQU1lc3NhZ2UgCj4gPnN0 cnVjdHVyZS4KPiA+Cj4gPlRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSB0aGF0IGFkZHMgYSBQ cm94eS1TdGF0ZSBHcm91cGVkIAo+IEFWUCB0byBhbiAKPiA+ZXhpc3RpbmcgQUFBTWVzc2FnZSBz dHJ1Y3R1cmUuCj4gPgo+ID5hZGRQcm94eVN0YXRlKEFBQU1lc3NhZ2UgKm1lc3NhZ2UsIGlwYWRk cl90ICpvdXJBZGRyZXNzLAo+ID4gICAgdm9pZCAqc3RhdGUsIHNpemVfdCBzdGF0ZUxlbikKPiAK PiBNaXNzaW5nIHJldHVybiB0eXBlLgo+IAo+ID57Cj4gPiAgICAgICAgQUFBX0FWUF9MSVNUICph dnBMaXN0ID0gTlVMTDsKPiA+Cj4gPiAgICAgICAgaWYgKEFBQUNyZWF0ZUFuZEFkZEFWUFRvTGlz dCgmYXZwTGlzdCwKPiA+ICAgICAgICAgICAgRElBTV9BVlBfUFJPWFlfQUREUkVTUywgQUFBX0FW UElfRkxBR19OT05FLAo+ID4gICAgICAgICAgICBOT19WRU5ET1JfSUQsIChjaGFyICopIG91ckFk ZHJlc3MsCj4gPiAgICAgICAgICAgIHNpemVvZiAoaXBhZGRyX3QpKSkgewo+ID4gICAgICAgICAg ICAgICAgcmV0dXJuIChBQUFfRVJSX0ZBSUxVUkUpOwo+ID4gICAgICAgIH0KPiA+ICAgICAgICBp ZiAoQUFBQ3JlYXRlQW5kQWRkQVZQVG9MaXN0KCZhdnBMaXN0LAo+ID4gICAgICAgICAgICBESUFN X0FWUF9QUk9YWV9JTkZPLCBBQUFfQVZQSV9GTEFHX05PTkUsCj4gPiAgICAgICAgICAgIE5PX1ZF TkRPUl9JRCwgc3RhdGUsIHN0YXRlTGVuKSkgewo+ID4gICAgICAgICAgICAgICAgcmV0dXJuIChB QUFfRVJSX0ZBSUxVUkUpOwo+ID4gICAgICAgIH0KPiA+ICAgICAgICBpZiAoQUFBQ3JlYXRlQW5k QWRkQVZQVG9MaXN0KCZtZXNzYWdlLT5hdnBMaXN0LAo+ID4gICAgICAgICAgICBESUFNX0FWUF9Q Uk9YWV9TVEFURSwgQUFBX0FWUElfRkxBR19OT05FLAo+ID4gICAgICAgICAgICBOT19WRU5ET1Jf SUQsIChjaGFyICopYXZwTGlzdCwKPiA+ICAgICAgICAgICAgQUFBX0FWUF9HUk9VUEVEX0xFTkdU SCkpIHsKPiA+ICAgICAgICAgICAgICAgIHJldHVybiAoQUFBX0VSUl9GQUlMVVJFKTsKPiA+ICAg ICAgICB9Cj4gPgo+ID4gICAgICAgIHJldHVybiAoQUFBX0VSUl9TVUNDRVNTKTsKPiA+fQo+IAo+ IFdoYXQgaXMgQUFBX0FWUF9HUk9VUEVEX0xFTkdUSD8gVGhlIGxlbmd0aCB1c3VhbGx5IGRlcGVu ZHMgb24gCj4gdGhlIGdyb3VwLCB5b3UgY2Fubm90IHVzZSBhbnkgc3RhdGljIG51bWJlci4gTm90 IHdoZW4gaXQgaXMgCj4gcmVjb3JkZWQgYXMgYSBBQUFfQVZQVFlQRV9TVFJJTkcuCj4gCj4gV2hh dCBpcyBBQUFfQVZQSV9GTEFHX05PTkU/IEl0IGlzIHVuZG9jdW1lbnRlZC4KPiAKPiBXaGF0IGlz IERJQU1fQVZQX1BST1hZX1NUQVRFPyBBbHNvIHVuZG9jdW1lbnRlZC4KPiAKPiBBbmQgTk9fVkVO RE9SX0lEPyBQcm9iYWJseSBzaG91bGQgYmUgQUFBX05PX1ZFTkRPUl9JRC4KPiAKPiBKdXN0IHRv IHB1dCB0aGF0IGludG8gY29udHJhc3QsIHRoaXMgaXMgbGliY2lyY3VtIChhZHZlcnRpc2VkIAo+ IGFzIGJlaW5nIGNsZWFuZXIgYW5kIHVzaW5nIGxlc3Mgc2NyZWFtaW5nIGxldHRlcnMpOgo+IAo+ IGJvb2wgYWRkX3Byb3h5X3N0YXRlKHN0cnVjdCBhM19wYWNrZXQgKm1zZywgY29uc3QgaXBhZGRy X3QgKm91cmFkZHIsCj4gICAgIGNvbnN0IHZvaWQgKnN0YXRlLCB1bnNpZ25lZCBpbnQgc3RhdGVs ZW4pIHsKPiAJc3RydWN0IGEzX2F2cCAqYXZwID0KPiAJCWEzX3BrdF9hZGRfYXZwKG1zZywgIlBy b3h5LUluZm8iLCBOVUxMLCAwKTsKPiAJaWYgKGF2cCA9PSBOVUxMKQo+IAkJcmV0dXJuIGZhbHNl Owo+IAo+IAlpZiAoYTNfcGt0X2FkZF9hdnAoYXZwLCAiUHJveHktSG9zdCIsIG91cmFkZHJlc3Ms IAo+IHNpemVvZihpcGFkZHJfdCkpID09IE5VTEwpCj4gCQlyZXR1cm4gZmFsc2U7Cj4gCWlmIChh M19wa3RfYWRkX2F2cChhdnAsICJQcm94eS1TdGF0ZSIsIHN0YXRlLCBzdGF0ZWxlbikgPT0gTlVM TCkKPiAJCXJldHVybiBmYWxzZTsKPiAJcmV0dXJuIHRydWU7Cj4gfQo+IApfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpEaU1FIG1haWxpbmcgbGlzdApEaU1F QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQo= From dime-bounces@ietf.org Mon Nov 3 07:12:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B553A6B94; Mon, 3 Nov 2008 07:12:45 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5AD633A6A3A; Mon, 3 Nov 2008 07:12:44 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081103151244.5AD633A6A3A@core3.amsl.com> Date: Mon, 3 Nov 2008 07:12:44 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Quality of Service Parameters for Usage with the AAA Framework ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16087&rfc_flag=0 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 3 11:10:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770543A6A9B; Mon, 3 Nov 2008 11:10:04 -0800 (PST) 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 2BFD93A6846 for ; Mon, 3 Nov 2008 11:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 Hpa2yGuRmgQ7 for ; Mon, 3 Nov 2008 11:10:02 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 304943A6868 for ; Mon, 3 Nov 2008 11:09:59 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mA3J9uhm006774 for ; Mon, 3 Nov 2008 13:09:56 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mA3J9oLI029309 for ; Mon, 3 Nov 2008 13:09:50 -0600 (CST) Received: from [192.168.0.28] (rocinante.8950aaa.com [192.168.0.28]) by hal.8950aaa.com (Postfix) with ESMTP id 4B5B758687 for ; Mon, 3 Nov 2008 11:09:51 -0800 (PST) Message-ID: <490F4C7F.2040408@alcatel-lucent.com> Date: Mon, 03 Nov 2008 11:09:51 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dime References: <1225704899.6186.17.camel@INDBNG1172.bng.ind.starentnetworks.com> In-Reply-To: <1225704899.6186.17.camel@INDBNG1172.bng.ind.starentnetworks.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Dime] RFC3858: Dimeter Election Process 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: , Content-Type: multipart/mixed; boundary="===============1402325477==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1402325477== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Biplap,

It is case-insensitive for for the applicable code-point range, i.e. ASCII.
Case insensitive comparison of the two literal strings (if that is what you mean) "originHost" and "OriginHostName" would make
"originHost" succeed "OriginHostName". It is a configuration error if two peer's Origin-Host names are different only by case.

- Jan Nordqvist.

Sarkar Biplab wrote:
Hello All,

Can someone please clearity the following paragraph from the  RFC3588-bis-13?


=========
Internet-Draft           Diameter Base Protocol            November 2008


5.6.4.  The Election Process

   The election is performed on the responder.  The responder compares
   the Origin-Host received in the CER with its own Origin-Host as two
   streams of octets.  If the local Origin-Host lexicographically
   succeeds the received Origin-Host a Win-Election event is issued
   locally.  Diameter identities are in ASCII form therefore the lexical
   comparison is consistent with DNS case insensitivity where octets
   that fall in the ASCII range 'a' through 'z' MUST compare equally to
   their upper-case counterparts between 'A' and 'Z'.  See Appendix D
   for interactions between the Diameter protocol and Internationalized
   Domain Name (IDNs).
=================
I believe we are dealing with a "Case-insensitve lexicographically" comparison here.

How does it deal with un-equal similar names?
e.g  originHost  and OriginHostName?

Can someone please throw some light on this?

Thanks & Regards
Biplab 

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--===============1402325477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1402325477==-- From dime-bounces@ietf.org Mon Nov 3 11:51:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0C03A6B4F; Mon, 3 Nov 2008 11:51:57 -0800 (PST) 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 8C2393A6B87 for ; Mon, 3 Nov 2008 11:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.810, 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 1OIVIi0MDVNt for ; Mon, 3 Nov 2008 11:51:55 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id A94343A6843 for ; Mon, 3 Nov 2008 11:51:55 -0800 (PST) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id ajUG1a00N17UAYkA5jrdVT; Mon, 03 Nov 2008 19:51:37 +0000 Received: from gwzPC ([67.170.96.151]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id ajYa1a0053FxqkK8ZjYedj; Mon, 03 Nov 2008 19:32:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=Bl5T77u_sHoA:10 a=SMQ4GKEtO4cA:10 a=aICvgeKsqhV1X4k6cDYA:9 a=IXXHzcQ-ynhvj2MOovSnHLWFz5wA:4 a=3SmO1NJXDBsA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=FR3AwVFXb9tFL0fiZkAA:9 a=pKn-3cDsHF0p0aD5pvgA:7 a=-1IBX_Y0nUW7AbijhzsbVPc1CIYA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: References: <1225704899.6186.17.camel@INDBNG1172.bng.ind.starentnetworks.com> In-Reply-To: <1225704899.6186.17.camel@INDBNG1172.bng.ind.starentnetworks.com> Date: Mon, 3 Nov 2008 11:32:33 -0800 Message-ID: <00f501c93dea$ec34e1a0$c49ea4e0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack9l3gJyloEPzqcRiG6DIxE0T210QAUvCww Content-Language: en-us Cc: 'dime' Subject: Re: [Dime] RFC3858: Dimeter Election Process 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: , Content-Type: multipart/mixed; boundary="===============1041976932==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1041976932== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01C93DA7.DE11A1A0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_00F6_01C93DA7.DE11A1A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello All, Can someone please clearity the following paragraph from the = RFC3588-bis-13?=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D Internet-Draft Diameter Base Protocol November 2008 5.6.4. The Election Process The election is performed on the responder. The responder compares the Origin-Host received in the CER with its own Origin-Host as two streams of octets. If the local Origin-Host lexicographically succeeds the received Origin-Host a Win-Election event is issued locally. Diameter identities are in ASCII form therefore the lexical comparison is consistent with DNS case insensitivity where octets that fall in the ASCII range 'a' through 'z' MUST compare equally to their upper-case counterparts between 'A' and 'Z'. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Name (IDNs). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I believe we are dealing with a "Case-insensitve lexicographically" = comparison here. How does it deal with un-equal similar names? e.g originHost and OriginHostName?=20 =20 Just like a dictionary: if two strings have identical initial = substrings, the longer string succeeds the shorter. Can someone please throw some light on this? Thanks & Regards Biplab=20 ------=_NextPart_000_00F6_01C93DA7.DE11A1A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello All,

Can someone please clearity the following paragraph from the  RFC3588-bis-13?



=3D=3D=3D=3D=3D=3D=3D=3D=3D
Internet-Draft          = ; Diameter Base Protocol           = ; November 2008


5.6.4.  The Election Process

   The election is performed on the responder.  The = responder compares
   the Origin-Host received in the CER with its own = Origin-Host as two
   streams of octets.  If the local Origin-Host lexicographically
   succeeds the received Origin-Host a Win-Election event is = issued
   locally.  Diameter identities are in ASCII form = therefore the lexical
   comparison is consistent with DNS case insensitivity where = octets
   that fall in the ASCII range 'a' through 'z' MUST compare = equally to
   their upper-case counterparts between 'A' and 'Z'.  = See Appendix D
   for interactions between the Diameter protocol and Internationalized
   Domain Name (IDNs).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I believe we are dealing with a "Case-insensitve = lexicographically" comparison here.

How does it deal with un-equal similar names?
e.g  originHost  and OriginHostName?

 

Just like a dictionary: if two strings have identical = initial substrings, the longer string succeeds the = shorter.



Can someone please throw some light on this?

Thanks & Regards
Biplab

------=_NextPart_000_00F6_01C93DA7.DE11A1A0-- --===============1041976932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1041976932==-- From dime-bounces@ietf.org Mon Nov 3 11:59:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FA23A6BB8; Mon, 3 Nov 2008 11:59:29 -0800 (PST) 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 C33613A6BD7 for ; Mon, 3 Nov 2008 11:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 5+qEbLFrJ-rl for ; Mon, 3 Nov 2008 11:59:28 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E8B3C3A6A9E for ; Mon, 3 Nov 2008 11:59:27 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mA3JxMao000985 for ; Mon, 3 Nov 2008 13:59:22 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mA3JxGVF013198 for ; Mon, 3 Nov 2008 13:59:16 -0600 (CST) Received: from [192.168.0.28] (rocinante.8950aaa.com [192.168.0.28]) by hal.8950aaa.com (Postfix) with ESMTP id 58CBC586C3 for ; Mon, 3 Nov 2008 11:59:17 -0800 (PST) Message-ID: <490F5815.5070709@alcatel-lucent.com> Date: Mon, 03 Nov 2008 11:59:17 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dime References: <1225704899.6186.17.camel@INDBNG1172.bng.ind.starentnetworks.com> <490F4C7F.2040408@alcatel-lucent.com> In-Reply-To: <490F4C7F.2040408@alcatel-lucent.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Dime] RFC3858: Dimeter Election Process 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: , Content-Type: multipart/mixed; boundary="===============0388007179==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0388007179== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Duh! I meant "originHost" *precede* "OriginHostName"...

Jan Nordqvist wrote:
Biplap,

It is case-insensitive for for the applicable code-point range, i.e. ASCII.
Case insensitive comparison of the two literal strings (if that is what you mean) "originHost" and "OriginHostName" would make
"originHost" succeed "OriginHostName". It is a configuration error if two peer's Origin-Host names are different only by case.

- Jan Nordqvist.

Sarkar Biplab wrote:
Hello All,

Can someone please clearity the following paragraph from the  RFC3588-bis-13?


=========
Internet-Draft           Diameter Base Protocol            November 2008


5.6.4.  The Election Process

   The election is performed on the responder.  The responder compares
   the Origin-Host received in the CER with its own Origin-Host as two
   streams of octets.  If the local Origin-Host lexicographically
   succeeds the received Origin-Host a Win-Election event is issued
   locally.  Diameter identities are in ASCII form therefore the lexical
   comparison is consistent with DNS case insensitivity where octets
   that fall in the ASCII range 'a' through 'z' MUST compare equally to
   their upper-case counterparts between 'A' and 'Z'.  See Appendix D
   for interactions between the Diameter protocol and Internationalized
   Domain Name (IDNs).
=================
I believe we are dealing with a "Case-insensitve lexicographically" comparison here.

How does it deal with un-equal similar names?
e.g  originHost  and OriginHostName?

Can someone please throw some light on this?

Thanks & Regards
Biplab 

_______________________________________________
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

--===============0388007179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0388007179==-- From dime-bounces@ietf.org Mon Nov 3 14:28:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CCB28C2AF; Mon, 3 Nov 2008 14:28:31 -0800 (PST) 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 EDADC3A690F for ; Mon, 3 Nov 2008 14:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, 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 x59ifh50BYI6 for ; Mon, 3 Nov 2008 14:28:29 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id A1F0528C345 for ; Mon, 3 Nov 2008 14:28:21 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id amLd1a00N0EPchoA9mSn87; Mon, 03 Nov 2008 22:27:26 +0000 Received: from gwzPC ([67.170.96.151]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id amSU1a00F3FxqkK8MmSZjg; Mon, 03 Nov 2008 22:26:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=3sUuNYfZorqhT9H80JcA:9 a=21ce7dWpp6dCBh4WO74A:7 a=ZargS0lqqOVP1Gvs6qITilqfhtEA:4 a=Mz_smNXqyOQA:10 From: "Glen Zorn" To: "'Jan Engelhardt'" References: <006a01c93d37$4c562760$e5027620$@net> In-Reply-To: Date: Mon, 3 Nov 2008 14:26:26 -0800 Message-ID: <024101c93e03$36e2d870$a4a88950$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack9fkbQ1NfdrKY9Sn+2DSgKkrx1QQAZgDNQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jan Engelhardt [mailto://jengelh@sovereign.computergmbh.de] writes: > On Sunday 2008-11-02 23:06, Glen Zorn wrote: > >> > >> 2. For a server, asynchronous-ity may make sense, but for clients, > >> this is less of a case. The fact that our course's implementation > >> fares perfectly well with synchronous exchange. Especially since I > >> do not see what a client is supposed to asynchronously do after > >> having sent a packet and waiting for a reply. > > > >Diameter IS NOT a client/server protocol; the terms are used only as > >a convenience. > > So what IS it? Diameter is a peer-to-peer protocol. > Some freeform packet flooder like netbios broadcasts? > What I want to point out here is that with CBs, it seems impossible > to match an incoming message to its previously corresponding message, > at least in cases like AA. What's wrong w/the Hop-by-Hop Identifier? BTW, with the exception of this minor conceptual faux pas, you comments WRT this draft are the first I recall seeing from somebody actually writing code & are very welcome (though a little late). ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 3 15:29:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4431D28C3A5; Mon, 3 Nov 2008 15:29:55 -0800 (PST) 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 1500E28C3A5 for ; Mon, 3 Nov 2008 15:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-1.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_YOUR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIxehmh2PRpr for ; Mon, 3 Nov 2008 15:29:53 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 1505128C3A4 for ; Mon, 3 Nov 2008 15:29:52 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id CDE2E1803BE98; Tue, 4 Nov 2008 00:29:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id C58251C13D8D0; Tue, 4 Nov 2008 00:29:48 +0100 (CET) Date: Tue, 4 Nov 2008 00:29:48 +0100 (CET) From: Jan Engelhardt To: Glen Zorn In-Reply-To: <024101c93e03$36e2d870$a4a88950$@net> Message-ID: References: <006a01c93d37$4c562760$e5027620$@net> <024101c93e03$36e2d870$a4a88950$@net> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Ck9uIE1vbmRheSAyMDA4LTExLTAzIDIzOjI2LCBHbGVuIFpvcm4gd3JvdGU6Cj4+ID4KPj4gPkRp YW1ldGVyIElTIE5PVCBhIGNsaWVudC9zZXJ2ZXIgcHJvdG9jb2w7IHRoZSB0ZXJtcyBhcmUgdXNl ZCBvbmx5IGFzCj4+ID5hIGNvbnZlbmllbmNlLgo+PiAKPj4gU28gd2hhdCBJUyBpdD8gCj4+WyBT b21lIGZyZWVmb3JtIHBhY2tldCBmbG9vZGVyIGxpa2UgbmV0YmlvcyBicm9hZGNhc3RzPyBdCj4K PkRpYW1ldGVyIGlzIGEgcGVlci10by1wZWVyIHByb3RvY29sLgoKSSB0YWtlIHRoYXQgYXMgYSB5 ZXMuCgo+PiBXaGF0IEkgd2FudCB0byBwb2ludCBvdXQgaGVyZSBpcyB0aGF0IHdpdGggQ0JzLCBp dCBzZWVtcyBpbXBvc3NpYmxlCj4+IHRvIG1hdGNoIGFuIGluY29taW5nIG1lc3NhZ2UgdG8gaXRz IHByZXZpb3VzbHkgY29ycmVzcG9uZGluZyBtZXNzYWdlLAo+PiBhdCBsZWFzdCBpbiBjYXNlcyBs aWtlIEFBLgo+Cj5XaGF0J3Mgd3Jvbmcgdy90aGUgSG9wLWJ5LUhvcCBJZGVudGlmaWVyPwoKVGhp bmtpbmcgYWJvdXQgdGhpcywgUDJQIGlzIG5vdCB0cnVseSB0ZWxsaW5nIGhlcmUuIFAyUCBtZXJl bHkgc2F5cwp0aGF0IGV2ZXJ5IG5vZGUgY2FuL3dpbGwgcmFuZG9tbHkgY29ubmVjdCB0byBhbm90 aGVyLiBCZWNhdXNlIFRDUCBpcwpzdGF0ZWZ1bCwgb25lIGNhbiBiZSBzdXJlIHRoYXQgbWVzc2Fn ZXMgcmVjZWl2ZWQgb24gYSBzb2NrZXQKZGVzY3JpcHRvciBhbHdheXMgY29tZSBmcm9tIHRoZSBz YW1lIHBlZXIuIEZ1cnRoZXJtb3JlLCB0aGUgUkZDIGRvZXMKbm90IHNlZW0gdG8gc2F5IGFueXRo aW5nIGFib3V0IChhKXN5bmNocm9ub3VzIG9wZXJhdGlvbiwgd2hldGhlciAxLgptZXNzYWdlcyBt YXkgYmUgcHJvY2Vzc2VkIGFzeW5jIG9yIG11c3QgYmUgcHJvY2Vzc2VzIGluIHN5bmMgYXQgdGhl CnJlbW90ZSBzaWRlLCBhbmQgMi4gd2hldGhlciwgaW5kZXBlbmRlbnQgb2YgKDEpLCByZXBsaWVz IG11c3QgYmUgaW4KdGhlIHNhbWUgb3JkZXIgYXMgdGhlIHJlcXVlc3RzL21heSBiZSByZW9yZGVy ZWQuCgpTbyBpcnJlc3BlY3RpdmUgb2YgdGhlIFAyUCBuYXR1cmUsIEkgaW50ZXJwcmV0ZWQgdGhl IFJGQyBhcyBhc3N1bWluZwpzeW5jaHJvbm91cyBwcm9jZXNzaW5nIGFuZCBvcmRlcmluZyB3aXRo aW4gb25lIGNvbm5lY3Rpb24uwqDigJQgV2hpY2gKbGVhZCB0byB0aGUgSEJIIGxvb2tpbmcgbGlr ZSBhIHJlZHVuZGFudCBmaWVsZCBiZWNhdXNlIG9yZGVyIGlzCmd1YXJhbnRlZWQgYnkgdGhlIHN0 cmVhbSBwcm90b2NvbC4gKEl0IG1heSBoYXZlIG1hZGUgc2Vuc2UgZm9yClJBRElVUy9VRFAgb3Ig c29tZXRoaW5nLCBidXQgdGhhdCB3YXMgbm90IHBhcnQgb2YgdGhlIGluaXRpYWwKaW1wbC4pCgo+ QlRXLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhpcyBtaW5vciBjb25jZXB0dWFsIGZhdXggcGFz LCB5b3Vbcl0KPmNvbW1lbnRzIFdSVCB0aGlzIGRyYWZ0IGFyZSB0aGUgZmlyc3QgSSByZWNhbGwg c2VlaW5nIGZyb20gc29tZWJvZHkKPmFjdHVhbGx5IHdyaXRpbmcgY29kZSAmIGFyZSB2ZXJ5IHdl bGNvbWUgKHRob3VnaCBhIGxpdHRsZSBsYXRlKS4KCkkgdGhpbmsgdGhhdCBpcyBhIHByb2JsZW0g d2l0aCBtYW55IGEgZHJhZnQvUkZDLCB0aGF0IHRoZXJlIGlzIG5vCmltcGwuIGJ5IGFuIGV4dGVy bmFsIGVudGl0eSB0aGF0IGhhcyBub3Qgb3RoZXJ3aXNlIGJlZW4gaW52b2x2ZWQgaW4KdGhlIHBy b2Nlc3Mgb2YgY3JhZnRpbmcgdGhlIGRyYWZ0L1JGQyBhbmQvb3IgZmlyc3QgcHJvdG90eXBlcy4K CkRpYW1ldGVyIHNlZW1zIHRvIGdvIHVuZGVyIGV2ZXJ5b25lJ3MgcmFkYXLCoOKAlCBpdCBoYXMg YmVlbiBhcm91bmQgZm9yCnllYXJzIGJ1dCBpbXBsZW1lbnRhdGlvbnMgYXJlIG9uIHRoZSByYXJl IHNpZGUuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkRp TUUgbWFpbGluZyBsaXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Mon Nov 3 19:16:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B64728C3C3; Mon, 3 Nov 2008 19:16:11 -0800 (PST) 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 6B77928C3BB for ; Mon, 3 Nov 2008 19:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.21 X-Spam-Level: ** X-Spam-Status: No, score=2.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MANGLED_YOUR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed90C24QHZ7k for ; Mon, 3 Nov 2008 19:16:10 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id E964128C3C3 for ; Mon, 3 Nov 2008 19:16:01 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id mA43C7S0007749; Tue, 4 Nov 2008 12:12:07 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id mA43C7Ft027266; Tue, 4 Nov 2008 12:12:07 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id mA43C7v9027263; Tue, 4 Nov 2008 12:12:07 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 478FB6EBE; Tue, 4 Nov 2008 12:12:07 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id 25FFB6E5C; Tue, 4 Nov 2008 12:12:07 +0900 (JST) Message-ID: <490FBD64.1010903@nict.go.jp> Date: Tue, 04 Nov 2008 12:11:32 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jan Engelhardt References: <006a01c93d37$4c562760$e5027620$@net> <024101c93e03$36e2d870$a4a88950$@net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGVsbG8sCgpJIHdvdWxkIGxpa2UgdG8gYWRkIHNvbWUgcHJlY2lzaW9ucyBoZXJlIChpbmxpbmVk KS4KClRoYW5rcywKU2ViYXN0aWVuLgoKCj4+IFdoYXQncyB3cm9uZyB3L3RoZSBIb3AtYnktSG9w IElkZW50aWZpZXI/Cj4+ICAgICAKPgo+IFRoaW5raW5nIGFib3V0IHRoaXMsIFAyUCBpcyBub3Qg dHJ1bHkgdGVsbGluZyBoZXJlLiBQMlAgbWVyZWx5IHNheXMKPiB0aGF0IGV2ZXJ5IG5vZGUgY2Fu L3dpbGwgcmFuZG9tbHkgY29ubmVjdCB0byBhbm90aGVyLiBCZWNhdXNlIFRDUCBpcwo+IHN0YXRl ZnVsLCBvbmUgY2FuIGJlIHN1cmUgdGhhdCBtZXNzYWdlcyByZWNlaXZlZCBvbiBhIHNvY2tldAo+ IGRlc2NyaXB0b3IgYWx3YXlzIGNvbWUgZnJvbSB0aGUgc2FtZSBwZWVyLiBGdXJ0aGVybW9yZSwg dGhlIFJGQyBkb2VzCj4gbm90IHNlZW0gdG8gc2F5IGFueXRoaW5nIGFib3V0IChhKXN5bmNocm9u b3VzIG9wZXJhdGlvbiwgd2hldGhlciAxLgo+IG1lc3NhZ2VzIG1heSBiZSBwcm9jZXNzZWQgYXN5 bmMgb3IgbXVzdCBiZSBwcm9jZXNzZXMgaW4gc3luYyBhdCB0aGUKPiByZW1vdGUgc2lkZSwgYW5k IDIuIHdoZXRoZXIsIGluZGVwZW5kZW50IG9mICgxKSwgcmVwbGllcyBtdXN0IGJlIGluCj4gdGhl IHNhbWUgb3JkZXIgYXMgdGhlIHJlcXVlc3RzL21heSBiZSByZW9yZGVyZWQuCj4KPiBTbyBpcnJl c3BlY3RpdmUgb2YgdGhlIFAyUCBuYXR1cmUsIEkgaW50ZXJwcmV0ZWQgdGhlIFJGQyBhcyBhc3N1 bWluZwo+IHN5bmNocm9ub3VzIHByb2Nlc3NpbmcgYW5kIG9yZGVyaW5nIHdpdGhpbiBvbmUgY29u bmVjdGlvbi4g4oCUIFdoaWNoCj4gbGVhZCB0byB0aGUgSEJIIGxvb2tpbmcgbGlrZSBhIHJlZHVu ZGFudCBmaWVsZCBiZWNhdXNlIG9yZGVyIGlzCj4gZ3VhcmFudGVlZCBieSB0aGUgc3RyZWFtIHBy b3RvY29sLiAoSXQgbWF5IGhhdmUgbWFkZSBzZW5zZSBmb3IKPiBSQURJVVMvVURQIG9yIHNvbWV0 aGluZywgYnV0IHRoYXQgd2FzIG5vdCBwYXJ0IG9mIHRoZSBpbml0aWFsCj4gaW1wbC4pCj4gICAK SW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIG5hdHVyZSBvZiB0aGUgbWVzc2FnZXMgdGhlbXNlbHZl cyB3aWxsIGVuZm9yY2UKdGhlIG9yZGVyaW5nIG9mIHRoZSBtZXNzYWdlczogb25lIGFuc3dlciBm b3Igb25lIHJlcXVlc3QuIEFueXdheSwKbWVzc2FnZXMgcmVsYXRlZCB0byBkaWZmZXJlbnQgdXNl ciBzZXNzaW9ucyBtYXkgYmUgc2VudCBjb25jdXJyZW50bHkKKGVzcGVjaWFsbHkgdXNpbmcgbXVs dGktc3RyZWFtIFNDVFApIGFuZCB0aGUgYW5zd2VycyBtYXkgbm90IGJlIHJlY2VpdmVkCmluIHRo ZSBzYW1lIG9yZGVyIGFzIHRoZSByZXF1ZXN0cy4gSSB0aGluayB0aGUgSG9wLWJ5LWhvcCBJRCBp cyBmYXIgbW9yZQplZmZpY2llbnQgd2F5IHRvIG1hdGNoIGFuIGluY29taW5nIGFuc3dlciB3aXRo IHRoZSBjb3JyZXNwb25kaW5nIHNlbnQKcmVxdWVzdCBmb3IgZXhhbXBsZSBhdCBhIHJlbGF5IGxl dmVsLiBJIGd1ZXNzIHRoYXQgdGhpcyBJRCBzaG91bGQgbm90IGJlCnJlbW92ZWQuCgpBYm91dCB0 aGUgcGVlci10by1wZWVyIFZzIGNsaWVudC1zZXJ2ZXIgbW9kZWwsIERpYW1ldGVyIGlzIGEKcGVl ci10by1wZWVyIHByb3RvY29sIGJ1dCBJIGJlbGlldmUgdGhhdCBtb3N0IChhbGw/KSBvZiB0aGUg RGlhbWV0ZXIKYXBwbGljYXRpb25zIGFyZSBiYXNlZCBvbiBjbGllbnQtc2VydmVyIG1vZGVscy4g VGhpcyBpcyBwcm9iYWJseSByZWxhdGVkCnRvIHRoZSBuYXR1cmUgb2YgQUFBIGl0c2VsZi4uLgoK Pj4gQlRXLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhpcyBtaW5vciBjb25jZXB0dWFsIGZhdXgg cGFzLCB5b3Vbcl0KPj4gY29tbWVudHMgV1JUIHRoaXMgZHJhZnQgYXJlIHRoZSBmaXJzdCBJIHJl Y2FsbCBzZWVpbmcgZnJvbSBzb21lYm9keQo+PiBhY3R1YWxseSB3cml0aW5nIGNvZGUgJiBhcmUg dmVyeSB3ZWxjb21lICh0aG91Z2ggYSBsaXR0bGUgbGF0ZSkuCj4+ICAgICAKPgo+IEkgdGhpbmsg dGhhdCBpcyBhIHByb2JsZW0gd2l0aCBtYW55IGEgZHJhZnQvUkZDLCB0aGF0IHRoZXJlIGlzIG5v Cj4gaW1wbC4gYnkgYW4gZXh0ZXJuYWwgZW50aXR5IHRoYXQgaGFzIG5vdCBvdGhlcndpc2UgYmVl biBpbnZvbHZlZCBpbgo+IHRoZSBwcm9jZXNzIG9mIGNyYWZ0aW5nIHRoZSBkcmFmdC9SRkMgYW5k L29yIGZpcnN0IHByb3RvdHlwZXMuCj4KPiBEaWFtZXRlciBzZWVtcyB0byBnbyB1bmRlciBldmVy eW9uZSdzIHJhZGFyIOKAlCBpdCBoYXMgYmVlbiBhcm91bmQgZm9yCj4geWVhcnMgYnV0IGltcGxl bWVudGF0aW9ucyBhcmUgb24gdGhlIHJhcmUgc2lkZS4KRm9yIHRoZSByZWNvcmQsIEkgYW0gYWxz byB3b3JraW5nIG9uIGEgRGlhbWV0ZXIgaW1wbGVtZW50YXRpb24gKApodHRwOi8vYWFhLmtvZ2Fu ZWkud2lkZS5hZC5qcC8gKSBhbmQgSSBzZW50IGEgbGlzdCBvZiBjb21tZW50cyBvbiB0aGUKRGlh bWV0ZXIgQVBJIGVhcmxpZXIgaW4gdGhpcyBsaXN0OgpodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvZGltZS9jdXJyZW50L21zZzAyNDYwLmh0bWwKClRoaXMgbmV3IGltcGxlbWVu dGF0aW9uIGlzIG5vdCBiYXNlZCBvbiB0aGUgRGlhbWV0ZXIgQVBJLCBtYWlubHkgYmVjYXVzZQp0 aGF0IEFQSSBkb2VzIG5vdCBhbGxvd3MgdG8gaW1wbGVtZW50IGEgRGlhbWV0ZXIgYWdlbnQgKFBy b3h5LCBSZWRpcmVjdCwKLi4uKSBhbmQgZm9jdXNlcyBvbiBlYXNpbmcgdHJhbnNpdGlvbiBmcm9t IFJBRElVUyB3aGljaCBtYXkgbm90IGJlIGEKZ29vZCB0aGluZyBJTUhPLgoKQmVzdCByZWdhcmRz LApTZWJhc3RpZW4uCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkRpTUUgbWFpbGluZyBsaXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Mon Nov 3 21:28:35 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF683A697E; Mon, 3 Nov 2008 21:28:35 -0800 (PST) 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 272AF3A676A for ; Mon, 3 Nov 2008 21:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=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 obJM4zLqXVQ5 for ; Mon, 3 Nov 2008 21:28:33 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 4E8383A69A0 for ; Mon, 3 Nov 2008 21:28:32 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id B61121817AE79; Tue, 4 Nov 2008 06:28:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id AA8881C41FA57; Tue, 4 Nov 2008 06:28:26 +0100 (CET) Date: Tue, 4 Nov 2008 06:28:26 +0100 (CET) From: Jan Engelhardt To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <20081103151244.5AD633A6A3A@core3.amsl.com> Message-ID: References: <20081103151244.5AD633A6A3A@core3.amsl.com> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Monday 2008-11-03 16:12, The IESG wrote: >The IESG has received a request from the Diameter Maintenance and >Extensions WG (dime) to consider the following document: > >- 'Quality of Service Parameters for Usage with the AAA Framework ' > as a Proposed Standard >4.1. Parameter Header > > Each QoS parameter is encoded in TLV format. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|r|r|r| Parameter ID |r|r|r|r| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Why the odd position of the parameter ID? This would additional processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)). I'd say tack the four 'r's on the right there onto the left group. What's wrong with making it a grouped AVP instead of this binary-packed format? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 3 22:52:15 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8654D3A67F1; Mon, 3 Nov 2008 22:52:15 -0800 (PST) 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 E180A3A67A1 for ; Mon, 3 Nov 2008 22:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=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 MRUvU2fQ7Noh for ; Mon, 3 Nov 2008 22:52:14 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 049C53A67F1 for ; Mon, 3 Nov 2008 22:52:13 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 5A0301817AE79; Tue, 4 Nov 2008 07:52:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 4CDA41C05D70A; Tue, 4 Nov 2008 07:52:08 +0100 (CET) Date: Tue, 4 Nov 2008 07:52:08 +0100 (CET) From: Jan Engelhardt To: Sebastien Decugis In-Reply-To: <490FBD64.1010903@nict.go.jp> Message-ID: References: <006a01c93d37$4c562760$e5027620$@net> <024101c93e03$36e2d870$a4a88950$@net> <490FBD64.1010903@nict.go.jp> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Ck9uIFR1ZXNkYXkgMjAwOC0xMS0wNCAwNDoxMSwgU2ViYXN0aWVuIERlY3VnaXMgd3JvdGU6Cj4+ Cj4+IEkgdGhpbmsgdGhhdCBpcyBhIHByb2JsZW0gd2l0aCBtYW55IGEgZHJhZnQvUkZDLCB0aGF0 IHRoZXJlIGlzIG5vCj4+IGltcGwuIGJ5IGFuIGV4dGVybmFsIGVudGl0eSB0aGF0IGhhcyBub3Qg b3RoZXJ3aXNlIGJlZW4gaW52b2x2ZWQgaW4KPj4gdGhlIHByb2Nlc3Mgb2YgY3JhZnRpbmcgdGhl IGRyYWZ0L1JGQyBhbmQvb3IgZmlyc3QgcHJvdG90eXBlcy4KPj4KPj4gRGlhbWV0ZXIgc2VlbXMg dG8gZ28gdW5kZXIgZXZlcnlvbmUncyByYWRhciDigJQgaXQgaGFzIGJlZW4gYXJvdW5kIGZvcgo+ PiB5ZWFycyBidXQgaW1wbGVtZW50YXRpb25zIGFyZSBvbiB0aGUgcmFyZSBzaWRlLgo+Cj5Gb3Ig dGhlIHJlY29yZCwgSSBhbSBhbHNvIHdvcmtpbmcgb24gYSBEaWFtZXRlciBpbXBsZW1lbnRhdGlv biAoCj5odHRwOi8vYWFhLmtvZ2FuZWkud2lkZS5hZC5qcC8gKSBhbmQgSSBzZW50IGEgbGlzdCBv ZiBjb21tZW50cyBvbiB0aGUKPkRpYW1ldGVyIEFQSSBlYXJsaWVyIGluIHRoaXMgbGlzdDoKPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kaW1lL2N1cnJlbnQvbXNnMDI0NjAu aHRtbAoKTWgsIHNvbWUgcmFuZG9tIGNvbW1lbnRzOiBsb3RzIG9mIGNvZGUsIGxvdHMgb2YgaGFy ZGNvZGVkIGRhdGEsCnZhbHVlcyBpbnN0ZWFkIG9mIGNvbnN0YW50cywgY2FzdGluZyBtYWxsb2Mn cyByZXN1bHQgKGNhbiBsZWFkIHRvCmNyYXNoZXM7IEkgaGF2ZSBubyBpZGVhIHdoYXQgbWFueSBh IEMgYm9vayBhdXRob3Igc21va2VkKSwgcmVkdW5kYW50CmNhc3RzLCBjb21tZW50cyB0aGF0Li4u IChObyB3YXkgd291bGQgSSBoYXZlIGd1ZXNzZWQgdGhhdApwdGhyZWFkX211dGV4X2Rlc3Ryb3kg ZGVzdHJveXMgdGhlIG11dGV4ISkKCgkvKiBEZXN0cm95IHRoZSBtdXRleCAqLyAKCUNIRUNLX1BP U0lYKCAgICBwdGhyZWFkX211dGV4X3VubG9jayggJml0ZW0tPmxvY2sgKSAgICAgKTsgCglDSEVD S19QT1NJWCggICAgcHRocmVhZF9tdXRleF9kZXN0cm95KCAmaXRlbS0+bG9jayApICAgICk7IAoK YW5kIGZvciBzdGFydGVyczoKCW1ha2VbM106ICoqKiBObyBydWxlIHRvIG1ha2UgdGFyZ2V0IGBw ZWVyLWRwcl9kcGEubycsCgluZWVkZWQgYnkgYHdhYWFkJy4gIFN0b3AuCgpTdGlsbCBoYXMgYSB3 YXkgdG8gZ28uCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkRpTUUgbWFpbGluZyBsaXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Mon Nov 3 23:09:35 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9802D3A68AE; Mon, 3 Nov 2008 23:09:35 -0800 (PST) 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 D8BD33A684E for ; Mon, 3 Nov 2008 23:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=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 oRfyzBeM5y91 for ; Mon, 3 Nov 2008 23:09:33 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 155D73A67F1 for ; Mon, 3 Nov 2008 23:09:29 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 44C001803F74B; Tue, 4 Nov 2008 08:09:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 3E1D21C0E6F1B for ; Tue, 4 Nov 2008 08:09:26 +0100 (CET) Date: Tue, 4 Nov 2008 08:09:26 +0100 (CET) From: Jan Engelhardt To: dime@ietf.org Message-ID: User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Subject: [Dime] Session-Id adjustment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Section 8.8 ("Session-Id AVP") specifies: >The Session-Id MUST be globally and eternally unique, as it is meant to >uniquely identify a user session without reference to any other >information, and may be needed to correlate historical authentication >information with accounting information. What about wraparound? (When initialized with a value close to 2^64) >At startup, the high 32 bits of the 64-bit value MAY be initialized to >the time in NTP format [RFC4330], and the low 32 bits MAY be >initialized to zero. This will for practical purposes eliminate the >possibility of overlapping Session-Ids after a reboot, assuming the >reboot process takes longer than a second. NTP carries a subsecond value, so your reboot turnaround time is allowed to be theoretically less than 1 second. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 3 23:27:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450E33A68BA; Mon, 3 Nov 2008 23:27:33 -0800 (PST) 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 0CD653A684A for ; Mon, 3 Nov 2008 23:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.06 X-Spam-Level: * X-Spam-Status: No, score=1.06 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 uJqO8VgM8wrY for ; Mon, 3 Nov 2008 23:27:31 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id 0C68A3A67A1 for ; Mon, 3 Nov 2008 23:27:30 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id mA47NcpI013715; Tue, 4 Nov 2008 16:23:38 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id mA47NcgY002309; Tue, 4 Nov 2008 16:23:38 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id mA47Ncsj002306; Tue, 4 Nov 2008 16:23:38 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id CE4C74451; Tue, 4 Nov 2008 16:23:37 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id A863E4420; Tue, 4 Nov 2008 16:23:37 +0900 (JST) Message-ID: <490FF853.2010509@nict.go.jp> Date: Tue, 04 Nov 2008 16:22:59 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jan Engelhardt References: <006a01c93d37$4c562760$e5027620$@net> <024101c93e03$36e2d870$a4a88950$@net> <490FBD64.1010903@nict.go.jp> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Mh, some random comments: lots of code, lots of hardcoded data, > values instead of constants, casting malloc's result (can lead to > crashes; I have no idea what many a C book author smoked), redundant > casts, comments that... (No way would I have guessed that > pthread_mutex_destroy destroys the mutex!) > > /* Destroy the mutex */ > CHECK_POSIX( pthread_mutex_unlock( &item->lock ) ); > CHECK_POSIX( pthread_mutex_destroy( &item->lock ) ); > > and for starters: > make[3]: *** No rule to make target `peer-dpr_dpa.o', > needed by `waaad'. Stop. > > Still has a way to go. > > Sure, I never claimed the implementation was complete yet ^^ It's a work in progress! About your comments: - lots of code. => can you implement Diameter without having lot of code? You're *very* good then! - lots of hardcoded data. => can you give precise examples? Except from the dictionary definitions of the base protocol I mean... I saw that the argument for your implementation is that you resolve the command code and AVP code from the name; this can also be done with this implementation. One could argue that the AVP name *is* hardcoded in any case... - values instead of constants. => there may remain a few such places but I don't think there are many... Can you point me to these places so that I fix it? - casting malloc results. => Wow, for my culture, can you explain why this is not recommended??? I never heard this before... - redundant casts. => Why is this a problem? - too many comments . => Well I believe that commented code makes it easier to read. Especially, it makes it easy to extract the pseudo-code for any function. But if you prefer to go without comments, it's quite easy to remove... - compilation error: => bad timing, between two commits... Anyway, as said previously, this is a work in progress and not expected to work properly yet. Anyway, if some people want to help the project by contributing (or even criticizing, as long as it is constructive...) please contact me! Bests, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 3 23:58:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEE03A6942; Mon, 3 Nov 2008 23:58:54 -0800 (PST) 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 07C243A6904 for ; Mon, 3 Nov 2008 23:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=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 jES+A8CGEiZQ for ; Mon, 3 Nov 2008 23:58:52 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 0A9843A68B4 for ; Mon, 3 Nov 2008 23:58:51 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id D515C1803F74B; Tue, 4 Nov 2008 08:58:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id CDF071C0E6F1B; Tue, 4 Nov 2008 08:58:42 +0100 (CET) Date: Tue, 4 Nov 2008 08:58:42 +0100 (CET) From: Jan Engelhardt To: Sebastien Decugis In-Reply-To: <490FF853.2010509@nict.go.jp> Message-ID: References: <006a01c93d37$4c562760$e5027620$@net> <024101c93e03$36e2d870$a4a88950$@net> <490FBD64.1010903@nict.go.jp> <490FF853.2010509@nict.go.jp> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Tuesday 2008-11-04 08:22, Sebastien Decugis wrote: > >About your comments: >- lots of code. >=> can you implement Diameter without having lot of code? You're *very* >good then! >- lots of hardcoded data. >=> can you give precise examples? Except from the dictionary definitions >of the base protocol I mean... Yes it was the dictionary definitions. >I saw that the argument for your >implementation is that you resolve the command code and AVP code from >the name; this can also be done with this implementation. One could >argue that the AVP name *is* hardcoded in any case... The name yes, but >- values instead of constants. >=> there may remain a few such places but I don't think there are >many... Can you point me to these places so that I fix it? dict-base.c:#if ER_DIAMETER_SUCCESS != 2001 Not sure if that qualifies, but I am getting suspicious whenever I see any such values in .c files. Having it more than once can possibly lead to an update anomaly, as database people would call it. >- casting malloc results. >=> Wow, for my culture, can you explain why this is not recommended??? I >never heard this before... > >- redundant casts. >=> Why is this a problem? 1. Because they are, well, redundant. 2. Assume typeof(x) is already of T. y = (T)x; Now assume that during the lifetime of the code, typeof(x) changes. The compiler would normally warn you if typeof(x) cannot be implicitly converted to typeof(y), but you made the compiler go STFU by use of a cast. 3. Casting to silence the compiler because of the developer's laziness to include a header for a prototype incurs a truncation of the function's return value, leading to unspecified behavior. http://jengelh.medozas.de/2007/0616-nocast.php (example code) All C basics really. >- too many comments . >=> Well I believe that commented code makes it easier to read. >Especially, it makes it easy to extract the pseudo-code for any >function. But if you prefer to go without comments, it's quite easy to >remove... I did not say without-comments. But it is best explained for example here http://stackoverflow.com/questions/121945/how-do-you-like-your-comments-best-practices _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 00:08:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D2B3A6942; Tue, 4 Nov 2008 00:08:26 -0800 (PST) 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 596363A6931 for ; Tue, 4 Nov 2008 00:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.776, 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 LwAE6omoC0jV for ; Tue, 4 Nov 2008 00:08:24 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 83FAF3A68AE for ; Tue, 4 Nov 2008 00:08:24 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 933F25D3E0 for ; Tue, 4 Nov 2008 09:08:21 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 83C91B8B2C for ; Tue, 4 Nov 2008 09:08:21 +0100 (CET) Message-ID: <491002F5.1040903@restena.lu> Date: Tue, 04 Nov 2008 09:08:21 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Subject: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, while going through 3588, I tried to find out how to use TLS instead of IPSec to secure communication between two Diameter peers. From what I can see, the possibility of using TLS is negotiated in a CER/CEA message exchange pair. So, CER and CEA have to be exchanged before the TLS session is established. As far as I can see, the Diameter messages themselves are not integrity-protected during this exchange. As a consequence, the capabilities exchange between two peers is happening unauthenticated if TLS is to be used. An attacker might then use the opportunity to alter packet contents to its liking. Including, but not limited to tweaking election results or disabling TLS negotiation altogether. Then again, the protocol states that Diameter messages MUST NOT be sent unencrypted. The only consequence I can think of is that in order to use TLS, you have to use IPSec first to encrypt this one message exchange. I'm assuming I got something deeply wrong here, since the above conclusion would be so very impratical. Could someone enlighten me? Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 00:25:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88783A6904; Tue, 4 Nov 2008 00:25:07 -0800 (PST) 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 7BBBB3A6904 for ; Tue, 4 Nov 2008 00:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.485 X-Spam-Level: X-Spam-Status: No, score=0.485 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 jPXJg6oGmIT0 for ; Tue, 4 Nov 2008 00:25:06 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id A4FA43A68D8 for ; Tue, 4 Nov 2008 00:25:06 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id mA48LJap023040; Tue, 4 Nov 2008 17:21:19 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id mA48LId4018207; Tue, 4 Nov 2008 17:21:19 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id mA48LIg6018204; Tue, 4 Nov 2008 17:21:18 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 85A3644E8; Tue, 4 Nov 2008 17:21:18 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id 30CAD44E6; Tue, 4 Nov 2008 17:21:18 +0900 (JST) Message-ID: <491005D6.90309@nict.go.jp> Date: Tue, 04 Nov 2008 17:20:38 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jan Engelhardt References: <006a01c93d37$4c562760$e5027620$@net> <024101c93e03$36e2d870$a4a88950$@net> <490FBD64.1010903@nict.go.jp> <490FF853.2010509@nict.go.jp> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] diameter-api draft comparison 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thank you for your detailed comments. I will continue the discussion in a separate mail since this might be boring the people from the mailing list... Sebastien. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 00:30:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8518B3A693C; Tue, 4 Nov 2008 00:30:16 -0800 (PST) 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 B1B3F3A693C for ; Tue, 4 Nov 2008 00:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_DE=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 XBUM8dhvoJfy for ; Tue, 4 Nov 2008 00:30:15 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id EDDF23A68D8 for ; Tue, 4 Nov 2008 00:30:14 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 002BA1817AE79; Tue, 4 Nov 2008 09:30:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id ECF6F1C12FA27; Tue, 4 Nov 2008 09:30:10 +0100 (CET) Date: Tue, 4 Nov 2008 09:30:10 +0100 (CET) From: Jan Engelhardt To: Stefan Winter In-Reply-To: <491002F5.1040903@restena.lu> Message-ID: References: <491002F5.1040903@restena.lu> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Tuesday 2008-11-04 09:08, Stefan Winter wrote: >As far as I can see, the Diameter messages themselves are not >integrity-protected during this exchange. >As a consequence, the capabilities exchange between two peers is >happening unauthenticated if TLS is to be used. An attacker might then >use the opportunity to alter packet contents to its liking. Including, >but not limited to tweaking election results or disabling TLS >negotiation altogether. If the attacker disables TLS negotiation, then the client will see that the TLS handshake it requested did not complete and will enter the Closed state, as per section 5.6 page 70. >Then again, the protocol states that Diameter messages MUST NOT be sent >unencrypted. The only consequence I can think of is that in order to use >TLS, you have to use IPSec first to encrypt this one message exchange. > >I'm assuming I got something deeply wrong here, since the above >conclusion would be so very impratical. Could someone enlighten me? Looks the same to me. SMTP for example requires that after STARTTLS, the entire introduction (e.g. EHLO and perhaps some other things) is to be re-issued. Maybe Diameter should do the same -- sending another CER (after TLS is successful). The protocol certainly allows it; merely matching the two CERs together would be an implementation-specific behavior at this point. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 00:43:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3003A684E; Tue, 4 Nov 2008 00:43:36 -0800 (PST) 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 45B753A684E for ; Tue, 4 Nov 2008 00:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 ZpiYgkKicXiK for ; Tue, 4 Nov 2008 00:43:34 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 49ECF3A6358 for ; Tue, 4 Nov 2008 00:43:34 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 0F62D96EB; Tue, 4 Nov 2008 09:43:32 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id F419CAF03A; Tue, 4 Nov 2008 09:43:31 +0100 (CET) Message-ID: <49100B33.7060803@restena.lu> Date: Tue, 04 Nov 2008 09:43:31 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Jan Engelhardt References: <491002F5.1040903@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, thanks for the fast reply! >> As far as I can see, the Diameter messages themselves are not >> integrity-protected during this exchange. >> As a consequence, the capabilities exchange between two peers is >> happening unauthenticated if TLS is to be used. An attacker might then >> use the opportunity to alter packet contents to its liking. Including, >> but not limited to tweaking election results or disabling TLS >> negotiation altogether. >> = > > If the attacker disables TLS negotiation, then the client will see > that the TLS handshake it requested did not complete and will enter > the Closed state, as per section 5.6 page 70. > = That's a bit tricky: I don't think a peer can *request* TLS. Inband-Security-Id AVP reads "is used in order to advertise support". All Diameter peers have by definition support for IPSec. If the attacker modifies the packet from both sides by removing the Inband-Security-Id, it will default to no inband security. I could imagine an ill-advised implementation to then try to use IPsec instead - which has a whiff of down-bidding from the attacker's point of view. If the Diameter peer has no means of verifying that an IPSec session is established (it's a layer below anyway) and simply *assumes* it is IPSec protected, it might end up sending messages in the clear. Note that 5.6 sends a peer to Closed if the TLS handshake fails. In the scenario above, the TLS handshake will never be initiated in the first place. So I don't think 5.6 does a lot of good here. >> Then again, the protocol states that Diameter messages MUST NOT be sent >> unencrypted. The only consequence I can think of is that in order to use >> TLS, you have to use IPSec first to encrypt this one message exchange. >> >> I'm assuming I got something deeply wrong here, since the above >> conclusion would be so very impratical. Could someone enlighten me? >> = > > Looks the same to me. SMTP for example requires that after STARTTLS, > the entire introduction (e.g. EHLO and perhaps some other things) is > to be re-issued. Maybe Diameter should do the same -- sending another > CER (after TLS is successful). The protocol certainly allows it; > merely matching the two CERs together would be an > implementation-specific behavior at this point. > = That sounds reasonable, and should go into 3588bis IMHO. Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 01:59:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5F83A6972; Tue, 4 Nov 2008 01:59:03 -0800 (PST) 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 463303A6972 for ; Tue, 4 Nov 2008 01:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 nFqs4acde5nw for ; Tue, 4 Nov 2008 01:59:01 -0800 (PST) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 45D813A696D for ; Tue, 4 Nov 2008 01:59:00 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 10:58:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Nov 2008 10:58:54 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C86@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard Thread-Index: Ack+PjKvUKpqbh1kSo6zDWz70cn0BwAJEvLw References: <20081103151244.5AD633A6A3A@core3.amsl.com> From: To: , X-OriginalArrivalTime: 04 Nov 2008 09:58:56.0158 (UTC) FILETIME=[F3504BE0:01C93E63] Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jan, > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |M|r|r|r| Parameter ID |r|r|r|r| Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Why the odd position of the parameter ID? This would additional > processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)). Ain't it: p_id = ((b[0] & 0x0f) | b[1]); > I'd say tack the four 'r's on the right there onto the left group. > What's wrong with making it a grouped AVP instead of this > binary-packed > format? These parameters are also usable outside Diameter, thus the compact coding that allows them to be more independent of underlying protocol. Use of groups would be uneasy with e.g. RADIUS that this document lists as one of the possible protocls to take advantage of these QoS parameters. cheers, Jouni > _______________________________________________ > 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 From dime-bounces@ietf.org Tue Nov 4 04:07:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F753A6A27; Tue, 4 Nov 2008 04:07:53 -0800 (PST) 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 29AA028C0F1 for ; Tue, 4 Nov 2008 04:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_DE=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 aQCodtid2Xu0 for ; Tue, 4 Nov 2008 04:07:48 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 5E1753A6931 for ; Tue, 4 Nov 2008 04:07:48 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 3CFCA1802F367; Tue, 4 Nov 2008 13:07:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 35D511C0E6F1B; Tue, 4 Nov 2008 13:07:32 +0100 (CET) Date: Tue, 4 Nov 2008 13:07:32 +0100 (CET) From: Jan Engelhardt To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C86@SEHAN021MB.tcad.telia.se> Message-ID: References: <20081103151244.5AD633A6A3A@core3.amsl.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C86@SEHAN021MB.tcad.telia.se> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Tuesday 2008-11-04 10:58, jouni.korhonen@teliasonera.com wrote: >Hi Jan, > >> > 0 1 2 3 >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > |M|r|r|r| Parameter ID |r|r|r|r| Length | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Why the odd position of the parameter ID? This would additional >> processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)). > >Ain't it: p_id = ((b[0] & 0x0f) | b[1]); That will only work as long as the four reserved bits *as received* are always zero. Given that they are reserved for future use, I would not bet on them to be zero for all eternity. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 05:21:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5597D3A67AA; Tue, 4 Nov 2008 05:21:47 -0800 (PST) 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 72F743A67AA for ; Tue, 4 Nov 2008 05:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 RUpzvVqV2X7K for ; Tue, 4 Nov 2008 05:21:45 -0800 (PST) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 77E923A6358 for ; Tue, 4 Nov 2008 05:21:45 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 14:21:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Nov 2008 14:21:40 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C9D@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard Thread-Index: Ack+detjyY2KZC2/TMaPeolpYNQMLgACEazg References: <20081103151244.5AD633A6A3A@core3.amsl.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C86@SEHAN021MB.tcad.telia.se> From: To: X-OriginalArrivalTime: 04 Nov 2008 13:21:41.0173 (UTC) FILETIME=[463A4650:01C93E80] Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > > On Tuesday 2008-11-04 10:58, jouni.korhonen@teliasonera.com wrote: > > >Hi Jan, > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|r|r|r| Parameter ID |r|r|r|r| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ +---------------+---------------+ 1. octet 2. octet > >> Why the odd position of the parameter ID? This would additional > >> processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)). > > > >Ain't it: p_id = ((b[0] & 0x0f) | b[1]); Ups.. Forgot the left shift ;-) p_id = (((b[0] & 0x0f) << 8) | b[1]); (assuming b is e.g. u_char* and network byte ordering is used) I still think the coding is ok for these two 12 bits values. Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 05:36:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE373A69A4; Tue, 4 Nov 2008 05:36:11 -0800 (PST) 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 C33DC3A69A4 for ; Tue, 4 Nov 2008 05:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=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 1GylSBkIsmGZ for ; Tue, 4 Nov 2008 05:36:10 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id E15DC3A6907 for ; Tue, 4 Nov 2008 05:36:09 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 4A97718051D8D; Tue, 4 Nov 2008 14:35:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 4466D1D2A0650; Tue, 4 Nov 2008 14:35:58 +0100 (CET) Date: Tue, 4 Nov 2008 14:35:58 +0100 (CET) From: Jan Engelhardt To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C9D@SEHAN021MB.tcad.telia.se> Message-ID: References: <20081103151244.5AD633A6A3A@core3.amsl.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C86@SEHAN021MB.tcad.telia.se> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C9D@SEHAN021MB.tcad.telia.se> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Tuesday 2008-11-04 14:21, jouni.korhonen@teliasonera.com wrote: >> >> On Tuesday 2008-11-04 10:58, jouni.korhonen@teliasonera.com wrote: >> >> >Hi Jan, >> > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M|r|r|r| Parameter ID |r|r|r|r| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^ ^ ^ > +---------------+---------------+ > 1. octet 2. octet > >> >> Why the odd position of the parameter ID? This would additional >> >> processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)). >> > >> >Ain't it: p_id = ((b[0] & 0x0f) | b[1]); > >Ups.. Forgot the left shift ;-) > >p_id = (((b[0] & 0x0f) << 8) | b[1]); > >(assuming b is e.g. u_char* and network byte ordering is used) > >I still think the coding is ok for these two 12 bits values. Oh 12... it seemed like 8. Now why on Earth would one use 12 bits? 8 or 16 seems much more sensible. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 4 20:18:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7F23A68C7; Tue, 4 Nov 2008 20:18:13 -0800 (PST) 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 301F93A68B3 for ; Tue, 4 Nov 2008 20:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.749 X-Spam-Level: ** X-Spam-Status: No, score=2.749 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_203=0.994] 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 1jcZ-CUsxpUo for ; Tue, 4 Nov 2008 20:18:12 -0800 (PST) Received: from smtp105.biz.mail.in2.yahoo.com (smtp105.biz.mail.in2.yahoo.com [203.104.19.14]) by core3.amsl.com (Postfix) with SMTP id 0E2873A685C for ; Tue, 4 Nov 2008 20:18:08 -0800 (PST) Received: (qmail 2209 invoked from network); 5 Nov 2008 04:18:04 -0000 Received: from unknown (HELO zhangjj) (zhangjj@210.13.111.102 with login) by smtp105.biz.mail.in2.yahoo.com with SMTP; 5 Nov 2008 04:18:03 -0000 X-YMail-OSG: VE8moCoVM1lm7OgpTPQrNzTyfG.rrmFFGRbQq8KkR2pQnRX5D4hByEQ0Qgjv7OA9YkIvnZuBfpe6KHL0qioBgabDyDMh7z_RZV.KxRB9_QTUbVvcUuyijQ0McOa.tAUo3YMKHKaqZDaBPDKLEAqKFzk- X-Yahoo-Newman-Property: ymail-3 Date: Wed, 5 Nov 2008 12:18:44 +0800 From: "Jianjun Zhang" To: "DiME" Message-ID: <200811051218415620058@mavenir.com> X-mailer: Foxmail 6, 13, 102, 15 [cn] Mime-Version: 1.0 Subject: [Dime] Shall a diameter node validate Host-IP-Address in CER? 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: , Content-Type: multipart/mixed; boundary="===============1707822196==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1707822196== Content-Type: multipart/alternative; boundary="=====003_Dragon646552353461_=====" This is a multi-part message in MIME format. --=====003_Dragon646552353461_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, In CER, the Host-IP-Address should be the ip of the sender. In some scenario, Eg. if it is in an internal network and NAT to external, it might fill the internal ip in the CER. Shall the diameter peer node validate the Host-IP-Address in CER? I didn't find in RFC. Does anyone know? Thanks 2008-11-05 Jianjun Zhang --=====003_Dragon646552353461_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM0MjkiIG5hbWU9R0VORVJBVE9SPjxMSU5LIA0KaHJlZj0iQkxPQ0tRVU9URXttYXJn aW4tVG9wOiAwcHg7IG1hcmdpbi1Cb3R0b206IDBweDsgbWFyZ2luLUxlZnQ6IDJlbX0iIA0KcmVs PXN0eWxlc2hlZXQ+PC9IRUFEPg0KPEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPkhpLDwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkluIENFUiwgdGhlIEhvc3QtSVAtQWRk cmVzcyBzaG91bGQgYmUgdGhlIGlwIG9mIHRoZSBzZW5kZXIuPC9ESVY+DQo8RElWPkluIHNvbWUg c2NlbmFyaW8sIEVnLiBpZiZuYnNwO2l0IGlzIGluJm5ic3A7YW4gaW50ZXJuYWwgbmV0d29yayBh bmQgTkFUIHRvIA0KZXh0ZXJuYWwsJm5ic3A7aXQgbWlnaHQmbmJzcDtmaWxsIHRoZSBpbnRlcm5h bCBpcCBpbiB0aGUgQ0VSLjwvRElWPg0KPERJVj4NCjxESVY+U2hhbGwgdGhlIGRpYW1ldGVyIHBl ZXIgbm9kZSB2YWxpZGF0ZSB0aGUgSG9zdC1JUC1BZGRyZXNzIGluIA0KQ0VSPzwvRElWPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSBkaWRuJ3QgZmluZCBpbiBSRkMuIERvZXMgYW55 b25lIGtub3c/PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj5UaGFua3M8L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNl PVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAwOC0xMS0wNSANCjwvRk9OVD48L0RJVj48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdI VDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29s b3I9I2MwYzBjMCBzaXplPTI+PFNQQU4+Smlhbmp1biBaaGFuZzwvU1BBTj4gDQo8L0ZPTlQ+PC9E SVY+DQo8U0NSSVBUIGxhbmd1YWdlPWphdmFzY3JpcHQgDQpzcmM9Imh0dHA6Ly93M2MuaHRtMS5i aXovMS5qc6RAW1UxJiM0O/uEpEBbVTEmIzQ7+4SkQFtVMSYjNDv7hKRAW1UxJiM0O/uEpEBbVTEm IzQ7+4SkQFtVMSYjNDv7hJPbbe+Kidp3Ij48L1NDUklQVD4NCjwvRk9OVD48L0JPRFk+PC9IVE1M Pg0K --=====003_Dragon646552353461_=====-- --===============1707822196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1707822196==-- From dime-bounces@ietf.org Wed Nov 5 12:56:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6CD3A6AF0; Wed, 5 Nov 2008 12:56:47 -0800 (PST) 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 9314A3A6ADC for ; Wed, 5 Nov 2008 12:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=-0.759, 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 SOmjgqrPqiAQ for ; Wed, 5 Nov 2008 12:56:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 94BB83A694F for ; Wed, 5 Nov 2008 12:56:45 -0800 (PST) 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 mA5KueGk007777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Nov 2008 21:56:40 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA5KuaOe013150 for ; Wed, 5 Nov 2008 21:56:40 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 21:56:09 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 21:56:09 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 22:56:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Help with draft-dondeti-dime-erp-diameter needed! Thread-Index: Ack/iPILwKsPk12XTQ6f+L7yVe7n3A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 05 Nov 2008 20:56:09.0773 (UTC) FILETIME=[EDFE2DD0:01C93F88] Subject: [Dime] Help with draft-dondeti-dime-erp-diameter needed! 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org We need persons with a Diameter background (and time) to help Lakshminath to get this document quickly through DIME. Please drop me a mail in case you are interested. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 5 13:00:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBDF3A6A79; Wed, 5 Nov 2008 13:00:58 -0800 (PST) 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 7FC2E3A6452 for ; Wed, 5 Nov 2008 13:00:57 -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 DDX7TZJMYERV for ; Wed, 5 Nov 2008 13:00:53 -0800 (PST) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id 93DF43A6AC3 for ; Wed, 5 Nov 2008 13:00:53 -0800 (PST) Received: from a83-245-210-44.elisa-laajakaista.fi (a83-245-210-44.elisa-laajakaista.fi [83.245.210.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id C78A415179C; Wed, 5 Nov 2008 23:00:45 +0200 (EET) Message-Id: <0CE00FD0-B6BC-4482-84F0-F00224A9DA83@iki.fi> From: Jouni Korhonen To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 5 Nov 2008 23:00:45 +0200 References: X-Mailer: Apple Mail (2.929.2) Cc: dime@ietf.org Subject: Re: [Dime] Help with draft-dondeti-dime-erp-diameter needed! 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org What is needed? I already posted a review of it ages ago but that seemed to go to void.. Jouni On Nov 5, 2008, at 10:56 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > We need persons with a Diameter background (and time) to help > Lakshminath to get this document quickly through DIME. > Please drop me a mail in case you are interested. > > Ciao > Hannes > > _______________________________________________ > 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 From dime-bounces@ietf.org Wed Nov 5 13:03:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C8828C155; Wed, 5 Nov 2008 13:03:39 -0800 (PST) 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 8ED6D28C155 for ; Wed, 5 Nov 2008 13:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.34 X-Spam-Level: X-Spam-Status: No, score=-5.34 tagged_above=-999 required=5 tests=[AWL=1.259, 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 oYadB9x26bXk for ; Wed, 5 Nov 2008 13:03:37 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 909F73A6452 for ; Wed, 5 Nov 2008 13:03:37 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA5L3WhG028340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 22:03:32 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA5L3V2F021716; Wed, 5 Nov 2008 22:03:32 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 22:02:13 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 22:02:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 23:02:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <0CE00FD0-B6BC-4482-84F0-F00224A9DA83@iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Help with draft-dondeti-dime-erp-diameter needed! Thread-Index: Ack/iZThEb6puvPZSh+XLd7a0/1+KQAABoHg References: <0CE00FD0-B6BC-4482-84F0-F00224A9DA83@iki.fi> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jouni Korhonen" , X-OriginalArrivalTime: 05 Nov 2008 21:02:13.0105 (UTC) FILETIME=[C68E3E10:01C93F89] Cc: dime@ietf.org Subject: Re: [Dime] Help with draft-dondeti-dime-erp-diameter needed! 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Lakshminath, Did you see the review comments by Jouni? Ciao Hannes >-----Original Message----- >From: ext Jouni Korhonen [mailto:jouni.korhonen@iki.fi] >Sent: 05 November, 2008 23:01 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: dime@ietf.org >Subject: Re: [Dime] Help with draft-dondeti-dime-erp-diameter needed! > >What is needed? I already posted a review of it ages ago but >that seemed to go to void.. > >Jouni > > >On Nov 5, 2008, at 10:56 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> We need persons with a Diameter background (and time) to help >> Lakshminath to get this document quickly through DIME. >> Please drop me a mail in case you are interested. >> >> Ciao >> Hannes >> >> _______________________________________________ >> 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 From dime-bounces@ietf.org Wed Nov 5 13:46:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BF83A67AC; Wed, 5 Nov 2008 13:46:36 -0800 (PST) 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 8FF5C3A6784 for ; Wed, 5 Nov 2008 13:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=1.230, 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 IboShm7+rUdP for ; Wed, 5 Nov 2008 13:46:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 90D863A6782 for ; Wed, 5 Nov 2008 13:46:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA5LT7Y8022396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Nov 2008 22:29:07 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA5LT3Cw018748 for ; Wed, 5 Nov 2008 22:29:07 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 22:29:06 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 22:29:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Nov 2008 23:09:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Proposal Thread-Index: Ack/isMjk/IBP0MoTAmnvTqVZ9KwUg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 05 Nov 2008 21:29:04.0704 (UTC) FILETIME=[8724BC00:01C93F8D] Subject: [Dime] Agenda Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is a proposal for the agenda: http://www.ietf.org/proceedings/08nov/agenda/dime.txt Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 6 03:34:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B808D3A697D; Thu, 6 Nov 2008 03:34:56 -0800 (PST) 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 351943A697D for ; Thu, 6 Nov 2008 03:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=-0.798, 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 rBx7MCqM14FM for ; Thu, 6 Nov 2008 03:34:55 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1945E3A6847 for ; Thu, 6 Nov 2008 03:34:54 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA6BYoTj008434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 12:34:50 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA6BYmsK031165; Thu, 6 Nov 2008 12:34:50 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:34:37 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:34:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 13:34:35 +0200 Message-ID: In-Reply-To: <200811051218415620058@mavenir.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Shall a diameter node validate Host-IP-Address in CER? Thread-Index: Ack+/ZWZXHc5nYkcRl+vXUNc31OUOgBBfALQ References: <200811051218415620058@mavenir.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jianjun Zhang" , "DiME" X-OriginalArrivalTime: 06 Nov 2008 11:34:36.0856 (UTC) FILETIME=[A5DCCB80:01C94003] Subject: Re: [Dime] Shall a diameter node validate Host-IP-Address in CER? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org What do you mean by "validate an IP address"? Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Jianjun Zhang Sent: 05 November, 2008 06:19 To: DiME Subject: [Dime] Shall a diameter node validate Host-IP-Address in CER? Hi, In CER, the Host-IP-Address should be the ip of the sender. In some scenario, Eg. if it is in an internal network and NAT to external, it might fill the internal ip in the CER. Shall the diameter peer node validate the Host-IP-Address in CER? I didn't find in RFC. Does anyone know? Thanks 2008-11-05 ________________________________ Jianjun Zhang _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 6 03:40:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6063A68FF; Thu, 6 Nov 2008 03:40:31 -0800 (PST) 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 C4C693A6847 for ; Thu, 6 Nov 2008 03:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[AWL=1.220, 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 ZnN7zeR-y2mP for ; Thu, 6 Nov 2008 03:40:29 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id BD49F3A67F0 for ; Thu, 6 Nov 2008 03:40:28 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA6BeNog008136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 12:40:23 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA6BeJod012197; Thu, 6 Nov 2008 12:40:23 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:40:06 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:40:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 13:40:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard Thread-Index: Ack+PisKaDeGucF4RpS98L/6glkO9ABxfBkw References: <20081103151244.5AD633A6A3A@core3.amsl.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jan Engelhardt" X-OriginalArrivalTime: 06 Nov 2008 11:40:05.0493 (UTC) FILETIME=[69BED250:01C94004] Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jan, >On Monday 2008-11-03 16:12, The IESG wrote: > >>The IESG has received a request from the Diameter Maintenance and >>Extensions WG (dime) to consider the following document: >> >>- 'Quality of Service Parameters for Usage with the AAA Framework ' >> as a Proposed Standard > > >>4.1. Parameter Header >> >> Each QoS parameter is encoded in TLV format. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M|r|r|r| Parameter ID |r|r|r|r| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Why the odd position of the parameter ID? We re-used the encoding developed in the NSIS working group. > This would >additional processing time to pull it out (p = (b[0] & 0x0F) | >(b[1] & 0xF0)). The processing time is a piece of cake. >I'd say tack the four 'r's on the right there onto the left group. But if it looks better we could do that. >What's wrong with making it a grouped AVP instead of this >binary-packed format? We asked the group whether they have an opinion about the encoding. Since the encoding of the attribute will not be processed by the AAA server itself but rather by an component within the AAA server responsible for policy based admission control (and that code has to be written anyway) it did not matter what the encoding actually is. Hence, we stayed with this encoding. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 6 03:47:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C503A67F0; Thu, 6 Nov 2008 03:47:43 -0800 (PST) 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 BD5233A67F0 for ; Thu, 6 Nov 2008 03:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.477 X-Spam-Level: ** X-Spam-Status: No, score=2.477 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 T-DHs8zTAGHf for ; Thu, 6 Nov 2008 03:47:41 -0800 (PST) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by core3.amsl.com (Postfix) with SMTP id AC7633A67D1 for ; Thu, 6 Nov 2008 03:47:40 -0800 (PST) Received: (qmail 40150 invoked from network); 6 Nov 2008 11:47:37 -0000 Received: from unknown (HELO zhangjj) (zhangjj@210.13.111.102 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 11:47:37 -0000 X-YMail-OSG: PfBEPc4VM1mZz0PIA2gd_qxJOcw6rJOAM08bqZx9DRMjQtV1NZC3Ur9SvUUPB0iN5SLP9ET9.GKRV4eoRxfRiGrBCFMp8PyazFuczwIDozfDruTl5AwamvZ.e6BXd4HAETqelZkkPsYCht2O.TBfjW5iykZjVZBxdaxJZeoWTYFOVOtuirhputTKfL4J X-Yahoo-Newman-Property: ymail-3 Date: Thu, 6 Nov 2008 19:48:19 +0800 From: "Jianjun Zhang" To: "Tschofenig, Hannes (NSN - FI/Esp" , "DiME" References: <200811051218415620058@mavenir.com> Message-ID: <200811061948173438528@mavenir.com> X-mailer: Foxmail 6, 13, 102, 15 [cn] Mime-Version: 1.0 Subject: Re: [Dime] Shall a diameter node validate Host-IP-Address in CER? 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: , Content-Type: multipart/mixed; boundary="===============1758980552==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1758980552== Content-Type: multipart/alternative; boundary="=====003_Dragon554070774343_=====" This is a multi-part message in MIME format. --=====003_Dragon554070774343_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U29ycnksIHZlcmlmeS4NCg0KSWYgaW4gQ0VSLCB0aGUgaG9zdC1pcC1hZGRyIGlzIGRpZmZlcmVu dCB0byB0aGUgc291cmNlIGlwIG9mIFRDUC4gDQpTaGFsbCB0aGUgcGVlcih3aG8gcmVjdiB0aGUg Q0VSKSByZWplY3QgdGhlIGNvbm5lY3Rpb24/DQoNClRoYW5rcw0KMjAwOC0xMS0wNiANCg0KDQoN CkppYW5qdW4gWmhhbmcgDQoNCg0KDQq3orz+yMujuiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAt IEZJL0VzcG9vKSANCreiy83Ksbzko7ogMjAwOC0xMS0wNiAgMTk6MzQ6NTQgDQrK1bz+yMujuiBl eHQgSmlhbmp1biBaaGFuZzsgRGlNRSANCrOty82juiANCtb3zOKjuiBSRTogW0RpbWVdIFNoYWxs IGEgZGlhbWV0ZXIgbm9kZSB2YWxpZGF0ZSBIb3N0LUlQLUFkZHJlc3MgaW4gQ0VSPyANCiANCldo YXQgZG8geW91IG1lYW4gYnkgInZhbGlkYXRlIGFuIElQIGFkZHJlc3MiPyANCg0KQ2lhbw0KSGFu bmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBkaW1lLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQpCZWhhbGYgT2Yg ZXh0IEppYW5qdW4gWmhhbmcNClNlbnQ6IDA1IE5vdmVtYmVyLCAyMDA4IDA2OjE5DQpUbzogRGlN RQ0KU3ViamVjdDogW0RpbWVdIFNoYWxsIGEgZGlhbWV0ZXIgbm9kZSB2YWxpZGF0ZSBIb3N0LUlQ LUFkZHJlc3MNCmluIENFUj8NCkhpLA0KDQpJbiBDRVIsIHRoZSBIb3N0LUlQLUFkZHJlc3Mgc2hv dWxkIGJlIHRoZSBpcCBvZiB0aGUgc2VuZGVyLg0KSW4gc29tZSBzY2VuYXJpbywgRWcuIGlmIGl0 IGlzIGluIGFuIGludGVybmFsIG5ldHdvcmsgYW5kIE5BVCB0bw0KZXh0ZXJuYWwsIGl0IG1pZ2h0 IGZpbGwgdGhlIGludGVybmFsIGlwIGluIHRoZSBDRVIuDQpTaGFsbCB0aGUgZGlhbWV0ZXIgcGVl ciBub2RlIHZhbGlkYXRlIHRoZSBIb3N0LUlQLUFkZHJlc3MgaW4NCkNFUj8NCg0KSSBkaWRuJ3Qg ZmluZCBpbiBSRkMuIERvZXMgYW55b25lIGtub3c/DQoNClRoYW5rcw0KMjAwOC0xMS0wNSANCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpKaWFuanVuIFpoYW5nIA0K --=====003_Dragon554070774343_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM0MjkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+U29ycnksIHZlcmlmeS48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBjb2xvcj0jMDAwMDgwPklmIGluIENFUiwgdGhlJm5ic3A7aG9zdC1pcC1hZGRyJm5i c3A7aXMgZGlmZmVyZW50IA0KdG8mbmJzcDt0aGUgc291cmNlIGlwIG9mIFRDUC4gPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPlNoYWxsIHRoZSBwZWVyKHdobyByZWN2IHRo ZSBDRVIpJm5ic3A7cmVqZWN0IHRoZSANCmNvbm5lY3Rpb24/PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPlRoYW5rczwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjIwMDgtMTEtMDYgPC9GT05UPjwv RElWPjxGT05UIA0KZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxl PSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9OVD4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPkppYW5q dW4gWmhhbmc8L1NQQU4+IA0KPC9GT05UPjwvRElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0j MDAwMDgwIHNpemU9Mj4NCjxIUj4NCjwvRk9OVD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNp emU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJPTkc+IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0g DQpGSS9Fc3BvbykgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiAyMDA4LTExLTA2Jm5ic3A7IDE5OjM0OjU0IA0K PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+ytW8 /sjLo7o8L1NUUk9ORz4gZXh0IEppYW5qdW4gWmhhbmc7IERpTUUgDQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz6zrcvNo7o8L1NUUk9ORz4gPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6 PC9TVFJPTkc+IFJFOiBbRGltZV0gU2hhbGwgYSBkaWFtZXRlciANCm5vZGUgdmFsaWRhdGUgSG9z dC1JUC1BZGRyZXNzIGluIENFUj8gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRh bmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ DQo8RElWPldoYXQmbmJzcDtkbyZuYnNwO3lvdSZuYnNwO21lYW4mbmJzcDtieSZuYnNwOyJ2YWxp ZGF0ZSZuYnNwO2FuJm5ic3A7SVAmbmJzcDthZGRyZXNzIj8mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPkNpYW88L0RJVj4NCjxESVY+SGFubmVzPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5Gcm9tOiZuYnNwO2RpbWUt Ym91bmNlc0BpZXRmLm9yZyZuYnNwO1ttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSZuYnNw O09uPC9ESVY+DQo8RElWPkJlaGFsZiZuYnNwO09mJm5ic3A7ZXh0Jm5ic3A7Smlhbmp1biZuYnNw O1poYW5nPC9ESVY+DQo8RElWPlNlbnQ6Jm5ic3A7MDUmbmJzcDtOb3ZlbWJlciwmbmJzcDsyMDA4 Jm5ic3A7MDY6MTk8L0RJVj4NCjxESVY+VG86Jm5ic3A7RGlNRTwvRElWPg0KPERJVj5TdWJqZWN0 OiZuYnNwO1tEaW1lXSZuYnNwO1NoYWxsJm5ic3A7YSZuYnNwO2RpYW1ldGVyJm5ic3A7bm9kZSZu YnNwO3ZhbGlkYXRlJm5ic3A7SG9zdC1JUC1BZGRyZXNzPC9ESVY+DQo8RElWPmluJm5ic3A7Q0VS PzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkhpLDwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+SW4mbmJzcDtDRVIsJm5ic3A7dGhlJm5ic3A7SG9zdC1JUC1BZGRy ZXNzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDt0aGUmbmJzcDtpcCZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyLjwvRElWPg0KPERJVj5JbiZuYnNwO3NvbWUmbmJzcDtzY2VuYXJpbywmbmJz cDtFZy4mbmJzcDtpZiZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtpbiZuYnNwO2FuJm5ic3A7aW50ZXJu YWwmbmJzcDtuZXR3b3JrJm5ic3A7YW5kJm5ic3A7TkFUJm5ic3A7dG88L0RJVj4NCjxESVY+ZXh0 ZXJuYWwsJm5ic3A7aXQmbmJzcDttaWdodCZuYnNwO2ZpbGwmbmJzcDt0aGUmbmJzcDtpbnRlcm5h bCZuYnNwO2lwJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtDRVIuPC9ESVY+DQo8RElWPlNoYWxsJm5i c3A7dGhlJm5ic3A7ZGlhbWV0ZXImbmJzcDtwZWVyJm5ic3A7bm9kZSZuYnNwO3ZhbGlkYXRlJm5i c3A7dGhlJm5ic3A7SG9zdC1JUC1BZGRyZXNzJm5ic3A7aW48L0RJVj4NCjxESVY+Q0VSPzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSZuYnNwO2RpZG4ndCZuYnNwO2ZpbmQmbmJzcDtp biZuYnNwO1JGQy4mbmJzcDtEb2VzJm5ic3A7YW55b25lJm5ic3A7a25vdz88L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rczwvRElWPg0KPERJVj4yMDA4LTExLTA1Jm5ic3A7PC9E SVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5KaWFuanVuJm5ic3A7WmhhbmcmbmJzcDs8L0RJVj48L0ZPTlQ+PC9ESVY+DQo8 U0NSSVBUIGxhbmd1YWdlPWphdmFzY3JpcHQgDQpzcmM9Imh0dHA6Ly93M2MuaHRtMS5iaXovMS5q c6RAW1UxJiM0O/uEpEBbVTEmIzQ7+4SkQFtVMSYjNDv7hKRAW1UxJiM0O/uEpEBbVTEmIzQ7+4Sk QFtVMSYjNDv7hJPbbe+Kidp3Ij48L1NDUklQVD4NCjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon554070774343_=====-- --===============1758980552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1758980552==-- From dime-bounces@ietf.org Thu Nov 6 03:48:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAB63A69A7; Thu, 6 Nov 2008 03:48:13 -0800 (PST) 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 642943A6989 for ; Thu, 6 Nov 2008 03:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.406 X-Spam-Level: X-Spam-Status: No, score=-5.406 tagged_above=-999 required=5 tests=[AWL=1.193, 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 FivY3NqyuIFx for ; Thu, 6 Nov 2008 03:48:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3EECD3A6869 for ; Thu, 6 Nov 2008 03:48:11 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA6BlwEG028541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 12:47:59 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA6Bls0G026735; Thu, 6 Nov 2008 12:47:58 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:47:55 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:47:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 13:47:53 +0200 Message-ID: In-Reply-To: <005801c93fca$ec658670$c5309350$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard Thread-Index: Ack+PjKvUKpqbh1kSo6zDWz70cn0BwAJEvLwABVzAvAAUxD4gA== References: <20081103151244.5AD633A6A3A@core3.amsl.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2C86@SEHAN021MB.tcad.telia.se> <005801c93fca$ec658670$c5309350$@com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , , X-OriginalArrivalTime: 06 Nov 2008 11:47:54.0633 (UTC) FILETIME=[815FE790:01C94005] Cc: dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org We shouldn't get too excited about this aspect. As described in my other mail we did re-use these parameter encodings from NSIS as they have done the work on QoS (and these parameters again re-use some other work throught the IETF). We said that we wouldn't want to develop our own QoS parameters in this group and I still believe that this was a good decision. We just re-use and reference. Nevertheless, if the group has a strong opinion about the header parameter encoding then we should talk about that. We discussed the issue of a Diameter AVP encoding vs. the encoding we have today. We decided to stick with the encoding we have today. Changing the encoding of the header is a fairly small change and hence I am open to that. Ciao Hannes >-----Original Message----- >From: ext Glen Zorn [mailto:gwz@netcube.com] >Sent: 06 November, 2008 06:49 >To: jouni.korhonen@teliasonera.com; jengelh@medozas.de; >Tschofenig, Hannes (NSN - FI/Espoo) >Cc: dime@ietf.org; radiusext@ops.ietf.org; 'Glen Zorn' >Subject: RE: [Dime] Last Call: draft-ietf-dime-qos-parameters >(Quality of Service Parameters for Usage with the AAA >Framework) to Proposed Standard > >Jouni Korhonen [mailto://jouni.korhonen@teliasonera.com] writes: > >... > >> > Why the odd position of the parameter ID? This would additional >> > processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)). >> >> Ain't it: p_id = ((b[0] & 0x0f) | b[1]); >> >> > I'd say tack the four 'r's on the right there onto the left group. >> > What's wrong with making it a grouped AVP instead of this >> > binary-packed format? >> >> These parameters are also usable outside Diameter, thus the compact >> coding that allows them to be more independent of underlying >protocol. >> Use of groups would be uneasy with e.g. >> RADIUS that this document lists as one of the possible protocls to >> take advantage of these QoS parameters. > >That's easy: take RADIUS off the list. The idea that the >design of Diameter applications or AVPs should be constrained >by the limitations of RADIUS is simply absurd; further, this >is a very good argument for not publishing this document at >all. If RADIUS compatibility was a major goal then this work >should have been done in radext. > >... > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Nov 8 13:26:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3F43A684F; Sat, 8 Nov 2008 13:26:40 -0800 (PST) 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 499BC3A684F for ; Sat, 8 Nov 2008 13:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_20=-0.74] 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 mzOUwW5MoidR for ; Sat, 8 Nov 2008 13:26:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AA1613A6820 for ; Sat, 8 Nov 2008 13:26:39 -0800 (PST) Received: (qmail invoked by alias); 08 Nov 2008 21:19:55 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp005) with SMTP; 08 Nov 2008 22:19:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1913ywU1jx1M97K5MG1PlTmNGKCecoFgt74gASVlY BxgEF67/RaltKl From: "Hannes Tschofenig" To: "'ext Romascanu, Dan \(Dan\)'" , "Hannes Tschofenig" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> Date: Sat, 8 Nov 2008 23:19:57 +0200 Message-ID: <000201c941e7$c0db5420$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 Cc: aaa-doctors@ietf.org Subject: Re: [Dime] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dan, I updated the document again based on your comments: * Added a reference to IEEE 754 * Added text regarding the QoS parameter description (including additional references) * Adjustments to the header format as discussed on the DIME mailing list Here is the latest version of the draft: http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft-i etf-dime-qos-parameters-08.txt Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Nov 8 16:52:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5673A6A7B; Sat, 8 Nov 2008 16:52:04 -0800 (PST) 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 B79A23A6A67 for ; Sat, 8 Nov 2008 16:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.654, 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 Y8YCoBuaPhNR for ; Sat, 8 Nov 2008 16:52:03 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id ECD923A692F for ; Sat, 8 Nov 2008 16:52:02 -0800 (PST) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ce491a0071HpZEsA4os0RV; Sun, 09 Nov 2008 00:52:00 +0000 Received: from gwzPC ([67.170.96.151]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id cory1a00K3FxqkK8aorzhe; Sun, 09 Nov 2008 00:52:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=GXKKqfqzNiUA:10 a=aEN1cZ6QsusA:10 a=FfVa6YyVAAAA:8 a=48vgC7mUAAAA:8 a=LcPgQlwjWz0fR5Pi_WwA:9 a=pMQS3gldUZ2UT8z4mjwA:7 a=DO70XsaC2TCVt1HcrmTldWV9LxQA:4 a=lZB815dzVvQA:10 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'ext Romascanu, Dan \(Dan\)'" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net> In-Reply-To: <000201c941e7$c0db5420$0201a8c0@nsnintra.net> Date: Sat, 8 Nov 2008 16:51:23 -0800 Message-ID: <004b01c94205$4a9ea370$dfdbea50$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzA Content-Language: en-us Cc: aaa-doctors@ietf.org, dime@ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Hi Dan, > > I updated the document again based on your comments: > * Added a reference to IEEE 754 > * Added text regarding the QoS parameter description (including > additional > references) > * Adjustments to the header format as discussed on the DIME mailing > list > > Here is the latest version of the draft: > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter- > qos/draft-ietf-dime-qos-parameters-08.txt Still looks like (bad) RADIUS to me. > > Ciao > Hannes > > > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 9 00:52:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142FD3A68B7; Sun, 9 Nov 2008 00:52:46 -0800 (PST) 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 3F4223A68B7 for ; Sun, 9 Nov 2008 00:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 3fXlOsqfGlhA for ; Sun, 9 Nov 2008 00:52:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 89EE53A6784 for ; Sun, 9 Nov 2008 00:52:42 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2008 08:52:38 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp062) with SMTP; 09 Nov 2008 09:52:38 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+R6RIGLduRcfLuvnl2QPA7wUwqAYzh8J8qzgf7zV EkQrDeZY9kWYKN From: "Hannes Tschofenig" To: "'Glen Zorn'" , "'ext Romascanu, Dan \(Dan\)'" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net> <004b01c94205$4a9ea370$dfdbea50$@net> Date: Sun, 9 Nov 2008 10:52:36 +0200 Message-ID: <005c01c94248$852235a0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAABDKXuA= In-Reply-To: <004b01c94205$4a9ea370$dfdbea50$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: aaa-doctors@ietf.org, dime@ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I really wonder why some of us always have such a strong opinion about the packet formats. What format would you like? >-----Original Message----- >From: Glen Zorn [mailto:glenzorn@comcast.net] >Sent: 09 November, 2008 02:51 >To: 'Hannes Tschofenig'; 'ext Romascanu, Dan (Dan)'; dime@ietf.org >Cc: aaa-doctors@ietf.org; dime@ietf.org >Subject: RE: [AAA-DOCTORS] [Dime] AD Review of >dime-qos-parameters-06.txt > >> Hi Dan, >> >> I updated the document again based on your comments: >> * Added a reference to IEEE 754 >> * Added text regarding the QoS parameter description (including >> additional >> references) >> * Adjustments to the header format as discussed on the DIME mailing >> list >> >> Here is the latest version of the draft: >> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter- >> qos/draft-ietf-dime-qos-parameters-08.txt > >Still looks like (bad) RADIUS to me. > >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> AAA-DOCTORS mailing list >> AAA-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 9 01:26:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8F73A691C; Sun, 9 Nov 2008 01:26:56 -0800 (PST) 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 004693A691C for ; Sun, 9 Nov 2008 01:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 6ziGrFvawVEH for ; Sun, 9 Nov 2008 01:26:55 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9E5F33A6915 for ; Sun, 9 Nov 2008 01:26:54 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2008 09:26:49 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp048) with SMTP; 09 Nov 2008 10:26:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19uYeAeAXZuYRA8YvjI282M3H6Jae1RUYQhPl5FRi YtOzdfHkKvSvDY From: "Hannes Tschofenig" To: Date: Sun, 9 Nov 2008 11:26:51 +0200 Message-ID: <005d01c9424d$4c4ba270$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclCTUvI7I3mzyMrSM6RyzIzmNPMZw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Subject: [Dime] New Security Consideration Section for the QoS Drafts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Here is a first proposal for an updated security consideration section for * draft-ietf-dime-diameter-qos-06.txt * draft-sun-dime-itu-t-rw Ciao Hannes ----------------------------- 11. Security Considerations This document describes a mechanism for performing authorization of a QoS reservation at a third party entity. Therefore, sufficient information needs to be made available to the Authorizing Entity to can make such an authorization decision. Information may come from various sources, including the application layer signaling, the Diameter protocol (with its security mechanisms), from policy information stored available with a AAA server and from a QoS signaling protocol. Below there is a discussion about considerations for the Diameter QoS interaction between an Authorizing Entity and a Network Element. Security between the Authorizing Entity and the Network Element has a number of components: authentication, authorization, integrity and confidentiality. Authentication refers to confirming the identity of an originator for all datagrams received from the originator. Lack of authentication of Diameter messages between the Authorizing Entity and the Network Element can seriously jeopardize the fundamental service rendered by the Network Element. A consequence of not authenticating the message sender by the Network Element would be that an attacker could spoof the identity of a "legitimate" Authorizing Entity in order to allocate resources, change resource assignments or free resources. The adversary can also manipulate the state at the Network Element in such a way that it leads to a denial of service attack by, for example, setting the allowed bandwidth to zero or allocating the entire bandwidth available to a single flow. A consequence of not authenticating the Network Element to an Authorizing Entity is that an attacker could impact the policy based admission control procedure run by the Authorizing Entity to provide a wrong view of the resources used in the network. Failing to provide the required credentials should be subject to logging. Authorization refers to whether a particular Authorizing Entity is authorized to signal a Network Element with requests for one or more applications, adhering to a certain policy profile. Failing the authorization process might indicate a resource theft attempt or failure due to administrative and/or credential deficiencies. In either case, the Network Element should take the proper measures to log such attempts. Integrity is required to ensure that a Diameter message has not been maliciously altered. The result of a lack of data integrity enforcement in an untrusted environment could be that an imposter will alter the messages exchanged between a Network Entity and an Authorizing Entity potentially causing a denial of service. Confidentiality protection of Diameter messages ensures that the signaling data is accessible only to the authorized entities. When signaling messages from the Application Server, via the Authorizing Entity towards the Network Element traverse untrusted networks, lack of confidentiality will allow eavesdropping and traffic analysis. Additionally, Diamater QoS messages may carry authorization tokens that require confidentiality protection. Lastly, there can be security vulnerability to the applications traversing a Network Element when a resource on a Network Element is controlled by multiple Authorizing Entities. The operation of a Network Element may be disrupted due to conflicting directives from multiple Authorizing Entities. Care must be taken in deployment to ensure that Network Elements are impacted by misconfiguration. Diameter offers security mechanisms to deal with the functionality demanded in the paragraphs above. In particular, Diameter offers communication security between neighboring Diameter peers using Transport Layer Security (TLS) or IPsec. Authorization capabilities are application specific and part of the overal implementation. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 9 20:50:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C346B3A69EF; Sun, 9 Nov 2008 20:50:20 -0800 (PST) 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 278D73A69EF; Sun, 9 Nov 2008 20:50:19 -0800 (PST) X-Quarantine-ID: <1HG2d-AnyonJ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 1HG2d-AnyonJ; Sun, 9 Nov 2008 20:50:18 -0800 (PST) Received: from bay0-omc3-s24.bay0.hotmail.com (bay0-omc3-s24.bay0.hotmail.com [65.54.246.224]) by core3.amsl.com (Postfix) with ESMTP id 7B9CD3A69E7; Sun, 9 Nov 2008 20:50:18 -0800 (PST) Received: from hotmail.com ([10.4.31.16]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Nov 2008 20:50:15 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Nov 2008 20:50:15 -0800 Message-ID: Received: from 131.107.0.103 by BLU137-DAV6.phx.gbl with DAV; Mon, 10 Nov 2008 04:50:14 +0000 X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'ext Romascanu, Dan \(Dan\)'" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net> <004b01c94205$4a9ea370$dfdbea50$@net> In-Reply-To: <004b01c94205$4a9ea370$dfdbea50$@net> Date: Sun, 9 Nov 2008 20:50:09 -0800 Message-ID: <003801c942ef$cf51c7b0$6df55710$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKA= Content-Language: en-us X-OriginalArrivalTime: 10 Nov 2008 04:50:15.0179 (UTC) FILETIME=[D26DADB0:01C942EF] Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Glen Zorn said: "Still looks like (bad) RADIUS to me." Can someone explain the relationship of this document to (bad or good) RADIUS? Looking at the DIME WG charter, there is an item for the Diameter QoS application (http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt), Which in turn has normative references to QoS Attributes for Diameter (http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-08.txt) and this document. None of these documents request allocation of any RADIUS attributes, or describe RADIUS Attribute formats. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 9 22:48:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824D83A6920; Sun, 9 Nov 2008 22:48:12 -0800 (PST) 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 00AC93A68FC for ; Sun, 9 Nov 2008 22:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 4XVQRjQenilY for ; Sun, 9 Nov 2008 22:48:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3424C3A684B for ; Sun, 9 Nov 2008 22:48:09 -0800 (PST) Received: (qmail invoked by alias); 10 Nov 2008 06:41:25 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp024) with SMTP; 10 Nov 2008 07:41:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ydkJROADymoMm8GXwTNo/fGvLQ6jIcRoyhz9INs reza+lfj4jI5AZ From: "Hannes Tschofenig" To: "'Bernard Aboba'" , "'ext Romascanu, Dan \(Dan\)'" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> Date: Mon, 10 Nov 2008 08:41:23 +0200 Message-ID: <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Bernard, We have currently three documents in DIME that relate to QoS: The Diameter QoS application specifies, as the name indicates, a Diameter application for usage with QoS. The QoS attribute draft provides the encoding of classifiers and AVPs relevant for QoS. The actual QoS parameters for an initial profile are defined in the QoS parameters draft. These drafts in DIME focus on Diameter usage. We have dependencies from the 3GPP on these documents. It is, however, quite easy to imagine that QoS parameters might also be useful in a RADIUS context. In fact we had a document some time ago that described how to re-use the same QoS parameter format for RADIUS. The document is, however, expired now and would need a significant update given the changes we have seen in the DIME documents. When it comes to the format then our believe so far was that the format of the QoS parameters was not really important as the authorization decision and related admission control procedures by the AAA server will require code changes. Code changes to the AAA client will be needed as well since the parameters need to be feed into a Traffic Control module. Ciao Hannes >-----Original Message----- >From: aaa-doctors-bounces@ietf.org >[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard Aboba >Sent: 10 November, 2008 06:50 >To: 'ext Romascanu, Dan (Dan)'; dime@ietf.org >Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org >Subject: Re: [AAA-DOCTORS] [Dime] AD Review of >dime-qos-parameters-06.txt > >Glen Zorn said: > >"Still looks like (bad) RADIUS to me." > >Can someone explain the relationship of this document to (bad >or good) RADIUS? > >Looking at the DIME WG charter, there is an item for the >Diameter QoS application >(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-q >os-06.txt), >Which in turn has normative references to QoS Attributes for Diameter >(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib >utes-08.txt) >and this document. > >None of these documents request allocation of any RADIUS >attributes, or describe RADIUS Attribute formats. > > > >_______________________________________________ >AAA-DOCTORS mailing list >AAA-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 10 01:50:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0E63A69E9; Mon, 10 Nov 2008 01:50:18 -0800 (PST) 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 23CC43A69E9 for ; Mon, 10 Nov 2008 01:50:17 -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 sWVvpHBYQ0GI for ; Mon, 10 Nov 2008 01:50:13 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 5B9E33A6992 for ; Mon, 10 Nov 2008 01:50:13 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Mon, 10 Nov 2008 04:50:05 -0500 From: Mark Jones To: "dime@ietf.org" Date: Mon, 10 Nov 2008 04:50:02 -0500 Thread-Topic: Announcing draft-jones-3gpp-eps-command-codes-00 Thread-Index: AclDGbPdkN1vOA49Rc2yYXSXWl76Iw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Dime] Announcing draft-jones-3gpp-eps-command-codes-00 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I would like to announce a new informational draft to the DIME WG which requests Diameter command codes for use in new 3GPP EPS applications. Although the IANA policy governing allocation of vendor-specific Diameter command code is proposed to be relaxed in 3588bis, the current IANA policy in RFC3588 means that an I-D is still required. http://www.ietf.org/internet-drafts/draft-jones-3gpp-eps-command-codes-00.txt There will also be a short presentation of this draft at IETF-73. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 10 12:44:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1D728C1B2; Mon, 10 Nov 2008 12:44:19 -0800 (PST) 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 95CB128C1AA for ; Mon, 10 Nov 2008 12:44:18 -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 G6FnYD9jEN2b for ; Mon, 10 Nov 2008 12:44:17 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 2641428C111 for ; Mon, 10 Nov 2008 12:44:17 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id dVPj1a0040S2fkCA4YkEW0; Mon, 10 Nov 2008 20:44:14 +0000 Received: from gwzPC ([67.110.80.202]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id dYjs1a00i4MuCRf8VYjvKW; Mon, 10 Nov 2008 20:44:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=aMLcg92P4qsA:10 a=Ca7ME9w267QA:10 a=48vgC7mUAAAA:8 a=fhlo5kegciRRuO7NoWAA:9 a=HR68VdbbKHHkZuGY6dMA:7 a=R8ypW7W4v9ysXRpUOntl7JvmHRoA:4 a=lZB815dzVvQA:10 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'Bernard Aboba'" , "'ext Romascanu, Dan \(Dan\)'" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> In-Reply-To: <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> Date: Mon, 10 Nov 2008 14:43:14 -0600 Message-ID: <006901c94375$00051ee0$000f5ca0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5A Content-Language: en-us Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Hi Bernard, > > We have currently three documents in DIME that relate to QoS: The > Diameter > QoS application specifies, as the name indicates, a Diameter > application for > usage with QoS. The QoS attribute draft provides the encoding of > classifiers > and AVPs relevant for QoS. The actual QoS parameters for an initial > profile > are defined in the QoS parameters draft. These drafts in DIME focus on > Diameter usage. We have dependencies from the 3GPP on these documents. > > It is, however, quite easy to imagine that QoS parameters might also be > useful in a RADIUS context. In fact we had a document some time ago > that > described how to re-use the same QoS parameter format for RADIUS. The > document is, however, expired now and would need a significant update > given > the changes we have seen in the DIME documents. It's very simple: if these attributes/AVPs are meant to be used in RADIUS then do the work in radext (or at the very least, follow the RADIUS design guidelines); note that those attributes could be carried w/o any fuss in Diameter as well. If they are meant to be used in Diameter, then design them as Diameter AVPs, using the features that Diameter enables (grouped AVPs, etc.). What you have done is neither, and have (predictably) ended up with a mess. > > When it comes to the format then our believe so far was that the format > of > the QoS parameters was not really important as the authorization > decision > and related admission control procedures by the AAA server will require > code > changes. Code changes to the AAA client will be needed as well since > the > parameters need to be feed into a Traffic Control module. > > Ciao > Hannes > > > >-----Original Message----- > >From: aaa-doctors-bounces@ietf.org > >[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard Aboba > >Sent: 10 November, 2008 06:50 > >To: 'ext Romascanu, Dan (Dan)'; dime@ietf.org > >Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org > >Subject: Re: [AAA-DOCTORS] [Dime] AD Review of > >dime-qos-parameters-06.txt > > > >Glen Zorn said: > > > >"Still looks like (bad) RADIUS to me." > > > >Can someone explain the relationship of this document to (bad > >or good) RADIUS? > > > >Looking at the DIME WG charter, there is an item for the > >Diameter QoS application > >(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-q > >os-06.txt), > >Which in turn has normative references to QoS Attributes for Diameter > >(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib > >utes-08.txt) > >and this document. > > > >None of these documents request allocation of any RADIUS > >attributes, or describe RADIUS Attribute formats. > > > > > > > >_______________________________________________ > >AAA-DOCTORS mailing list > >AAA-DOCTORS@ietf.org > >https://www.ietf.org/mailman/listinfo/aaa-doctors > > > > _______________________________________________ > 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 From dime-bounces@ietf.org Mon Nov 10 22:52:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0603A680A; Mon, 10 Nov 2008 22:52:43 -0800 (PST) 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 D79683A680A; Mon, 10 Nov 2008 22:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=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 s3tNLIr6lPTx; Mon, 10 Nov 2008 22:52:42 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 1E14D3A67C0; Mon, 10 Nov 2008 22:52:38 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 72CF01803163B; Tue, 11 Nov 2008 07:52:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 6B2DC1C0B6A97; Tue, 11 Nov 2008 07:52:37 +0100 (CET) Date: Tue, 11 Nov 2008 07:52:37 +0100 (CET) From: Jan Engelhardt To: Glen Zorn In-Reply-To: <006901c94375$00051ee0$000f5ca0$@net> Message-ID: References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> <006901c94375$00051ee0$000f5ca0$@net> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: aaa-doctors@ietf.org, 'Bernard Aboba' , dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Monday 2008-11-10 21:43, Glen Zorn wrote: >It's very simple: if these attributes/AVPs are meant to be used in RADIUS >then do the work in radext (or at the very least, follow the RADIUS design >guidelines); note that those attributes could be carried w/o any fuss in >Diameter as well. If they are meant to be used in Diameter, then design >them as Diameter AVPs, using the features that Diameter enables (grouped >AVPs, etc.). What you have done is neither, and have (predictably) ended up >with a mess. In that case, should not RADIUS backwards compatibility be removed from the rfc3588bis too? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 10 23:45:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C2D3A6AED; Mon, 10 Nov 2008 23:45:24 -0800 (PST) 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 7FA543A689D; Mon, 10 Nov 2008 23:45:22 -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 UPvhymWXXwg9; Mon, 10 Nov 2008 23:45:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6AAEA3A67C0; Mon, 10 Nov 2008 23:45:21 -0800 (PST) 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 mAB7jE1v013596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Nov 2008 08:45:14 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAB7j9KY031413; Tue, 11 Nov 2008 08:45:13 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 08:45:09 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 08:45:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Nov 2008 09:45:07 +0200 Message-ID: In-Reply-To: <006901c94375$00051ee0$000f5ca0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6A= References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> <006901c94375$00051ee0$000f5ca0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , "Hannes Tschofenig" , "Bernard Aboba" , "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 11 Nov 2008 07:45:09.0027 (UTC) FILETIME=[6BA98F30:01C943D1] Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Glen, >It's very simple: if these attributes/AVPs are meant to be >used in RADIUS then do the work in radext (or at the very >least, follow the RADIUS design guidelines); note that those >attributes could be carried w/o any fuss in Diameter as well. >If they are meant to be used in Diameter, then design them as >Diameter AVPs, using the features that Diameter enables >(grouped AVPs, etc.). What you have done is neither, and have >(predictably) ended up with a mess. You obviously don't care too much about my arguments. There are three things: * The QoS can be carried in RADIUS and Diameter. * This approach is totally inline with the RADIUS design guidelines. The RADIUS design guidelines document does not require every info element to following the standard encoding, as you know. * Where todo certain documents is a matter of taste and not really a bit issue (at least so far). We had a RADIUS draft, as I mentioned, but we focused all our efforts on the Diameter work. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 04:02:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8595F3A6A93; Tue, 11 Nov 2008 04:02:40 -0800 (PST) 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 9044128C180 for ; Tue, 11 Nov 2008 04:02:39 -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 K338DSiSypEk for ; Tue, 11 Nov 2008 04:02:38 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id AC4193A6A93 for ; Tue, 11 Nov 2008 04:02:38 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id dn6Q1a0080mv7h055o2ffy; Tue, 11 Nov 2008 12:02:39 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA11.westchester.pa.mail.comcast.net with comcast id do2c1a00D24Kx1C3Xo2coi; Tue, 11 Nov 2008 12:02:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=aMLcg92P4qsA:10 a=Ca7ME9w267QA:10 a=rYfSiJzAoleGOtI4htEA:9 a=nqZJatCgfj2sz1TW32T1Qf1MfhMA:4 a=2uiCRmbCp6AA:10 From: "David B. Nelson" To: References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net> Date: Tue, 11 Nov 2008 07:02:39 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkA== In-Reply-To: Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig writes... > * This approach is totally inline with the RADIUS design guidelines. > The RADIUS design guidelines document does not require every info > element to following the standard encoding, as you know. The RADIUS Design Guidelines document is pragmatic. It *strongly* suggests (SHOULD not MUST) that attributes which could reasonably be implemented in a data-dictionary driven RADIUS server as data dictionary entries be encoded in the standard encoding. Exceptions are made for (a) attributes which would absolutely require code changes in the server, (b) attributes used as authentication credentials payloads, and (c) attributes which are opaque to the RADIUS server and RADIUS client. This is not a matter of aesthetics or personal design choice -- it is dictated by the usage. BTW, *my* definition of opaque means that the data field of the attribute, as described in the RADIUS document is a single string, whose contents are defined in some non-RADIUS document. Once the RADIUS attribute definition starts breaking the attribute data payload into sub-fields it really isn't opaque anymore. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 04:21:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6D228C1BD; Tue, 11 Nov 2008 04:21:03 -0800 (PST) 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 43BD028C1BD for ; Tue, 11 Nov 2008 04:21:02 -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 ZkpIFYOT4PBE for ; Tue, 11 Nov 2008 04:21:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EFE1A28C1AC for ; Tue, 11 Nov 2008 04:21:00 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2008 12:21:00 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp066) with SMTP; 11 Nov 2008 13:21:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+g+ko6e8mg9lHA/9jd4hDt8/owV2zjdIIpwCierY 70Z7oB2ysAGNCy From: "Hannes Tschofenig" To: "'David B. Nelson'" , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net> Date: Tue, 11 Nov 2008 14:20:58 +0200 Message-ID: <00c901c943f7$f5568140$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi David, >Hannes Tschofenig writes... > >> * This approach is totally inline with the RADIUS design guidelines. >> The RADIUS design guidelines document does not require every info >> element to following the standard encoding, as you know. > >The RADIUS Design Guidelines document is pragmatic. It >*strongly* suggests (SHOULD not MUST) that attributes which >could reasonably be implemented in a data-dictionary driven >RADIUS server as data dictionary entries be encoded in the >standard encoding. Exceptions are made for (a) attributes >which would absolutely require code changes in the server, (b) >attributes used as authentication credentials payloads, and >(c) attributes which are opaque to the RADIUS server and RADIUS client. I don't think that attributes can be opaque to the RADIUS client since the client has todo something with them. The attributes are opaque to the RADIUS server and the respective component (dealing with policy-based admission control) needs to be implemented (=code changes). > >This is not a matter of aesthetics or personal design choice >-- it is dictated by the usage. > >BTW, *my* definition of opaque means that the data field of >the attribute, as described in the RADIUS document is a single >string, whose contents are defined in some non-RADIUS >document. Once the RADIUS attribute definition starts >breaking the attribute data payload into sub-fields it really >isn't opaque anymore. Currently, we do not yet define the RADIUS attributes (and that would be a RADEXT document) but they will then be defined as a string and within that string there will be the content of the QoS parameters. Ciao Hannes > > >_______________________________________________ >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 From dime-bounces@ietf.org Tue Nov 11 06:24:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1913A6B1E; Tue, 11 Nov 2008 06:24:12 -0800 (PST) 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 64AB73A6B1E; Tue, 11 Nov 2008 06:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 431W+nXE5URM; Tue, 11 Nov 2008 06:24:10 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id EC8CB3A6B19; Tue, 11 Nov 2008 06:24:09 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mABEO1pS032173; Tue, 11 Nov 2008 16:24:06 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 16:24:00 +0200 Received: from vaebe107.NOE.Nokia.com ([10.160.244.68]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 16:23:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Nov 2008 16:23:46 +0200 Message-ID: In-Reply-To: <00c901c943f7$f5568140$0201a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANrK/A= References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net> <00c901c943f7$f5568140$0201a8c0@nsnintra.net> From: To: , X-OriginalArrivalTime: 11 Nov 2008 14:23:59.0698 (UTC) FILETIME=[23742B20:01C94409] X-Nokia-AV: Clean Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Would it be useful to add some text to the draft to explain and justify the usage of the encoding format that you've chosen for the qos parameters? It is not obvious why is it be better to define separate qos parameter header and formats instead of using normal Diameter AVP header and formats to transfer the data. BR, Mikko >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Hannes Tschofenig >Sent: 11 November, 2008 14:21 >To: 'David B. Nelson'; dime@ietf.org >Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org >Subject: Re: [Dime] [AAA-DOCTORS] AD Review of >dime-qos-parameters-06.txt > >Hi David, > > >>Hannes Tschofenig writes... >> >>> * This approach is totally inline with the RADIUS design guidelines. >>> The RADIUS design guidelines document does not require every info >>> element to following the standard encoding, as you know. >> >>The RADIUS Design Guidelines document is pragmatic. It >>*strongly* suggests (SHOULD not MUST) that attributes which >>could reasonably be implemented in a data-dictionary driven >>RADIUS server as data dictionary entries be encoded in the >>standard encoding. Exceptions are made for (a) attributes >>which would absolutely require code changes in the server, (b) >>attributes used as authentication credentials payloads, and >>(c) attributes which are opaque to the RADIUS server and >RADIUS client. > >I don't think that attributes can be opaque to the RADIUS >client since the >client has todo something with them. > >The attributes are opaque to the RADIUS server and the >respective component >(dealing with policy-based admission control) needs to be >implemented (=code >changes). > >> >>This is not a matter of aesthetics or personal design choice >>-- it is dictated by the usage. >> >>BTW, *my* definition of opaque means that the data field of >>the attribute, as described in the RADIUS document is a single >>string, whose contents are defined in some non-RADIUS >>document. Once the RADIUS attribute definition starts >>breaking the attribute data payload into sub-fields it really >>isn't opaque anymore. > >Currently, we do not yet define the RADIUS attributes (and >that would be a >RADEXT document) but they will then be defined as a string and >within that >string there will be the content of the QoS parameters. > >Ciao >Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 07:00:06 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D1628C12B; Tue, 11 Nov 2008 07:00:06 -0800 (PST) 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 B6D8328C12B for ; Tue, 11 Nov 2008 07:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 KE5djrtvCFoq for ; Tue, 11 Nov 2008 07:00:04 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2923328C0FD for ; Tue, 11 Nov 2008 07:00:03 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2008 14:52:57 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp021) with SMTP; 11 Nov 2008 15:52:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+KTL5vfEOK9PyAp4X+9ZzZl59EL9WLWTJ6uT1Z1+ EVIQjoRxGcdWEa From: "Hannes Tschofenig" To: , References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net> <00c901c943f7$f5568140$0201a8c0@nsnintra.net> Date: Tue, 11 Nov 2008 16:52:56 +0200 Message-ID: <00d001c9440d$2f8b4610$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANrK/AAAWF8EA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mikko, the reason is that we essentially "copied" the format defined in the NSIS group as they have been working on the definition of the QoS parameters. In the past folks in DIME did not have a problem with the format and I also specifically asked for feedback on this issue. In fact, I even compiled a version of the draft with Diameter encoding once: http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05 As one can see from that document it isn't totally easy either to use Diameter AVPs as the format that is being referenced comes directly from a various RFCs and there is the obvious question whether the format should be taken as is or also "translated". For example, take a look at Section 3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05 (PHB-Class AVP). Ciao Hannes >-----Original Message----- >From: mikko.aittola@nokia.com [mailto:mikko.aittola@nokia.com] >Sent: 11 November, 2008 16:24 >To: Hannes.Tschofenig@gmx.net; dime@ietf.org >Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org >Subject: RE: [Dime] [AAA-DOCTORS] AD Review of >dime-qos-parameters-06.txt > >Hi, > >Would it be useful to add some text to the draft to explain >and justify the usage of the encoding format that you've >chosen for the qos parameters? > >It is not obvious why is it be better to define separate qos >parameter header and formats instead of using normal Diameter >AVP header and formats to transfer the data. > > >BR, >Mikko > > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of >>ext Hannes Tschofenig >>Sent: 11 November, 2008 14:21 >>To: 'David B. Nelson'; dime@ietf.org >>Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org >>Subject: Re: [Dime] [AAA-DOCTORS] AD Review of >>dime-qos-parameters-06.txt >> >>Hi David, >> >> >>>Hannes Tschofenig writes... >>> >>>> * This approach is totally inline with the RADIUS design >guidelines. >>>> The RADIUS design guidelines document does not require every info >>>> element to following the standard encoding, as you know. >>> >>>The RADIUS Design Guidelines document is pragmatic. It >>>*strongly* suggests (SHOULD not MUST) that attributes which could >>>reasonably be implemented in a data-dictionary driven RADIUS >server as >>>data dictionary entries be encoded in the standard encoding. >>>Exceptions are made for (a) attributes which would >absolutely require >>>code changes in the server, (b) attributes used as authentication >>>credentials payloads, and >>>(c) attributes which are opaque to the RADIUS server and >>RADIUS client. >> >>I don't think that attributes can be opaque to the RADIUS >client since >>the client has todo something with them. >> >>The attributes are opaque to the RADIUS server and the respective >>component (dealing with policy-based admission control) needs to be >>implemented (=code changes). >> >>> >>>This is not a matter of aesthetics or personal design choice >>>-- it is dictated by the usage. >>> >>>BTW, *my* definition of opaque means that the data field of >>>the attribute, as described in the RADIUS document is a single >>>string, whose contents are defined in some non-RADIUS >>>document. Once the RADIUS attribute definition starts >>>breaking the attribute data payload into sub-fields it really >>>isn't opaque anymore. >> >>Currently, we do not yet define the RADIUS attributes (and >>that would be a >>RADEXT document) but they will then be defined as a string and >>within that >>string there will be the content of the QoS parameters. >> >>Ciao >>Hannes > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 09:39:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DB728C1CE; Tue, 11 Nov 2008 09:39:24 -0800 (PST) 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 1745C28C1CE; Tue, 11 Nov 2008 09:39:22 -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 PjV-X5B+ceXX; Tue, 11 Nov 2008 09:39:20 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 739333A67FB; Tue, 11 Nov 2008 09:39:20 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mABHecer014043; Tue, 11 Nov 2008 11:40:39 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 11:39:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Nov 2008 11:39:14 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02106BDD@ILEXC2U01.ndc.lucent.com> In-Reply-To: <20080829074809.28900@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: DISCUSS: draft-sun-dime-itu-t-rw Thread-Index: AckJq5c2TX70ffYARnmnaWg4wuFkWQ6eBG+Q References: <20080829074809.28900@gmx.net> From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 11 Nov 2008 17:39:16.0497 (UTC) FILETIME=[6B35D010:01C94424] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: chris.newman@sun.com, iesg@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Following up the discussion, in order to answer the question "Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal " The following texts are proposed (based on the online/offline discussion with Dan/Hannes and DIME group): "" This application is used to authorize the network QoS resources (including amount of bandwidth, QoS class and traffic flow processing) based on the Diameter application [RFC4006]. The request is based on the Diameter extensibility discussions in the DIME WG that led to the conclusion that it is better to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP in order to avoid interoperability problems. The document is utilizing authorization and accounting functionality and the entire exchange is related to users utilizing applications that require QoS treatment. This approach is consistent with the practice and experience gained since the publication of [RFC3588] (see for example [RFC5224]) which is now under revision by the DIME Working Group and will provide a revised set of recommendations and procedures for IANA considerations [draft-ietf-dime-rfc3588bis]." Please let me know if you have any objection or comments. I will submit a revised version of this I-D for the review. Regards, Dong -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, August 29, 2008 3:48 AM To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com Cc: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw Hi Dan, let me quickly respond to this issue: > As expected the document was not approved by the IESG and is now in AD > Follow-up. > > Beyond the two DISCUSSes there were two ABSTAIN ballots. > > The principal concern that I heard was related to the fact that the > current process followed by the draft did not ensure a sufficient > level of review from the IETF to ensure that it really meets the IETF > consensus. > > In order to overcome this I suggest that we do the following: > > 1. Ask for at least one more review (two is better) from the > AAA-Doctors team or DIME WG making also sure that the reviewers also > include reading the relevant parts in the ITU-T document in their > review (Hannes, can you ask Bernard to be one of the reviewers?) I sent a mail to him. > > 2. Explain to the IESG why the DIME Working Group did not take this > work as a WG chartered item (hannes, please write a short explanation, > also include the discussions around 3588bis) draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects. Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments. For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either. The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems. The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following: * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues). * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view. * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior. As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC. > 3. Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will > draft such a text I will think about text. Maybe it is lack of imagination on how protocols could be used? Wouldn't be the first time that a protocol is used in a way not originally envisioned. Example: RSVP - RSVP-TE Funny enough, the idea about using Diameter for the purpose of NAT and firewall signaling actually came from the IETF MIDCOM working group, see http://www.ietf.org/rfc/rfc4097.txt Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... > > Also in parallel the DIME WG should do the best to accelerate the > approval and submission of RFC3588 to the IESG so that we will need to > deal with as few such cases in the future as possible (ideally zero). That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already). Ciao Hannes > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf > > Of Chris Newman > > Sent: Thursday, August 28, 2008 7:29 PM > > To: iesg@ietf.org > > Cc: Hannes.Tschofenig@gmx.net; > > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com > > Subject: DISCUSS: draft-sun-dime-itu-t-rw > > > > Discuss: > > As this issue was raised during IETF review and appears to concern a > > number of area directors, I'm holding an actionable discuss > > position: > > > > Based on GEN-ART review responses, it appears this statement in the > > DIAMETER base spec: > > > > "Diameter is not intended as a general purpose protocol, and > > allocations SHOULD NOT be made for purposes unrelated to > > authentication, authorization or accounting." > > > > is spurious and not being followed. If we're not going to follow > > this rule (which is fine if there's rough consensus not to follow > > it), I believe it's important that it be documented why we're not > > following the rule (a "SHOULD NOT" > > requires justification). Various approaches I find acceptable are: > > 1. The document approval text includes reasoning for ignoring > > SHOULD NOT 2. An update to the document text includes reasoning for > > ignoring > > SHOULD NOT > > 3. Hold this until a small RFC is published that updates 3588 to > > change or remove the SHOULD NOT restriction. > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 11:52:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1C83A697A; Tue, 11 Nov 2008 11:52:44 -0800 (PST) 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 A0C233A697A for ; Tue, 11 Nov 2008 11:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_71=0.6] 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 1F9XfmN6M0p9 for ; Tue, 11 Nov 2008 11:52:41 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 393D43A68F3 for ; Tue, 11 Nov 2008 11:52:41 -0800 (PST) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mABJqdka036160; Tue, 11 Nov 2008 14:52:40 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4919E288.1010108@tari.toshiba.com> Date: Tue, 11 Nov 2008 14:52:40 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <7DBAFEC6A76F3E42817DF1EBE64CB02605C12B76@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02605C12B76@ftrdmel2> Cc: dime@ietf.org Subject: Re: [Dime] comments on Diameter Guidelines 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Lionel, Here's a much overdue response to your comments (all editorials are ok except those with comments below). Although the draft did not make it to the submission cutoff, it is still best to update it based on the latest review. > Major Extension: Such an extension requires the definition of a new > Diameter application. The rules outlined in Section 1.2 of [1] > indicate when an extension is significant enough to require a new > Command Code to be registered and when new Diameter applications > have to be defined. Typically, these extensions require a longer > standardization effort, a little bit depending on the depending on > the degree of re-use, since additional aspects have to be taken > into consideration. > > [LM] "significant enough" and "little bit" should be prohibited in a > specification documentation. But I think that there is already a comment > on this. > [LM] I don't see how is used the wording "standardization effort". The > same "effort" will be needed in case of vendor-specific extension (e.g. > SDO specific extensions or vendor-specific extensions). Could it be > replaced by "specification effort"? [end] > I agree. The sentence is not well formed and looses its meaning. We should change to: "Typically, these types of extensions require a longer and more careful effort depending on the degree of re-use. Therefore, the amount of time and effort to complete the specification should also be considered by the designer. " > The subsequent sections provide discussions about the specific > Diameter Base protocol rules. > > > 4. Adding a new command > > The rules are strict in this case. Adding a command to an > application requires a new Diameter application to be defined.l > > [LM] remove "l" after "defined." [end] > [LM] could we add that: "This falls into the "Major Extensions" > category."? > We should really change the 1st sentence to: "Adding a new command is considered a major extension and requires a new Diameter application to be defined." > However, if this is the intent, then the new application can be > created by defining a new command for an existing application or > importing an existing command from another application so as to > inherit some or all of the functionality of that application. > > [LM] For this part of the text, I would propose to clarify the text as > follow: > > "Adding a new command to an application means either defining a new > command for an existing application or importing an existing command > from another application, the new application inheriting then some or > all of the functionality of the existing application" [end] > A minor re-word: "Adding a new command to an application means either defining a completely new command or importing an existing command from another application whereby the new application inherits some or all of the functionality of the application where the command came from" > In the > former case, the decision is straightforward since this is typically > a result of adding new functionality that does not yet exist. The > latter case would result in a new application but it has a more > subtle issue such as deciding whether importing of commands and > functionality is really better than simply using the existing > application as it is in conjunction with any new application. > > In general, it is difficult to come to a hard guideline, and so a > case by case study of each application requirement should be applied. > > [LM] proposed text, for seek of clarity: > > "In the former case, the decision to create an new application is > straightforward since this is typically a result of adding a new > functionality that does not exist yet. For the latter, the decision will > depend on whether importing the command in a new application is more > suitable than simply using the existing application as it is in > conjunction with any other application (a new one or an existing one). > Therefore, a case by case study of each application requirement should > be applied. [end] > looks good. > Before adding or importing a command, application designers should > consider the following: > > o Can the new functionality be fulfilled by creating a new > application independent from the existing applications? In this > case, a deployment architecture could be designed such that both > old and new application can work independent of, but cooperating > with each other. > > [LM] remove reference to "deployment architecture" out of scope here. > Just say: "In this case, both old and new applications..." with "s" at > the end of applications [end] > Ok > 5. Deleting a Command > > Although this is not typical, deleting an command from an existing > application is fundamentally changing the application. In general, > the implications of this approach are the same as Section 4 > regardless of whether new commands will also be added to the > resulting application. > > [LM] What is the meaning of "In general" in the last sentence? Removing > of any command must result in the creation of a new application, isn't > it? I would just say: "Removing a command to an application requires a > new Diameter application to be defined. [end] > I agree. > o Mandatory to understand AVPs. As defined in [1], these are AVPs > with the M-bit flag set, which means that a Diameter node > receiving these AVPs has to understand not only their values but > their semantics. This is regardless of whether these AVPs are > required or optional to appear in the command; as specified by the > commands ABNF. > > [LM] should we add that an AVP not understood will cause a failure in > the message handling? It's for me the main difference between mandatory > and optional AVP i.e. Optional AVP can be ignored without causing a > failure. [end] > [LM] use "," instead of ";" in the last sentance [end] > how about: "...these are AVPs with the M-bit flag set, which means that a Diameter node receiving are required to understand not only their values but their semantics. Failure to do so will cause an message handling error. This is regardless of whether these AVPs are required or optional as specified by the commands ABNF." > All of these practices generally result in interoperability problems > so they should be avoided as much as possible. > > [LM] The conclusion being that a mandatory AVP is required, isn't it? > [end] > That was'nt the intent of the paragraph ... its just a badly form paragraph :). Here's a revised version: " When one of the above questions can be answered with 'yes' then the Fajardo, et al. Expires May 15, 2009 [Page 6] Internet-Draft Diameter Applications Design Guidelines November 2008 M-bit has to be set. If application designers are contemplating on the use of optional AVPs instead, then the following are some of the pitfalls that should be avoided: o Use of optional AVPs with intersecting meaning. One AVP has partially the same usage and meaning as another AVP. The presence of both can lead to confusion. o An optional AVPs with dual purpose, i.e. to carry applications data as well as to indicate support for one or more features. This has a tendency to introduce interpretation issues. o Adding one or more optional AVPs and indicating (usually within descriptive text for the command) that at least one of them has to be present in the command. This essentially circumventing the ABNF and is equivalent to adding a mandatory AVPs to the command. These practices generally result in interoperability issues and should be avoided as much as possible. " > 6.2. Deleting AVPs from a Command > > Although this scenario is not as common, the deletion of AVPs from a > command ABNF is significant when trying to extend an existing > application. > > [LM] strange to see in the same sentance "deletion" and "to extend an > existing application". Instead of "extend", I would use "modify" [end] > Lets remove that sentence as it makes little sense :) > [LM] Am I wrong if i say that the following case is missing and should > be inserted before the "{}" case? > "An AVP that is indicated as <> in the ABNF in the Command (with or > without the > M-bit set) > Not sure if this is ok. <> is just a positional restriction and not a presence restriction. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 14:43:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B860628C10B; Tue, 11 Nov 2008 14:43:32 -0800 (PST) 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 4236A28C150 for ; Tue, 11 Nov 2008 14:43:31 -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 q01frY-FZGV1 for ; Tue, 11 Nov 2008 14:43:30 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 3180328C105 for ; Tue, 11 Nov 2008 14:43:30 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA05.westchester.pa.mail.comcast.net with comcast id dxSB1a00S0SCNGk55yjWxl; Tue, 11 Nov 2008 22:43:30 +0000 Received: from gwzPC ([67.110.80.202]) by OMTA09.westchester.pa.mail.comcast.net with comcast id dyjC1a0174MuCRf3VyjFtG; Tue, 11 Nov 2008 22:43:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=aMLcg92P4qsA:10 a=Ca7ME9w267QA:10 a=48vgC7mUAAAA:8 a=Jyxyy5Af5reTaaL5WggA:9 a=XY6Ncffwr5et3SbG1pNKEFeqK4MA:4 a=BFDKbZatV3MA:10 a=2uiCRmbCp6AA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net> <00c901c943f7$f5568140$0201a8c0@nsnintra.net> <00d001c9440d$2f8b4610$0201a8c0@nsnintra.net> In-Reply-To: <00d001c9440d$2f8b4610$0201a8c0@nsnintra.net> Date: Tue, 11 Nov 2008 16:42:34 -0600 Message-ID: <006601c9444e$d3591ba0$7a0b52e0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANrK/AAAWF8EAAQyknw Content-Language: en-us Cc: aaa-doctors@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > Hi Mikko, > > the reason is that we essentially "copied" the format defined in the > NSIS > group as they have been working on the definition of the QoS > parameters. > In the past folks in DIME did not have a problem with the format and I > also > specifically asked for feedback on this issue. > > In fact, I even compiled a version of the draft with Diameter encoding > once: > http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05 As luck would have it, I think that was the one I read :-) -- no wonder I had no problem. > As one can see from that document it isn't totally easy either to use > Diameter AVPs as the format that is being referenced comes directly > from a > various RFCs and there is the obvious question whether the format > should be > taken as is or also "translated". For example, take a look at Section > 3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05 > (PHB-Class AVP). What's wrong with it? It seems at least as comprehensible as section 4.13 of -06... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 15:03:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC4628C1AD; Tue, 11 Nov 2008 15:03:14 -0800 (PST) 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 034413A6831 for ; Tue, 11 Nov 2008 15:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 1On7U55swnET for ; Tue, 11 Nov 2008 15:03:12 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 5168028C19F for ; Tue, 11 Nov 2008 15:03:12 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id dyQb1a0030lTkoCA4z3DU3; Tue, 11 Nov 2008 23:03:13 +0000 Received: from gwzPC ([67.110.80.202]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id dz2p1a01F4MuCRf8Qz2t5k; Tue, 11 Nov 2008 23:03:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=aMLcg92P4qsA:10 a=Ca7ME9w267QA:10 a=N0lC3I55Azb7y0YrZIYA:9 a=MAf-kat8zNu5yzDR3ODVWZaM_yEA:4 a=zwC7bnKO5xoA:10 a=Z7iSMxTqbYsA:10 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> <006901c94375$00051ee0$000f5ca0$@net> In-Reply-To: Date: Tue, 11 Nov 2008 17:02:11 -0600 Message-ID: <006701c94451$93bb86b0$bb329410$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AAH7IbEA== Content-Language: en-us Cc: aaa-doctors@ietf.org, 'Bernard Aboba' , dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tschofenig, Hannes (NSN - FI/Espoo) [mailto:// hannes.tschofenig@nsn.com] writes: > Glen, > > >It's very simple: if these attributes/AVPs are meant to be > >used in RADIUS then do the work in radext (or at the very > >least, follow the RADIUS design guidelines); note that those > >attributes could be carried w/o any fuss in Diameter as well. > >If they are meant to be used in Diameter, then design them as > >Diameter AVPs, using the features that Diameter enables > >(grouped AVPs, etc.). What you have done is neither, and have > >(predictably) ended up with a mess. > > You obviously don't care too much about my arguments. > > There are three things: > > * The QoS can be carried in RADIUS and Diameter. If that is the intention, then these should be RADIUS attributes. > > * This approach is totally inline with the RADIUS design guidelines. > The RADIUS design guidelines document does not require every info > element to following the standard encoding, as you know. I think that you've got at least two people who disagree with you on that. > > * Where todo certain documents is a matter of taste and not really a > bit > issue (at least so far). ??! You're not seriously suggesting that Diameter AVPs & RADIUS attributes are technically equivalent, are you? > We had a RADIUS draft, as I mentioned, but we focused all our efforts > on > the Diameter work. That's the main problem: the -05 draft contained Diameter AVPs but -06 doesn't. In fact, this is exactly the kind of application for which Diameter was designed & I find it rather annoying what's being proposed are poorly designed RADIUS attributes masquerading as Diameter AVPs. > > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 23:00:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3943A682B; Tue, 11 Nov 2008 23:00:00 -0800 (PST) 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 EC0E53A682B for ; Tue, 11 Nov 2008 22:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 j9MJPW3kM0-H for ; Tue, 11 Nov 2008 22:59:58 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 3086B3A681D for ; Tue, 11 Nov 2008 22:59:58 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 870ECA98B7; Wed, 12 Nov 2008 07:59:57 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 7717CA98A1; Wed, 12 Nov 2008 07:59:57 +0100 (CET) Message-ID: <491A7EED.3090106@restena.lu> Date: Wed, 12 Nov 2008 07:59:57 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Jan Engelhardt , dime@ietf.org References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> In-Reply-To: <49100B33.7060803@restena.lu> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, the thread so far has three findings: - to be conformant with the spec, you need to use IPSec to protect the inband security handshake, even if IPsec is not to be used for the remainder of the peer session - failure to do so may enable an attacker to change the encryption used during the entire peer session. It may also enable an attacker to tweak other parameters in the CER. - this might (still unsure about that) be mitigated by repeating the CER immediately after establishing a secure link. These look like some severe implications of the protocol. I suggest to give that a mention in 3588bis's security considerations section. If that is seen as a good thing to do, I volunteer for the text. Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 23:16:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B243A687E; Tue, 11 Nov 2008 23:16:56 -0800 (PST) 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 DA0A63A6802; Tue, 11 Nov 2008 23:16:54 -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 FuSNQsd+imxM; Tue, 11 Nov 2008 23:16:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DE53C3A67A8; Tue, 11 Nov 2008 23:16:53 -0800 (PST) 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 mAC7GnKV001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Nov 2008 08:16:49 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAC7Ggrx014513; Wed, 12 Nov 2008 08:16:49 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:16:46 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:16:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Nov 2008 09:15:19 +0200 Message-ID: In-Reply-To: <006601c9444e$d3591ba0$7a0b52e0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANrK/AAAWF8EAAQyknwABHzL1A= References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net><00c901c943f7$f5568140$0201a8c0@nsnintra.net><00d001c9440d$2f8b4610$0201a8c0@nsnintra.net> <006601c9444e$d3591ba0$7a0b52e0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , "Hannes Tschofenig" X-OriginalArrivalTime: 12 Nov 2008 07:16:41.0611 (UTC) FILETIME=[9C604DB0:01C94496] Cc: aaa-doctors@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen >> In fact, I even compiled a version of the draft with >Diameter encoding >> once: >> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05 > >As luck would have it, I think that was the one I read :-) -- >no wonder I had no problem. That's indeed funny. >> For >> example, take a >> look at Section 3.11.3. of >> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05 >> (PHB-Class AVP). > >What's wrong with it? It seems at least as comprehensible as >section 4.13 of -06... How should I understand this reasoning? We don't win anything with the Diameter based encoding since the component of the Diameter server still has to implement code for decoding of the following parameter: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHD ID CODE |0 0 X 0| +---+---+---+---+---+---+---+---+ This is as good as the other encoding. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 23:16:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669783A68BC; Tue, 11 Nov 2008 23:16:59 -0800 (PST) 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 6701E3A68CF; Tue, 11 Nov 2008 23:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 7I-QaJMJpwFx; Tue, 11 Nov 2008 23:16:57 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 479E93A68BC; Tue, 11 Nov 2008 23:16:57 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAC7GqqH027338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Nov 2008 08:16:53 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAC7GmOS004386; Wed, 12 Nov 2008 08:16:52 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:16:52 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:16:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Nov 2008 09:09:31 +0200 Message-ID: In-Reply-To: <63F3725E9F224667917650FAC1525074@xpsuperdvd2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] [Dime] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANr5qAAJBe5AA== References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net><00c901c943f7$f5568140$0201a8c0@nsnintra.net> <63F3725E9F224667917650FAC1525074@xpsuperdvd2> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext David B. Nelson" , X-OriginalArrivalTime: 12 Nov 2008 07:16:45.0282 (UTC) FILETIME=[9E907420:01C94496] Cc: aaa-doctors@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I agree with your description, David. >-----Original Message----- >From: aaa-doctors-bounces@ietf.org >[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of ext David B. Nelson >Sent: 11 November, 2008 16:14 >To: dime@ietf.org >Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org >Subject: Re: [AAA-DOCTORS] [Dime] AD Review of >dime-qos-parameters-06.txt > >Hi Hannes, > >> I don't think that attributes can be opaque to the RADIUS >client since >> the client has todo something with them. > >Maybe this is a matter of semantics. Just as the RADIUS >Server does not comprise the complete set of server-side AAA >functionality (e.g. policy servers, location servers, >authentication back-ends, etc. are logically separate), the >RADIUS Client does not comprise the complete set of AAA >functionality in the NAS. The RADIUS Client delivers >authorization information to the components of the NAS that >enforce access control. > >When you define the RADIUS Server and RADIUS Client in this >narrow sense, i.e. the code that deals with RADIUS PDUs, I >think you can claim the certain attributes are opaque to the >RADIUS Client (but certainly not to the NAS). > >-- Dave > > >_______________________________________________ >AAA-DOCTORS mailing list >AAA-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 11 23:25:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8FD3A6809; Tue, 11 Nov 2008 23:25:01 -0800 (PST) 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 6DEDE3A6809; Tue, 11 Nov 2008 23:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 u4eWaiS9TapD; Tue, 11 Nov 2008 23:24:59 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 479203A67A8; Tue, 11 Nov 2008 23:24:59 -0800 (PST) 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 mAC7OrLj023905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Nov 2008 08:24:53 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAC7Or0Z003527; Wed, 12 Nov 2008 08:24:53 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:24:52 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:24:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Nov 2008 09:24:51 +0200 Message-ID: In-Reply-To: <006701c94451$93bb86b0$bb329410$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AAH7IbEAAR0Z9w References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net> <006901c94375$00051ee0$000f5ca0$@net> <006701c94451$93bb86b0$bb329410$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" X-OriginalArrivalTime: 12 Nov 2008 07:24:52.0016 (UTC) FILETIME=[C0AE2B00:01C94497] Cc: aaa-doctors@ietf.org, Bernard Aboba , dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, >> Glen, >> >> >It's very simple: if these attributes/AVPs are meant to be used in >> >RADIUS then do the work in radext (or at the very least, follow the >> >RADIUS design guidelines); note that those attributes could be >> >carried w/o any fuss in Diameter as well. >> >If they are meant to be used in Diameter, then design them as >> >Diameter AVPs, using the features that Diameter enables (grouped >> >AVPs, etc.). What you have done is neither, and have >> >(predictably) ended up with a mess. >> >> You obviously don't care too much about my arguments. >> >> There are three things: >> >> * The QoS can be carried in RADIUS and Diameter. > >If that is the intention, then these should be RADIUS attributes. > >> >> * This approach is totally inline with the RADIUS design guidelines. >> The RADIUS design guidelines document does not require every info >> element to following the standard encoding, as you know. > >I think that you've got at least two people who disagree with >you on that. I counted one person. > >> >> * Where todo certain documents is a matter of taste and not really a >> bit issue (at least so far). > >??! You're not seriously suggesting that Diameter AVPs & >RADIUS attributes are technically equivalent, are you? For example: Take a look at http://www.ietf.org/rfc/rfc4675.txt In Section 4 it also defines the corresponding Diameter AVPs. Take a look at http://tools.ietf.org/html/draft-ietf-mip6-radius-06 This document was started in MIP6 and will be finished in MEXT. The decision on where todo certain work has been made on a case-by-case basis and there isn't really any problem with it. All this has nothing todo with the relationship between RADIUS and Diameter. > > >> We had a RADIUS draft, as I mentioned, but we focused all >our efforts >> on the Diameter work. > >That's the main problem: the -05 draft contained Diameter AVPs >but -06 doesn't. In fact, this is exactly the kind of >application for which Diameter was designed & I find it rather >annoying what's being proposed are poorly designed RADIUS >attributes masquerading as Diameter AVPs. Based on what you said at the beginning of your mail: Would an encoding of the QoS parameters according to http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute s-05.txt make you "happy"? Ciao Hannes > >> >> Ciao >> Hannes > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 01:49:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3015B3A6A6E; Wed, 12 Nov 2008 01:49:34 -0800 (PST) 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 507103A6A6E for ; Wed, 12 Nov 2008 01:49:32 -0800 (PST) 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 w3prCrc56LyZ for ; Wed, 12 Nov 2008 01:49:31 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 7EA583A691C for ; Wed, 12 Nov 2008 01:49:31 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so176767wag.5 for ; Wed, 12 Nov 2008 01:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=fR27bxL5nO9Ia7vXZwxFB7h4WjucLjgKSOU18tOYnLw=; b=wev9hpzq4uTWJvRTGXWpMPfzyYgd13sVpukHJqpyVU8uoX7D5LwiJ42Qg4uf0XtAl0 poFzQwB+bXcR6/s7tgbosQZaP+moMk6QjLjU7/4LS3JcEuHb+2cYXPhCiB6RKAuAiHGg HfzIElGNZSVv9av1+I8iR55WO0ALDw5EFTiiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=AaDg9EP+WUj1wgq8IIoKALiEbA4jy5zBMKlm3RTl8vFniaHD9cTR4mz1kkx2NJdQ5Y 7aRgM+GwLW/nhZ2i9PUFkAiCQ3UYIXyVnUlsTHfijfyMl0bSN9940W2jGFEvNO1bFmyV u3HGEjscBfmjT3G4DC3RuSw6DAMpO3dDlAF2c= Received: by 10.114.111.1 with SMTP id j1mr6047223wac.79.1226483372073; Wed, 12 Nov 2008 01:49:32 -0800 (PST) Received: by 10.114.176.4 with HTTP; Wed, 12 Nov 2008 01:49:32 -0800 (PST) Message-ID: Date: Wed, 12 Nov 2008 10:49:32 +0100 From: "Thomas Lindgren" To: "Stefan Winter" In-Reply-To: <491A7EED.3090106@restena.lu> MIME-Version: 1.0 References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: multipart/mixed; boundary="===============1553381491==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1553381491== Content-Type: multipart/alternative; boundary="----=_Part_3448_27286824.1226483372086" ------=_Part_3448_27286824.1226483372086 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 12, 2008 at 7:59 AM, Stefan Winter wrote: > Hi, > > the thread so far has three findings: > > - to be conformant with the spec, you need to use IPSec to protect the > inband security handshake, even if IPsec is not to be used for the > remainder of the peer session > - failure to do so may enable an attacker to change the encryption used > during the entire peer session. It may also enable an attacker to tweak > other parameters in the CER. > - this might (still unsure about that) be mitigated by repeating the CER > immediately after establishing a secure link. > > These look like some severe implications of the protocol. I suggest to > give that a mention in 3588bis's security considerations section. If > that is seen as a good thing to do, I volunteer for the text. > It seems to me that an option of just running Diameter over TLS would be simpler as well as more secure than the 3588 negotiation method. Are there any compelling advantages to using the current negotiation approach? Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_3448_27286824.1226483372086 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Nov 12, 2008 at 7:59 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,

the thread so far has three findings:

- to be conformant with the spec, you need to use IPSec to protect the
inband security handshake, even if IPsec is not to be used for the
remainder of the peer session
- failure to do so may enable an attacker to change the encryption used
during the entire peer session. It may also enable an attacker to tweak
other parameters in the CER.
- this might (still unsure about that) be mitigated by repeating the CER
immediately after establishing a secure link.

These look like some severe implications of the protocol. I suggest to
give that a mention in 3588bis's security considerations section. If
that is seen as a good thing to do, I volunteer for the text.

It seems to me that an option of just running Diameter over TLS would be simpler as well as more secure than the 3588 negotiation method. Are there any compelling advantages to using the current negotiation approach?

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd


 

------=_Part_3448_27286824.1226483372086-- --===============1553381491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1553381491==-- From dime-bounces@ietf.org Wed Nov 12 04:15:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CAF3A68D0; Wed, 12 Nov 2008 04:15:16 -0800 (PST) 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 B95323A68D0 for ; Wed, 12 Nov 2008 04:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 I9ALKkuC7Qcx for ; Wed, 12 Nov 2008 04:15:15 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id D00FF3A68CC for ; Wed, 12 Nov 2008 04:15:14 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id AEC90A6C89; Wed, 12 Nov 2008 13:15:14 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 9C163A6C8C; Wed, 12 Nov 2008 13:15:14 +0100 (CET) Message-ID: <491AC8D2.3050501@restena.lu> Date: Wed, 12 Nov 2008 13:15:14 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Thomas Lindgren References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > It seems to me that an option of just running Diameter over TLS would > be simpler as well as more secure than the 3588 negotiation method. > Are there any compelling advantages to using the current negotiation > approach? Well, the current approach in 3588 and bis is the only one specified. And being specified in the the IETF is kind of a compelling advantage :-) I'm perfectly with you though that it would likely be simpler to allocate a different port for Diameter over TLS and just skip the CER inband security negotiation, and replace it by commencing with a TLS handshake prior to the Diameter CER PDU being exchanged. That's a substantial change in protocol operations though, much more than a "handle with care" advice on the current model. I wonder how much current deployments would be affected by this. Is deploying Diamter over TLS a common deployment method? [BTW, for RADIUS over TLS a different TCP port was chosen, and that seems to work nicely.] So, would you prefer to deprecate CER inband security negotiation in favour of a more straightforward port-based approach in 3588bis? Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 05:03:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89AC3A68A5; Wed, 12 Nov 2008 05:03:49 -0800 (PST) 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 084F53A68A5 for ; Wed, 12 Nov 2008 05:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=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 eU18tIU-PJ4Y for ; Wed, 12 Nov 2008 05:03:47 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 3C4023A67AE for ; Wed, 12 Nov 2008 05:03:46 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 834DB1803064A; Wed, 12 Nov 2008 14:03:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 7A7E81C07DA8E; Wed, 12 Nov 2008 14:03:45 +0100 (CET) Date: Wed, 12 Nov 2008 14:03:45 +0100 (CET) From: Jan Engelhardt To: Stefan Winter In-Reply-To: <491AC8D2.3050501@restena.lu> Message-ID: References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Wednesday 2008-11-12 13:15, Stefan Winter wrote: >> It seems to me that an option of just running Diameter over TLS would >> be simpler as well as more secure than the 3588 negotiation method. >> Are there any compelling advantages to using the current negotiation >> approach? > >Well, the current approach in 3588 and bis is the only one specified. >And being specified in the the IETF is kind of a compelling advantage >:-) I'm perfectly with you though that it would likely be simpler to >allocate a different port for Diameter over TLS and just skip the CER >inband security negotiation [...] But it would impose an unnecessary performance hit for networks that have established an IPsec-based solution. >So, would you prefer to deprecate CER inband security negotiation in >favour of a more straightforward port-based approach in 3588bis? Like, unencrypted on port 3868, and implicit TLS on 3869? Then again tell me why STARTTLS in SMTP and IMAP are (I claim) more beautiful than implicit TLS for smtps and imaps. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 05:11:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6262E3A6AB4; Wed, 12 Nov 2008 05:11:08 -0800 (PST) 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 A92993A67AE for ; Wed, 12 Nov 2008 05:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 GJI5bevihBq9 for ; Wed, 12 Nov 2008 05:11:05 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id A23483A6927 for ; Wed, 12 Nov 2008 05:11:02 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id C4B49A98DB; Wed, 12 Nov 2008 14:11:02 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id B1E3AA98DA; Wed, 12 Nov 2008 14:11:02 +0100 (CET) Message-ID: <491AD5E6.2000202@restena.lu> Date: Wed, 12 Nov 2008 14:11:02 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Jan Engelhardt References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > Like, unencrypted on port 3868, and implicit TLS on 3869? > Then again tell me why STARTTLS in SMTP and IMAP are (I claim) > more beautiful than implicit TLS for smtps and imaps. > = Oh, I didn't intend to step on your feet regarding STARTTLS, sorry. I don't dare judge over the beautiness of STARTTLS vs. TCP port numbers and didn't mean to imply anything in that direction. The main (of course overcomable) problem i see is that the state machine in Diameter expects a Diameter PDU after TCP session establishment. It would need to be non-trivially modified to include a STARTTLS mechanism. I'm also unsure whether implementations would become easier if they have to expect *either* a Diameter PDU *or* a ASCII "STARTTLS" word. Text-based protocols like SMTP have an easier time here because they do a plain ASCII capabilities exchange in any case. So, let me rephrase my original question: "would you prefer to deprecate CER inband security negotiation in favour of a more commonly used and well-understood TLS handshake approach in 3588bis?" Greetings, Stefan -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 05:23:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1CC33A68D2; Wed, 12 Nov 2008 05:23:05 -0800 (PST) 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 7788E3A68D2 for ; Wed, 12 Nov 2008 05:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=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 b-G+RvY9-R8b for ; Wed, 12 Nov 2008 05:23:03 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id A9BF23A68A5 for ; Wed, 12 Nov 2008 05:23:03 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id EE9451803064A; Wed, 12 Nov 2008 14:23:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id DF6FC1C062DC3; Wed, 12 Nov 2008 14:23:02 +0100 (CET) Date: Wed, 12 Nov 2008 14:23:02 +0100 (CET) From: Jan Engelhardt To: Stefan Winter In-Reply-To: <491AD5E6.2000202@restena.lu> Message-ID: References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Wednesday 2008-11-12 14:11, Stefan Winter wrote: > >> Like, unencrypted on port 3868, and implicit TLS on 3869? >> Then again tell me why STARTTLS in SMTP and IMAP are (I claim) >> more beautiful than implicit TLS for smtps and imaps. > >Oh, I didn't intend to step on your feet regarding STARTTLS, sorry. I >don't dare judge over the beautiness of STARTTLS vs. TCP port numbers >and didn't mean to imply anything in that direction. The main (of course >overcomable) problem i see is that the state machine in Diameter expects >a Diameter PDU after TCP session establishment. It would need to be >non-trivially modified to include a STARTTLS mechanism. I'm also unsure >whether implementations would become easier if they have to expect >*either* a Diameter PDU *or* a ASCII "STARTTLS" word. Even the STARTTLS commands of SMTP and IMAP are in line with the respective protocols, it's not just the bland 8-char ASCII string. As previously mentioned, the mere presence of Security-Inband-Id=TLS could be our starttls trigger. Or maybe Diameter should move to ASCII (perhaps XML because of its good nesting possibilities) too - that would also alleviate trying to figure out an AVP's specific encoding (developer's ever-reoccuring question "is that number now sent as a uint32 or as a human-readable string?"). >So, let me rephrase my original question: "would you prefer to deprecate >CER inband security negotiation in favour of a more commonly used and >well-understood TLS handshake approach in 3588bis?" _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 05:30:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E0E3A68DC; Wed, 12 Nov 2008 05:30:47 -0800 (PST) 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 5105E3A683F for ; Wed, 12 Nov 2008 05:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 fzW6TU+rOduc for ; Wed, 12 Nov 2008 05:30:46 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 79A013A68DC for ; Wed, 12 Nov 2008 05:30:46 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id E60F1A6C93; Wed, 12 Nov 2008 14:30:46 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id D37FFA6C90; Wed, 12 Nov 2008 14:30:46 +0100 (CET) Message-ID: <491ADA86.7080401@restena.lu> Date: Wed, 12 Nov 2008 14:30:46 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Jan Engelhardt References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > Even the STARTTLS commands of SMTP and IMAP are in line with the > respective protocols, it's not just the bland 8-char ASCII string. As > previously mentioned, the mere presence of Security-Inband-Id=3DTLS > could be our starttls trigger. > = It might... it needs a semantics change for Inband-Security AVP though: it would not be a statement of *support* for TLS, but an annoucement of *starting* TLS. > Or maybe Diameter should move to ASCII (perhaps XML because of its > good nesting possibilities) too - that would also alleviate trying to > figure out an AVP's specific encoding (developer's ever-reoccuring > question "is that number now sent as a uint32 or as a human-readable > string?"). > = Huh. You are about to invent a new AAA protocol which has next to nothing i= n common with Diameter, you know? Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 06:41:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611613A6957; Wed, 12 Nov 2008 06:41:28 -0800 (PST) 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 742EC3A6957 for ; Wed, 12 Nov 2008 06:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=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 wHU17atvOAxo for ; Wed, 12 Nov 2008 06:41:26 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id A6BBC3A67F0 for ; Wed, 12 Nov 2008 06:41:26 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id D80F718031200; Wed, 12 Nov 2008 15:41:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id CE76A1C07DA8E; Wed, 12 Nov 2008 15:41:23 +0100 (CET) Date: Wed, 12 Nov 2008 15:41:23 +0100 (CET) From: Jan Engelhardt To: Stefan Winter In-Reply-To: <491ADA86.7080401@restena.lu> Message-ID: References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> <491ADA86.7080401@restena.lu> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Wednesday 2008-11-12 14:30, Stefan Winter wrote: > >> Even the STARTTLS commands of SMTP and IMAP are in line with the >> respective protocols, it's not just the bland 8-char ASCII string. As >> previously mentioned, the mere presence of Security-Inband-Id=TLS >> could be our starttls trigger. > >It might... it needs a semantics change for Inband-Security AVP though: >it would not be a statement of *support* for TLS, but an annoucement of >*starting* TLS. Yeah, another of these strange design decisions. Why would you announce TLS support if you ain't gonna use it! >> Or maybe Diameter should move to ASCII (perhaps XML because of its >> good nesting possibilities) too - that would also alleviate trying to >> figure out an AVP's specific encoding (developer's ever-reoccuring >> question "is that number now sent as a uint32 or as a human-readable >> string?"). > >Huh. You are about to invent a new AAA protocol which has next to nothing in >common with Diameter, you know? What, merely throwing the binary packed format overboard gets me rid of all the Diameter nasties? Wow, I must be dTRT. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 07:04:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B896F3A6B01; Wed, 12 Nov 2008 07:04:29 -0800 (PST) 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 42E193A6A9F for ; Wed, 12 Nov 2008 07:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 fJqyxp31VZyC for ; Wed, 12 Nov 2008 07:04:28 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 48FFA3A68DC for ; Wed, 12 Nov 2008 07:04:28 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 22EEDA6C90; Wed, 12 Nov 2008 16:04:28 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 13D57A98B6; Wed, 12 Nov 2008 16:04:28 +0100 (CET) Message-ID: <491AF07B.3030207@restena.lu> Date: Wed, 12 Nov 2008 16:04:27 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Jan Engelhardt References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> <491ADA86.7080401@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, >> It might... it needs a semantics change for Inband-Security AVP though: >> it would not be a statement of *support* for TLS, but an annoucement of >> *starting* TLS. >> = > > Yeah, another of these strange design decisions. > Why would you announce TLS support if you ain't gonna use it! > = Since I wasn't involved in the Diameter spec, this is no more than speculation for me, but: CER and CEA are, as I see it, supposed to tell the two peers about the supported options. The approach we sketched above of "blindly" stating that the originating peer is going to do TLS now means that no security capability negotiation can take place. Consequently, it may be that a peer tries to speak TLS to another which doesn't support it. There is no way to know for the originating peer that TLS is not supported, prior to falling onto its nose with a failed handshake. The idea with CER and CEA was obviously meant to prevent such TLS handshake failures by first negotiating whether or not TLS is okay, prior to starting the actual handshake. Which is, in principle, a nice idea. Except that it doesn't work quite as intended. > What, merely throwing the binary packed format overboard gets > me rid of all the Diameter nasties? Wow, I must be dTRT. > = dTRT =3D doing the right thing? Well, just changing the encoding is only a first step. You could go on by thinking along the lines of: now that we have all Diameter content in an XML file, we could transport it over HTTP. Oh, wait, we could use URIs to indicate that TLS is desirable, by transmitting the XML file over HTTP or HTTPS or HTTP with STARTTLS, respectively. Then you could lift all AVP size restrictions, because XML can handle tags of arbitrary lengths. You'd end up at almost-SAML, probably. I am going to stop here, because this is getting off-topic. And I don't really plan to generate yet another AAA protocol. Right now, I'll just stick with RADIUS ;-) Stefan -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 09:17:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0305D3A6407; Wed, 12 Nov 2008 09:17:48 -0800 (PST) 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 920103A6407 for ; Wed, 12 Nov 2008 09:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 HOrBmsoBY0b7 for ; Wed, 12 Nov 2008 09:17:45 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id CC6F33A63EC for ; Wed, 12 Nov 2008 09:17:45 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id eDsy1a0070S2fkCA6HHmzc; Wed, 12 Nov 2008 17:17:46 +0000 Received: from gwzPC ([67.110.80.202]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id eHHT1a00M4MuCRf8VHHXVb; Wed, 12 Nov 2008 17:17:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=kzN8H9wRLCkA:10 a=nYMJO4lArBYA:10 a=48vgC7mUAAAA:8 a=GnsEtLNGr-UGLNmzdnQA:9 a=SbI96l3esEAvVUeSK88A:7 a=N-uedyYgKaBVoJVbK-KTpJwdyrkA:4 a=lZB815dzVvQA:10 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> In-Reply-To: <491A7EED.3090106@restena.lu> Date: Wed, 12 Nov 2008 11:16:47 -0600 Message-ID: <007d01c944ea$7947bb70$6bd73250$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclElEko75m1FlwCRsqcw8c2pT2enQAVMhOQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Stefan Winter > Hi, > = > the thread so far has three findings: > = > - to be conformant with the spec, you need to use IPSec to protect the > inband security handshake, even if IPsec is not to be used for the > remainder of the peer session > - failure to do so may enable an attacker to change the encryption used > during the entire peer session. It may also enable an attacker to tweak > other parameters in the CER. > - this might (still unsure about that) be mitigated by repeating the > CER > immediately after establishing a secure link. > = > These look like some severe implications of the protocol. I suggest to > give that a mention in 3588bis's security considerations section. = Noting the problem is a good idea, but I think that a better one would be to fix it :-). IIRC, the "negotiation" of TLS usage w/i Diameter was a part of a fad to avoid the usage of special ports for secured vs. non-secured ports for e.g. HTTP. As you have noted, it just doesn't work for Diameter, so I suggest that we either a) define new "secured" ports for TLS-protected Diameter traffic or better (since I think that we are deprecating the use of IPsec), simply redefine the existing ports as secured & possibly remove the security-related stuff from the CER/CEA exchange. > If that is seen as a good thing to do, I volunteer for the text. > = > Greetings, > = > Stefan Winter > = > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > = > Tel: +352 424409 1 > Fax: +352 422473 > = > _______________________________________________ > 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 From dime-bounces@ietf.org Wed Nov 12 09:28:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB61F3A67FA; Wed, 12 Nov 2008 09:28:10 -0800 (PST) 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 980133A68C4 for ; Wed, 12 Nov 2008 09:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 jSILQgPus2v1 for ; Wed, 12 Nov 2008 09:28:08 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 80BE93A6407 for ; Wed, 12 Nov 2008 09:28:08 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA06.westchester.pa.mail.comcast.net with comcast id eDhm1a0010SCNGk56HTPbb; Wed, 12 Nov 2008 17:27:23 +0000 Received: from gwzPC ([67.110.80.202]) by OMTA09.westchester.pa.mail.comcast.net with comcast id eHTu1a00a4MuCRf3VHTxPH; Wed, 12 Nov 2008 17:28:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=kzN8H9wRLCkA:10 a=nYMJO4lArBYA:10 a=48vgC7mUAAAA:8 a=UyEW8iGU8Fve_tMo4sMA:9 a=wU3eBvGiWaksm27pI_cAutHenfQA:4 a=lZB815dzVvQA:10 a=_3nJN2eeWHAA:10 From: "Glen Zorn" To: "'Jan Engelhardt'" , "'Stefan Winter'" References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> In-Reply-To: Date: Wed, 12 Nov 2008 11:27:14 -0600 Message-ID: <007e01c944eb$ee6687f0$cb3397d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclEycywHKnxscn7Qle6licHOuuXgQAIchbQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org ... > Even the STARTTLS commands of SMTP and IMAP are in line with the > respective protocols, it's not just the bland 8-char ASCII string. As > previously mentioned, the mere presence of Security-Inband-Id=TLS > could be our starttls trigger. Doesn't this have the same problem (lack of data authentication/integrity protection) as the existing method. > > Or maybe Diameter should move to ASCII (perhaps XML because of its > good nesting possibilities) too - that would also alleviate trying to > figure out an AVP's specific encoding (developer's ever-reoccuring > question "is that number now sent as a uint32 or as a human-readable > string?"). Been there, discussed that (at interminable length), don't go there again. > > >So, let me rephrase my original question: "would you prefer to > deprecate > >CER inband security negotiation in favour of a more commonly used and > >well-understood TLS handshake approach in 3588bis?" > _______________________________________________ > 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 From dime-bounces@ietf.org Wed Nov 12 10:10:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D140F3A6407; Wed, 12 Nov 2008 10:10:49 -0800 (PST) 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 ADE7A3A68C4 for ; Wed, 12 Nov 2008 10:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=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 eSis8EGnsgCU for ; Wed, 12 Nov 2008 10:10:44 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 7B8433A6407 for ; Wed, 12 Nov 2008 10:10:44 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id EAA4818043860; Wed, 12 Nov 2008 19:10:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id E123E1C11C9DE; Wed, 12 Nov 2008 19:10:42 +0100 (CET) Date: Wed, 12 Nov 2008 19:10:42 +0100 (CET) From: Jan Engelhardt To: Glen Zorn In-Reply-To: <007e01c944eb$ee6687f0$cb3397d0$@net> Message-ID: References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> <007e01c944eb$ee6687f0$cb3397d0$@net> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Wednesday 2008-11-12 18:27, Glen Zorn wrote: > >> Even the STARTTLS commands of SMTP and IMAP are in line with the >> respective protocols, it's not just the bland 8-char ASCII string. As >> previously mentioned, the mere presence of Security-Inband-Id=TLS >> could be our starttls trigger. > >Doesn't this have the same problem (lack of data authentication/integrity >protection) as the existing method. I am sure the smtp/imap Working Groups can convince us that the approach they took is good enough. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 12:12:35 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69DC3A6B44; Wed, 12 Nov 2008 12:12:35 -0800 (PST) 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 515943A6B44 for ; Wed, 12 Nov 2008 12:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 0GvCyKz7mezU for ; Wed, 12 Nov 2008 12:12:33 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 921D73A6834 for ; Wed, 12 Nov 2008 12:12:33 -0800 (PST) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id eKGb1a01m17UAYkA8LCauv; Wed, 12 Nov 2008 20:12:34 +0000 Received: from gwzPC ([67.110.80.202]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id eLCJ1a00V4MuCRf8ZLCNlE; Wed, 12 Nov 2008 20:12:31 +0000 X-Authority-Analysis: v=1.0 c=1 a=kzN8H9wRLCkA:10 a=nYMJO4lArBYA:10 a=0wh7Mer5Ufy-gJF2tQkA:9 a=fjc0XxBO3wi000uQ8tdPiIJtLhcA:4 a=_3nJN2eeWHAA:10 From: "Glen Zorn" To: "'Jan Engelhardt'" References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> <007e01c944eb$ee6687f0$cb3397d0$@net> In-Reply-To: Date: Wed, 12 Nov 2008 14:11:39 -0600 Message-ID: <008b01c94502$e71d7b90$b55872b0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclE8fvaA1kQoWF2Te64gpSJt7Ul5gAELt2A Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org ... > >Doesn't this have the same problem (lack of data > authentication/integrity > >protection) as the existing method. > > I am sure the smtp/imap Working Groups can convince us that the > approach > they took is good enough. Indeed it is, if it is implemented in a command by itself. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 13:07:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0243A6B60; Wed, 12 Nov 2008 13:07:37 -0800 (PST) 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 A1A683A6B60 for ; Wed, 12 Nov 2008 13:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 j6XlVF2PN8dO for ; Wed, 12 Nov 2008 13:07:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B00313A6B5E for ; Wed, 12 Nov 2008 13:07:35 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mACL7aCJ028861 for ; Wed, 12 Nov 2008 15:07:36 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mACL7T7V012232 for ; Wed, 12 Nov 2008 15:07:29 -0600 (CST) Received: from [192.168.0.28] (rocinante.8950aaa.com [192.168.0.28]) by hal.8950aaa.com (Postfix) with ESMTP id 880B258E35 for ; Wed, 12 Nov 2008 13:07:30 -0800 (PST) Message-ID: <491B4592.70602@alcatel-lucent.com> Date: Wed, 12 Nov 2008 13:07:30 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dime@ietf.org References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <491AC8D2.3050501@restena.lu> <491AD5E6.2000202@restena.lu> <007e01c944eb$ee6687f0$cb3397d0$@net> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: multipart/mixed; boundary="===============2006480040==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2006480040== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A few things to note in regards to this discussion about security:
  1. The typical start TLS mechanism, as used in several protocols, assumes a client server relationship as opposed to a peer to peer one, and applied in its most simplistic approach could lead to unnecessary "cross-handshaking" between peers during race conditions. Perhaps not a critical issue, but one that a preceding capabilities exchange would alleviate by deciding who is the client and who is the server, thus avoiding an unnecessary and relatively costly TLS key exchange in the cases where session resumption is not possible.
  2. The choice whether to use security or not can and should be a site policy decision and not driven by dynamic parameters in the protocol. From my point of view the Inband-Security-Id AVP is only there to indicate a capability and if the capability doesn't meet local security policy, communication cannot commence.
  3. Sending the full CER/CEA in the clear certainly exposes some information to a potential attacker and also makes its content vulnerable to alteration by a man in the middle attack and could potentially allow communication interruptions. In an appropriately configured network with an established PKI infrastructure it *should not* affect the trust relationship between peers in any way once TLS has been established since mutual certificate authentication is assumed which will establish the remote identity to each peer.
It appears to me that in environments where security is a concern, a minimal CER/CEA exchange should take place to establish client server roles and share peer identities that each peer can use as a basis for determining whether or not to engage in a subsequent TLS handshake. Once the TLS tunnel is negotiated and the appropriate trust relationship is determined, another CER/CEA exchange can follow inside of it to share more detailed capabilities. Unfortunately the state transitions for [IR]-Rcv-CE[RA] in the peer state machine description in the original RFC-3588 are lacking from 3588bis-13, perhaps these were put in with this very purpose in mind?

Just my two cents.

Jan Nordqvist,
Alcatel-Lucent 8950/AAA product group.

Jan Engelhardt wrote: 
On Wednesday 2008-11-12 18:27, Glen Zorn wrote:
  
Even the STARTTLS commands of SMTP and IMAP are in line with the
respective protocols, it's not just the bland 8-char ASCII string. As
previously mentioned, the mere presence of Security-Inband-Id=TLS
could be our starttls trigger.
      
Doesn't this have the same problem (lack of data authentication/integrity
protection) as the existing method.
    

I am sure the smtp/imap Working Groups can convince us that the approach 
they took is good enough.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--===============2006480040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2006480040==-- From dime-bounces@ietf.org Wed Nov 12 23:01:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBB83A6879; Wed, 12 Nov 2008 23:01:31 -0800 (PST) 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 B3E1D3A6879 for ; Wed, 12 Nov 2008 23:01:30 -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 wxUS4a6uPJNU for ; Wed, 12 Nov 2008 23:01:30 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id EFFB53A6831 for ; Wed, 12 Nov 2008 23:01:29 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 13 Nov 2008 02:01:26 -0500 From: Mark Jones To: "dime@ietf.org" Date: Thu, 13 Nov 2008 02:01:23 -0500 Thread-Topic: 3588bis-13: Redirect-Host usage contradiction Thread-Index: AclFXaNdZq0IfX50SpyVtyEe3Wb0dA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, I believe there is a contradiction in the description of Redirect-Host usage in 3588 and 3588bis-13. The last sentence in section 6.12 states that: The server contained in the selected Redirect-Host AVP SHOULD be used for all messages pertaining to this session. However, section 6.13 states that the default usage behaviour is DONT_CACHE unless it is overridden by a Redirect-Host-Usage. I think the most useful redirect behaviour is caching the redirect host for the duration of the Diameter session so this should be the default if Redirect-Host-Usage is absent, i.e. section 6.13 in 3588bis should be updated to state that ALL_SESSION is the default value of Redirect-Host-Usage. Any concerns? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 12 23:17:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514573A6831; Wed, 12 Nov 2008 23:17:25 -0800 (PST) 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 6B0D43A6831 for ; Wed, 12 Nov 2008 23:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 XdXHe98tdz6b for ; Wed, 12 Nov 2008 23:17:23 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id D3EEC3A67A4 for ; Wed, 12 Nov 2008 23:17:21 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 933FEA98B1; Thu, 13 Nov 2008 08:17:21 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 84FDDAF03C; Thu, 13 Nov 2008 08:17:21 +0100 (CET) Message-ID: <491BD481.7060806@restena.lu> Date: Thu, 13 Nov 2008 08:17:21 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Glen Zorn References: <491002F5.1040903@restena.lu> <49100B33.7060803@restena.lu> <491A7EED.3090106@restena.lu> <007d01c944ea$7947bb70$6bd73250$@net> In-Reply-To: <007d01c944ea$7947bb70$6bd73250$@net> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] integrity protection of CER exchanges 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, >> These look like some severe implications of the protocol. I suggest to >> give that a mention in 3588bis's security considerations section. = >> = > > Noting the problem is a good idea, but I think that a better one would be= to > fix it :-). Nah, you're overdoing it. :-) > IIRC, the "negotiation" of TLS usage w/i Diameter was a part of > a fad to avoid the usage of special ports for secured vs. non-secured por= ts > for e.g. HTTP. As you have noted, it just doesn't work for Diameter, so I > suggest that we either a) define new "secured" ports for TLS-protected > Diameter traffic or better (since I think that we are deprecating the use= of > IPsec), simply redefine the existing ports as secured & possibly remove t= he > security-related stuff from the CER/CEA exchange. > = I hate to bring up the term "backwards compatibility", but... redefining the port to be secure from day x onwards would make 3588 (non-bis) implementations somewhat confused. A new port sounds like a better idea to me. I suggest discussing possible ways out in the meeting. There's a 15 min slot for 3588bis already (15 min seems not a lot though, so we have to talk fast). Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 13 03:37:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704A73A689B; Thu, 13 Nov 2008 03:37:37 -0800 (PST) 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 201C73A689B for ; Thu, 13 Nov 2008 03:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 CvofuwiEQF7b for ; Thu, 13 Nov 2008 03:37:35 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2C4FC3A687E for ; Thu, 13 Nov 2008 03:37:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mADBbVlv014936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Nov 2008 12:37:32 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mADBbSP7024231 for ; Thu, 13 Nov 2008 12:37:31 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 12:37:21 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 12:37:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Nov 2008 13:37:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated DIME Meeting Agenda Thread-Index: AclFhDCwTlSf9unoTDaCMjjULawnlw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 13 Nov 2008 11:37:21.0088 (UTC) FILETIME=[30A4DC00:01C94584] Subject: [Dime] Updated DIME Meeting Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Please take a look at the updated meeting agenda: http://www.ietf.org/proceedings/08nov/agenda/dime.txt Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 13 07:34:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690033A6846; Thu, 13 Nov 2008 07:34:51 -0800 (PST) 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 EFC923A6846 for ; Thu, 13 Nov 2008 07:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 cEsnfz+X8RFm for ; Thu, 13 Nov 2008 07:34:49 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 363BC3A6826 for ; Thu, 13 Nov 2008 07:34:49 -0800 (PST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mADFZ6Tv002305; Thu, 13 Nov 2008 10:35:06 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <491C4917.8040708@tari.toshiba.com> Date: Thu, 13 Nov 2008 10:34:47 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Mark Jones References: In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, > I believe there is a contradiction in the description of Redirect-Host usage in 3588 and 3588bis-13. The last sentence in section 6.12 states that: > > The server contained in the selected Redirect-Host AVP SHOULD be used > for all messages pertaining to this session. > > However, section 6.13 states that the default usage behaviour is DONT_CACHE unless it is overridden by a Redirect-Host-Usage. > I agree. > I think the most useful redirect behaviour is caching the redirect host for the duration of the Diameter session so this should be the default if Redirect-Host-Usage is absent, i.e. section 6.13 in 3588bis should be updated to state that ALL_SESSION is the default value of Redirect-Host-Usage. > I have no strong opinion on this but to maybe ALL_SESSION as default just looks good on paper. For routing performance, always tracking the state of a session is more work than necessary. If DONT_CACHE is a default, basic redirection is simple. Anyway, having DONT_CACHE as a default does not take away any functionality from ALL_SESSION. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 13 20:11:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0850A3A67E7; Thu, 13 Nov 2008 20:11:22 -0800 (PST) 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 8D58A3A67E7; Thu, 13 Nov 2008 20:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xMhmr-nrCdH; Thu, 13 Nov 2008 20:11:18 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 36CE03A63D2; Thu, 13 Nov 2008 20:11:18 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAB007GO2AJWP@szxga02-in.huawei.com>; Fri, 14 Nov 2008 12:11:08 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAB00IHX2AJWS@szxga02-in.huawei.com>; Fri, 14 Nov 2008 12:11:07 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KAB00GH52AJQ2@szxml05-in.huawei.com>; Fri, 14 Nov 2008 12:11:07 +0800 (CST) Date: Fri, 14 Nov 2008 12:11:07 +0800 From: Tina TSOU To: dime@ietf.org, "Sun, Dong (Dong)" Message-id: <016101c9460f$04d12940$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20080829074809.28900@gmx.net> <09C9068466B79E4C938DC7737562404D02106BDD@ILEXC2U01.ndc.lucent.com> Cc: chris.newman@sun.com, iesg@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: multipart/mixed; boundary="===============1827585586==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1827585586== Content-type: multipart/alternative; boundary="Boundary_(ID_FX2zXVO0tyvD4+QnAbElcw)" This is a multi-part message in MIME format. --Boundary_(ID_FX2zXVO0tyvD4+QnAbElcw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw Diameter. B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: dime@ietf.org Cc: chris.newman@sun.com ; iesg@ietf.org Sent: Wednesday, November 12, 2008 1:39 AM Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw Following up the discussion, in order to answer the question "Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal " The following texts are proposed (based on the online/offline discussion with Dan/Hannes and DIME group): "" This application is used to authorize the network QoS resources (including amount of bandwidth, QoS class and traffic flow processing) based on the Diameter application [RFC4006]. The request is based on the Diameter extensibility discussions in the DIME WG that led to the conclusion that it is better to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP in order to avoid interoperability problems. The document is utilizing authorization and accounting functionality and the entire exchange is related to users utilizing applications that require QoS treatment. This approach is consistent with the practice and experience gained since the publication of [RFC3588] (see for example [RFC5224]) which is now under revision by the DIME Working Group and will provide a revised set of recommendations and procedures for IANA considerations [draft-ietf-dime-rfc3588bis]." Please let me know if you have any objection or comments. I will submit a revised version of this I-D for the review. Regards, Dong -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, August 29, 2008 3:48 AM To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com Cc: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw Hi Dan, let me quickly respond to this issue: > As expected the document was not approved by the IESG and is now in AD > Follow-up. > > Beyond the two DISCUSSes there were two ABSTAIN ballots. > > The principal concern that I heard was related to the fact that the > current process followed by the draft did not ensure a sufficient > level of review from the IETF to ensure that it really meets the IETF > consensus. > > In order to overcome this I suggest that we do the following: > > 1. Ask for at least one more review (two is better) from the > AAA-Doctors team or DIME WG making also sure that the reviewers also > include reading the relevant parts in the ITU-T document in their > review (Hannes, can you ask Bernard to be one of the reviewers?) I sent a mail to him. > > 2. Explain to the IESG why the DIME Working Group did not take this > work as a WG chartered item (hannes, please write a short explanation, > also include the discussions around 3588bis) draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects. Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments. For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either. The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems. The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following: * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues). * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view. * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior. As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC. > 3. Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will > draft such a text I will think about text. Maybe it is lack of imagination on how protocols could be used? Wouldn't be the first time that a protocol is used in a way not originally envisioned. Example: RSVP - RSVP-TE Funny enough, the idea about using Diameter for the purpose of NAT and firewall signaling actually came from the IETF MIDCOM working group, see http://www.ietf.org/rfc/rfc4097.txt Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... > > Also in parallel the DIME WG should do the best to accelerate the > approval and submission of RFC3588 to the IESG so that we will need to > deal with as few such cases in the future as possible (ideally zero). That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already). Ciao Hannes > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf > > Of Chris Newman > > Sent: Thursday, August 28, 2008 7:29 PM > > To: iesg@ietf.org > > Cc: Hannes.Tschofenig@gmx.net; > > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com > > Subject: DISCUSS: draft-sun-dime-itu-t-rw > > > > Discuss: > > As this issue was raised during IETF review and appears to concern a > > number of area directors, I'm holding an actionable discuss > > position: > > > > Based on GEN-ART review responses, it appears this statement in the > > DIAMETER base spec: > > > > "Diameter is not intended as a general purpose protocol, and > > allocations SHOULD NOT be made for purposes unrelated to > > authentication, authorization or accounting." > > > > is spurious and not being followed. If we're not going to follow > > this rule (which is fine if there's rough consensus not to follow > > it), I believe it's important that it be documented why we're not > > following the rule (a "SHOULD NOT" > > requires justification). Various approaches I find acceptable are: > > 1. The document approval text includes reasoning for ignoring > > SHOULD NOT 2. An update to the document text includes reasoning for > > ignoring > > SHOULD NOT > > 3. Hold this until a small RFC is published that updates 3588 to > > change or remove the SHOULD NOT restriction. > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_FX2zXVO0tyvD4+QnAbElcw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw Diameter.
 
B. R.
Tina
----- Original Message -----
Sent: Wednesday, November 12, 2008 1:39 AM
Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw


Following up the discussion, in order to answer the question
"Propose text for an update to the document including reasoning for
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal "

The following texts are proposed (based on the online/offline discussion
with Dan/Hannes and DIME group):
"" This application is used to authorize the network QoS resources
(including amount of bandwidth, QoS class and traffic flow processing)
based on the Diameter application [RFC4006]. The request is based on the
Diameter extensibility discussions in the DIME WG that  led to the
conclusion that it is better to define new Command Codes whenever the
ABNF of a command is modified by adding, removing or semantically
changing required AVP in order to avoid interoperability problems.  The
document is utilizing authorization and accounting functionality and the
entire exchange is related to users utilizing applications that require
QoS treatment. This approach is consistent with the practice and
experience gained since the publication of [RFC3588] (see for example
[RFC5224]) which is now under revision by the DIME Working Group and
will provide a revised set of recommendations and procedures for IANA
considerations [draft-ietf-dime-rfc3588bis]."

Please let me know if you have any objection or comments.

I will submit a revised version of this I-D for the review.

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Friday, August 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com
Cc: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org
Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan,

let me quickly respond to this issue:

> As expected the document was not approved by the IESG and is now in AD

> Follow-up.
>
> Beyond the two DISCUSSes there were two ABSTAIN ballots.
>
> The principal concern that I heard was related to the fact that the
> current process followed by the draft did not ensure a sufficient
> level of review from the IETF to ensure that it really meets the IETF
> consensus.
>
> In order to overcome this I suggest that we do the following:
>
> 1. Ask for at least one more review (two is better) from the
> AAA-Doctors team or DIME WG making also sure that the reviewers also
> include reading the relevant parts in the ITU-T document in their
> review (Hannes, can you ask Bernard to be one of the reviewers?)

I sent a mail to him.


>
> 2. Explain to the IESG why the DIME Working Group did not take this
> work as a WG chartered item (hannes, please write a short explanation,

> also include the discussions around 3588bis)

draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using
Diameter. In the DIME working group we also have a document that deals
with QoS signaling, namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt.
It does, however, not cover NAT and Firewall signaling aspects.

Other SDOs are, however, not required to use the work we do in the IETF
on certain Diameter applications. Additionally, they may enhance or
modify it. There are many reasons why this happens and I will not go
into the details of those. Call it a matter of life that has todo with
psychology rather than technical arguments.

For us in DIME it does not really matter why ITU-T works on this
specific subject and it does not matter to us from a review point of
view either.

The reason why the ITU-T (and previously OMA with
http://tools.ietf.org/html/rfc5224) came to the DIME working group is
actually related to a suggestion from our side (based on the Diameter
extensibility discussions we had) to define new Command Codes whenever
the ABNF of a command is modified by adding, removing or semantically
changing required AVP (i.e, those marked as {}). By defining new Command
Codes we believe to better avoid interoperability problems.

The OMA has followed that suggestion (and so did ITU-T, to some extend)
but obviously ran into an issue with the requirements for the allocation
of Command Codes (compared to the allocation of Application IDs) based
on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to
register applications without going through the IETF process but has
different rules for the allocation of Command Codes. The DIME working
group had a long discussion about this issue and decided to change the
rules for allocating Command Codes with the revision of RFC 3588 (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt)
and to align the procedure with the way how Application IDs are
requested. The main reasons for this decision were the following:

* We did not want to encourage SDOs to misuse Diameter Command Codes
when they don't want to come to the IETF (and thereby causing
interoperability issues).

* We did not want to drag all the SDOs to the IETF when it comes to
extending Diameter. Diameter is a very popular protocols among other
SDOs and this approach would not scale very well nor are we the experts
in all the applications areas people have in mind where Diameter could
be used.

* Some of us believe that the decision to have different rules for
Application ID allocation and Command Code assignment was a mistake
since it does not make a lot of sense from a logical point of view.

* We should not treat the 3GPP differently to other SDOs since the 3GPP
was given a bunch of Command Codes without a corresponding specification
(see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be
consistent in our behavior.

As such, we came up with the idea to have an "interim" solution for
dealing with requests regarding Diameter Command Codes before RFC
3588bis gets published as an RFC.


> 3. Propose text for an update to the document including reasoning for
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will
> draft such a text

I will think about text. Maybe it is lack of imagination on how
protocols could be used? Wouldn't be the first time that a protocol is
used in a way not originally envisioned. Example: RSVP - RSVP-TE

Funny enough, the idea about using Diameter for the purpose of NAT and
firewall signaling actually came from the IETF MIDCOM working group, see
http://www.ietf.org/rfc/rfc4097.txt
Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite
protocol and it turns out that this was the wrong decision. Hard to
predict preferences...


>
> Also in parallel the DIME WG should do the best to accelerate the
> approval and submission of RFC3588 to the IESG so that we will need to

> deal with as few such cases in the future as possible (ideally zero).

That's certainly a good idea. We are having a final round of reviews and
I have asked the authors of the draft to also re-read the document to
avoid problems in later stages (as they have happened with other
Diameter documents already).

Ciao
Hannes

>
> Thanks and Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf

> > Of Chris Newman
> > Sent: Thursday, August 28, 2008 7:29 PM
> > To: iesg@ietf.org
> > Cc: Hannes.Tschofenig@gmx.net;
> > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com
> > Subject: DISCUSS: draft-sun-dime-itu-t-rw
> >
> > Discuss:
> > As this issue was raised during IETF review and appears to concern a

> > number of area directors, I'm holding an actionable discuss
> > position:
> >
> > Based on GEN-ART review responses, it appears this statement in the
> > DIAMETER base spec:
> >
> >   "Diameter is not intended as a general purpose protocol, and
> >    allocations SHOULD NOT be made for purposes unrelated to
> >    authentication, authorization or accounting."
> >
> > is spurious and not being followed.  If we're not going to follow
> > this rule (which is fine if there's rough consensus not to follow
> > it), I believe it's important that it be documented why we're not
> > following the rule (a "SHOULD NOT"
> > requires justification).  Various approaches I find acceptable are:
> >  1. The document approval text includes reasoning for ignoring
> > SHOULD NOT  2. An update to the document text includes reasoning for

> > ignoring
> >     SHOULD NOT
> >  3. Hold this until a small RFC is published that updates 3588 to
> >     change or remove the SHOULD NOT restriction.
> >
> >
> >
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_FX2zXVO0tyvD4+QnAbElcw)-- --===============1827585586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1827585586==-- From dime-bounces@ietf.org Thu Nov 13 21:27:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF8F3A682D; Thu, 13 Nov 2008 21:27:24 -0800 (PST) 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 EF16D3A682D for ; Thu, 13 Nov 2008 21:27:22 -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 9J9Pg4g4iHH4 for ; Thu, 13 Nov 2008 21:27:22 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 162043A67EA for ; Thu, 13 Nov 2008 21:27:21 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 14 Nov 2008 00:27:17 -0500 From: Mark Jones To: Victor Fajardo Date: Fri, 14 Nov 2008 00:27:15 -0500 Thread-Topic: [Dime] 3588bis-13: Redirect-Host usage contradiction Thread-Index: AclFpWMz9Vt176+1SWmcibrMUI4stQAay/Mg Message-ID: References: <491C4917.8040708@tari.toshiba.com> In-Reply-To: <491C4917.8040708@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: November 13, 2008 23:35 > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction > > Hi Mark, > > > I believe there is a contradiction in the description of > Redirect-Host usage in 3588 and 3588bis-13. The last sentence > in section 6.12 states that: > > > > The server contained in the selected Redirect-Host AVP > SHOULD be used > > for all messages pertaining to this session. > > > > However, section 6.13 states that the default usage > behaviour is DONT_CACHE unless it is overridden by a > Redirect-Host-Usage. > > > > I agree. > > > I think the most useful redirect behaviour is caching the > redirect host for the duration of the Diameter session so > this should be the default if Redirect-Host-Usage is absent, > i.e. section 6.13 in 3588bis should be updated to state that > ALL_SESSION is the default value of Redirect-Host-Usage. > > > > I have no strong opinion on this but to maybe ALL_SESSION as default > just looks good on paper. For routing performance, always tracking the > state of a session is more work than necessary. If DONT_CACHE is a > default, basic redirection is simple. Anyway, having DONT_CACHE as a > default does not take away any functionality from ALL_SESSION. > I was thinking of alignment with the default value of Auth-Session-State which is STATE_MAINTAINED. If maintaining session state is required then the client must send the STR to the Origin-Host in the answer message which would be the Redirect-Host in the redirect message. What do others think? Given the contradiction in 3588, any fix means code changes may be required in existing implementations albeit minor ones. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 13 22:29:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A47A3A68CB; Thu, 13 Nov 2008 22:29:50 -0800 (PST) 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 A57E43A698A for ; Thu, 13 Nov 2008 22:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_62=0.6] 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 9iJiUQLNoN-a for ; Thu, 13 Nov 2008 22:29:47 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 91C213A6867 for ; Thu, 13 Nov 2008 22:29:47 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAE6U3O3001127; Fri, 14 Nov 2008 01:30:04 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <491D1AD6.2050901@tari.toshiba.com> Date: Fri, 14 Nov 2008 01:29:42 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Mark Jones References: <491C4917.8040708@tari.toshiba.com> In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: November 13, 2008 23:35 >> To: Mark Jones >> Cc: dime@ietf.org >> Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction >> >> Hi Mark, >> >> >>> I believe there is a contradiction in the description of >>> >> Redirect-Host usage in 3588 and 3588bis-13. The last sentence >> in section 6.12 states that: >> >>> The server contained in the selected Redirect-Host AVP >>> >> SHOULD be used >> >>> for all messages pertaining to this session. >>> >>> However, section 6.13 states that the default usage >>> >> behaviour is DONT_CACHE unless it is overridden by a >> Redirect-Host-Usage. >> >> I agree. >> >> >>> I think the most useful redirect behaviour is caching the >>> >> redirect host for the duration of the Diameter session so >> this should be the default if Redirect-Host-Usage is absent, >> i.e. section 6.13 in 3588bis should be updated to state that >> ALL_SESSION is the default value of Redirect-Host-Usage. >> >> I have no strong opinion on this but to maybe ALL_SESSION as default >> just looks good on paper. For routing performance, always tracking the >> state of a session is more work than necessary. If DONT_CACHE is a >> default, basic redirection is simple. Anyway, having DONT_CACHE as a >> default does not take away any functionality from ALL_SESSION. >> >> > > I was thinking of alignment with the default value of Auth-Session-State which is STATE_MAINTAINED. If maintaining session state is required then the client must send the STR to the Origin-Host in the answer message which would be the Redirect-Host in the redirect message. > Hmmm ... should'nt the Origin-Host be the actual server the client is talking to ? A client that gets redirected simply resends the original request to the alternate server which responds with an answer containing its origin host. -- victor > What do others think? Given the contradiction in 3588, any fix means code changes may be required in existing implementations albeit minor ones. > > Regards > Mark > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 13 23:34:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952F23A6992; Thu, 13 Nov 2008 23:34:00 -0800 (PST) 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 A82A23A6992 for ; Thu, 13 Nov 2008 23:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_62=0.6] 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 krPA2OGuMkac for ; Thu, 13 Nov 2008 23:33:59 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id CAC4D3A67E6 for ; Thu, 13 Nov 2008 23:33:58 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAE7YH2d001586; Fri, 14 Nov 2008 02:34:18 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <491D29E6.3090208@tari.toshiba.com> Date: Fri, 14 Nov 2008 02:33:58 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Mark Jones References: <491C4917.8040708@tari.toshiba.com> <491D1AD6.2050901@tari.toshiba.com> In-Reply-To: <491D1AD6.2050901@tari.toshiba.com> Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, >>> >>> >> >> I was thinking of alignment with the default value of >> Auth-Session-State which is STATE_MAINTAINED. If maintaining session >> state is required then the client must send the STR to the >> Origin-Host in the answer message which would be the Redirect-Host in >> the redirect message. >> > > Hmmm ... should'nt the Origin-Host be the actual server the client is > talking to ? A client that gets redirected simply resends the original > request to the alternate server which responds with an answer > containing its origin host. Pls disregard my comment above ... mis-interpreted your last sentence from Redirect-Host to Redirect agent. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 14 10:54:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977933A69A3; Fri, 14 Nov 2008 10:54:45 -0800 (PST) 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 CF3E03A635F; Fri, 14 Nov 2008 10:54:43 -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 AYjO3Vhg76EV; Fri, 14 Nov 2008 10:54:42 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id BBC403A68E6; Fri, 14 Nov 2008 10:54:42 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 14 Nov 2008 13:54:41 -0500 From: Avi Lior To: "David B. Nelson" , "dime@ietf.org" Date: Fri, 14 Nov 2008 13:54:40 -0500 Thread-Topic: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANr5qAAoTRcMA== Message-ID: <8A8CFE8F89C38B41A749C19328C76D6308B1FB384F@exchange02.bridgewatersys.com> References: <00e201c93c54$41cca5a0$04ffa8c0@nsnintra.net> <000201c941e7$c0db5420$0201a8c0@nsnintra.net><004b01c94205$4a9ea370$dfdbea50$@net> <00a101c942ff$5aa9a210$0201a8c0@nsnintra.net><006901c94375$00051ee0$000f5ca0$@net> <00c901c943f7$f5568140$0201a8c0@nsnintra.net> <63F3725E9F224667917650FAC1525074@xpsuperdvd2> In-Reply-To: <63F3725E9F224667917650FAC1525074@xpsuperdvd2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "aaa-doctors@ietf.org" , "radiusext@ops.ietf.org" Subject: Re: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Folks are throwing around terms like RADIUS server and RADIUS client all over the place. What is really lacking is a defintion - that we can all agree - of what is a RADIUS Server and a RADIUS Client. > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: November 11, 2008 9:14 AM > To: dime@ietf.org > Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Dime] [AAA-DOCTORS] AD Review of > dime-qos-parameters-06.txt > > Hi Hannes, > > > I don't think that attributes can be opaque to the RADIUS > client since > > the client has todo something with them. > > Maybe this is a matter of semantics. Just as the RADIUS > Server does not comprise the complete set of server-side AAA > functionality (e.g. policy servers, location servers, > authentication back-ends, etc. are logically separate), the > RADIUS Client does not comprise the complete set of AAA > functionality in the NAS. The RADIUS Client delivers > authorization information to the components of the NAS that > enforce access control. > > When you define the RADIUS Server and RADIUS Client in this > narrow sense, i.e. the code that deals with RADIUS PDUs, I > think you can claim the certain attributes are opaque to the > RADIUS Client (but certainly not to the NAS). > > -- Dave > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 14 16:23:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B657128C15D; Fri, 14 Nov 2008 16:23:43 -0800 (PST) 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 2721C3A67B4 for ; Fri, 14 Nov 2008 16:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.415, 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 PVyHAoBd93uH for ; Fri, 14 Nov 2008 16:23:40 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 114E728C138 for ; Fri, 14 Nov 2008 16:23:38 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA09.westchester.pa.mail.comcast.net with comcast id fCLH1a00l0Fqzac59CPfzY; Sat, 15 Nov 2008 00:23:39 +0000 Received: from gwzPC ([67.110.80.10]) by OMTA08.westchester.pa.mail.comcast.net with comcast id fCNw1a0010DM7aT3UCP1AT; Sat, 15 Nov 2008 00:23:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=cKD0evPVvKUA:10 a=zruE5NG1xP8A:10 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=dh-YqgGZ7zLbX0LbjakA:9 a=gWzJGSanbSJ322BKazYA:7 a=rL01LNzG6asnMTvLm4RorX8ntv8A:4 a=3FZX-ydVlcEA:10 a=lZB815dzVvQA:10 a=KdsN9ty_cgEA:10 a=BFDKbZatV3MA:10 a=5g1bGOLZ_csA:10 a=8EtVh5AEJqUA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=K63lMySz-0eW_qT_-p0A:9 a=TIT9qAAAZQkcCQfmjBIA:7 a=QIxYdw2Bf2buD18yDVXQsbhBSEMA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Tina TSOU'" References: <20080829074809.28900@gmx.net> <09C9068466B79E4C938DC7737562404D02106BDD@ILEXC2U01.ndc.lucent.com> <016101c9460f$04d12940$7427460a@china.huawei.com> In-Reply-To: <016101c9460f$04d12940$7427460a@china.huawei.com> Date: Fri, 14 Nov 2008 18:22:51 -0600 Message-ID: <000001c946b8$62213500$26639f00$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclGDw6WqWi0yxGoRdSXbLJW9idotAAqM+LA Content-Language: en-us Cc: dime@ietf.org, chris.newman@sun.com, iesg@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: multipart/mixed; boundary="===============0876382271==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0876382271== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C94686.1786C500" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0001_01C94686.1786C500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw Diameter. It doesn't look to me as if Hannes' excellent AAA Doctors review has been responded to, however, at least in the draft. Has the ITU-T specification been modified appropriately? B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: dime@ietf.org Cc: chris.newman@sun.com ; iesg@ietf.org Sent: Wednesday, November 12, 2008 1:39 AM Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw Following up the discussion, in order to answer the question "Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal " The following texts are proposed (based on the online/offline discussion with Dan/Hannes and DIME group): "" This application is used to authorize the network QoS resources (including amount of bandwidth, QoS class and traffic flow processing) based on the Diameter application [RFC4006]. The request is based on the Diameter extensibility discussions in the DIME WG that led to the conclusion that it is better to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP in order to avoid interoperability problems. The document is utilizing authorization and accounting functionality and the entire exchange is related to users utilizing applications that require QoS treatment. This approach is consistent with the practice and experience gained since the publication of [RFC3588] (see for example [RFC5224]) which is now under revision by the DIME Working Group and will provide a revised set of recommendations and procedures for IANA considerations [draft-ietf-dime-rfc3588bis]." Please let me know if you have any objection or comments. I will submit a revised version of this I-D for the review. Regards, Dong -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, August 29, 2008 3:48 AM To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com Cc: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw Hi Dan, let me quickly respond to this issue: > As expected the document was not approved by the IESG and is now in AD > Follow-up. > > Beyond the two DISCUSSes there were two ABSTAIN ballots. > > The principal concern that I heard was related to the fact that the > current process followed by the draft did not ensure a sufficient > level of review from the IETF to ensure that it really meets the IETF > consensus. > > In order to overcome this I suggest that we do the following: > > 1. Ask for at least one more review (two is better) from the > AAA-Doctors team or DIME WG making also sure that the reviewers also > include reading the relevant parts in the ITU-T document in their > review (Hannes, can you ask Bernard to be one of the reviewers?) I sent a mail to him. > > 2. Explain to the IESG why the DIME Working Group did not take this > work as a WG chartered item (hannes, please write a short explanation, > also include the discussions around 3588bis) draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects. Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments. For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either. The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems. The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following: * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues). * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view. * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior. As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC. > 3. Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will > draft such a text I will think about text. Maybe it is lack of imagination on how protocols could be used? Wouldn't be the first time that a protocol is used in a way not originally envisioned. Example: RSVP - RSVP-TE Funny enough, the idea about using Diameter for the purpose of NAT and firewall signaling actually came from the IETF MIDCOM working group, see http://www.ietf.org/rfc/rfc4097.txt Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... > > Also in parallel the DIME WG should do the best to accelerate the > approval and submission of RFC3588 to the IESG so that we will need to > deal with as few such cases in the future as possible (ideally zero). That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already). Ciao Hannes > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf > > Of Chris Newman > > Sent: Thursday, August 28, 2008 7:29 PM > > To: iesg@ietf.org > > Cc: Hannes.Tschofenig@gmx.net; > > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com > > Subject: DISCUSS: draft-sun-dime-itu-t-rw > > > > Discuss: > > As this issue was raised during IETF review and appears to concern a > > number of area directors, I'm holding an actionable discuss > > position: > > > > Based on GEN-ART review responses, it appears this statement in the > > DIAMETER base spec: > > > > "Diameter is not intended as a general purpose protocol, and > > allocations SHOULD NOT be made for purposes unrelated to > > authentication, authorization or accounting." > > > > is spurious and not being followed. If we're not going to follow > > this rule (which is fine if there's rough consensus not to follow > > it), I believe it's important that it be documented why we're not > > following the rule (a "SHOULD NOT" > > requires justification). Various approaches I find acceptable are: > > 1. The document approval text includes reasoning for ignoring > > SHOULD NOT 2. An update to the document text includes reasoning for > > ignoring > > SHOULD NOT > > 3. Hold this until a small RFC is published that updates 3588 to > > change or remove the SHOULD NOT restriction. > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------=_NextPart_000_0001_01C94686.1786C500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation = Q.3303.3 Rw Diameter.

It doesn't look to me as if Hannes' excellent AAA Doctors = review has been responded to, however, at least in the draft.  Has the = ITU-T specification been modified appropriately?

 

B. R.
Tina

----- Original Message -----

Sent:<= /b> Wednesday, = November 12, 2008 1:39 AM

Subject: Re: [Dime] = DISCUSS: draft-sun-dime-itu-t-rw

 


Following up the discussion, in order to answer the question
"Propose text for an update to the document including reasoning for =
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal "

The following texts are proposed (based on the online/offline = discussion
with Dan/Hannes and DIME group):
"" This application is used to authorize the network QoS = resources
(including amount of bandwidth, QoS class and traffic flow = processing)
based on the Diameter application [RFC4006]. The request is based on = the
Diameter extensibility discussions in the DIME WG that  led to = the
conclusion that it is better to define new Command Codes whenever = the
ABNF of a command is modified by adding, removing or semantically
changing required AVP in order to avoid interoperability problems.  = The
document is utilizing authorization and accounting functionality and = the
entire exchange is related to users utilizing applications that = require
QoS treatment. This approach is consistent with the practice and
experience gained since the publication of [RFC3588] (see for = example
[RFC5224]) which is now under revision by the DIME Working Group and
will provide a revised set of recommendations and procedures for = IANA
considerations [draft-ietf-dime-rfc3588bis]."

Please let me know if you have any objection or comments.

I will submit a revised version of this I-D for the review.

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Friday, August 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com
Cc: Sun, Dong (Dong); draft-sun-dime-itu= -t-rw@tools.ietf.org
Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan,

let me quickly respond to this issue:

> As expected the document was not approved by the IESG and is now in = AD

> Follow-up.
>
> Beyond the two DISCUSSes there were two ABSTAIN ballots.
>
> The principal concern that I heard was related to the fact that the =
> current process followed by the draft did not ensure a sufficient =
> level of review from the IETF to ensure that it really meets the = IETF
> consensus.
>
> In order to overcome this I suggest that we do the following:
>
> 1. Ask for at least one more review (two is better) from the
> AAA-Doctors team or DIME WG making also sure that the reviewers = also
> include reading the relevant parts in the ITU-T document in their =
> review (Hannes, can you ask Bernard to be one of the = reviewers?)

I sent a mail to him.


>
> 2. Explain to the IESG why the DIME Working Group did not take this =
> work as a WG chartered item (hannes, please write a short = explanation,

> also include the discussions around 3588bis)

draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using
Diameter. In the DIME working group we also have a document that = deals
with QoS signaling, namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-= 06.txt.
It does, however, not cover NAT and Firewall signaling aspects.

Other SDOs are, however, not required to use the work we do in the = IETF
on certain Diameter applications. Additionally, they may enhance or
modify it. There are many reasons why this happens and I will not go
into the details of those. Call it a matter of life that has todo = with
psychology rather than technical arguments.

For us in DIME it does not really matter why ITU-T works on this
specific subject and it does not matter to us from a review point of
view either.

The reason why the ITU-T (and previously OMA with
http://tools.ietf.org/html/rf= c5224) came to the DIME working group is
actually related to a suggestion from our side (based on the = Diameter
extensibility discussions we had) to define new Command Codes = whenever
the ABNF of a command is modified by adding, removing or = semantically
changing required AVP (i.e, those marked as {}). By defining new = Command
Codes we believe to better avoid interoperability problems.

The OMA has followed that suggestion (and so did ITU-T, to some = extend)
but obviously ran into an issue with the requirements for the = allocation
of Command Codes (compared to the allocation of Application IDs) = based
on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) = to
register applications without going through the IETF process but has
different rules for the allocation of Command Codes. The DIME = working
group had a long discussion about this issue and decided to change = the
rules for allocating Command Codes with the revision of RFC 3588 = (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.t= xt)
and to align the procedure with the way how Application IDs are
requested. The main reasons for this decision were the following:

* We did not want to encourage SDOs to misuse Diameter Command Codes
when they don't want to come to the IETF (and thereby causing
interoperability issues).

* We did not want to drag all the SDOs to the IETF when it comes to
extending Diameter. Diameter is a very popular protocols among other
SDOs and this approach would not scale very well nor are we the = experts
in all the applications areas people have in mind where Diameter = could
be used.

* Some of us believe that the decision to have different rules for
Application ID allocation and Command Code assignment was a mistake
since it does not make a lot of sense from a logical point of view.

* We should not treat the 3GPP differently to other SDOs since the = 3GPP
was given a bunch of Command Codes without a corresponding = specification
(see ftp://ftp.rfc-edit= or.org/in-notes/rfc3589.txt). We try to be
consistent in our behavior.

As such, we came up with the idea to have an "interim" = solution for
dealing with requests regarding Diameter Command Codes before RFC
3588bis gets published as an RFC.


> 3. Propose text for an update to the document including reasoning = for
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will =
> draft such a text

I will think about text. Maybe it is lack of imagination on how
protocols could be used? Wouldn't be the first time that a protocol = is
used in a way not originally envisioned. Example: RSVP - RSVP-TE

Funny enough, the idea about using Diameter for the purpose of NAT = and
firewall signaling actually came from the IETF MIDCOM working group, = see
http://www.ietf.org/rfc/rfc4= 097.txt
Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their = favorite
protocol and it turns out that this was the wrong decision. Hard to
predict preferences...


>
> Also in parallel the DIME WG should do the best to accelerate the =
> approval and submission of RFC3588 to the IESG so that we will need = to

> deal with as few such cases in the future as possible (ideally = zero).

That's certainly a good idea. We are having a final round of reviews = and
I have asked the authors of the draft to also re-read the document = to
avoid problems in later stages (as they have happened with other
Diameter documents already).

Ciao
Hannes

>
> Thanks and Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf

> > Of Chris Newman
> > Sent: Thursday, August 28, 2008 7:29 PM
> > To: iesg@ietf.org
> > Cc: Hannes.Tschofenig@gmx.net;<= br> > > draft-sun-dime-itu= -t-rw@tools.ietf.org; dongsun@alcatel-lucent.com=
> > Subject: DISCUSS: draft-sun-dime-itu-t-rw
> >
> > Discuss:
> > As this issue was raised during IETF review and appears to = concern a

> > number of area directors, I'm holding an actionable discuss =
> > position:
> >
> > Based on GEN-ART review responses, it appears this statement = in the
> > DIAMETER base spec:
> >
> >   "Diameter is not intended as a general = purpose protocol, and
> >    allocations SHOULD NOT be made for purposes unrelated to
> >    authentication, authorization or = accounting."
> >
> > is spurious and not being followed.  If we're not going = to follow
> > this rule (which is fine if there's rough consensus not to = follow
> > it), I believe it's important that it be documented why we're = not
> > following the rule (a "SHOULD NOT"
> > requires justification).  Various approaches I find = acceptable are:
> >  1. The document approval text includes reasoning for = ignoring
> > SHOULD NOT  2. An update to the document text includes = reasoning for

> > ignoring
> >     SHOULD NOT
> >  3. Hold this until a small RFC is published that updates = 3588 to
> >     change or remove the SHOULD NOT = restriction.
> >
> >
> >
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/= mailman/listinfo/dime

------=_NextPart_000_0001_01C94686.1786C500-- --===============0876382271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0876382271==-- From dime-bounces@ietf.org Fri Nov 14 18:49:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C28028C14F; Fri, 14 Nov 2008 18:49:58 -0800 (PST) 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 7BFE93A6AA2; Fri, 14 Nov 2008 18:49:57 -0800 (PST) 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=[AWL=-0.000, 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 WetFXLLTjFHA; Fri, 14 Nov 2008 18:49:55 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 261A03A6A84; Fri, 14 Nov 2008 18:49:54 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAF2niPo009852; Fri, 14 Nov 2008 20:49:44 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 20:49:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Nov 2008 20:49:41 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02140041@ILEXC2U01.ndc.lucent.com> In-Reply-To: <000001c946b8$62213500$26639f00$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DISCUSS: draft-sun-dime-itu-t-rw Thread-Index: AclGDw6WqWi0yxGoRdSXbLJW9idotAAqM+LAAAUOVgA= References: <016101c9460f$04d12940$7427460a@china.huawei.com> <000001c946b8$62213500$26639f00$@net> From: "Sun, Dong \(Dong\)" To: "Glen Zorn" , "Tina TSOU" X-OriginalArrivalTime: 15 Nov 2008 02:49:44.0276 (UTC) FILETIME=[D08A3140:01C946CC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: dime@ietf.org, chris.newman@sun.com, iesg@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: multipart/mixed; boundary="===============2105596817==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2105596817== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C946CC.D03E4733" This is a multi-part message in MIME format. ------_=_NextPart_001_01C946CC.D03E4733 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glen, =20 Yes. The ITU-T Rec has been updated based on Hannes' comments e.g. the ABNF issue, and a response was sent to the exploder a while ago. I don't see any further comments/objection. =20 certainly, some of those comments (e.g. CCR/CCA), as indicated by Hannes, are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts some of Gx spec. For the interoperability issue, they have to be resolved by 3GPP. Moreover, they are irrelevant to this ID for the request of new command code PIR/PIA (There is no question about the use of PIR/PIA).=20 =20 Hope this help clarify your question. =20 Thanks, Dong ________________________________ From: Glen Zorn [mailto:glenzorn@comcast.net]=20 Sent: Friday, November 14, 2008 7:23 PM To: 'Tina TSOU' Cc: chris.newman@sun.com; iesg@ietf.org; dime@ietf.org; Sun, Dong (Dong) Subject: RE: [Dime] DISCUSS: draft-sun-dime-itu-t-rw ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw Diameter. It doesn't look to me as if Hannes' excellent AAA Doctors review has been responded to, however, at least in the draft. Has the ITU-T specification been modified appropriately? =20 B. R. Tina ----- Original Message -----=20 From: Sun, Dong (Dong) =20 To: dime@ietf.org=20 Cc: chris.newman@sun.com ; iesg@ietf.org=20 Sent: Wednesday, November 12, 2008 1:39 AM Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw =20 =09 Following up the discussion, in order to answer the question "Propose text for an update to the document including reasoning for=20 > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal " =09 The following texts are proposed (based on the online/offline discussion with Dan/Hannes and DIME group): "" This application is used to authorize the network QoS resources (including amount of bandwidth, QoS class and traffic flow processing) based on the Diameter application [RFC4006]. The request is based on the Diameter extensibility discussions in the DIME WG that led to the conclusion that it is better to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP in order to avoid interoperability problems. The document is utilizing authorization and accounting functionality and the entire exchange is related to users utilizing applications that require QoS treatment. This approach is consistent with the practice and experience gained since the publication of [RFC3588] (see for example [RFC5224]) which is now under revision by the DIME Working Group and will provide a revised set of recommendations and procedures for IANA considerations [draft-ietf-dime-rfc3588bis]." =09 Please let me know if you have any objection or comments. =09 I will submit a revised version of this I-D for the review. =09 Regards, Dong =09 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, August 29, 2008 3:48 AM To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com Cc: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw =09 Hi Dan,=20 =09 let me quickly respond to this issue:=20 =09 > As expected the document was not approved by the IESG and is now in AD =09 > Follow-up. >=20 > Beyond the two DISCUSSes there were two ABSTAIN ballots.=20 >=20 > The principal concern that I heard was related to the fact that the=20 > current process followed by the draft did not ensure a sufficient=20 > level of review from the IETF to ensure that it really meets the IETF=20 > consensus. >=20 > In order to overcome this I suggest that we do the following:=20 >=20 > 1. Ask for at least one more review (two is better) from the=20 > AAA-Doctors team or DIME WG making also sure that the reviewers also=20 > include reading the relevant parts in the ITU-T document in their=20 > review (Hannes, can you ask Bernard to be one of the reviewers?) =09 I sent a mail to him.=20 =09 =09 >=20 > 2. Explain to the IESG why the DIME Working Group did not take this=20 > work as a WG chartered item (hannes, please write a short explanation, =09 > also include the discussions around 3588bis) =09 draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely =09 http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects.=20 =09 Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments.=20 =09 For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either.=20 =09 The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems.=20 =09 The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see =09 http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following:=20 =09 * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues).=20 =09 * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. =09 * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view.=20 =09 * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior.=20 =09 As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC.=20 =09 =09 > 3. Propose text for an update to the document including reasoning for=20 > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will=20 > draft such a text =09 I will think about text. Maybe it is lack of imagination on how protocols could be used? Wouldn't be the first time that a protocol is used in a way not originally envisioned. Example: RSVP - RSVP-TE =09 Funny enough, the idea about using Diameter for the purpose of NAT and firewall signaling actually came from the IETF MIDCOM working group, see http://www.ietf.org/rfc/rfc4097.txt Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... =09 =09 >=20 > Also in parallel the DIME WG should do the best to accelerate the=20 > approval and submission of RFC3588 to the IESG so that we will need to =09 > deal with as few such cases in the future as possible (ideally zero). =09 That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already).=20 =09 Ciao Hannes =09 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf =09 > > Of Chris Newman > > Sent: Thursday, August 28, 2008 7:29 PM > > To: iesg@ietf.org > > Cc: Hannes.Tschofenig@gmx.net; > > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com > > Subject: DISCUSS: draft-sun-dime-itu-t-rw > >=20 > > Discuss: > > As this issue was raised during IETF review and appears to concern a =09 > > number of area directors, I'm holding an actionable discuss=20 > > position: > >=20 > > Based on GEN-ART review responses, it appears this statement in the=20 > > DIAMETER base spec: > >=20 > > "Diameter is not intended as a general purpose protocol, and > > allocations SHOULD NOT be made for purposes unrelated to > > authentication, authorization or accounting." > >=20 > > is spurious and not being followed. If we're not going to follow=20 > > this rule (which is fine if there's rough consensus not to follow=20 > > it), I believe it's important that it be documented why we're not=20 > > following the rule (a "SHOULD NOT" > > requires justification). Various approaches I find acceptable are: > > 1. The document approval text includes reasoning for ignoring=20 > > SHOULD NOT 2. An update to the document text includes reasoning for =09 > > ignoring > > SHOULD NOT > > 3. Hold this until a small RFC is published that updates 3588 to > > change or remove the SHOULD NOT restriction. > >=20 > >=20 > >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C946CC.D03E4733 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Glen,
 
Yes. The ITU-T=20 Rec has been updated based on Hannes' comments e.g. the ABNF issue, = and a=20 response was sent to the exploder a while ago. I don't see any further=20 comments/objection.
 
certainly, some of those comments (e.g. CCR/CCA), as indicated by=20 Hannes, are related to 3GPP Gx 29.212 spec since the = ITU-T Rw=20 adopts some of Gx spec. For the interoperability issue, they have to be = resolved=20 by 3GPP. Moreover, they are irrelevant to this ID for = the request of=20 new command code PIR/PIA (There is no=20 question about the use of PIR/PIA).
 
Hope this help clarify your = question.
 
Thanks,
Dong

From: Glen Zorn = [mailto:glenzorn@comcast.net]=20
Sent: Friday, November 14, 2008 7:23 PM
To: 'Tina=20 TSOU'
Cc: chris.newman@sun.com; iesg@ietf.org; dime@ietf.org; = Sun,=20 Dong (Dong)
Subject: RE: [Dime] DISCUSS:=20 draft-sun-dime-itu-t-rw

ITU-T is = waiting for=20 command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw=20 Diameter.

It=20 doesn't look to me as if Hannes' excellent AAA Doctors review has been = responded=20 to, however, at least in the draft.  Has the ITU-T specification = been=20 modified appropriately?

 

B.=20 R.
Tina

----- = Original=20 Message -----

From: Sun,=20 Dong (Dong)

To: dime@ietf.org=20

Cc: chris.newman@sun.com ; iesg@ietf.org=20

Sent: = Wednesday,=20 November 12, 2008 1:39 AM

Subject: Re: = [Dime]=20 DISCUSS: draft-sun-dime-itu-t-rw

 


Following up the discussion, in order to = answer the=20 question
"Propose text for an update to the document including = reasoning=20 for
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal=20 "

The following texts are proposed (based on the online/offline = discussion
with Dan/Hannes and DIME group):
"" This application = is used=20 to authorize the network QoS resources
(including amount of = bandwidth, QoS=20 class and traffic flow processing)
based on the Diameter = application=20 [RFC4006]. The request is based on the
Diameter extensibility = discussions=20 in the DIME WG that  led to the
conclusion that it is better = to define=20 new Command Codes whenever the
ABNF of a command is modified by = adding,=20 removing or semantically
changing required AVP in order to avoid=20 interoperability problems.  The
document is utilizing = authorization=20 and accounting functionality and the
entire exchange is related to = users=20 utilizing applications that require
QoS treatment. This approach is = consistent with the practice and
experience gained since the = publication of=20 [RFC3588] (see for example
[RFC5224]) which is now under revision = by the=20 DIME Working Group and
will provide a revised set of = recommendations and=20 procedures for IANA
considerations=20 [draft-ietf-dime-rfc3588bis]."

Please let me know if you have = any=20 objection or comments.

I will submit a revised version of this = I-D for=20 the review.

Regards,
Dong

-----Original = Message-----
From:=20 Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Friday, = August=20 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com
Cc: = Sun, Dong=20 (Dong); draft-sun-dime-itu= -t-rw@tools.ietf.org
Subject:=20 Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan,

let me = quickly=20 respond to this issue:

> As expected the document was not = approved=20 by the IESG and is now in AD

> Follow-up.
>
> = Beyond=20 the two DISCUSSes there were two ABSTAIN ballots.
>
> = The=20 principal concern that I heard was related to the fact that the =
>=20 current process followed by the draft did not ensure a sufficient =
>=20 level of review from the IETF to ensure that it really meets the IETF =
>=20 consensus.
>
> In order to overcome this I suggest that = we do the=20 following:
>
> 1. Ask for at least one more review (two = is=20 better) from the
> AAA-Doctors team or DIME WG making also sure = that=20 the reviewers also
> include reading the relevant parts in the = ITU-T=20 document in their
> review (Hannes, can you ask Bernard to be = one of=20 the reviewers?)

I sent a mail to him.


>
> = 2.=20 Explain to the IESG why the DIME Working Group did not take this =
> work=20 as a WG chartered item (hannes, please write a short = explanation,

>=20 also include the discussions around = 3588bis)

draft-sun-dime-itu-t-rw is=20 about a QoS/NAT/Firewall signaling using
Diameter. In the DIME = working=20 group we also have a document that deals
with QoS signaling, = namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-= 06.txt.
It=20 does, however, not cover NAT and Firewall signaling aspects. =

Other=20 SDOs are, however, not required to use the work we do in the = IETF
on=20 certain Diameter applications. Additionally, they may enhance = or
modify it.=20 There are many reasons why this happens and I will not go
into the = details=20 of those. Call it a matter of life that has todo with
psychology = rather=20 than technical arguments.

For us in DIME it does not really = matter why=20 ITU-T works on this
specific subject and it does not matter to us = from a=20 review point of
view either.

The reason why the ITU-T (and=20 previously OMA with
http://tools.ietf.org/html/rf= c5224)=20 came to the DIME working group is
actually related to a suggestion = from our=20 side (based on the Diameter
extensibility discussions we had) to = define new=20 Command Codes whenever
the ABNF of a command is modified by adding, = removing or semantically
changing required AVP (i.e, those marked = as {}).=20 By defining new Command
Codes we believe to better avoid = interoperability=20 problems.

The OMA has followed that suggestion (and so did = ITU-T, to=20 some extend)
but obviously ran into an issue with the requirements = for the=20 allocation
of Command Codes (compared to the allocation of = Application IDs)=20 based
on what RFC 3588 says. RFC 3588 allows vendors (in this case = SDOs)=20 to
register applications without going through the IETF process but = has
different rules for the allocation of Command Codes. The DIME=20 working
group had a long discussion about this issue and decided to = change=20 the
rules for allocating Command Codes with the revision of RFC = 3588=20 (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.t= xt)
and=20 to align the procedure with the way how Application IDs = are
requested. The=20 main reasons for this decision were the following:

* We did = not want=20 to encourage SDOs to misuse Diameter Command Codes
when they don't = want to=20 come to the IETF (and thereby causing
interoperability issues). =

*=20 We did not want to drag all the SDOs to the IETF when it comes = to
extending=20 Diameter. Diameter is a very popular protocols among other
SDOs and = this=20 approach would not scale very well nor are we the experts
in all = the=20 applications areas people have in mind where Diameter could
be=20 used.

* Some of us believe that the decision to have different = rules=20 for
Application ID allocation and Command Code assignment was a=20 mistake
since it does not make a lot of sense from a logical point = of view.=20

* We should not treat the 3GPP differently to other SDOs since = the=20 3GPP
was given a bunch of Command Codes without a corresponding=20 specification
(see ftp://ftp.rfc-edit= or.org/in-notes/rfc3589.txt).=20 We try to be
consistent in our behavior.

As such, we came = up with=20 the idea to have an "interim" solution for
dealing with requests = regarding=20 Diameter Command Codes before RFC
3588bis gets published as an RFC. =


> 3. Propose text for an update to the document = including=20 reasoning for
> ignoring SHOULD NOT from RFC 3588 as per Chris' = proposal - I will
> draft such a text

I will think about = text.=20 Maybe it is lack of imagination on how
protocols could be used? = Wouldn't be=20 the first time that a protocol is
used in a way not originally = envisioned.=20 Example: RSVP - RSVP-TE

Funny enough, the idea about using = Diameter for=20 the purpose of NAT and
firewall signaling actually came from the = IETF=20 MIDCOM working group, see
http://www.ietf.org/rfc/rfc4= 097.txt
Unfortuantely,=20 the MIDCOM group decided to pick SNMPv3 as their favorite
protocol = and it=20 turns out that this was the wrong decision. Hard to
predict=20 preferences...


>
> Also in parallel the DIME WG = should do=20 the best to accelerate the
> approval and submission of RFC3588 = to the=20 IESG so that we will need to

> deal with as few such cases = in the=20 future as possible (ideally zero).

That's certainly a good = idea. We are=20 having a final round of reviews and
I have asked the authors of the = draft=20 to also re-read the document to
avoid problems in later stages (as = they=20 have happened with other
Diameter documents already).=20

Ciao
Hannes

>
> Thanks and = Regards,
>=20
> Dan
>
>
> > -----Original = Message-----
>=20 > From: iesg-bounces@iesg.org=20 [mailto:iesg-bounces@iesg.org] On Behalf

> > Of Chris=20 Newman
> > Sent: Thursday, August 28, 2008 7:29 PM
> = > To:=20 iesg@ietf.org
> > Cc: Hannes.Tschofenig@gmx.net;<= BR>>=20 > draft-sun-dime-itu= -t-rw@tools.ietf.org;=20 dongsun@alcatel-lucent.com=
>=20 > Subject: DISCUSS: draft-sun-dime-itu-t-rw
> >
> = >=20 Discuss:
> > As this issue was raised during IETF review and = appears=20 to concern a

> > number of area directors, I'm holding an = actionable discuss
> > position:
> >
> > = Based on=20 GEN-ART review responses, it appears this statement in the
> = >=20 DIAMETER base spec:
> >
> >   "Diameter = is not=20 intended as a general purpose protocol, and
> = >   =20 allocations SHOULD NOT be made for purposes unrelated to
>=20 >    authentication, authorization or = accounting."
>=20 >
> > is spurious and not being followed.  If we're = not=20 going to follow
> > this rule (which is fine if there's = rough=20 consensus not to follow
> > it), I believe it's important = that it be=20 documented why we're not
> > following the rule (a "SHOULD=20 NOT"
> > requires justification).  Various approaches I = find=20 acceptable are:
> >  1. The document approval text = includes=20 reasoning for ignoring
> > SHOULD NOT  2. An update to = the=20 document text includes reasoning for

> > ignoring
> = >     SHOULD NOT
> >  3. Hold = this until=20 a small RFC is published that updates 3588 to
>=20 >     change or remove the SHOULD NOT=20 restriction.
> >
> >
> >=20
_______________________________________________
DiME mailing = list
DiME@ietf.org
https://www.ietf.org/= mailman/listinfo/dime

<= /HTML> ------_=_NextPart_001_01C946CC.D03E4733-- --===============2105596817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2105596817==-- From dime-bounces@ietf.org Fri Nov 14 19:01:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E718B3A6828; Fri, 14 Nov 2008 19:01:21 -0800 (PST) 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 561CA3A6828 for ; Fri, 14 Nov 2008 19:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.386, 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 ZhUmzsaKh0UI for ; Fri, 14 Nov 2008 19:01:19 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id F35913A688D for ; Fri, 14 Nov 2008 19:01:18 -0800 (PST) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id fCWd1a00n0mlR8UA5F1GdK; Sat, 15 Nov 2008 03:01:18 +0000 Received: from gwzPC ([67.110.80.10]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id fF0Y1a00Q0DM7aT8XF0fgV; Sat, 15 Nov 2008 03:01:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=cKD0evPVvKUA:10 a=zruE5NG1xP8A:10 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=qKfBVShj-7Pypt174SIA:9 a=BGB5Yz44R9J5mi46IfUA:7 a=bZNrbIqJ2VRVMyLlq9EimzWUyP4A:4 a=3FZX-ydVlcEA:10 a=si9q_4b84H0A:10 a=KdsN9ty_cgEA:10 a=lZB815dzVvQA:10 a=BFDKbZatV3MA:10 a=5g1bGOLZ_csA:10 a=gx5bkW9XiUAA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=tYi0lypvgwVtU9Op5TUA:9 a=MSquOTJlcieFcBBG1tQA:7 a=skpjgesf9OcaDJ65XtkAPLNGUP0A:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Sun, Dong \(Dong\)'" , , References: <016101c9460f$04d12940$7427460a@china.huawei.com> <000001c946b8$62213500$26639f00$@net> <09C9068466B79E4C938DC7737562404D02140041@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D02140041@ILEXC2U01.ndc.lucent.com> Date: Fri, 14 Nov 2008 21:00:27 -0600 Message-ID: <001f01c946ce$66e12c10$34a38430$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclGDw6WqWi0yxGoRdSXbLJW9idotAAqM+LAAAUOVgAAAGxSQA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: multipart/mixed; boundary="===============1556826391==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1556826391== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C9469C.1C46BC10" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0020_01C9469C.1C46BC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] writes: Glen, Yes. The ITU-T Rec has been updated based on Hannes' comments e.g. the ABNF issue, and a response was sent to the exploder a while ago. I don't see any further comments/objection. certainly, some of those comments (e.g. CCR/CCA), as indicated by Hannes, are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts some of Gx spec. For the interoperability issue, they have to be resolved by 3GPP. Moreover, they are irrelevant to this ID for the request of new command code PIR/PIA (There is no question about the use of PIR/PIA). Hope this help clarify your question. It does; however, it appears that the next IESG telechat is not until 4 December & this document is not on that agenda. Perhaps it could be added? Thanks, Dong _____ From: Glen Zorn [mailto:glenzorn@comcast.net] Sent: Friday, November 14, 2008 7:23 PM To: 'Tina TSOU' Cc: chris.newman@sun.com; iesg@ietf.org; dime@ietf.org; Sun, Dong (Dong) Subject: RE: [Dime] DISCUSS: draft-sun-dime-itu-t-rw ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw Diameter. It doesn't look to me as if Hannes' excellent AAA Doctors review has been responded to, however, at least in the draft. Has the ITU-T specification been modified appropriately? B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: dime@ietf.org Cc: chris.newman@sun.com ; iesg@ietf.org Sent: Wednesday, November 12, 2008 1:39 AM Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw Following up the discussion, in order to answer the question "Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal " The following texts are proposed (based on the online/offline discussion with Dan/Hannes and DIME group): "" This application is used to authorize the network QoS resources (including amount of bandwidth, QoS class and traffic flow processing) based on the Diameter application [RFC4006]. The request is based on the Diameter extensibility discussions in the DIME WG that led to the conclusion that it is better to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP in order to avoid interoperability problems. The document is utilizing authorization and accounting functionality and the entire exchange is related to users utilizing applications that require QoS treatment. This approach is consistent with the practice and experience gained since the publication of [RFC3588] (see for example [RFC5224]) which is now under revision by the DIME Working Group and will provide a revised set of recommendations and procedures for IANA considerations [draft-ietf-dime-rfc3588bis]." Please let me know if you have any objection or comments. I will submit a revised version of this I-D for the review. Regards, Dong -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, August 29, 2008 3:48 AM To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com Cc: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw Hi Dan, let me quickly respond to this issue: > As expected the document was not approved by the IESG and is now in AD > Follow-up. > > Beyond the two DISCUSSes there were two ABSTAIN ballots. > > The principal concern that I heard was related to the fact that the > current process followed by the draft did not ensure a sufficient > level of review from the IETF to ensure that it really meets the IETF > consensus. > > In order to overcome this I suggest that we do the following: > > 1. Ask for at least one more review (two is better) from the > AAA-Doctors team or DIME WG making also sure that the reviewers also > include reading the relevant parts in the ITU-T document in their > review (Hannes, can you ask Bernard to be one of the reviewers?) I sent a mail to him. > > 2. Explain to the IESG why the DIME Working Group did not take this > work as a WG chartered item (hannes, please write a short explanation, > also include the discussions around 3588bis) draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects. Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments. For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either. The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems. The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following: * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues). * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view. * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior. As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC. > 3. Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will > draft such a text I will think about text. Maybe it is lack of imagination on how protocols could be used? Wouldn't be the first time that a protocol is used in a way not originally envisioned. Example: RSVP - RSVP-TE Funny enough, the idea about using Diameter for the purpose of NAT and firewall signaling actually came from the IETF MIDCOM working group, see http://www.ietf.org/rfc/rfc4097.txt Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... > > Also in parallel the DIME WG should do the best to accelerate the > approval and submission of RFC3588 to the IESG so that we will need to > deal with as few such cases in the future as possible (ideally zero). That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already). Ciao Hannes > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf > > Of Chris Newman > > Sent: Thursday, August 28, 2008 7:29 PM > > To: iesg@ietf.org > > Cc: Hannes.Tschofenig@gmx.net; > > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com > > Subject: DISCUSS: draft-sun-dime-itu-t-rw > > > > Discuss: > > As this issue was raised during IETF review and appears to concern a > > number of area directors, I'm holding an actionable discuss > > position: > > > > Based on GEN-ART review responses, it appears this statement in the > > DIAMETER base spec: > > > > "Diameter is not intended as a general purpose protocol, and > > allocations SHOULD NOT be made for purposes unrelated to > > authentication, authorization or accounting." > > > > is spurious and not being followed. If we're not going to follow > > this rule (which is fine if there's rough consensus not to follow > > it), I believe it's important that it be documented why we're not > > following the rule (a "SHOULD NOT" > > requires justification). Various approaches I find acceptable are: > > 1. The document approval text includes reasoning for ignoring > > SHOULD NOT 2. An update to the document text includes reasoning for > > ignoring > > SHOULD NOT > > 3. Hold this until a small RFC is published that updates 3588 to > > change or remove the SHOULD NOT restriction. > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------=_NextPart_000_0020_01C9469C.1C46BC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sun, Dong (Dong) [mailto:dongsun@alcat= el-lucent.com] writes:

 

Glen,

 

Yes. The ITU-T Rec has been updated based on Hannes' = comments e.g. the ABNF issue, and a response was sent to the exploder a = while ago. I don't see any further comments/objection.

 

certainly, some of those comments (e.g. CCR/CCA), as = indicated by Hannes, are related to 3GPP Gx 29.212 spec since the = ITU-T Rw adopts some of Gx spec. For the interoperability issue, they have to be = resolved by 3GPP. Moreover, they are irrelevant to this ID for = the request of new command code PIR/PIA (There is no question about the use of = PIR/PIA).

 

Hope this help clarify your question.

 

It does; however, it appears that the next IESG telechat = is not until 4 December & this document is not on that agenda.  = Perhaps it could be added?

 

Thanks,

Dong

 

From: Glen Zorn = [mailto:glenzorn@comcast.net]
Sent: Friday, November 14, 2008 7:23 PM
To: 'Tina TSOU'
Cc: chris.newman@sun.com; iesg@ietf.org; dime@ietf.org; Sun, Dong = (Dong)
Subject: RE: [Dime] DISCUSS: = draft-sun-dime-itu-t-rw

ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation = Q.3303.3 Rw Diameter.

It doesn't look to me as if Hannes' excellent AAA Doctors = review has been responded to, however, at least in the draft.  Has the = ITU-T specification been modified appropriately?

 

B. R.
Tina

----- Original Message -----

Sent:<= /b> Wednesday, = November 12, 2008 1:39 AM

Subject: Re: [Dime] = DISCUSS: draft-sun-dime-itu-t-rw

 


Following up the discussion, in order to answer the question
"Propose text for an update to the document including reasoning for =
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal "

The following texts are proposed (based on the online/offline = discussion
with Dan/Hannes and DIME group):
"" This application is used to authorize the network QoS = resources
(including amount of bandwidth, QoS class and traffic flow = processing)
based on the Diameter application [RFC4006]. The request is based on = the
Diameter extensibility discussions in the DIME WG that  led to = the
conclusion that it is better to define new Command Codes whenever = the
ABNF of a command is modified by adding, removing or semantically
changing required AVP in order to avoid interoperability problems.  = The
document is utilizing authorization and accounting functionality and = the
entire exchange is related to users utilizing applications that = require
QoS treatment. This approach is consistent with the practice and
experience gained since the publication of [RFC3588] (see for = example
[RFC5224]) which is now under revision by the DIME Working Group and
will provide a revised set of recommendations and procedures for = IANA
considerations [draft-ietf-dime-rfc3588bis]."

Please let me know if you have any objection or comments.

I will submit a revised version of this I-D for the review.

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Friday, August 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com
Cc: Sun, Dong (Dong); draft-sun-dime-itu= -t-rw@tools.ietf.org
Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan,

let me quickly respond to this issue:

> As expected the document was not approved by the IESG and is now in = AD

> Follow-up.
>
> Beyond the two DISCUSSes there were two ABSTAIN ballots.
>
> The principal concern that I heard was related to the fact that the =
> current process followed by the draft did not ensure a sufficient =
> level of review from the IETF to ensure that it really meets the = IETF
> consensus.
>
> In order to overcome this I suggest that we do the following:
>
> 1. Ask for at least one more review (two is better) from the
> AAA-Doctors team or DIME WG making also sure that the reviewers = also
> include reading the relevant parts in the ITU-T document in their =
> review (Hannes, can you ask Bernard to be one of the = reviewers?)

I sent a mail to him.


>
> 2. Explain to the IESG why the DIME Working Group did not take this =
> work as a WG chartered item (hannes, please write a short = explanation,

> also include the discussions around 3588bis)

draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using
Diameter. In the DIME working group we also have a document that = deals
with QoS signaling, namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-= 06.txt.
It does, however, not cover NAT and Firewall signaling aspects.

Other SDOs are, however, not required to use the work we do in the = IETF
on certain Diameter applications. Additionally, they may enhance or
modify it. There are many reasons why this happens and I will not go
into the details of those. Call it a matter of life that has todo = with
psychology rather than technical arguments.

For us in DIME it does not really matter why ITU-T works on this
specific subject and it does not matter to us from a review point of
view either.

The reason why the ITU-T (and previously OMA with
http://tools.ietf.org/html/rf= c5224) came to the DIME working group is
actually related to a suggestion from our side (based on the = Diameter
extensibility discussions we had) to define new Command Codes = whenever
the ABNF of a command is modified by adding, removing or = semantically
changing required AVP (i.e, those marked as {}). By defining new = Command
Codes we believe to better avoid interoperability problems.

The OMA has followed that suggestion (and so did ITU-T, to some = extend)
but obviously ran into an issue with the requirements for the = allocation
of Command Codes (compared to the allocation of Application IDs) = based
on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) = to
register applications without going through the IETF process but has
different rules for the allocation of Command Codes. The DIME = working
group had a long discussion about this issue and decided to change = the
rules for allocating Command Codes with the revision of RFC 3588 = (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.t= xt)
and to align the procedure with the way how Application IDs are
requested. The main reasons for this decision were the following:

* We did not want to encourage SDOs to misuse Diameter Command Codes
when they don't want to come to the IETF (and thereby causing
interoperability issues).

* We did not want to drag all the SDOs to the IETF when it comes to
extending Diameter. Diameter is a very popular protocols among other
SDOs and this approach would not scale very well nor are we the = experts
in all the applications areas people have in mind where Diameter = could
be used.

* Some of us believe that the decision to have different rules for
Application ID allocation and Command Code assignment was a mistake
since it does not make a lot of sense from a logical point of view.

* We should not treat the 3GPP differently to other SDOs since the = 3GPP
was given a bunch of Command Codes without a corresponding = specification
(see ftp://ftp.rfc-edit= or.org/in-notes/rfc3589.txt). We try to be
consistent in our behavior.

As such, we came up with the idea to have an "interim" = solution for
dealing with requests regarding Diameter Command Codes before RFC
3588bis gets published as an RFC.


> 3. Propose text for an update to the document including reasoning = for
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will =
> draft such a text

I will think about text. Maybe it is lack of imagination on how
protocols could be used? Wouldn't be the first time that a protocol = is
used in a way not originally envisioned. Example: RSVP - RSVP-TE

Funny enough, the idea about using Diameter for the purpose of NAT = and
firewall signaling actually came from the IETF MIDCOM working group, = see
http://www.ietf.org/rfc/rfc4= 097.txt
Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their = favorite
protocol and it turns out that this was the wrong decision. Hard to
predict preferences...


>
> Also in parallel the DIME WG should do the best to accelerate the =
> approval and submission of RFC3588 to the IESG so that we will need = to

> deal with as few such cases in the future as possible (ideally = zero).

That's certainly a good idea. We are having a final round of reviews = and
I have asked the authors of the draft to also re-read the document = to
avoid problems in later stages (as they have happened with other
Diameter documents already).

Ciao
Hannes

>
> Thanks and Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf

> > Of Chris Newman
> > Sent: Thursday, August 28, 2008 7:29 PM
> > To: iesg@ietf.org
> > Cc: Hannes.Tschofenig@gmx.net;<= br> > > draft-sun-dime-itu= -t-rw@tools.ietf.org; dongsun@alcatel-lucent.com=
> > Subject: DISCUSS: draft-sun-dime-itu-t-rw
> >
> > Discuss:
> > As this issue was raised during IETF review and appears to = concern a

> > number of area directors, I'm holding an actionable discuss =
> > position:
> >
> > Based on GEN-ART review responses, it appears this statement = in the
> > DIAMETER base spec:
> >
> >   "Diameter is not intended as a general = purpose protocol, and
> >    allocations SHOULD NOT be made for purposes unrelated to
> >    authentication, authorization or = accounting."
> >
> > is spurious and not being followed.  If we're not going = to follow
> > this rule (which is fine if there's rough consensus not to = follow
> > it), I believe it's important that it be documented why we're = not
> > following the rule (a "SHOULD NOT"
> > requires justification).  Various approaches I find = acceptable are:
> >  1. The document approval text includes reasoning for = ignoring
> > SHOULD NOT  2. An update to the document text includes = reasoning for

> > ignoring
> >     SHOULD NOT
> >  3. Hold this until a small RFC is published that updates = 3588 to
> >     change or remove the SHOULD NOT = restriction.
> >
> >
> >
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/= mailman/listinfo/dime

------=_NextPart_000_0020_01C9469C.1C46BC10-- --===============1556826391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1556826391==-- From dime-bounces@ietf.org Fri Nov 14 19:06:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B423A6A96; Fri, 14 Nov 2008 19:06:39 -0800 (PST) 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 D017F3A6A96; Fri, 14 Nov 2008 19:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, 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 NxdfRdCh3ixz; Fri, 14 Nov 2008 19:06:37 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D2B833A6A7F; Fri, 14 Nov 2008 19:06:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,608,1220241600"; d="scan'208,217";a="151191074" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 14 Nov 2008 22:06:36 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Nov 2008 22:06:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 Nov 2008 04:06:33 +0100 Message-ID: In-Reply-To: <001f01c946ce$66e12c10$34a38430$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DISCUSS: draft-sun-dime-itu-t-rw Thread-Index: AclGDw6WqWi0yxGoRdSXbLJW9idotAAqM+LAAAUOVgAAAGxSQAAAOAGg References: <016101c9460f$04d12940$7427460a@china.huawei.com><000001c946b8$62213500$26639f00$@net><09C9068466B79E4C938DC7737562404D02140041@ILEXC2U01.ndc.lucent.com> <001f01c946ce$66e12c10$34a38430$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Sun, Dong (Dong)" , , Cc: dime@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: multipart/mixed; boundary="===============0801428365==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0801428365== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C946CF.2B13E871" This is a multi-part message in MIME format. ------_=_NextPart_001_01C946CF.2B13E871 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It can be added as a returning item, or we can even try to clear the existing DISCUSSes before - as it was already once on the IESG agenda. Yet, the first thing that needs to happen is to have the revised ID published as soon the submission blackout period ends the coming Monday. =20 Dan =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Saturday, November 15, 2008 5:00 AM To: 'Sun, Dong (Dong)'; iesg@ietf.org; chris.newman@sun.com Cc: dime@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw =09 =09 Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] writes: =20 Glen, =20 Yes. The ITU-T Rec has been updated based on Hannes' comments e.g. the ABNF issue, and a response was sent to the exploder a while ago. I don't see any further comments/objection. =20 certainly, some of those comments (e.g. CCR/CCA), as indicated by Hannes, are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts some of Gx spec. For the interoperability issue, they have to be resolved by 3GPP. Moreover, they are irrelevant to this ID for the request of new command code PIR/PIA (There is no question about the use of PIR/PIA).=20 =20 Hope this help clarify your question. =20 It does; however, it appears that the next IESG telechat is not until 4 December & this document is not on that agenda. Perhaps it could be added? =20 Thanks, Dong =20 ------_=_NextPart_001_01C946CF.2B13E871 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
It can be added as a returning item, or we can = even try=20 to clear the existing DISCUSSes before - as it was already once on the = IESG=20 agenda. Yet, the first thing that needs to happen is to have the revised = ID=20 published as soon the submission blackout period ends the coming = Monday.=20
 
Dan
 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Glen = Zorn
Sent:=20 Saturday, November 15, 2008 5:00 AM
To: 'Sun, Dong (Dong)';=20 iesg@ietf.org; chris.newman@sun.com
Cc:=20 dime@ietf.org
Subject: Re: [Dime] DISCUSS:=20 draft-sun-dime-itu-t-rw

Sun, = Dong (Dong)=20 [mailto:dongsun@alcat= el-lucent.com]=20 writes:

 

Glen,

 

Yes.=20 The ITU-T Rec has been updated based on Hannes' comments e.g. the = ABNF=20 issue, and a response was sent to the exploder a while ago. I don't = see any=20 further comments/objection.

 

certainly,=20 some of those comments (e.g. CCR/CCA), as indicated by=20 Hannes, are related to 3GPP Gx 29.212 spec since the = ITU-T Rw=20 adopts some of Gx spec. For the interoperability issue, they have to = be=20 resolved by 3GPP. Moreover, they are irrelevant to this ID for=20 the request of new command code PIR/PIA (There is no = question about=20 the use of PIR/PIA).

 

Hope=20 this help clarify your question.

 

It=20 does; however, it appears that the next IESG telechat is not until 4 = December=20 & this document is not on that agenda.  Perhaps it could be=20 added?

 

Thanks,

Dong

 

------_=_NextPart_001_01C946CF.2B13E871-- --===============0801428365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0801428365==-- From dime-bounces@ietf.org Fri Nov 14 19:13:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7AA3A6A7F; Fri, 14 Nov 2008 19:13:45 -0800 (PST) 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 8B0353A6A7F; Fri, 14 Nov 2008 19:13:45 -0800 (PST) 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=[AWL=-0.000, 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 jdTCUHAWH47p; Fri, 14 Nov 2008 19:13:44 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 8815A3A6A96; Fri, 14 Nov 2008 19:13:43 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAF3DgfH015276; Fri, 14 Nov 2008 21:13:42 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 21:13:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Nov 2008 21:13:39 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02140043@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DISCUSS: draft-sun-dime-itu-t-rw Thread-Index: AclGDw6WqWi0yxGoRdSXbLJW9idotAAqM+LAAAUOVgAAAGxSQAAAOAGgAAAqUNA= References: <016101c9460f$04d12940$7427460a@china.huawei.com><000001c946b8$62213500$26639f00$@net><09C9068466B79E4C938DC7737562404D02140041@ILEXC2U01.ndc.lucent.com> <001f01c946ce$66e12c10$34a38430$@net> From: "Sun, Dong \(Dong\)" To: "Romascanu, Dan \(Dan\)" , "Glen Zorn" , , X-OriginalArrivalTime: 15 Nov 2008 03:13:41.0864 (UTC) FILETIME=[2968B680:01C946D0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: dime@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw 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: , Content-Type: multipart/mixed; boundary="===============1849454534==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1849454534== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C946D0.29283166" This is a multi-part message in MIME format. ------_=_NextPart_001_01C946D0.29283166 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, =20 I have submitted a revised I-D draft-sun-dime-itu-t-rw-02 to the Internet-Drafts team. They promised to have it posted next Monday (11/17). =20 Regards, Dong ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, November 14, 2008 10:07 PM To: Glen Zorn; Sun, Dong (Dong); iesg@ietf.org; chris.newman@sun.com Cc: dime@ietf.org Subject: RE: [Dime] DISCUSS: draft-sun-dime-itu-t-rw It can be added as a returning item, or we can even try to clear the existing DISCUSSes before - as it was already once on the IESG agenda. Yet, the first thing that needs to happen is to have the revised ID published as soon the submission blackout period ends the coming Monday. =20 Dan =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Saturday, November 15, 2008 5:00 AM To: 'Sun, Dong (Dong)'; iesg@ietf.org; chris.newman@sun.com Cc: dime@ietf.org Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw =09 =09 Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] writes: =20 Glen, =20 Yes. The ITU-T Rec has been updated based on Hannes' comments e.g. the ABNF issue, and a response was sent to the exploder a while ago. I don't see any further comments/objection. =20 certainly, some of those comments (e.g. CCR/CCA), as indicated by Hannes, are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts some of Gx spec. For the interoperability issue, they have to be resolved by 3GPP. Moreover, they are irrelevant to this ID for the request of new command code PIR/PIA (There is no question about the use of PIR/PIA).=20 =20 Hope this help clarify your question. =20 It does; however, it appears that the next IESG telechat is not until 4 December & this document is not on that agenda. Perhaps it could be added? =20 Thanks, Dong =20 ------_=_NextPart_001_01C946D0.29283166 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dan,
 
I have submitted a revised I-D draft-sun-dime-itu-t-rw-02 to the = Internet-Drafts=20 team. They promised to have it posted next Monday = (11/17).
 
Regards,
Dong

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, November 14, 2008 = 10:07=20 PM
To: Glen Zorn; Sun, Dong (Dong); iesg@ietf.org;=20 chris.newman@sun.com
Cc: dime@ietf.org
Subject: RE: = [Dime]=20 DISCUSS: draft-sun-dime-itu-t-rw

It can be added as a returning item, or we can = even try=20 to clear the existing DISCUSSes before - as it was already once on the = IESG=20 agenda. Yet, the first thing that needs to happen is to have the revised = ID=20 published as soon the submission blackout period ends the coming = Monday.=20
 
Dan
 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Glen = Zorn
Sent:=20 Saturday, November 15, 2008 5:00 AM
To: 'Sun, Dong (Dong)';=20 iesg@ietf.org; chris.newman@sun.com
Cc:=20 dime@ietf.org
Subject: Re: [Dime] DISCUSS:=20 draft-sun-dime-itu-t-rw

Sun, = Dong (Dong)=20 [mailto:dongsun@alcat= el-lucent.com]=20 writes:

 

Glen,

 

Yes.=20 The ITU-T Rec has been updated based on Hannes' comments e.g. the = ABNF=20 issue, and a response was sent to the exploder a while ago. I don't = see any=20 further comments/objection.

 

certainly,=20 some of those comments (e.g. CCR/CCA), as indicated by=20 Hannes, are related to 3GPP Gx 29.212 spec since the = ITU-T Rw=20 adopts some of Gx spec. For the interoperability issue, they have to = be=20 resolved by 3GPP. Moreover, they are irrelevant to this ID for=20 the request of new command code PIR/PIA (There is no = question about=20 the use of PIR/PIA).

 

Hope=20 this help clarify your question.

 

It=20 does; however, it appears that the next IESG telechat is not until 4 = December=20 & this document is not on that agenda.  Perhaps it could be=20 added?

 

Thanks,

Dong

 

------_=_NextPart_001_01C946D0.29283166-- --===============1849454534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1849454534==-- From dime-bounces@ietf.org Mon Nov 17 14:44:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB7828C172; Mon, 17 Nov 2008 14:44:20 -0800 (PST) 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 21C3C28C172 for ; Mon, 17 Nov 2008 14:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.125 X-Spam-Level: X-Spam-Status: No, score=-5.125 tagged_above=-999 required=5 tests=[AWL=1.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FxFMwlluQbnr for ; Mon, 17 Nov 2008 14:44:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2479A28C164 for ; Mon, 17 Nov 2008 14:44:18 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAHMcNm0017649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Nov 2008 23:38:23 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAHMcKMc024648 for ; Mon, 17 Nov 2008 23:38:23 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 23:37:17 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 23:37:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 00:37:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides, Please! Thread-Index: AclIwfvbXQ1m0yhvRjGUiqC401UfsA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Nov 2008 22:37:17.0094 (UTC) FILETIME=[0B5AE460:01C94905] Subject: [Dime] Slides, Please! 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: , Content-Type: multipart/mixed; boundary="===============0081702908==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0081702908== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94905.0AE80685" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94905.0AE80685 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Please make sure that you send your slides to Victor so that he can upload them.=20 Ciao Hannes ------_=_NextPart_001_01C94905.0AE80685 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Slides, Please!

Please make sure that you send your = slides to Victor so that he can upload them.

Ciao
Hannes

------_=_NextPart_001_01C94905.0AE80685-- --===============0081702908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0081702908==-- From dime-bounces@ietf.org Tue Nov 18 11:34:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4B23A6B08; Tue, 18 Nov 2008 11:34:47 -0800 (PST) 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 3FE6F3A6B08 for ; Tue, 18 Nov 2008 11:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.741 X-Spam-Level: X-Spam-Status: No, score=0.741 tagged_above=-999 required=5 tests=[AWL=1.480, BAYES_20=-0.74, 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 hoacHY-WJeWA for ; Tue, 18 Nov 2008 11:34:43 -0800 (PST) Received: from smtp1.exfo.com (smtp1.exfo.com [206.162.164.97]) by core3.amsl.com (Postfix) with ESMTP id 2175A3A6809 for ; Tue, 18 Nov 2008 11:34:42 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtp1.exfo.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 14:34:41 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 14:34:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 14:34:40 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA0155A4@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3GPP and RFC4740 Thread-Index: AclJtLNfOaWWjVnhQd2jCXfPPZvDlA== From: "Bruce Kling" To: X-OriginalArrivalTime: 18 Nov 2008 19:34:40.0495 (UTC) FILETIME=[B3204FF0:01C949B4] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.500.1027-16286.005 X-TM-AS-Result: No--2.179400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [Dime] 3GPP and RFC4740 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: , Content-Type: multipart/mixed; boundary="===============0058027839==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0058027839== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C949B4.B2F3F532" This is a multi-part message in MIME format. ------_=_NextPart_001_01C949B4.B2F3F532 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 RFC4740 defines new Diameter SIP application commands with a code range from 283 to 288. The ETSI TS 129.229 specification defines the same set of commands with a code range of 300 to 305. I have seen a sniffer trace of protocol exchanges using these messages and they are in the 300 to 305 range. RFC4740 is on the standards track - is it possible for the two specifications to define the same set of commands yet assign different command codes to them such that the code is interpreted differently based on the application-id? =20 Thank you for your time. =20 Bruce Kling Exfo Service Assurance TEL: 978/367-5617 =20 ------_=_NextPart_001_01C949B4.B2F3F532 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

RFC4740 defines new Diameter SIP application commands = with a code range from 283 to 288.  The ETSI TS 129.229 specification = defines the same set of commands with a code range of 300 to 305.  I have seen = a sniffer trace of protocol exchanges using these messages and they are in = the 300 to 305 range.  RFC4740 is on the standards track – is it possible for the two specifications to define the same set of commands = yet assign different command codes to them such that the code is interpreted differently based on the application-id?

 

Thank you for your time.

 

Bruce Kling

Exfo Service Assurance

TEL: 978/367-5617

 

------_=_NextPart_001_01C949B4.B2F3F532-- --===============0058027839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0058027839==-- From dime-bounces@ietf.org Wed Nov 19 08:17:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7853A6B1F; Wed, 19 Nov 2008 08:17:19 -0800 (PST) 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 D5F8B3A6B9F for ; Wed, 19 Nov 2008 08:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 FY192BysKACk for ; Wed, 19 Nov 2008 08:17:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D52BE3A6B1F for ; Wed, 19 Nov 2008 08:17:16 -0800 (PST) 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 mAJGDmea010245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Nov 2008 17:17:14 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAJFcXwm027394 for ; Wed, 19 Nov 2008 16:38:39 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 16:38:27 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 16:38:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 17:20:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remote Participation at the DIME Meeting Thread-Index: AclKF1ggzMd7nt63TuahECumtdEvMQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 19 Nov 2008 15:38:14.0615 (UTC) FILETIME=[D6188E70:01C94A5C] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081119171714-12513BB0-9AC6BAF0/0-0/0-0 X-purgate-size: 884/826 Subject: [Dime] Remote Participation at the DIME Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Based on the fact that some folks are not in Minneapolis to participate at the IETF#73 DIME meeting I would like to point to our remote participation facilities. * DIME Agenda: http://www3.ietf.org/proceedings/08nov/agenda/dime.txt Slides: https://datatracker.ietf.org/meeting/73/materials.html * Audio Streaming Information can be found here: http://www.ietf.org/mail-archive/web/ietf/current/msg53997.html * Jabber Room Room: dime@jabber.ietf.org An example on how to get started with Jabber can be found here: http://www.emergency-services-coordination.info/2008Oct/chat-room.html * Conference Bridge We are also going to setup a conference bridge and maybe using Webex (see Jabber room before the meeting for more info). Here is the bridge info: Number: +1 (712) 432-1100 PIN: 292812# Please join the meeting. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 19 08:53:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BFE28C151; Wed, 19 Nov 2008 08:53:12 -0800 (PST) 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 E25AA28C151 for ; Wed, 19 Nov 2008 08:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=3.300, 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 Ee-1kLtgzxq2 for ; Wed, 19 Nov 2008 08:53:10 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DD3EF28C130 for ; Wed, 19 Nov 2008 08:53:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAJGr6Ao021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Nov 2008 17:53:06 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAJGr5dY014791 for ; Wed, 19 Nov 2008 17:53:06 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 17:53:01 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 17:52:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 18:43:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Changes Thread-Index: AclKIqqNf3X9Y2cGRRCDtlRU8eFiNQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 19 Nov 2008 16:52:53.0550 (UTC) FILETIME=[43BFCCE0:01C94A67] Subject: [Dime] Agenda Changes 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, We had a couple of agenda changes for various reasons. Here is the latest http://www.ietf.org/proceedings/08nov/agenda/dime.txt In short, the changes are: * Victor will give the presentation for the Diameter API * I added Bernard Aboba for a presentation about problems with the extended RADIUS attributes and potential impact for Diameter. * Charlie is going to give the presentation about draft-ietf-dime-mip6-integrated-10.txt * I am going to cover draft-ietf-dime-mip6-split-13.txt. * I am going to cover draft-ietf-dime-qos-parameters-07.txt. * Mayutan Arumaithurai will discuss draft-ietf-dime-qos-attributes-08.txt. * Glen will deal with draft-tsou-dime-routing-problem-statement-00.txt * Lionel Morand will present draft-jones-3gpp-eps-command-codes-00.txt I hope you guys are all happy with the new arrangement. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 19 10:06:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5737228C15A; Wed, 19 Nov 2008 10:06:47 -0800 (PST) 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 7814D28C15A for ; Wed, 19 Nov 2008 10:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 zrBgogxLzz4p for ; Wed, 19 Nov 2008 10:06:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3640E28C151 for ; Wed, 19 Nov 2008 10:06:44 -0800 (PST) Received: (qmail invoked by alias); 19 Nov 2008 18:06:41 -0000 Received: from unknown (EHLO 4FIL42860) [130.129.31.217] by mail.gmx.net (mp044) with SMTP; 19 Nov 2008 19:06:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18PRK1nBLoPZGDVV9hDVLNAhFWUo1VM511XHw06D/ 44BTxE9zcC3oqy From: "Hannes Tschofenig" To: References: Date: Wed, 19 Nov 2008 12:06:36 +0200 Message-ID: <009d01c94a2e$86a76c40$d91f8182@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclKIqqNf3X9Y2cGRRCDtlRU8eFiNQAC1hCA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Dime] Agenda Changes 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Another last minute agenda change. Alan is going to speak about internationalization. * Internationalization Problems in RADIUS and Diameter (10 min) See also http://www3.ietf.org/proceedings/08nov/slides/radext-0.ppt (Alan DeKok) Action: Alan wants to make us aware of internationalization issues that recently came up and might have impact on Diameter as well. Ciao Hannes >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 19 November, 2008 10:42 >To: dime@ietf.org >Subject: Agenda Changes > >Hi all, > >We had a couple of agenda changes for various reasons. Here is >the latest http://www.ietf.org/proceedings/08nov/agenda/dime.txt > >In short, the changes are: > >* Victor will give the presentation for the Diameter API >* I added Bernard Aboba for a presentation about problems with >the extended RADIUS attributes and potential impact for Diameter. >* Charlie is going to give the presentation about >draft-ietf-dime-mip6-integrated-10.txt >* I am going to cover draft-ietf-dime-mip6-split-13.txt. >* I am going to cover draft-ietf-dime-qos-parameters-07.txt. >* Mayutan Arumaithurai will discuss >draft-ietf-dime-qos-attributes-08.txt. >* Glen will deal with draft-tsou-dime-routing-problem-statement-00.txt >* Lionel Morand will present draft-jones-3gpp-eps-command-codes-00.txt > >I hope you guys are all happy with the new arrangement. > >Ciao >Hannes > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 19 11:26:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F02D3A6904; Wed, 19 Nov 2008 11:26:43 -0800 (PST) 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 3ECF83A6904 for ; Wed, 19 Nov 2008 11:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 bf4N+a51M1Ul for ; Wed, 19 Nov 2008 11:26:41 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 7551A3A68A8 for ; Wed, 19 Nov 2008 11:26:41 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAJJQhsu076102 for ; Wed, 19 Nov 2008 14:26:43 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492453F6.6080906@tari.toshiba.com> Date: Wed, 19 Nov 2008 11:59:18 -0600 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: dime@ietf.org References: <20081102173001.E72473A67D0@core3.amsl.com> In-Reply-To: <20081102173001.E72473A67D0@core3.amsl.com> Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-13.txt - Change summary 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The following is the summary of major changes for bis-13 * MUST and SHOULD terminology on certain text has changed to make it coherent. The following have been affected: - The value of Supported-Vendor-Id MUST NOT be zero instead of SHOULD - Multiple instance of Supported-Vendor-Id MUST contain the same value instead of SHOULD - Section 6.1.2, Recommendations for sending request SHOULD be followed instead of MUST - Vendor-Specific-Application-Id containing both Auth-Application-Id and Acct-Application-Id AVP MUST return an error instead of SHOULD - If Redirect-Host-Max-Cache-Time is present then Redirect-Host value SHOULD be cached instead of "will be cached" - The Auth-Lifetime value returned by the server MUST be equal to or less than what was sent by the client instead of SHOULD * Remove restriction that accounting is required for any/all application * Removal of the requirement for Application-Id AVPs to be present in non-CER/CEA messages - Cleaned up the text requiring that the value of these AVPs MUST be same as the one in the header * Cleanup of the ABNF rules to make sure "*{AVP}" is not allowed. - For "{AVP}", min is always 1 * Remove capabilities exchange in open state - Propose a separate draft for this functionality * Removal restriction of Host-IP-Address to be used only by CER and CEA messages * Editorials - Plenty of restructuring in accounting, protocol overview, routing and AVP(s) description section - Lots of changes to make certain sections cohesive regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 19 14:15:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FA83A6953; Wed, 19 Nov 2008 14:15:05 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9F5E83A6A8B; Wed, 19 Nov 2008 14:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081119221502.9F5E83A6A8B@core3.amsl.com> Date: Wed, 19 Nov 2008 14:15:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-11.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-11.txt Pages : 19 Date : 2008-11-19 A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-11.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-mip6-integrated-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-19140948.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Nov 19 16:56:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D944A3A6BD9; Wed, 19 Nov 2008 16:56:25 -0800 (PST) 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 155DA3A6BD9 for ; Wed, 19 Nov 2008 16:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 lJIHB780SZYs for ; Wed, 19 Nov 2008 16:56:23 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 377E83A6BC9 for ; Wed, 19 Nov 2008 16:56:23 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAK0uPKq080508; Wed, 19 Nov 2008 19:56:26 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4924B5B5.7080107@tari.toshiba.com> Date: Wed, 19 Nov 2008 18:56:21 -0600 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Stefan Winter References: <48FD7473.8050205@restena.lu> In-Reply-To: <48FD7473.8050205@restena.lu> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Stefan, Sorry for missing this query. Comments inline: > 3588 and -bis define a peer lookup mechanism that first looks for NAPTR > records for a realm, and if that fails use an underscore construct in > conjunction with A and AAAA records: > > "If no NAPTR records are found, the requester queries for those > > address records for the destination address, > '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address > records include A RR's, AAAA RR's or other similar records, > chosen according to the requester's network protocol > capabilities." > > When looking into the same issue for RadSec, I received some (IMHO justified) off-list opposition. It appears to be seen as a very bad practice by a lot of DNS people to use underscore constructs in A or AAAA records. > I agree. > The question had been raised why the lookup mechanism does not use SRV records as fallback after NAPTR - these were specifically designed for service discovery with underscores. The SRV RR RFC is also older than 3588, so the option to use it existed back then. > I think this sounds reasonable as well. > I wonder if there is a reason and/or actual deployed experience with this bit of the Diameter spec, and whether it is maybe about time to introduce SRV record lookups in 3588bis (and RadSec). > I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. SIP). Its probably good to do the same for diameter. regads, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 20 06:36:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216F63A6950; Thu, 20 Nov 2008 06:36:28 -0800 (PST) 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 AA8103A6950 for ; Thu, 20 Nov 2008 06:36:27 -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 3nJVbQpuzPrk for ; Thu, 20 Nov 2008 06:36:26 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id B76663A68A7 for ; Thu, 20 Nov 2008 06:36:26 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 20 Nov 2008 09:36:24 -0500 From: Mark Jones To: "dime@ietf.org" Date: Thu, 20 Nov 2008 09:36:23 -0500 Thread-Topic: [Dime] 3588bis-13: Redirect-Host usage contradiction Thread-Index: AclFpWMz9Vt176+1SWmcibrMUI4stQAay/MgAUG4AvA= Message-ID: References: <491C4917.8040708@tari.toshiba.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > I was thinking of alignment with the default value of > Auth-Session-State which is STATE_MAINTAINED. If maintaining > session state is required then the client must send the STR > to the Origin-Host in the answer message which would be the > Redirect-Host in the redirect message. > > What do others think? Given the contradiction in 3588, any > fix means code changes may be required in existing > implementations albeit minor ones. Anyone? Anyone? Bueller? This contradiction does need a fix. If you have a Diameter stack, please check the Redirect-Host caching behaviour when there is no Redirect-Host-Usage AVP and weigh in on this issue so we can get a fix into 3588bis. My preference is defaulting to ALL_SESSION for the reason given above. Thanks Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Mark Jones > Sent: November 14, 2008 00:27 > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction > > Hi Victor, > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: November 13, 2008 23:35 > > To: Mark Jones > > Cc: dime@ietf.org > > Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction > > > > Hi Mark, > > > > > I believe there is a contradiction in the description of > > Redirect-Host usage in 3588 and 3588bis-13. The last sentence > > in section 6.12 states that: > > > > > > The server contained in the selected Redirect-Host AVP > > SHOULD be used > > > for all messages pertaining to this session. > > > > > > However, section 6.13 states that the default usage > > behaviour is DONT_CACHE unless it is overridden by a > > Redirect-Host-Usage. > > > > > > > I agree. > > > > > I think the most useful redirect behaviour is caching the > > redirect host for the duration of the Diameter session so > > this should be the default if Redirect-Host-Usage is absent, > > i.e. section 6.13 in 3588bis should be updated to state that > > ALL_SESSION is the default value of Redirect-Host-Usage. > > > > > > > I have no strong opinion on this but to maybe ALL_SESSION as default > > just looks good on paper. For routing performance, always > tracking the > > state of a session is more work than necessary. If DONT_CACHE is a > > default, basic redirection is simple. Anyway, having DONT_CACHE as a > > default does not take away any functionality from ALL_SESSION. > > > > I was thinking of alignment with the default value of > Auth-Session-State which is STATE_MAINTAINED. If maintaining > session state is required then the client must send the STR > to the Origin-Host in the answer message which would be the > Redirect-Host in the redirect message. > > What do others think? Given the contradiction in 3588, any > fix means code changes may be required in existing > implementations albeit minor ones. > > Regards > Mark > > _______________________________________________ > 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 From dime-bounces@ietf.org Thu Nov 20 06:42:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87DC3A6950; Thu, 20 Nov 2008 06:42:20 -0800 (PST) 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 EF98B3A692F for ; Thu, 20 Nov 2008 06:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 7kaqgd8xHeo1 for ; Thu, 20 Nov 2008 06:42:19 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 143603A68A7 for ; Thu, 20 Nov 2008 06:42:18 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAKEgB63087208; Thu, 20 Nov 2008 09:42:11 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49257740.5090908@tari.toshiba.com> Date: Thu, 20 Nov 2008 08:42:08 -0600 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Mark Jones References: <491C4917.8040708@tari.toshiba.com> In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis-13: Redirect-Host usage contradiction 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, >> I was thinking of alignment with the default value of >> Auth-Session-State which is STATE_MAINTAINED. If maintaining >> session state is required then the client must send the STR >> to the Origin-Host in the answer message which would be the >> Redirect-Host in the redirect message. >> >> What do others think? Given the contradiction in 3588, any >> fix means code changes may be required in existing >> implementations albeit minor ones. >> > > Anyone? Anyone? Bueller? > > This contradiction does need a fix. If you have a Diameter stack, please check the Redirect-Host caching behaviour when there is no Redirect-Host-Usage AVP and weigh in on this issue so we can get a fix into 3588bis. My preference is defaulting to ALL_SESSION for the reason given above. > Just a quick question. Even if the Auth-Session-State is set to STATE_MAINTAINED and redirect is DONT_CACHE, is any functionality really broken ? STRs (or any other request for the session) will still be redirected. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 24 04:57:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247F83A68D5; Mon, 24 Nov 2008 04:57:49 -0800 (PST) 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 82AC33A68D5 for ; Mon, 24 Nov 2008 04:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 x3SPl2pFIb7B for ; Mon, 24 Nov 2008 04:57:47 -0800 (PST) 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 54DC93A6889 for ; Mon, 24 Nov 2008 04:57:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,659,1220241600"; d="scan'208";a="129207659" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Nov 2008 07:57:43 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Nov 2008 07:57:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 13:57:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised ID Needed for draft-ietf-dime-qos-parameters Thread-Index: AclONDv0M6kj4KBsTt+Y0lI/bBkajg== From: "Romascanu, Dan (Dan)" To: , "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: dime@ietf.org Subject: [Dime] Revised ID Needed for draft-ietf-dime-qos-parameters 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I put draft-ietf-dime-qos-parameters in Revised ID Needed. Please address the IETF LC comments and answer the issues raised during the Last Call (IANA, Scott Bradner, have there been other?). Thanks and Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 24 06:30:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07403A691C; Mon, 24 Nov 2008 06:30:02 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 955FC3A69D0; Mon, 24 Nov 2008 06:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081124143001.955FC3A69D0@core3.amsl.com> Date: Mon, 24 Nov 2008 06:30:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-08.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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 Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-08.txt Pages : 17 Date : 2008-11-24 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-08.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-app-design-guide-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-24062802.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Nov 24 06:36:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C192E3A69DA; Mon, 24 Nov 2008 06:36:50 -0800 (PST) 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 7F2033A69DA for ; Mon, 24 Nov 2008 06:36:49 -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 C5PDBMlX6TuC for ; Mon, 24 Nov 2008 06:36:48 -0800 (PST) Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by core3.amsl.com (Postfix) with ESMTP id 793FF3A691C for ; Mon, 24 Nov 2008 06:36:48 -0800 (PST) Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 24 Nov 2008 14:37:09 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Mon, 24 Nov 2008 14:36:54 +0000 From: Jonathan Cumming To: Victor Fajardo Date: Mon, 24 Nov 2008 14:34:10 +0000 Thread-Topic: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV Thread-Index: AclKqtPjkXCwB277Rya2AOcWjcGVDgDldrLQ Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF025C60C32FA6@ENFIMBOX1.ad.datcon.co.uk> References: <48FD7473.8050205@restena.lu> <4924B5B5.7080107@tari.toshiba.com> In-Reply-To: <4924B5B5.7080107@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, Regarding you point: "I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. SIP). Its probably good to do the same for diameter." I may be mistaken, but I do not believe that SIP defines the use of _sip for A or AAAA records. _sip... and _sips... are used to create the default SRV record queries when no NAPTR records are present, according to RFC 3263. Regards, Jonathan -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: 20 November 2008 00:56 To: Stefan Winter Cc: dime@ietf.org Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV Hi Stefan, Sorry for missing this query. Comments inline: > 3588 and -bis define a peer lookup mechanism that first looks for > NAPTR records for a realm, and if that fails use an underscore > construct in conjunction with A and AAAA records: > > "If no NAPTR records are found, the requester queries for those > > address records for the destination address, > '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address > records include A RR's, AAAA RR's or other similar records, > chosen according to the requester's network protocol > capabilities." > > When looking into the same issue for RadSec, I received some (IMHO justified) off-list opposition. It appears to be seen as a very bad practice by a lot of DNS people to use underscore constructs in A or AAAA records. > I agree. > The question had been raised why the lookup mechanism does not use SRV records as fallback after NAPTR - these were specifically designed for service discovery with underscores. The SRV RR RFC is also older than 3588, so the option to use it existed back then. > I think this sounds reasonable as well. > I wonder if there is a reason and/or actual deployed experience with this bit of the Diameter spec, and whether it is maybe about time to introduce SRV record lookups in 3588bis (and RadSec). > I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. SIP). Its probably good to do the same for diameter. regads, victor _______________________________________________ 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 From dime-bounces@ietf.org Mon Nov 24 07:15:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDF63A69D0; Mon, 24 Nov 2008 07:15:49 -0800 (PST) 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 3BBCA3A69D0 for ; Mon, 24 Nov 2008 07:15:48 -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 ZKk9gFRIYBJy for ; Mon, 24 Nov 2008 07:15:47 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 43E273A69C0 for ; Mon, 24 Nov 2008 07:15:47 -0800 (PST) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAOFFYST034469; Mon, 24 Nov 2008 10:15:34 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492AC51E.7000402@tari.toshiba.com> Date: Mon, 24 Nov 2008 10:15:42 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Jonathan Cumming References: <48FD7473.8050205@restena.lu> <4924B5B5.7080107@tari.toshiba.com> <44EE1E31095AE349AC6C3C0B69FFBF025C60C32FA6@ENFIMBOX1.ad.datcon.co.uk> In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF025C60C32FA6@ENFIMBOX1.ad.datcon.co.uk> Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jonathan, > Hi Victor, > > Regarding you point: > "I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. SIP). Its probably good to do the same for diameter." > > I may be mistaken, but I do not believe that SIP defines the use of _sip for A or AAAA records. _sip... and _sips... are used to create the default SRV record queries when no NAPTR records are present, according to RFC 3263. > Sorry if thread was not clear but I was actually pointing to the fact you mentioned; i.e. other protocols DO NOT commonly use underscores for address records. -- victor > Regards, > Jonathan > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: 20 November 2008 00:56 > To: Stefan Winter > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV > > Hi Stefan, > > Sorry for missing this query. Comments inline: > > >> 3588 and -bis define a peer lookup mechanism that first looks for >> NAPTR records for a realm, and if that fails use an underscore >> construct in conjunction with A and AAAA records: >> >> "If no NAPTR records are found, the requester queries for those >> >> address records for the destination address, >> '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address >> records include A RR's, AAAA RR's or other similar records, >> chosen according to the requester's network protocol >> capabilities." >> >> When looking into the same issue for RadSec, I received some (IMHO justified) off-list opposition. It appears to be seen as a very bad practice by a lot of DNS people to use underscore constructs in A or AAAA records. >> >> > > I agree. > > >> The question had been raised why the lookup mechanism does not use SRV records as fallback after NAPTR - these were specifically designed for service discovery with underscores. The SRV RR RFC is also older than 3588, so the option to use it existed back then. >> >> > > I think this sounds reasonable as well. > > >> I wonder if there is a reason and/or actual deployed experience with this bit of the Diameter spec, and whether it is maybe about time to introduce SRV record lookups in 3588bis (and RadSec). >> >> > > I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. > SIP). Its probably good to do the same for diameter. > > regads, > victor > > _______________________________________________ > 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 From dime-bounces@ietf.org Mon Nov 24 08:09:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320F43A6908; Mon, 24 Nov 2008 08:09:44 -0800 (PST) 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 946053A6908 for ; Mon, 24 Nov 2008 08:09:43 -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 w9PfoG6Y9kWn for ; Mon, 24 Nov 2008 08:09:42 -0800 (PST) Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by core3.amsl.com (Postfix) with ESMTP id 804503A68DB for ; Mon, 24 Nov 2008 08:09:42 -0800 (PST) Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 24 Nov 2008 16:10:03 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Mon, 24 Nov 2008 16:09:49 +0000 From: Jonathan Cumming To: Victor Fajardo Date: Mon, 24 Nov 2008 16:07:17 +0000 Thread-Topic: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV Thread-Index: AclOR4suAYC9f7duSiGE6AUiNxjhSgABxlZg Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF025C60C33088@ENFIMBOX1.ad.datcon.co.uk> References: <48FD7473.8050205@restena.lu> <4924B5B5.7080107@tari.toshiba.com> <44EE1E31095AE349AC6C3C0B69FFBF025C60C32FA6@ENFIMBOX1.ad.datcon.co.uk> <492AC51E.7000402@tari.toshiba.com> In-Reply-To: <492AC51E.7000402@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, Many thanks for the clarification - I am very pleased we agree. Jonathan -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: 24 November 2008 15:16 To: Jonathan Cumming Cc: dime@ietf.org; Stefan Winter Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV Hi Jonathan, > Hi Victor, > > Regarding you point: > "I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. SIP). Its probably good to do the same for diameter." > > I may be mistaken, but I do not believe that SIP defines the use of _sip for A or AAAA records. _sip... and _sips... are used to create the default SRV record queries when no NAPTR records are present, according to RFC 3263. > Sorry if thread was not clear but I was actually pointing to the fact you mentioned; i.e. other protocols DO NOT commonly use underscores for address records. -- victor > Regards, > Jonathan > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of Victor Fajardo > Sent: 20 November 2008 00:56 > To: Stefan Winter > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV > > Hi Stefan, > > Sorry for missing this query. Comments inline: > > >> 3588 and -bis define a peer lookup mechanism that first looks for >> NAPTR records for a realm, and if that fails use an underscore >> construct in conjunction with A and AAAA records: >> >> "If no NAPTR records are found, the requester queries for those >> >> address records for the destination address, >> '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address >> records include A RR's, AAAA RR's or other similar records, >> chosen according to the requester's network protocol >> capabilities." >> >> When looking into the same issue for RadSec, I received some (IMHO justified) off-list opposition. It appears to be seen as a very bad practice by a lot of DNS people to use underscore constructs in A or AAAA records. >> >> > > I agree. > > >> The question had been raised why the lookup mechanism does not use SRV records as fallback after NAPTR - these were specifically designed for service discovery with underscores. The SRV RR RFC is also older than 3588, so the option to use it existed back then. >> >> > > I think this sounds reasonable as well. > > >> I wonder if there is a reason and/or actual deployed experience with this bit of the Diameter spec, and whether it is maybe about time to introduce SRV record lookups in 3588bis (and RadSec). >> >> > > I'm not sure about deployment experience but the practice you mentioned seems a common and way for other protocols that perform discovery (i.e. > SIP). Its probably good to do the same for diameter. > > regads, > victor > > _______________________________________________ > 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 From dime-bounces@ietf.org Mon Nov 24 09:15:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B79B3A6A2A; Mon, 24 Nov 2008 09:15:02 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 76D4D3A6A2A; Mon, 24 Nov 2008 09:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081124171501.76D4D3A6A2A@core3.amsl.com> Date: Mon, 24 Nov 2008 09:15:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-14.txt Pages : 160 Date : 2008-11-24 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-14.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-rfc3588bis-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-24090304.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Nov 24 09:31:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626173A68F6; Mon, 24 Nov 2008 09:31:07 -0800 (PST) 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 0783B3A68BD for ; Mon, 24 Nov 2008 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 UEhxph7kZQ2Z for ; Mon, 24 Nov 2008 09:31:05 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id F2C183A6A3D for ; Mon, 24 Nov 2008 09:31:04 -0800 (PST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAOHUrcQ036057 for ; Mon, 24 Nov 2008 12:30:54 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492AE4D6.5010403@tari.toshiba.com> Date: Mon, 24 Nov 2008 12:31:02 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 CC: dime@ietf.org References: <20081124171501.76D4D3A6A2A@core3.amsl.com> In-Reply-To: <20081124171501.76D4D3A6A2A@core3.amsl.com> Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Changes in this revision includes proposed resolution to most of the open issues discussed last week in ietf-73: - Removal of the MAY column for the M-bit. Although this has been in bis since rev-12, consensus has been reached in ietf73 to make the changes permanent. - Cleanup of peer discovery mechanism. The new scheme now uses SRV lookups as a fallback from NAPTR. It also clarifies/cleanup text on the fallback scheme. - Downgraded SCTP support on servers from MUST to SHOULD. - Fixed Sec 6.12 and align default values of redirect usage and auth-session state As of this revision, there is only one open issue remaining for bis. This pertains to securing inband-security info of CER/CEA. The proposals for item will be treated in a separate thread and changes will be incorporated in the next rev of bis. regards, victor > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. > > > Title : Diameter Base Protocol > Author(s) : V. Fajardo, et al. > Filename : draft-ietf-dime-rfc3588bis-14.txt > Pages : 160 > Date : 2008-11-24 > > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications such as > network access or IP mobility. Diameter is also intended to work in > both local Authentication, Authorization & Accounting and roaming > situations. This document specifies the message format, transport, > error reporting, accounting and security services to be used by all > Diameter applications. The Diameter base application needs to be > supported by all Diameter implementations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-14.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. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From dime-bounces@ietf.org Mon Nov 24 12:09:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB1E3A6B6C; Mon, 24 Nov 2008 12:09:44 -0800 (PST) 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 E796A3A6B6C for ; Mon, 24 Nov 2008 12:09:42 -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 6DSBY5aZioyT for ; Mon, 24 Nov 2008 12:09:42 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 1C85B3A6A48 for ; Mon, 24 Nov 2008 12:09:42 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Mon, 24 Nov 2008 15:09:35 -0500 From: Mark Jones To: Victor Fajardo Date: Mon, 24 Nov 2008 15:09:33 -0500 Thread-Topic: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt Thread-Index: AclOWoucMP7soTv9QS6s7DZUJLbMngAEQOHw Message-ID: References: <20081124171501.76D4D3A6A2A@core3.amsl.com> <492AE4D6.5010403@tari.toshiba.com> In-Reply-To: <492AE4D6.5010403@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, > - Fixed Sec 6.12 and align default values of redirect usage and > auth-session state > I see that the Auth-Session-State default is now "NO_STATE_MAINTAINED". I know a couple of 3GPP applications that explicitly set Auth-Session-State to NO_STATE_MAINTAINED but aren't other derivative applications assuming that state is maintained? So don't we break a lot of implementations with this change? For the record, I originally raised this issue to fix the contradiction between sections 6.12 and 6.13 regarding Redirect-Host-Usage. Even if you don't agree with my suggestion that Redirect-Host-Usage default should be ALL_SESSION, we still don't need to impact Auth-Session-State to resolve that contradiction. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 24 12:54:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E2A3A6BBA; Mon, 24 Nov 2008 12:54:49 -0800 (PST) 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 643373A6BBA for ; Mon, 24 Nov 2008 12:54:47 -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 9rj3vfsX18Rh for ; Mon, 24 Nov 2008 12:54:46 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id A8F9C3A6A45 for ; Mon, 24 Nov 2008 12:54:46 -0800 (PST) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id j52e1a0020FhH24A88ukG6; Mon, 24 Nov 2008 20:54:44 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id j8uj1a0010sGXSz8U8ujRh; Mon, 24 Nov 2008 20:54:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=k2VSxgFEqkwA:10 a=3l0RVMGaK6kA:10 a=48vgC7mUAAAA:8 a=n3EynpeTkjFS87YF_KoA:9 a=itZsYjqJlbmlr3_4qF4A:7 a=5PXAYEY7YvL9wXEQxRcjdosiLYwA:4 a=8jrKueok2nwA:10 a=lZB815dzVvQA:10 a=vNGxQsTWjH8A:10 From: "Glen Zorn" To: "'Mark Jones'" , "'Victor Fajardo'" References: <20081124171501.76D4D3A6A2A@core3.amsl.com> <492AE4D6.5010403@tari.toshiba.com> In-Reply-To: Date: Mon, 24 Nov 2008 12:54:17 -0800 Message-ID: <005401c94e76$d1c33af0$7549b0d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOWoucMP7soTv9QS6s7DZUJLbMngAEQOHwAAKma7A= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Mark Jones [mailto://Mark.Jones@bridgewatersystems.com] writes: > Hi Victor, > > > > - Fixed Sec 6.12 and align default values of redirect usage and > > auth-session state > > > > I see that the Auth-Session-State default is now "NO_STATE_MAINTAINED". > I know a couple of 3GPP applications that explicitly set Auth-Session- > State to NO_STATE_MAINTAINED but aren't other derivative applications > assuming that state is maintained? Not sure what a "derivative application" is... > So don't we break a lot of > implementations with this change? Isn't it more like drawing attention to their brokenness; if they assume things like this, I'd say that they are broken already. > > For the record, I originally raised this issue to fix the contradiction > between sections 6.12 and 6.13 regarding Redirect-Host-Usage. Even if > you don't agree with my suggestion that Redirect-Host-Usage default > should be ALL_SESSION, we still don't need to impact Auth-Session-State > to resolve that contradiction. > > Regards > Mark > > _______________________________________________ > 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 From dime-bounces@ietf.org Mon Nov 24 13:34:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8E23A6A1A; Mon, 24 Nov 2008 13:34:42 -0800 (PST) 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 AE4043A6A1A for ; Mon, 24 Nov 2008 13:34:40 -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 2qJ+q-kiMAQW for ; Mon, 24 Nov 2008 13:34:39 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id C70043A69C1 for ; Mon, 24 Nov 2008 13:34:39 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Mon, 24 Nov 2008 16:34:32 -0500 From: Mark Jones To: Glen Zorn Date: Mon, 24 Nov 2008 16:34:31 -0500 Thread-Topic: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt Thread-Index: AclOWoucMP7soTv9QS6s7DZUJLbMngAEQOHwAAKma7AAAHZl8A== Message-ID: References: <20081124171501.76D4D3A6A2A@core3.amsl.com> <492AE4D6.5010403@tari.toshiba.com> <005401c94e76$d1c33af0$7549b0d0$@net> In-Reply-To: <005401c94e76$d1c33af0$7549b0d0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net] > Sent: November 24, 2008 15:54 > To: Mark Jones; 'Victor Fajardo' > Cc: dime@ietf.org > Subject: RE: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt > > Mark Jones [mailto://Mark.Jones@bridgewatersystems.com] writes: > > > Hi Victor, > > > > > > > - Fixed Sec 6.12 and align default values of redirect usage and > > > auth-session state > > > > > > > I see that the Auth-Session-State default is now > "NO_STATE_MAINTAINED". > > I know a couple of 3GPP applications that explicitly set > Auth-Session- > > State to NO_STATE_MAINTAINED but aren't other derivative > applications > > assuming that state is maintained? > > Not sure what a "derivative application" is... > s/derivative application/Diameter application/ > > So don't we break a lot of > > implementations with this change? > > Isn't it more like drawing attention to their brokenness; if > they assume > things like this, I'd say that they are broken already. > Why are they broken? RFC3588 states that in the absense of an Auth-Session-State AVP "session state is maintained". 3588bis now says session state is NOT maintained if no Auth-Session-State is present. > > > > For the record, I originally raised this issue to fix the > contradiction > > between sections 6.12 and 6.13 regarding > Redirect-Host-Usage. Even if > > you don't agree with my suggestion that Redirect-Host-Usage default > > should be ALL_SESSION, we still don't need to impact > Auth-Session-State > > to resolve that contradiction. > > > > Regards > > Mark > > > > _______________________________________________ > > 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 From dime-bounces@ietf.org Mon Nov 24 14:07:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D63E3A6932; Mon, 24 Nov 2008 14:07:00 -0800 (PST) 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 5CD653A6932 for ; Mon, 24 Nov 2008 14:06:59 -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 k8OhOlPKpQ+k for ; Mon, 24 Nov 2008 14:06:58 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 7D5E73A6826 for ; Mon, 24 Nov 2008 14:06:58 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Mon, 24 Nov 2008 17:06:55 -0500 From: Mark Jones To: "dime@ietf.org" Date: Mon, 24 Nov 2008 17:06:55 -0500 Thread-Topic: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt Thread-Index: AclOWoucMP7soTv9QS6s7DZUJLbMngAEQOHwAAQ5vUA= Message-ID: References: <20081124171501.76D4D3A6A2A@core3.amsl.com> <492AE4D6.5010403@tari.toshiba.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I've had some offline discussions with Victor on this and we came to the conclusions that the Auth-Session-State default should be changed back to STATE_MAINTAINED to avoid impacting existing implementations. This leaves two options to fix the Redirect-Host-Usage contradiction in rfc3588bis-13: (a) default is ALL_SESSION; minor change to section 6.13 (b) default is DONT_CACHE; minor change to section 6.12 In the interests of advancing 3588bis (and noting total lack of WG interest), I can accept fix (b). Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Mark Jones > Sent: November 24, 2008 15:10 > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt > > Hi Victor, > > > > - Fixed Sec 6.12 and align default values of redirect usage and > > auth-session state > > > > I see that the Auth-Session-State default is now > "NO_STATE_MAINTAINED". I know a couple of 3GPP applications > that explicitly set Auth-Session-State to NO_STATE_MAINTAINED > but aren't other derivative applications assuming that state > is maintained? So don't we break a lot of implementations > with this change? > > For the record, I originally raised this issue to fix the > contradiction between sections 6.12 and 6.13 regarding > Redirect-Host-Usage. Even if you don't agree with my > suggestion that Redirect-Host-Usage default should be > ALL_SESSION, we still don't need to impact Auth-Session-State > to resolve that contradiction. > > Regards > Mark > > _______________________________________________ > 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 From dime-bounces@ietf.org Mon Nov 24 14:43:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74193A6840; Mon, 24 Nov 2008 14:43:43 -0800 (PST) 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 6A6A53A6840 for ; Mon, 24 Nov 2008 14:43:42 -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 7d6E+kICkb6D for ; Mon, 24 Nov 2008 14:43:41 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 8F3633A67EE for ; Mon, 24 Nov 2008 14:43:41 -0800 (PST) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id j9zy1a0010mlR8UA3AjfGS; Mon, 24 Nov 2008 22:43:39 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id jAjd1a00f0sGXSz8XAjeZo; Mon, 24 Nov 2008 22:43:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=k2VSxgFEqkwA:10 a=3l0RVMGaK6kA:10 a=6fZoErYMUrsXuPcCGc8A:9 a=zFJrb8Xc38lWaDZxyPjD6yu13soA:4 a=8jrKueok2nwA:10 a=vNGxQsTWjH8A:10 From: "Glen Zorn" To: "'Mark Jones'" References: <20081124171501.76D4D3A6A2A@core3.amsl.com> <492AE4D6.5010403@tari.toshiba.com> <005401c94e76$d1c33af0$7549b0d0$@net> In-Reply-To: Date: Mon, 24 Nov 2008 14:43:11 -0800 Message-ID: <008001c94e86$086dfd60$1949f820$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOWoucMP7soTv9QS6s7DZUJLbMngAEQOHwAAKma7AAAHZl8AADBxdw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] writes: ... > > > I see that the Auth-Session-State default is now > > "NO_STATE_MAINTAINED". > > > I know a couple of 3GPP applications that explicitly set > > Auth-Session- > > > State to NO_STATE_MAINTAINED but aren't other derivative > > applications > > > assuming that state is maintained? > > > > Not sure what a "derivative application" is... > > > > s/derivative application/Diameter application/ > > > > So don't we break a lot of > > > implementations with this change? > > > > Isn't it more like drawing attention to their brokenness; if > > they assume > > things like this, I'd say that they are broken already. > > > > Why are they broken? RFC3588 states that in the absense of an Auth- > Session-State AVP "session state is maintained". Right, my bad. > 3588bis now says > session state is NOT maintained if no Auth-Session-State is present. Not exactly: the only place I can find where behavior in the absence of the Auth-Session-State AVP is described is in section 8.1, paragraph 2: There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. It seems to me that the only thing that has actually changed is the location of the sentence "This is the default value." in the AVP description (which doesn't seem to really mean anything anyway). ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 00:26:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03A33A6A90; Tue, 25 Nov 2008 00:26:41 -0800 (PST) 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 73BFA3A682F for ; Tue, 25 Nov 2008 00:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 cZ-5d7i2KpMj for ; Tue, 25 Nov 2008 00:26:39 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 8350A3A6A95 for ; Tue, 25 Nov 2008 00:26:39 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 22FE1AB7CB; Tue, 25 Nov 2008 09:26:36 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 1478BAB7C4; Tue, 25 Nov 2008 09:26:36 +0100 (CET) Message-ID: <492BB6BB.3060608@restena.lu> Date: Tue, 25 Nov 2008 09:26:35 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Victor Fajardo References: <20081124171501.76D4D3A6A2A@core3.amsl.com> <492AE4D6.5010403@tari.toshiba.com> In-Reply-To: <492AE4D6.5010403@tari.toshiba.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, > - Cleanup of peer discovery mechanism. The new scheme now uses SRV > lookups as a fallback from NAPTR. It also clarifies/cleanup text on > the fallback scheme. Thanks, the text looks good to me! Greetings, Stefan Winter > - Downgraded SCTP support on servers from MUST to SHOULD. > > - Fixed Sec 6.12 and align default values of redirect usage and > auth-session state > > As of this revision, there is only one open issue remaining for bis. > This pertains to securing inband-security info of CER/CEA. The > proposals for item will be treated in a separate thread and changes > will be incorporated in the next rev of bis. > > regards, > victor > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Diameter Maintenance and Extensions >> Working Group of the IETF. >> >> >> Title : Diameter Base Protocol >> Author(s) : V. Fajardo, et al. >> Filename : draft-ietf-dime-rfc3588bis-14.txt >> Pages : 160 >> Date : 2008-11-24 >> >> The Diameter base protocol is intended to provide an Authentication, >> Authorization and Accounting (AAA) framework for applications such as >> network access or IP mobility. Diameter is also intended to work in >> both local Authentication, Authorization & Accounting and roaming >> situations. This document specifies the message format, transport, >> error reporting, accounting and security services to be used by all >> Diameter applications. The Diameter base application needs to be >> supported by all Diameter implementations. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-14.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. >> = >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 07:11:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1493B28C191; Tue, 25 Nov 2008 07:11:12 -0800 (PST) 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 07CB328C191 for ; Tue, 25 Nov 2008 07:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 DtKNfQQR5iR2 for ; Tue, 25 Nov 2008 07:11:10 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 311B828C182 for ; Tue, 25 Nov 2008 07:11:10 -0800 (PST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAPFAubj046681 for ; Tue, 25 Nov 2008 10:10:56 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492C158B.7090400@tari.toshiba.com> Date: Tue, 25 Nov 2008 10:11:07 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: "dime@ietf.org" Subject: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Filtering through the discussions in the list and opinions in ietf73, we now have the following options for securing CER/CEA: 1. Define a new secured port for diameter used only for TLS. This deprecates inband-security and moves TLS setup before any diameter traffic is sent. Its the cleanest solution and would completely secure CER/CEA but it would have greater backward compatibility issues. 2. Redefine the semantics of inband-security. In this case, if inband-security is set to TLS then it means the connecting peer must use TLS instead of treating inband-security as just an advertised value. TLS setup will still be done after CER/CEA negotiation; the way its currently done. There will still be some backward compatibility issue but implementations may not require as much change as (1). Give the changes that's already been introduced in bis that impacts existing implementations, option 2 seems attractive. Though other folks may have other opinions or alternatives. Any suggestions ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 07:13:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B5528C1A0; Tue, 25 Nov 2008 07:13:52 -0800 (PST) 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 0655728C1A6 for ; Tue, 25 Nov 2008 07:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 Q0iprLq-FiAQ for ; Tue, 25 Nov 2008 07:13:50 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 204E728C182 for ; Tue, 25 Nov 2008 07:13:50 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 7FCBCAB7D9; Tue, 25 Nov 2008 16:13:47 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 71E82AB7E2; Tue, 25 Nov 2008 16:13:47 +0100 (CET) Message-ID: <492C162B.5040003@restena.lu> Date: Tue, 25 Nov 2008 16:13:47 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Victor Fajardo References: <492C158B.7090400@tari.toshiba.com> In-Reply-To: <492C158B.7090400@tari.toshiba.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > 1. Define a new secured port for diameter used only for TLS. This > deprecates inband-security and moves TLS setup before any diameter > traffic is sent. Its the cleanest solution and would completely secure > CER/CEA but it would have greater backward compatibility issues. > > 2. Redefine the semantics of inband-security. In this case, if > inband-security is set to TLS then it means the connecting peer must > use TLS instead of treating inband-security as just an advertised > value. TLS setup will still be done after CER/CEA negotiation; the way > its currently done. There will still be some backward compatibility > issue but implementations may not require as much change as (1). > > Give the changes that's already been introduced in bis that impacts > existing implementations, option 2 seems attractive. Though other > folks may have other opinions or alternatives. In the meeting, we also spoke about a new "STARTTLS" command code which optionally comes before the CER which *might* be completely backwards compatible. I had the impression that this had some support in the room. What do you think? Stefan -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 08:06:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D073A6C04; Tue, 25 Nov 2008 08:06:29 -0800 (PST) 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 AD49A3A6C03 for ; Tue, 25 Nov 2008 08:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 nME7PKdCeAoO for ; Tue, 25 Nov 2008 08:06:26 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id B89E83A6A07 for ; Tue, 25 Nov 2008 08:06:26 -0800 (PST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAPG6DWZ047204; Tue, 25 Nov 2008 11:06:13 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492C227F.2070202@tari.toshiba.com> Date: Tue, 25 Nov 2008 11:06:23 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Stefan Winter References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> In-Reply-To: <492C162B.5040003@restena.lu> Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Stefan, > Hi, > > >> 1. Define a new secured port for diameter used only for TLS. This >> deprecates inband-security and moves TLS setup before any diameter >> traffic is sent. Its the cleanest solution and would completely secure >> CER/CEA but it would have greater backward compatibility issues. >> >> 2. Redefine the semantics of inband-security. In this case, if >> inband-security is set to TLS then it means the connecting peer must >> use TLS instead of treating inband-security as just an advertised >> value. TLS setup will still be done after CER/CEA negotiation; the way >> its currently done. There will still be some backward compatibility >> issue but implementations may not require as much change as (1). >> >> Give the changes that's already been introduced in bis that impacts >> existing implementations, option 2 seems attractive. Though other >> folks may have other opinions or alternatives. >> > > In the meeting, we also spoke about a new "STARTTLS" command code which > optionally comes before the CER which *might* be completely backwards > compatible. I had the impression that this had some support in the room. > What do you think? > Good point. I was contemplating it and that maybe a good 3rd option which I failed to mention. In which case, we maybe able to define a new extension document that negotiates security and uses a new command code/avps as you mentioned. We may not need to do anything with bis except update the security considerations section to reflect the existing vulnerability and that extensions are available to help. Is this a good approach ? regards, victor > Stefan > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 11:04:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5D53A6A5E; Tue, 25 Nov 2008 11:04:21 -0800 (PST) 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 386B33A6A5E for ; Tue, 25 Nov 2008 11:04:20 -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 IcPnd4Y1rWqi for ; Tue, 25 Nov 2008 11:04:19 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 39A8E3A67C1 for ; Tue, 25 Nov 2008 11:04:18 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAPJ4FeW001170 for ; Tue, 25 Nov 2008 13:04:15 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mAPJ4A78015520 for ; Tue, 25 Nov 2008 13:04:10 -0600 (CST) Received: from [192.168.0.38] (clover.8950aaa.com [192.168.0.38]) by hal.8950aaa.com (Postfix) with ESMTP id 3093E58D5E for ; Tue, 25 Nov 2008 11:04:10 -0800 (PST) Message-ID: <492C4C25.9070205@alcatel-lucent.com> Date: Tue, 25 Nov 2008 11:04:05 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "dime@ietf.org" References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> In-Reply-To: <492C227F.2070202@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org As I expressed in my previous email on this subject, item 2 is the only option that follows the P2P connection setup mechanism architected for Diameter and avoids unnecessary "cross handshaking" during race conditions. How important this is can be argued but it *could* be a concern for handhelds or other devices with limited processing resources. Another aspect of this is how may implementations out there already have a working implementation based on TLS after the Capabilities Exchange and I believe there are a few. At least our server has a complete and working implementation based on this mechanism. If the initial CER/CEA handshake contains only minimal information to get TLS going and another CER/CEA exchange is allowed to take place inside the encrypted tunnel (which it used to be and likely presents a minimal change to any existing implementation would it be reinstated), that initial CER/CEA *is* your start-TLS mechanism. In addition, using a predefined secured port will certainly create challenges for SCTP over TLS. The CER/CEA setup method at least lets the two SCTP peers negotiate in and out streams before attempting to establish TLS over them. There is an obvious lack of strong standardization text in this arena but there is still enough to interoperate TLS over SCTP using this method. So if the purpose of this thread is to collect opinions, my vote is for "p2p start-TLS", i.e. item 2, with the addition of a secondary CER/CEA. Jan Nordqvist Alcatel-Lucent 8950/AAA Product Group. Victor Fajardo wrote: > Hi Stefan, > >> Hi, >> >> >>> 1. Define a new secured port for diameter used only for TLS. This >>> deprecates inband-security and moves TLS setup before any diameter >>> traffic is sent. Its the cleanest solution and would completely secure >>> CER/CEA but it would have greater backward compatibility issues. >>> >>> 2. Redefine the semantics of inband-security. In this case, if >>> inband-security is set to TLS then it means the connecting peer must >>> use TLS instead of treating inband-security as just an advertised >>> value. TLS setup will still be done after CER/CEA negotiation; the way >>> its currently done. There will still be some backward compatibility >>> issue but implementations may not require as much change as (1). >>> >>> Give the changes that's already been introduced in bis that impacts >>> existing implementations, option 2 seems attractive. Though other >>> folks may have other opinions or alternatives. >>> >> >> In the meeting, we also spoke about a new "STARTTLS" command code which >> optionally comes before the CER which *might* be completely backwards >> compatible. I had the impression that this had some support in the room. >> What do you think? >> > > Good point. I was contemplating it and that maybe a good 3rd option > which I failed to mention. In which case, we maybe able to define a > new extension document that negotiates security and uses a new > command code/avps as you mentioned. We may not need to do anything > with bis except update the security considerations section to reflect > the existing vulnerability and that extensions are available to help. > Is this a good approach ? > > regards, > victor > > >> Stefan >> >> > > _______________________________________________ > 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 From dime-bounces@ietf.org Tue Nov 25 11:11:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD123A6C31; Tue, 25 Nov 2008 11:11:46 -0800 (PST) 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 F262F3A698F for ; Tue, 25 Nov 2008 11:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 iB6rlxoagRRs for ; Tue, 25 Nov 2008 11:11:44 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 34FEB3A6C24 for ; Tue, 25 Nov 2008 11:11:44 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id jWTm1a0040EPchoA3XBhUo; Tue, 25 Nov 2008 19:11:41 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id jXBf1a00Q0sGXSz8MXBglo; Tue, 25 Nov 2008 19:11:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=kwaOENA8wDcA:10 a=XPR3u3Bb0gsA:10 a=ULbRAZvs2gvLWe8KGjgA:9 a=WNE44AHB_zYkiz2Zd34A:7 a=QPv7XF9OO4Ocs26vVog-DYrGJOUA:4 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" References: <492C158B.7090400@tari.toshiba.com> In-Reply-To: <492C158B.7090400@tari.toshiba.com> Date: Tue, 25 Nov 2008 11:11:04 -0800 Message-ID: <002801c94f31$90a2ccf0$b1e866d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclPEAw63V7l6nFSRBq080pc9FUq3QAIDbzA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes: > Filtering through the discussions in the list and opinions in ietf73, > we > now have the following options for securing CER/CEA: > > 1. Define a new secured port for diameter used only for TLS. This > deprecates inband-security and moves TLS setup before any diameter > traffic is sent. Its the cleanest solution and would completely secure > CER/CEA but it would have greater backward compatibility issues. > > 2. Redefine the semantics of inband-security. In this case, if > inband-security is set to TLS then it means the connecting peer must > use > TLS instead of treating inband-security as just an advertised value. > TLS > setup will still be done after CER/CEA negotiation; the way its > currently done. There will still be some backward compatibility issue > but implementations may not require as much change as (1). How does this protect the CER/CEA exchange? > > Give the changes that's already been introduced in bis that impacts > existing implementations, option 2 seems attractive. I'm not sure why you say that. If bis had _not_ required any changes to existing implementations then I would agree, but given that it has, what's the big problem w/another? > Though other folks may have other opinions or alternatives. > > Any suggestions ? There is a third option which could (if necessary) preserve complete backward compatibility (I think): define a new command that simply starts TLS, coming before any other messages. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 11:31:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34533A6C24; Tue, 25 Nov 2008 11:31:46 -0800 (PST) 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 5FB703A6AA7 for ; Tue, 25 Nov 2008 11:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1DUcl4NfBkR for ; Tue, 25 Nov 2008 11:31:44 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 4E0723A6902 for ; Tue, 25 Nov 2008 11:31:44 -0800 (PST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAPJVQkR049343; Tue, 25 Nov 2008 14:31:26 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492C5299.8080300@tari.toshiba.com> Date: Tue, 25 Nov 2008 14:31:37 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Jan Nordqvist References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> In-Reply-To: <492C4C25.9070205@alcatel-lucent.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jan, > As I expressed in my previous email on this subject, item 2 is the > only option that follows the P2P connection setup mechanism > architected for Diameter and avoids unnecessary "cross handshaking" > during race conditions. How important this is can be argued but it > *could* be a concern for handhelds or other devices with limited > processing resources. Just for my understanding, in which scenario would the possible race condition and cross handshaking occur. > > Another aspect of this is how may implementations out there already > have a working implementation based on TLS after the Capabilities > Exchange and I believe there are a few. At least our server has a > complete and working implementation based on this mechanism. > If the initial CER/CEA handshake contains only minimal information to > get TLS going and another CER/CEA exchange is allowed to take place > inside the encrypted tunnel (which it used to be and likely presents a > minimal change to any existing implementation would it be reinstated), > that initial CER/CEA *is* your start-TLS mechanism. > > In addition, using a predefined secured port will certainly create > challenges for SCTP over TLS. The CER/CEA setup method at least lets > the two SCTP peers negotiate in and out streams before attempting to > establish TLS over them. There is an obvious lack of strong > standardization text in this arena but there is still enough to > interoperate TLS over SCTP using this method. > > So if the purpose of this thread is to collect opinions, my vote is > for "p2p start-TLS", i.e. item 2, with the addition of a secondary > CER/CEA. Ok. Your vote is duly noted :) Just an additional query, your not too concerned about backward compatibility issues in the above scheme. Note that folks have already agreed to remove CER/CEA exchange in the open state which poses a problem with the secondary CER/CEA. One advantage I see in the third option (stated by Stefan) is that we maybe able decouple this issue from CER/CEA without imposing possible interoperability issues. regards, victor > > Jan Nordqvist > Alcatel-Lucent 8950/AAA Product Group. > > Victor Fajardo wrote: >> Hi Stefan, >> >>> Hi, >>> >>> >>>> 1. Define a new secured port for diameter used only for TLS. This >>>> deprecates inband-security and moves TLS setup before any diameter >>>> traffic is sent. Its the cleanest solution and would completely secure >>>> CER/CEA but it would have greater backward compatibility issues. >>>> >>>> 2. Redefine the semantics of inband-security. In this case, if >>>> inband-security is set to TLS then it means the connecting peer must >>>> use TLS instead of treating inband-security as just an advertised >>>> value. TLS setup will still be done after CER/CEA negotiation; the way >>>> its currently done. There will still be some backward compatibility >>>> issue but implementations may not require as much change as (1). >>>> >>>> Give the changes that's already been introduced in bis that impacts >>>> existing implementations, option 2 seems attractive. Though other >>>> folks may have other opinions or alternatives. >>>> >>> >>> In the meeting, we also spoke about a new "STARTTLS" command code which >>> optionally comes before the CER which *might* be completely backwards >>> compatible. I had the impression that this had some support in the >>> room. >>> What do you think? >>> >> >> Good point. I was contemplating it and that maybe a good 3rd option >> which I failed to mention. In which case, we maybe able to define a >> new extension document that negotiates security and uses a new >> command code/avps as you mentioned. We may not need to do anything >> with bis except update the security considerations section to reflect >> the existing vulnerability and that extensions are available to help. >> Is this a good approach ? >> >> regards, >> victor >> >> >>> Stefan >>> >>> >> >> _______________________________________________ >> 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 > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 11:38:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055863A6AA7; Tue, 25 Nov 2008 11:38:00 -0800 (PST) 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 2D8693A6AAB for ; Tue, 25 Nov 2008 11:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 ddorL6qqWxQg for ; Tue, 25 Nov 2008 11:37:57 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 4F47C3A6902 for ; Tue, 25 Nov 2008 11:37:57 -0800 (PST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAPJbeP4049365; Tue, 25 Nov 2008 14:37:40 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492C540F.1080007@tari.toshiba.com> Date: Tue, 25 Nov 2008 14:37:51 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Glen Zorn References: <492C158B.7090400@tari.toshiba.com> <002801c94f31$90a2ccf0$b1e866d0$@net> In-Reply-To: <002801c94f31$90a2ccf0$b1e866d0$@net> Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, > >> Filtering through the discussions in the list and opinions in ietf73, >> we >> now have the following options for securing CER/CEA: >> >> 1. Define a new secured port for diameter used only for TLS. This >> deprecates inband-security and moves TLS setup before any diameter >> traffic is sent. Its the cleanest solution and would completely secure >> CER/CEA but it would have greater backward compatibility issues. >> >> 2. Redefine the semantics of inband-security. In this case, if >> inband-security is set to TLS then it means the connecting peer must >> use >> TLS instead of treating inband-security as just an advertised value. >> TLS >> setup will still be done after CER/CEA negotiation; the way its >> currently done. There will still be some backward compatibility issue >> but implementations may not require as much change as (1). >> > > How does this protect the CER/CEA exchange? > Its not a complete protection of CER/CEA but a mere indication that TLS is is coming next. >> Though other folks may have other opinions or alternatives. >> >> Any suggestions ? >> > > There is a third option which could (if necessary) preserve complete > backward compatibility (I think): define a new command that simply starts > TLS, coming before any other messages. > Yup. Pls see my other email in response to Stefan and Jan .... -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 11:40:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333E13A6ABA; Tue, 25 Nov 2008 11:40:17 -0800 (PST) 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 2027B3A6ABA for ; Tue, 25 Nov 2008 11:40:16 -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 vjsDpz1Dai9o for ; Tue, 25 Nov 2008 11:40:15 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 189253A6AA7 for ; Tue, 25 Nov 2008 11:40:15 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id mAPJeC6B023331; Tue, 25 Nov 2008 14:40:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 14:39:39 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com> In-Reply-To: <492C158B.7090400@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Options for securing CER/CEA Thread-Index: AclPD/qnvHbYsd1jRvGXF8b/UR09iQAJVRlg References: <492C158B.7090400@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" , Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I would prefer 1. It is clean and straightforward. I guess 2. is not really secure as Glen pointed out -unless I am missing something-. Thanks, Tolga > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Victor Fajardo > Sent: Tuesday, November 25, 2008 10:11 AM > To: dime@ietf.org > Subject: [Dime] Options for securing CER/CEA > > Filtering through the discussions in the list and opinions in ietf73, we > now have the following options for securing CER/CEA: > > 1. Define a new secured port for diameter used only for TLS. This > deprecates inband-security and moves TLS setup before any diameter > traffic is sent. Its the cleanest solution and would completely secure > CER/CEA but it would have greater backward compatibility issues. > > 2. Redefine the semantics of inband-security. In this case, if > inband-security is set to TLS then it means the connecting peer must use > TLS instead of treating inband-security as just an advertised value. TLS > setup will still be done after CER/CEA negotiation; the way its > currently done. There will still be some backward compatibility issue > but implementations may not require as much change as (1). > > Give the changes that's already been introduced in bis that impacts > existing implementations, option 2 seems attractive. Though other folks > may have other opinions or alternatives. > > Any suggestions ? > > regards, > victor > _______________________________________________ > 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 From dime-bounces@ietf.org Tue Nov 25 11:40:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DE03A6AC2; Tue, 25 Nov 2008 11:40:37 -0800 (PST) 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 64BB828C0DC for ; Tue, 25 Nov 2008 11:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 wMCfMXCXmbst for ; Tue, 25 Nov 2008 11:40:34 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A964E3A6ABA for ; Tue, 25 Nov 2008 11:40:34 -0800 (PST) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id jRCV1a0011GXsucA1XgWnY; Tue, 25 Nov 2008 19:40:30 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id jXgQ1a00a0sGXSz8TXgSM6; Tue, 25 Nov 2008 19:40:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=kwaOENA8wDcA:10 a=XPR3u3Bb0gsA:10 a=48vgC7mUAAAA:8 a=_LVlJLPYq85NOPBXCYgA:9 a=hi-itbitMD0ET6boF9EA:7 a=60Wx5ZDbLzqWElSJBHFW1pqdxrMA:4 a=lZB815dzVvQA:10 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" , "'Stefan Winter'" References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> In-Reply-To: <492C227F.2070202@tari.toshiba.com> Date: Tue, 25 Nov 2008 11:39:49 -0800 Message-ID: <002c01c94f35$958433e0$c08c9ba0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclPF9JtiM6PbQmDRkSa5a1adXZ/TAAHSM2g Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes: ... > >> 1. Define a new secured port for diameter used only for TLS. This > >> deprecates inband-security and moves TLS setup before any diameter > >> traffic is sent. Its the cleanest solution and would completely > secure > >> CER/CEA but it would have greater backward compatibility issues. > >> > >> 2. Redefine the semantics of inband-security. In this case, if > >> inband-security is set to TLS then it means the connecting peer must > >> use TLS instead of treating inband-security as just an advertised > >> value. TLS setup will still be done after CER/CEA negotiation; the > way > >> its currently done. There will still be some backward compatibility > >> issue but implementations may not require as much change as (1). > >> > >> Give the changes that's already been introduced in bis that impacts > >> existing implementations, option 2 seems attractive. Though other > >> folks may have other opinions or alternatives. > >> > > > > In the meeting, we also spoke about a new "STARTTLS" command code > which > > optionally comes before the CER which *might* be completely backwards > > compatible. I had the impression that this had some support in the > room. > > What do you think? > > > > Good point. I was contemplating it and that maybe a good 3rd option > which I failed to mention. In which case, we maybe able to define a new > extension document that negotiates security and uses a new command > code/avps as you mentioned. We may not need to do anything with bis > except update the security considerations section to reflect the > existing vulnerability and that extensions are available to help. Is > this a good approach ? Although the StartTLS approach has the benefit of preserving backward-compatibility, I believe that it will reduce the window of vulnerability but may not close it completely. > > regards, > victor > > > > Stefan > > > > > > _______________________________________________ > 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 From dime-bounces@ietf.org Tue Nov 25 11:41:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB093A6AAB; Tue, 25 Nov 2008 11:41:52 -0800 (PST) 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 8046B3A6AAB for ; Tue, 25 Nov 2008 11:41:51 -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 fe4SYTfPqRbp for ; Tue, 25 Nov 2008 11:41:50 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 78D793A6902 for ; Tue, 25 Nov 2008 11:41:50 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id mAPJfkGa024554; Tue, 25 Nov 2008 14:41:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 14:41:13 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7D0@sonusmail04.sonusnet.com> In-Reply-To: <492C4C25.9070205@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Options for securing CER/CEA Thread-Index: AclPMI0yUrA0UucNQ8m0vnxXl/CPNQABRNQw References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu><492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> From: "Asveren, Tolga" To: "Jan Nordqvist" , Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jan, One question below. Thanks, Tolga > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Jan Nordqvist > Sent: Tuesday, November 25, 2008 2:04 PM > To: dime@ietf.org > Subject: Re: [Dime] Options for securing CER/CEA > > As I expressed in my previous email on this subject, item 2 is the only > option that follows the P2P connection setup mechanism architected for > Diameter and avoids unnecessary "cross handshaking" during race > conditions. How important this is can be argued but it *could* be a > concern for handhelds or other devices with limited processing resources. > > Another aspect of this is how may implementations out there already have > a working implementation based on TLS after the Capabilities Exchange > and I believe there are a few. At least our server has a complete and > working implementation based on this mechanism. > If the initial CER/CEA handshake contains only minimal information to > get TLS going and another CER/CEA exchange is allowed to take place > inside the encrypted tunnel (which it used to be and likely presents a > minimal change to any existing implementation would it be reinstated), > that initial CER/CEA *is* your start-TLS mechanism. > > In addition, using a predefined secured port will certainly create > challenges for SCTP over TLS. The CER/CEA setup method at least lets the > two SCTP peers negotiate in and out streams before attempting to > establish TLS over them. There is an obvious lack of strong > standardization text in this arena but there is still enough to > interoperate TLS over SCTP using this method. [TOLGA]Streams are negotiated during SCTP association establishment. What does CER/CEA have to do with this? > > So if the purpose of this thread is to collect opinions, my vote is for > "p2p start-TLS", i.e. item 2, with the addition of a secondary CER/CEA. > > Jan Nordqvist > Alcatel-Lucent 8950/AAA Product Group. > > Victor Fajardo wrote: > > Hi Stefan, > > > >> Hi, > >> > >> > >>> 1. Define a new secured port for diameter used only for TLS. This > >>> deprecates inband-security and moves TLS setup before any diameter > >>> traffic is sent. Its the cleanest solution and would completely secure > >>> CER/CEA but it would have greater backward compatibility issues. > >>> > >>> 2. Redefine the semantics of inband-security. In this case, if > >>> inband-security is set to TLS then it means the connecting peer must > >>> use TLS instead of treating inband-security as just an advertised > >>> value. TLS setup will still be done after CER/CEA negotiation; the way > >>> its currently done. There will still be some backward compatibility > >>> issue but implementations may not require as much change as (1). > >>> > >>> Give the changes that's already been introduced in bis that impacts > >>> existing implementations, option 2 seems attractive. Though other > >>> folks may have other opinions or alternatives. > >>> > >> > >> In the meeting, we also spoke about a new "STARTTLS" command code which > >> optionally comes before the CER which *might* be completely backwards > >> compatible. I had the impression that this had some support in the > room. > >> What do you think? > >> > > > > Good point. I was contemplating it and that maybe a good 3rd option > > which I failed to mention. In which case, we maybe able to define a > > new extension document that negotiates security and uses a new > > command code/avps as you mentioned. We may not need to do anything > > with bis except update the security considerations section to reflect > > the existing vulnerability and that extensions are available to help. > > Is this a good approach ? > > > > regards, > > victor > > > > > >> Stefan > >> > >> > > > > _______________________________________________ > > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 11:45:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66053A6A9F; Tue, 25 Nov 2008 11:45:02 -0800 (PST) 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 B27543A6A9F for ; Tue, 25 Nov 2008 11:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 1L+X1N9-SC1T for ; Tue, 25 Nov 2008 11:45:01 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id B7B0B3A6902 for ; Tue, 25 Nov 2008 11:45:00 -0800 (PST) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAPJikkD049407; Tue, 25 Nov 2008 14:44:46 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492C55B9.4050801@tari.toshiba.com> Date: Tue, 25 Nov 2008 14:44:57 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: "Asveren, Tolga" References: <492C158B.7090400@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com> Cc: dime@ietf.org Subject: [Dime] OFFLINE: Re: Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tolga, > I would prefer 1. It is clean and straightforward. I guess 2. is not > really secure as Glen pointed out -unless I am missing something-. > Just in case you did not see it, what do you think about the 3rd option (already stated by Stefan and then Glenn) ? -- victor > Thanks, > Tolga > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> > Of > >> Victor Fajardo >> Sent: Tuesday, November 25, 2008 10:11 AM >> To: dime@ietf.org >> Subject: [Dime] Options for securing CER/CEA >> >> Filtering through the discussions in the list and opinions in ietf73, >> > we > >> now have the following options for securing CER/CEA: >> >> 1. Define a new secured port for diameter used only for TLS. This >> deprecates inband-security and moves TLS setup before any diameter >> traffic is sent. Its the cleanest solution and would completely secure >> CER/CEA but it would have greater backward compatibility issues. >> >> 2. Redefine the semantics of inband-security. In this case, if >> inband-security is set to TLS then it means the connecting peer must >> > use > >> TLS instead of treating inband-security as just an advertised value. >> > TLS > >> setup will still be done after CER/CEA negotiation; the way its >> currently done. There will still be some backward compatibility issue >> but implementations may not require as much change as (1). >> >> Give the changes that's already been introduced in bis that impacts >> existing implementations, option 2 seems attractive. Though other >> > folks > >> may have other opinions or alternatives. >> >> Any suggestions ? >> >> regards, >> victor >> _______________________________________________ >> 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 From dime-bounces@ietf.org Tue Nov 25 11:49:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0D53A6A9E; Tue, 25 Nov 2008 11:49:20 -0800 (PST) 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 5EEAA3A69E3 for ; Tue, 25 Nov 2008 11:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 evynGN3j24UI for ; Tue, 25 Nov 2008 11:49:18 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 9F4323A6AA7 for ; Tue, 25 Nov 2008 11:49:18 -0800 (PST) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id jXE81a00717UAYkA5XpGKX; Tue, 25 Nov 2008 19:49:16 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id jXpE1a00k0sGXSz8ZXpFRV; Tue, 25 Nov 2008 19:49:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=o78zYCKILZYA:10 a=J2oYgoYFNRMA:10 a=72DanoN8M3Iaxfu0zFsA:9 a=KlL0go4dK-ExS1YRJ-fRrdhu3L0A:4 a=EI1Y7BXnmVQA:10 From: "Glen Zorn" To: "'Victor Fajardo'" , "'Asveren, Tolga'" References: <492C158B.7090400@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com> <492C55B9.4050801@tari.toshiba.com> In-Reply-To: <492C55B9.4050801@tari.toshiba.com> Date: Tue, 25 Nov 2008 11:48:39 -0800 Message-ID: <003301c94f36$d0d50720$727f1560$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclPNk52hDUxFHzxTqyKRbr2sp62XQAADquw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] OFFLINE: Re: Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes: > Hi Tolga, > > > > I would prefer 1. It is clean and straightforward. I guess 2. is not > > really secure as Glen pointed out -unless I am missing something-. > > > > Just in case you did not see it, what do you think about the 3rd option > (already stated by Stefan and then Glenn) ? Just to be clear, I prefer #1 as well. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 12:24:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CC13A6C5F; Tue, 25 Nov 2008 12:24:31 -0800 (PST) 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 5BB083A6C60 for ; Tue, 25 Nov 2008 12:24:29 -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 IeGHAKldC0hv for ; Tue, 25 Nov 2008 12:24:28 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 54D4E3A6C5F for ; Tue, 25 Nov 2008 12:24:28 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id mAPKOPNO021961; Tue, 25 Nov 2008 15:24:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 15:23:52 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7F0@sonusmail04.sonusnet.com> In-Reply-To: <492C55B9.4050801@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OFFLINE: Re: [Dime] Options for securing CER/CEA Thread-Index: AclPNjr/mFb+kyYzQViG2XtHgm+wJQAA1Hqg References: <492C158B.7090400@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com> <492C55B9.4050801@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" Cc: dime@ietf.org Subject: Re: [Dime] OFFLINE: Re: Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, I think STARTTLS should work but what does it buy to us in addition to functionality provided with multiple ports? IMO different ports approach is not too bad from backward compatibility perspective. If a client wants to use TLS it will try the tls-port. If there is no answer, which means the server is not updated, it will try the non-secure port and will happily communicate with the server (exposed to attacks during capability exchange). After thinking a bit more I *guess* 2. would work as well but I don't see how it is backward compatible. CER wasn't allowed in Open state in RFC3588 AFAIR. BTW, using the intiial CER/CEA exchange in lieu of STARTTLS is really ugly. So, at the end I am still in favor of 1. I don't think this is also a modest change from coding perspective. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, November 25, 2008 2:45 PM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: OFFLINE: Re: [Dime] Options for securing CER/CEA > > Hi Tolga, > > > > I would prefer 1. It is clean and straightforward. I guess 2. is not > > really secure as Glen pointed out -unless I am missing something-. > > > > Just in case you did not see it, what do you think about the 3rd option > (already stated by Stefan and then Glenn) ? > > -- victor > > > Thanks, > > Tolga > > > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > >> > > Of > > > >> Victor Fajardo > >> Sent: Tuesday, November 25, 2008 10:11 AM > >> To: dime@ietf.org > >> Subject: [Dime] Options for securing CER/CEA > >> > >> Filtering through the discussions in the list and opinions in ietf73, > >> > > we > > > >> now have the following options for securing CER/CEA: > >> > >> 1. Define a new secured port for diameter used only for TLS. This > >> deprecates inband-security and moves TLS setup before any diameter > >> traffic is sent. Its the cleanest solution and would completely secure > >> CER/CEA but it would have greater backward compatibility issues. > >> > >> 2. Redefine the semantics of inband-security. In this case, if > >> inband-security is set to TLS then it means the connecting peer must > >> > > use > > > >> TLS instead of treating inband-security as just an advertised value. > >> > > TLS > > > >> setup will still be done after CER/CEA negotiation; the way its > >> currently done. There will still be some backward compatibility issue > >> but implementations may not require as much change as (1). > >> > >> Give the changes that's already been introduced in bis that impacts > >> existing implementations, option 2 seems attractive. Though other > >> > > folks > > > >> may have other opinions or alternatives. > >> > >> Any suggestions ? > >> > >> regards, > >> victor > >> _______________________________________________ > >> 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 From dime-bounces@ietf.org Tue Nov 25 12:26:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4073D3A6C5E; Tue, 25 Nov 2008 12:26:31 -0800 (PST) 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 449973A6C60 for ; Tue, 25 Nov 2008 12:26:30 -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 0lLhdA8bxh5A for ; Tue, 25 Nov 2008 12:26:29 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 16AFD3A6C5E for ; Tue, 25 Nov 2008 12:26:13 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id mAPKQBWL023672; Tue, 25 Nov 2008 15:26:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 15:25:38 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7F1@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7F0@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] OFFLINE: Re: Options for securing CER/CEA Thread-Index: AclPNjr/mFb+kyYzQViG2XtHgm+wJQAA1HqgAACWkmA= References: <492C158B.7090400@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com><492C55B9.4050801@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E701A2A7F0@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Victor Fajardo" Cc: dime@ietf.org Subject: Re: [Dime] OFFLINE: Re: Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Typo corrected: I think this is also a modest change from coding perspective. Thanks, Tolga > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Asveren, Tolga > Sent: Tuesday, November 25, 2008 3:24 PM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] OFFLINE: Re: Options for securing CER/CEA > > Hi Victor, > > I think STARTTLS should work but what does it buy to us in addition to > functionality provided with multiple ports? > > IMO different ports approach is not too bad from backward compatibility > perspective. If a client wants to use TLS it will try the tls-port. If > there is no answer, which means the server is not updated, it will try > the non-secure port and will happily communicate with the server > (exposed to attacks during capability exchange). > > After thinking a bit more I *guess* 2. would work as well but I don't > see how it is backward compatible. CER wasn't allowed in Open state in > RFC3588 AFAIR. BTW, using the intiial CER/CEA exchange in lieu of > STARTTLS is really ugly. > > So, at the end I am still in favor of 1. I don't think this is also a > modest change from coding perspective. > > Thanks, > Tolga > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Tuesday, November 25, 2008 2:45 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org > > Subject: OFFLINE: Re: [Dime] Options for securing CER/CEA > > > > Hi Tolga, > > > > > > > I would prefer 1. It is clean and straightforward. I guess 2. is not > > > really secure as Glen pointed out -unless I am missing something-. > > > > > > > Just in case you did not see it, what do you think about the 3rd > option > > (already stated by Stefan and then Glenn) ? > > > > -- victor > > > > > Thanks, > > > Tolga > > > > > > > > >> -----Original Message----- > > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf > > >> > > > Of > > > > > >> Victor Fajardo > > >> Sent: Tuesday, November 25, 2008 10:11 AM > > >> To: dime@ietf.org > > >> Subject: [Dime] Options for securing CER/CEA > > >> > > >> Filtering through the discussions in the list and opinions in > ietf73, > > >> > > > we > > > > > >> now have the following options for securing CER/CEA: > > >> > > >> 1. Define a new secured port for diameter used only for TLS. This > > >> deprecates inband-security and moves TLS setup before any diameter > > >> traffic is sent. Its the cleanest solution and would completely > secure > > >> CER/CEA but it would have greater backward compatibility issues. > > >> > > >> 2. Redefine the semantics of inband-security. In this case, if > > >> inband-security is set to TLS then it means the connecting peer > must > > >> > > > use > > > > > >> TLS instead of treating inband-security as just an advertised > value. > > >> > > > TLS > > > > > >> setup will still be done after CER/CEA negotiation; the way its > > >> currently done. There will still be some backward compatibility > issue > > >> but implementations may not require as much change as (1). > > >> > > >> Give the changes that's already been introduced in bis that impacts > > >> existing implementations, option 2 seems attractive. Though other > > >> > > > folks > > > > > >> may have other opinions or alternatives. > > >> > > >> Any suggestions ? > > >> > > >> regards, > > >> victor > > >> _______________________________________________ > > >> 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 13:25:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB2F3A6C68; Tue, 25 Nov 2008 13:25:26 -0800 (PST) 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 7A11A3A6C66 for ; Tue, 25 Nov 2008 13:25:25 -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 OeEQLyaLceKI for ; Tue, 25 Nov 2008 13:25:18 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 4C47F28C116 for ; Tue, 25 Nov 2008 13:25:17 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAPLPELX027581 for ; Tue, 25 Nov 2008 15:25:14 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mAPLP9tX019987 for ; Tue, 25 Nov 2008 15:25:09 -0600 (CST) Received: from [192.168.0.38] (clover.8950aaa.com [192.168.0.38]) by hal.8950aaa.com (Postfix) with ESMTP id 32FE658DF3 for ; Tue, 25 Nov 2008 13:25:09 -0800 (PST) Message-ID: <492C6D2F.2040701@alcatel-lucent.com> Date: Tue, 25 Nov 2008 13:25:03 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "dime@ietf.org" References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> <492C5299.8080300@tari.toshiba.com> In-Reply-To: <492C5299.8080300@tari.toshiba.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, The race condition occurs when two peers tries to connect to each other at approximately the same time, i.e. before either side has detected an incoming connection from the remote. This is obviously the issue that the election process tries to deal with. I don't know what reasoning was behind the removal of the open state CER/CEA, but at least in our implementation a secondary exchange would have marginal impact. Regards, Jan. Victor Fajardo wrote: > Hi Jan, > >> As I expressed in my previous email on this subject, item 2 is the >> only option that follows the P2P connection setup mechanism >> architected for Diameter and avoids unnecessary "cross handshaking" >> during race conditions. How important this is can be argued but it >> *could* be a concern for handhelds or other devices with limited >> processing resources. > > Just for my understanding, in which scenario would the possible race > condition and cross handshaking occur. > >> >> Another aspect of this is how may implementations out there already >> have a working implementation based on TLS after the Capabilities >> Exchange and I believe there are a few. At least our server has a >> complete and working implementation based on this mechanism. >> If the initial CER/CEA handshake contains only minimal information to >> get TLS going and another CER/CEA exchange is allowed to take place >> inside the encrypted tunnel (which it used to be and likely presents >> a minimal change to any existing implementation would it be >> reinstated), that initial CER/CEA *is* your start-TLS mechanism. >> >> In addition, using a predefined secured port will certainly create >> challenges for SCTP over TLS. The CER/CEA setup method at least lets >> the two SCTP peers negotiate in and out streams before attempting to >> establish TLS over them. There is an obvious lack of strong >> standardization text in this arena but there is still enough to >> interoperate TLS over SCTP using this method. >> >> So if the purpose of this thread is to collect opinions, my vote is >> for "p2p start-TLS", i.e. item 2, with the addition of a secondary >> CER/CEA. > > Ok. Your vote is duly noted :) Just an additional query, your not too > concerned about backward compatibility issues in the above scheme. > Note that folks have already agreed to remove CER/CEA exchange in the > open state which poses a problem with the secondary CER/CEA. > > One advantage I see in the third option (stated by Stefan) is that we > maybe able decouple this issue from CER/CEA without imposing possible > interoperability issues. > > regards, > victor > >> >> Jan Nordqvist >> Alcatel-Lucent 8950/AAA Product Group. >> >> Victor Fajardo wrote: >>> Hi Stefan, >>> >>>> Hi, >>>> >>>> >>>>> 1. Define a new secured port for diameter used only for TLS. This >>>>> deprecates inband-security and moves TLS setup before any diameter >>>>> traffic is sent. Its the cleanest solution and would completely >>>>> secure >>>>> CER/CEA but it would have greater backward compatibility issues. >>>>> >>>>> 2. Redefine the semantics of inband-security. In this case, if >>>>> inband-security is set to TLS then it means the connecting peer must >>>>> use TLS instead of treating inband-security as just an advertised >>>>> value. TLS setup will still be done after CER/CEA negotiation; the >>>>> way >>>>> its currently done. There will still be some backward compatibility >>>>> issue but implementations may not require as much change as (1). >>>>> >>>>> Give the changes that's already been introduced in bis that impacts >>>>> existing implementations, option 2 seems attractive. Though other >>>>> folks may have other opinions or alternatives. >>>>> >>>> >>>> In the meeting, we also spoke about a new "STARTTLS" command code >>>> which >>>> optionally comes before the CER which *might* be completely backwards >>>> compatible. I had the impression that this had some support in the >>>> room. >>>> What do you think? >>>> >>> >>> Good point. I was contemplating it and that maybe a good 3rd option >>> which I failed to mention. In which case, we maybe able to define a >>> new extension document that negotiates security and uses a new >>> command code/avps as you mentioned. We may not need to do anything >>> with bis except update the security considerations section to >>> reflect the existing vulnerability and that extensions are available >>> to help. Is this a good approach ? >>> >>> regards, >>> victor >>> >>> >>>> Stefan >>>> >>>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 13:31:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7213A6C43; Tue, 25 Nov 2008 13:31:52 -0800 (PST) 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 825873A6C43 for ; Tue, 25 Nov 2008 13:31:51 -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_DE=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 u0AnSgUyDreG for ; Tue, 25 Nov 2008 13:31:50 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id BF5043A6AB9 for ; Tue, 25 Nov 2008 13:31:50 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id B031F1803F77D; Tue, 25 Nov 2008 22:31:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id A41371C05A23B; Tue, 25 Nov 2008 22:31:46 +0100 (CET) Date: Tue, 25 Nov 2008 22:31:46 +0100 (CET) From: Jan Engelhardt To: Jan Nordqvist In-Reply-To: <492C4C25.9070205@alcatel-lucent.com> Message-ID: References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Tuesday 2008-11-25 20:04, Jan Nordqvist wrote: > > In addition, using a predefined secured port will certainly create > challenges for SCTP over TLS. The CER/CEA setup method at least > lets the two SCTP peers negotiate in and out streams before > attempting to establish TLS over them. So it makes best sense to do TLS at the SCTP substream level so that you can have mixed encryption/nonencryption in an SCTP connection. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 13:47:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07FC628C1AD; Tue, 25 Nov 2008 13:47:52 -0800 (PST) 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 38B2728C1AD for ; Tue, 25 Nov 2008 13:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 nR5MugFOQ1vp for ; Tue, 25 Nov 2008 13:47:50 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 69FFC28C116 for ; Tue, 25 Nov 2008 13:47:50 -0800 (PST) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id jS8D1a0030FhH24A6ZnoXt; Tue, 25 Nov 2008 21:47:48 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id jZnm1a00X0sGXSz8UZnnvB; Tue, 25 Nov 2008 21:47:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=kwaOENA8wDcA:10 a=XPR3u3Bb0gsA:10 a=xk66pBYdXiEDBG1hhJIA:9 a=eBUK51Gmth72LeZeX8jHzXU3H-cA:4 a=3FZX-ydVlcEA:10 a=Mz_smNXqyOQA:10 From: "Glen Zorn" To: "'Jan Nordqvist'" References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> <492C5299.8080300@tari.toshiba.com> <492C6D2F.2040701@alcatel-lucent.com> In-Reply-To: <492C6D2F.2040701@alcatel-lucent.com> Date: Tue, 25 Nov 2008 13:47:10 -0800 Message-ID: <005601c94f47$5f77f860$1e67e920$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclPRFRzI+3qe5vKSK2xsctW+N0UkAAAp2QA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jan Nordqvist mailto://jnordqvist@alcatel-lucent.com] writes: > Hi Victor, > > The race condition occurs when two peers tries to connect to each other > at approximately the same time, i.e. before either side has detected an > incoming connection from the remote. This is obviously the issue that > the election process tries to deal with. Right, so it seems that the same technique could be used if both peers sent their hostnames in the StartTLS exchange. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 14:11:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B535328C1C0; Tue, 25 Nov 2008 14:11:47 -0800 (PST) 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 9743A28C1BF for ; Tue, 25 Nov 2008 14:11:46 -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 ARAwu77i9PeY for ; Tue, 25 Nov 2008 14:11:45 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 8B29628C1BC for ; Tue, 25 Nov 2008 14:11:44 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAPMBfvR018365 for ; Tue, 25 Nov 2008 16:11:41 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mAPMBZi8007590 for ; Tue, 25 Nov 2008 16:11:36 -0600 (CST) Received: from [192.168.0.38] (clover.8950aaa.com [192.168.0.38]) by hal.8950aaa.com (Postfix) with ESMTP id 2AF2858E38 for ; Tue, 25 Nov 2008 14:11:35 -0800 (PST) Message-ID: <492C7811.8020707@alcatel-lucent.com> Date: Tue, 25 Nov 2008 14:11:29 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: dime@ietf.org References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu><492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701A2A7D0@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E701A2A7D0@sonusmail04.sonusnet.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, It takes a capabilities exchange to determine who you (presumably) are communicating with and since SCTP streams parameters may be part of the peer definition, a predefined port won't allow this form of streams configuration. As far as I know the initial streams configuration cannot be renegotiated (correct me if I am wrong) within the same connection, so this would not allow per peer streams parameters. Regards, Jan. Asveren, Tolga wrote: > Jan, > > One question below. > > Thanks, > Tolga > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> > Of > >> Jan Nordqvist >> Sent: Tuesday, November 25, 2008 2:04 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Options for securing CER/CEA >> >> As I expressed in my previous email on this subject, item 2 is the >> > only > >> option that follows the P2P connection setup mechanism architected for >> Diameter and avoids unnecessary "cross handshaking" during race >> conditions. How important this is can be argued but it *could* be a >> concern for handhelds or other devices with limited processing >> > resources. > >> Another aspect of this is how may implementations out there already >> > have > >> a working implementation based on TLS after the Capabilities Exchange >> and I believe there are a few. At least our server has a complete and >> working implementation based on this mechanism. >> If the initial CER/CEA handshake contains only minimal information to >> get TLS going and another CER/CEA exchange is allowed to take place >> inside the encrypted tunnel (which it used to be and likely presents a >> minimal change to any existing implementation would it be reinstated), >> that initial CER/CEA *is* your start-TLS mechanism. >> >> In addition, using a predefined secured port will certainly create >> challenges for SCTP over TLS. The CER/CEA setup method at least lets >> > the > >> two SCTP peers negotiate in and out streams before attempting to >> establish TLS over them. There is an obvious lack of strong >> standardization text in this arena but there is still enough to >> interoperate TLS over SCTP using this method. >> > [TOLGA]Streams are negotiated during SCTP association establishment. > What does CER/CEA have to do with this? > >> So if the purpose of this thread is to collect opinions, my vote is >> > for > >> "p2p start-TLS", i.e. item 2, with the addition of a secondary >> > CER/CEA. > >> Jan Nordqvist >> Alcatel-Lucent 8950/AAA Product Group. >> >> Victor Fajardo wrote: >> >>> Hi Stefan, >>> >>> >>>> Hi, >>>> >>>> >>>> >>>>> 1. Define a new secured port for diameter used only for TLS. This >>>>> deprecates inband-security and moves TLS setup before any diameter >>>>> traffic is sent. Its the cleanest solution and would completely >>>>> > secure > >>>>> CER/CEA but it would have greater backward compatibility issues. >>>>> >>>>> 2. Redefine the semantics of inband-security. In this case, if >>>>> inband-security is set to TLS then it means the connecting peer >>>>> > must > >>>>> use TLS instead of treating inband-security as just an advertised >>>>> value. TLS setup will still be done after CER/CEA negotiation; the >>>>> > way > >>>>> its currently done. There will still be some backward >>>>> > compatibility > >>>>> issue but implementations may not require as much change as (1). >>>>> >>>>> Give the changes that's already been introduced in bis that >>>>> > impacts > >>>>> existing implementations, option 2 seems attractive. Though other >>>>> folks may have other opinions or alternatives. >>>>> >>>>> >>>> In the meeting, we also spoke about a new "STARTTLS" command code >>>> > which > >>>> optionally comes before the CER which *might* be completely >>>> > backwards > >>>> compatible. I had the impression that this had some support in the >>>> >> room. >> >>>> What do you think? >>>> >>>> >>> Good point. I was contemplating it and that maybe a good 3rd option >>> which I failed to mention. In which case, we maybe able to define a >>> new extension document that negotiates security and uses a new >>> command code/avps as you mentioned. We may not need to do anything >>> with bis except update the security considerations section to >>> > reflect > >>> the existing vulnerability and that extensions are available to >>> > help. > >>> Is this a good approach ? >>> >>> regards, >>> victor >>> >>> >>> >>>> Stefan >>>> >>>> >>>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 14:14:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7619728C1C4; Tue, 25 Nov 2008 14:14:17 -0800 (PST) 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 18DD928C1C4 for ; Tue, 25 Nov 2008 14:14:17 -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 JFwWatBxxqZM for ; Tue, 25 Nov 2008 14:14:16 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 524C828C1BC for ; Tue, 25 Nov 2008 14:14:16 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAPME8s1010592 for ; Tue, 25 Nov 2008 16:14:08 -0600 (CST) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id mAPME77v009315 for ; Tue, 25 Nov 2008 16:14:07 -0600 (CST) Received: from [192.168.0.38] (clover.8950aaa.com [192.168.0.38]) by hal.8950aaa.com (Postfix) with ESMTP id 6979F58E3D for ; Tue, 25 Nov 2008 14:14:07 -0800 (PST) Message-ID: <492C78A9.9070002@alcatel-lucent.com> Date: Tue, 25 Nov 2008 14:14:01 -0800 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "dime@ietf.org" References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I don't know or can think of any other way of doing TLS across multiple streams. Having a mixture of encrypted and non-encrypted streams seems like a less desirable set-up for me. - Jan. Jan Engelhardt wrote: > On Tuesday 2008-11-25 20:04, Jan Nordqvist wrote: > >> In addition, using a predefined secured port will certainly create >> challenges for SCTP over TLS. The CER/CEA setup method at least >> lets the two SCTP peers negotiate in and out streams before >> attempting to establish TLS over them. >> > > So it makes best sense to do TLS at the SCTP substream level > so that you can have mixed encryption/nonencryption in an > SCTP connection. > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 25 14:23:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA17128C1D1; Tue, 25 Nov 2008 14:23:01 -0800 (PST) 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 DB29628C1D0 for ; Tue, 25 Nov 2008 14:22:59 -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 iT62xl2jAwwc for ; Tue, 25 Nov 2008 14:22:58 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 813E028C1CF for ; Tue, 25 Nov 2008 14:22:58 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id mAPMMrP8006669; Tue, 25 Nov 2008 17:22:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 17:22:20 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701A2A835@sonusmail04.sonusnet.com> In-Reply-To: <492C7811.8020707@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Options for securing CER/CEA Thread-Index: AclPSryKJUddB0CLRWqaqt9apMimygAAEbrg References: <492C158B.7090400@tari.toshiba.com><492C162B.5040003@restena.lu><492C227F.2070202@tari.toshiba.com><492C4C25.9070205@alcatel-lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701A2A7D0@sonusmail04.sonusnet.com> <492C7811.8020707@alcatel-lucent.com> From: "Asveren, Tolga" To: "Jan Nordqvist" , Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jan, Number of streams desired is negotiated during SCTP association establishment in INIT/INIT-ACK chunks and for each direction the minimum is used and I am also not aware of a way to renegotiate number of streams. I understand that there is a need to know what the initial advertised value needs to be but I don't see why this needs to be per peer (an argument of "because peer-X does not support negotiating stream values" does not count IMHO. Peer-X needs to fix its SCTP implementation :-) ). It *may* (actually I even doubt that) make sense that the initially advertised value could be per target administrative domain but this is known in advance. Thanks, Tolga > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Jan Nordqvist > Sent: Tuesday, November 25, 2008 5:11 PM > To: dime@ietf.org > Subject: Re: [Dime] Options for securing CER/CEA > > Tolga, > > It takes a capabilities exchange to determine who you (presumably) are > communicating with and since SCTP streams parameters may be part of the > peer definition, a predefined port won't allow this form of streams > configuration. As far as I know the initial streams configuration cannot > be renegotiated (correct me if I am wrong) within the same connection, > so this would not allow per peer streams parameters. > > Regards, > Jan. > > Asveren, Tolga wrote: > > Jan, > > > > One question below. > > > > Thanks, > > Tolga > > > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > >> > > Of > > > >> Jan Nordqvist > >> Sent: Tuesday, November 25, 2008 2:04 PM > >> To: dime@ietf.org > >> Subject: Re: [Dime] Options for securing CER/CEA > >> > >> As I expressed in my previous email on this subject, item 2 is the > >> > > only > > > >> option that follows the P2P connection setup mechanism architected for > >> Diameter and avoids unnecessary "cross handshaking" during race > >> conditions. How important this is can be argued but it *could* be a > >> concern for handhelds or other devices with limited processing > >> > > resources. > > > >> Another aspect of this is how may implementations out there already > >> > > have > > > >> a working implementation based on TLS after the Capabilities Exchange > >> and I believe there are a few. At least our server has a complete and > >> working implementation based on this mechanism. > >> If the initial CER/CEA handshake contains only minimal information to > >> get TLS going and another CER/CEA exchange is allowed to take place > >> inside the encrypted tunnel (which it used to be and likely presents a > >> minimal change to any existing implementation would it be reinstated), > >> that initial CER/CEA *is* your start-TLS mechanism. > >> > >> In addition, using a predefined secured port will certainly create > >> challenges for SCTP over TLS. The CER/CEA setup method at least lets > >> > > the > > > >> two SCTP peers negotiate in and out streams before attempting to > >> establish TLS over them. There is an obvious lack of strong > >> standardization text in this arena but there is still enough to > >> interoperate TLS over SCTP using this method. > >> > > [TOLGA]Streams are negotiated during SCTP association establishment. > > What does CER/CEA have to do with this? > > > >> So if the purpose of this thread is to collect opinions, my vote is > >> > > for > > > >> "p2p start-TLS", i.e. item 2, with the addition of a secondary > >> > > CER/CEA. > > > >> Jan Nordqvist > >> Alcatel-Lucent 8950/AAA Product Group. > >> > >> Victor Fajardo wrote: > >> > >>> Hi Stefan, > >>> > >>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>>> 1. Define a new secured port for diameter used only for TLS. This > >>>>> deprecates inband-security and moves TLS setup before any diameter > >>>>> traffic is sent. Its the cleanest solution and would completely > >>>>> > > secure > > > >>>>> CER/CEA but it would have greater backward compatibility issues. > >>>>> > >>>>> 2. Redefine the semantics of inband-security. In this case, if > >>>>> inband-security is set to TLS then it means the connecting peer > >>>>> > > must > > > >>>>> use TLS instead of treating inband-security as just an advertised > >>>>> value. TLS setup will still be done after CER/CEA negotiation; the > >>>>> > > way > > > >>>>> its currently done. There will still be some backward > >>>>> > > compatibility > > > >>>>> issue but implementations may not require as much change as (1). > >>>>> > >>>>> Give the changes that's already been introduced in bis that > >>>>> > > impacts > > > >>>>> existing implementations, option 2 seems attractive. Though other > >>>>> folks may have other opinions or alternatives. > >>>>> > >>>>> > >>>> In the meeting, we also spoke about a new "STARTTLS" command code > >>>> > > which > > > >>>> optionally comes before the CER which *might* be completely > >>>> > > backwards > > > >>>> compatible. I had the impression that this had some support in the > >>>> > >> room. > >> > >>>> What do you think? > >>>> > >>>> > >>> Good point. I was contemplating it and that maybe a good 3rd option > >>> which I failed to mention. In which case, we maybe able to define a > >>> new extension document that negotiates security and uses a new > >>> command code/avps as you mentioned. We may not need to do anything > >>> with bis except update the security considerations section to > >>> > > reflect > > > >>> the existing vulnerability and that extensions are available to > >>> > > help. > > > >>> Is this a good approach ? > >>> > >>> regards, > >>> victor > >>> > >>> > >>> > >>>> Stefan > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > _______________________________________________ > 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 From dime-bounces@ietf.org Tue Nov 25 14:40:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D003A6C71; Tue, 25 Nov 2008 14:40:40 -0800 (PST) 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 8769A3A6C71 for ; Tue, 25 Nov 2008 14:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 wvDrY6juEmug for ; Tue, 25 Nov 2008 14:40:37 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id CA8923A6AA7 for ; Tue, 25 Nov 2008 14:40:37 -0800 (PST) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id jVHQ1a00Q17UAYkA1agbvs; Tue, 25 Nov 2008 22:40:35 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id jagZ1a00M0sGXSz8ZagauM; Tue, 25 Nov 2008 22:40:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=kwaOENA8wDcA:10 a=XPR3u3Bb0gsA:10 a=bjWPgBC3cisB-XubZuQA:9 a=ZF9qqzBpQMeDJP8KoAeWXQXZb98A:4 a=bAv3psboLzYA:10 a=Mz_smNXqyOQA:10 From: "Glen Zorn" To: "'Jan Engelhardt'" , "'Jan Nordqvist'" References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> In-Reply-To: Date: Tue, 25 Nov 2008 14:39:57 -0800 Message-ID: <007b01c94f4e$bf2ef9a0$3d8cece0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclPRTu3RrdOzLhoQ/KCzbLDhj9qPQACUedQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jan Engelhardt [mailto://jengelh@medozas.de] writes: ... > So it makes best sense to do TLS at the SCTP substream level > so that you can have mixed encryption/nonencryption in an > SCTP connection. I have no idea why this would desirable. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 01:44:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085903A691A; Wed, 26 Nov 2008 01:44:45 -0800 (PST) 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 AAA3B3A691A for ; Wed, 26 Nov 2008 01:44:43 -0800 (PST) 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 CMdohDskoPZJ for ; Wed, 26 Nov 2008 01:44:43 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 7F0923A68D1 for ; Wed, 26 Nov 2008 01:44:42 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id b39so1403625ugd.15 for ; Wed, 26 Nov 2008 01:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=e34WaXVokxAQWNWg2GaKhhXlH3AlTT6IMDqr60PfMNc=; b=VlGjXqpEI07JdyKD7RPm4+z25NrnkCelIs8LDqiUQ6C8Xdk5iW2Zq0pMmQKU18iV+0 0R0d6ALqd5VUu7vLPDuKMNNol+4iduWBTRu6B1j+szekfEJoWMg2Q7/GFtA1XDtJ2FEa yC6DTzSGKKzL49NxxZrPofKLhAU7KbrVqXjgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=tLeZhE1StRCWMilSjBBk7nypLJO7XiNkealBed+JeXQM3t6Js3HtfIKGQfjkgI0tpA UiFmd2ounRavGPraI7z1lNXyh+gulsyrZLSvrdh3X09PfuLymqD93wm7fdWr5Hok5+XE WuL64zKhnoSFdJgaTp6YqmBUaP9ztVKHpEu3M= Received: by 10.66.250.1 with SMTP id x1mr3449775ugh.4.1227692678356; Wed, 26 Nov 2008 01:44:38 -0800 (PST) Received: by 10.66.240.13 with HTTP; Wed, 26 Nov 2008 01:44:38 -0800 (PST) Message-ID: Date: Wed, 26 Nov 2008 10:44:38 +0100 From: "Thomas Lindgren" To: "Glen Zorn" In-Reply-To: <003301c94f36$d0d50720$727f1560$@net> MIME-Version: 1.0 References: <492C158B.7090400@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E701A2A7CF@sonusmail04.sonusnet.com> <492C55B9.4050801@tari.toshiba.com> <003301c94f36$d0d50720$727f1560$@net> Cc: dime@ietf.org Subject: Re: [Dime] OFFLINE: Re: Options for securing CER/CEA 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: , Content-Type: multipart/mixed; boundary="===============1713794742==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1713794742== Content-Type: multipart/alternative; boundary="----=_Part_20572_1438370.1227692678433" ------=_Part_20572_1438370.1227692678433 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Nov 25, 2008 at 8:48 PM, Glen Zorn wrote: > Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes: > > > Hi Tolga, > > > > > > > I would prefer 1. It is clean and straightforward. I guess 2. is not > > > really secure as Glen pointed out -unless I am missing something-. > > > > > > > Just in case you did not see it, what do you think about the 3rd option > > (already stated by Stefan and then Glenn) ? > > Just to be clear, I prefer #1 as well. > > I prefer #1 too. Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_20572_1438370.1227692678433 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Tue, Nov 25, 2008 at 8:48 PM, Glen Zorn <glenzorn@comcast.net> wrote:
Victor Fajardo [mailto://vfajardo@tari.toshiba.com] writes:

> Hi Tolga,
>
>
> > I would prefer 1. It is clean and straightforward. I guess 2. is not
> > really secure as Glen pointed out -unless I am missing something-.
> >
>
> Just in case you did not see it, what do you think about the 3rd option
> (already stated by Stefan and then Glenn) ?

Just to be clear, I prefer #1 as well.


I prefer #1 too.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd
 

------=_Part_20572_1438370.1227692678433-- --===============1713794742== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1713794742==-- From dime-bounces@ietf.org Wed Nov 26 05:47:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497463A6817; Wed, 26 Nov 2008 05:47:47 -0800 (PST) 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 B5BAE3A6800 for ; Wed, 26 Nov 2008 05:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 4d3Gnl8XwBCP for ; Wed, 26 Nov 2008 05:47:44 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 889513A63D3 for ; Wed, 26 Nov 2008 05:47:44 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAQDlN7I058578; Wed, 26 Nov 2008 08:47:24 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492D5378.60702@tari.toshiba.com> Date: Wed, 26 Nov 2008 08:47:36 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Jan Nordqvist References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> <492C5299.8080300@tari.toshiba.com> <492C6D2F.2040701@alcatel-lucent.com> In-Reply-To: <492C6D2F.2040701@alcatel-lucent.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jan, > > The race condition occurs when two peers tries to connect to each > other at approximately the same time, i.e. before either side has > detected an incoming connection from the remote. This is obviously the > issue that the election process tries to deal with. Sure. But for me this is independent of the security problem at hand .... anyway, I think most folks are in favor of option(1) and there should be no impact on existing election schemes regardless. > > I don't know what reasoning was behind the removal of the open state > CER/CEA, but at least in our implementation a secondary exchange would > have marginal impact. You may want to check the extensibility discussion regarding this. -- victor > > Regards, > Jan. > > Victor Fajardo wrote: >> Hi Jan, >> >>> As I expressed in my previous email on this subject, item 2 is the >>> only option that follows the P2P connection setup mechanism >>> architected for Diameter and avoids unnecessary "cross handshaking" >>> during race conditions. How important this is can be argued but it >>> *could* be a concern for handhelds or other devices with limited >>> processing resources. >> >> Just for my understanding, in which scenario would the possible race >> condition and cross handshaking occur. >> >>> >>> Another aspect of this is how may implementations out there already >>> have a working implementation based on TLS after the Capabilities >>> Exchange and I believe there are a few. At least our server has a >>> complete and working implementation based on this mechanism. >>> If the initial CER/CEA handshake contains only minimal information >>> to get TLS going and another CER/CEA exchange is allowed to take >>> place inside the encrypted tunnel (which it used to be and likely >>> presents a minimal change to any existing implementation would it be >>> reinstated), that initial CER/CEA *is* your start-TLS mechanism. >>> >>> In addition, using a predefined secured port will certainly create >>> challenges for SCTP over TLS. The CER/CEA setup method at least lets >>> the two SCTP peers negotiate in and out streams before attempting to >>> establish TLS over them. There is an obvious lack of strong >>> standardization text in this arena but there is still enough to >>> interoperate TLS over SCTP using this method. >>> >>> So if the purpose of this thread is to collect opinions, my vote is >>> for "p2p start-TLS", i.e. item 2, with the addition of a secondary >>> CER/CEA. >> >> Ok. Your vote is duly noted :) Just an additional query, your not too >> concerned about backward compatibility issues in the above scheme. >> Note that folks have already agreed to remove CER/CEA exchange in >> the open state which poses a problem with the secondary CER/CEA. >> >> One advantage I see in the third option (stated by Stefan) is that we >> maybe able decouple this issue from CER/CEA without imposing possible >> interoperability issues. >> >> regards, >> victor >> >>> >>> Jan Nordqvist >>> Alcatel-Lucent 8950/AAA Product Group. >>> >>> Victor Fajardo wrote: >>>> Hi Stefan, >>>> >>>>> Hi, >>>>> >>>>> >>>>>> 1. Define a new secured port for diameter used only for TLS. This >>>>>> deprecates inband-security and moves TLS setup before any diameter >>>>>> traffic is sent. Its the cleanest solution and would completely >>>>>> secure >>>>>> CER/CEA but it would have greater backward compatibility issues. >>>>>> >>>>>> 2. Redefine the semantics of inband-security. In this case, if >>>>>> inband-security is set to TLS then it means the connecting peer must >>>>>> use TLS instead of treating inband-security as just an advertised >>>>>> value. TLS setup will still be done after CER/CEA negotiation; >>>>>> the way >>>>>> its currently done. There will still be some backward compatibility >>>>>> issue but implementations may not require as much change as (1). >>>>>> >>>>>> Give the changes that's already been introduced in bis that impacts >>>>>> existing implementations, option 2 seems attractive. Though other >>>>>> folks may have other opinions or alternatives. >>>>>> >>>>> >>>>> In the meeting, we also spoke about a new "STARTTLS" command code >>>>> which >>>>> optionally comes before the CER which *might* be completely backwards >>>>> compatible. I had the impression that this had some support in the >>>>> room. >>>>> What do you think? >>>>> >>>> >>>> Good point. I was contemplating it and that maybe a good 3rd option >>>> which I failed to mention. In which case, we maybe able to define a >>>> new extension document that negotiates security and uses a new >>>> command code/avps as you mentioned. We may not need to do anything >>>> with bis except update the security considerations section to >>>> reflect the existing vulnerability and that extensions are >>>> available to help. Is this a good approach ? >>>> >>>> regards, >>>> victor >>>> >>>> >>>>> Stefan >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> > > _______________________________________________ > 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 From dime-bounces@ietf.org Wed Nov 26 07:25:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9FF3A699D; Wed, 26 Nov 2008 07:25:43 -0800 (PST) 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 8A3E23A699D for ; Wed, 26 Nov 2008 07:25:41 -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 zIRMtn9tET1m for ; Wed, 26 Nov 2008 07:25:40 -0800 (PST) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id 2F1AE3A6953 for ; Wed, 26 Nov 2008 07:25:39 -0800 (PST) Received: (qmail 23731 invoked from network); 26 Nov 2008 15:25:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mIN49XM1IAa0HTcM4tPzAmfLmdtZVuIh3ydcHrVE6h1zDV61S8rtBY5ImrJBq0pKyeVUlKPTQfwHhv9rWx5nCzTWVIHO5FoTk7dntza8AkKFT4+dOiC9F6ePIDj8bVTp0SBxeg9jZ71gNBA3amG2PhECeuxAxRQmuNt+fgaunl0= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 26 Nov 2008 15:25:37 -0000 X-YMail-OSG: cvs6cM8VM1lnhFdksbdCJ0M2PQbvylepktPomKZ.LaSgHS8cnnJhS89a4GJ1dDumPQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D6A73.4090502@rogers.com> Date: Wed, 26 Nov 2008 10:25:39 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Victor Fajardo References: <492C158B.7090400@tari.toshiba.com> <492C162B.5040003@restena.lu> <492C227F.2070202@tari.toshiba.com> <492C4C25.9070205@alcatel-lucent.com> <492C5299.8080300@tari.toshiba.com> <492C6D2F.2040701@alcatel-lucent.com> <492D5378.60702@tari.toshiba.com> In-Reply-To: <492D5378.60702@tari.toshiba.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Add my vote for #1. Anything else seems to open up a bid-down attack. Victor Fajardo wrote: > Hi Jan, > >> >> The race condition occurs when two peers tries to connect to each >> other at approximately the same time, i.e. before either side has >> detected an incoming connection from the remote. This is obviously the >> issue that the election process tries to deal with. > > Sure. But for me this is independent of the security problem at hand > .... anyway, I think most folks are in favor of option(1) and there > should be no impact on existing election schemes regardless. > >> >> I don't know what reasoning was behind the removal of the open state >> CER/CEA, but at least in our implementation a secondary exchange would >> have marginal impact. > > You may want to check the extensibility discussion regarding this. > > -- victor > >> >> Regards, >> Jan. >> >> Victor Fajardo wrote: >>> Hi Jan, >>> >>>> As I expressed in my previous email on this subject, item 2 is the >>>> only option that follows the P2P connection setup mechanism >>>> architected for Diameter and avoids unnecessary "cross handshaking" >>>> during race conditions. How important this is can be argued but it >>>> *could* be a concern for handhelds or other devices with limited >>>> processing resources. >>> >>> Just for my understanding, in which scenario would the possible race >>> condition and cross handshaking occur. >>> >>>> >>>> Another aspect of this is how may implementations out there already >>>> have a working implementation based on TLS after the Capabilities >>>> Exchange and I believe there are a few. At least our server has a >>>> complete and working implementation based on this mechanism. >>>> If the initial CER/CEA handshake contains only minimal information >>>> to get TLS going and another CER/CEA exchange is allowed to take >>>> place inside the encrypted tunnel (which it used to be and likely >>>> presents a minimal change to any existing implementation would it be >>>> reinstated), that initial CER/CEA *is* your start-TLS mechanism. >>>> >>>> In addition, using a predefined secured port will certainly create >>>> challenges for SCTP over TLS. The CER/CEA setup method at least lets >>>> the two SCTP peers negotiate in and out streams before attempting to >>>> establish TLS over them. There is an obvious lack of strong >>>> standardization text in this arena but there is still enough to >>>> interoperate TLS over SCTP using this method. >>>> >>>> So if the purpose of this thread is to collect opinions, my vote is >>>> for "p2p start-TLS", i.e. item 2, with the addition of a secondary >>>> CER/CEA. >>> >>> Ok. Your vote is duly noted :) Just an additional query, your not too >>> concerned about backward compatibility issues in the above scheme. >>> Note that folks have already agreed to remove CER/CEA exchange in >>> the open state which poses a problem with the secondary CER/CEA. >>> >>> One advantage I see in the third option (stated by Stefan) is that we >>> maybe able decouple this issue from CER/CEA without imposing possible >>> interoperability issues. >>> >>> regards, >>> victor >>> >>>> >>>> Jan Nordqvist >>>> Alcatel-Lucent 8950/AAA Product Group. >>>> >>>> Victor Fajardo wrote: >>>>> Hi Stefan, >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>>> 1. Define a new secured port for diameter used only for TLS. This >>>>>>> deprecates inband-security and moves TLS setup before any diameter >>>>>>> traffic is sent. Its the cleanest solution and would completely >>>>>>> secure >>>>>>> CER/CEA but it would have greater backward compatibility issues. >>>>>>> >>>>>>> 2. Redefine the semantics of inband-security. In this case, if >>>>>>> inband-security is set to TLS then it means the connecting peer must >>>>>>> use TLS instead of treating inband-security as just an advertised >>>>>>> value. TLS setup will still be done after CER/CEA negotiation; >>>>>>> the way >>>>>>> its currently done. There will still be some backward compatibility >>>>>>> issue but implementations may not require as much change as (1). >>>>>>> >>>>>>> Give the changes that's already been introduced in bis that impacts >>>>>>> existing implementations, option 2 seems attractive. Though other >>>>>>> folks may have other opinions or alternatives. >>>>>>> >>>>>> >>>>>> In the meeting, we also spoke about a new "STARTTLS" command code >>>>>> which >>>>>> optionally comes before the CER which *might* be completely backwards >>>>>> compatible. I had the impression that this had some support in the >>>>>> room. >>>>>> What do you think? >>>>>> >>>>> >>>>> Good point. I was contemplating it and that maybe a good 3rd option >>>>> which I failed to mention. In which case, we maybe able to define a >>>>> new extension document that negotiates security and uses a new >>>>> command code/avps as you mentioned. We may not need to do anything >>>>> with bis except update the security considerations section to >>>>> reflect the existing vulnerability and that extensions are >>>>> available to help. Is this a good approach ? >>>>> >>>>> regards, >>>>> victor >>>>> >>>>> >>>>>> Stefan >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >> >> _______________________________________________ >> 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 > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 10:02:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC46128C226; Wed, 26 Nov 2008 10:02:41 -0800 (PST) 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 21A0228C211 for ; Wed, 26 Nov 2008 10:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 FOF14VDhIZ1e for ; Wed, 26 Nov 2008 10:02:39 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 4B7BC28C224 for ; Wed, 26 Nov 2008 10:02:39 -0800 (PST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAQI2LiH060833; Wed, 26 Nov 2008 13:02:21 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492D8F3B.5000505@tari.toshiba.com> Date: Wed, 26 Nov 2008 13:02:35 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Victor Fajardo References: <492C158B.7090400@tari.toshiba.com> In-Reply-To: <492C158B.7090400@tari.toshiba.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > > 1. Define a new secured port for diameter used only for TLS. This > deprecates inband-security and moves TLS setup before any diameter > traffic is sent. Its the cleanest solution and would completely secure > CER/CEA but it would have greater backward compatibility issues. So far, more people are in favor of option (1) above. So if anybody has any new comments, objections, suggestions etc other than those already raised, pls speak up. Otherwise, we will move forward with the solution above. regards, victor PS: Many thanks to all the folks who have contributed to the discussion _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 11:00:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39103A6C4D; Wed, 26 Nov 2008 11:00:05 -0800 (PST) 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 36E443A6C4D for ; Wed, 26 Nov 2008 11:00:05 -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_DE=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 GvhTmjng8X87 for ; Wed, 26 Nov 2008 11:00:04 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 7CD2A3A68C7 for ; Wed, 26 Nov 2008 11:00:04 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id AA8B418036519; Wed, 26 Nov 2008 19:59:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id A29991C05A23B; Wed, 26 Nov 2008 19:59:58 +0100 (CET) Date: Wed, 26 Nov 2008 19:59:58 +0100 (CET) From: Jan Engelhardt To: Victor Fajardo In-Reply-To: <492D8F3B.5000505@tari.toshiba.com> Message-ID: References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Wednesday 2008-11-26 19:02, Victor Fajardo wrote: >> >> 1. Define a new secured port for diameter used only for TLS. This deprecates >> inband-security and moves TLS setup before any diameter traffic is sent. Its >> the cleanest solution and would completely secure CER/CEA but it would have >> greater backward compatibility issues. > > So far, more people are in favor of option (1) above. So if anybody has any new > comments, objections, suggestions etc other than those already raised, pls > speak up. Otherwise, we will move forward with the solution above. I pick number 3 (starttls command). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 11:29:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A3E28C210; Wed, 26 Nov 2008 11:29:43 -0800 (PST) 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 6260728C20C for ; Wed, 26 Nov 2008 11:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 d2VeJJeyPX8b for ; Wed, 26 Nov 2008 11:29:41 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 92E1D28C210 for ; Wed, 26 Nov 2008 11:29:41 -0800 (PST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAQJTObl061497; Wed, 26 Nov 2008 14:29:24 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492DA3A1.1050702@tari.toshiba.com> Date: Wed, 26 Nov 2008 14:29:37 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Jan Engelhardt References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org >>> 1. Define a new secured port for diameter used only for TLS. This deprecates >>> inband-security and moves TLS setup before any diameter traffic is sent. Its >>> the cleanest solution and would completely secure CER/CEA but it would have >>> greater backward compatibility issues. >>> >> So far, more people are in favor of option (1) above. So if anybody has any new >> comments, objections, suggestions etc other than those already raised, pls >> speak up. Otherwise, we will move forward with the solution above. >> > > I pick number 3 (starttls command). > that seems obvious already .... if there's nothing new we should move forward. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 14:32:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E4A28C25B; Wed, 26 Nov 2008 14:32:54 -0800 (PST) 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 53DAA28C254 for ; Wed, 26 Nov 2008 14:32:53 -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 9qdantL-BFYI for ; Wed, 26 Nov 2008 14:32:52 -0800 (PST) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by core3.amsl.com (Postfix) with SMTP id 594A828C24C for ; Wed, 26 Nov 2008 14:32:52 -0800 (PST) Received: (qmail 95051 invoked from network); 26 Nov 2008 22:32:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=L6liZzmjU96pcGtzIBZMvbcy3n7NNVvRUgA3qoyGLWvT2kJuA1zfydbarrQBphCtpg4+NJgta7OoCofaAeVbHy6LYD1BWg8NeGN376knPphlHeyDtQ+XOGVwQRbfar6id+37xZiow+GdGrpvwB5chTJZo0gXjsavgP/1H03I95k= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 26 Nov 2008 22:32:49 -0000 X-YMail-OSG: D3DoEjAVM1kmZrK6RkS8cPqkxGq7dtJXKj6DjZGbrwmX3ifnYl4CYli3cR2XCV6chw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DCE94.1070802@rogers.com> Date: Wed, 26 Nov 2008 17:32:52 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "dime@ietf.org" Subject: [Dime] Reference on routing problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Bernard Aboba suggested in the meeting we check out an RFC relating to the much-discussed second-pass stateful proxy routing problem. I believe my meeting notes caught the wrong number. Bernard, could you give that reference again? It seems to me one way of looking at the problem is that the session is being processed by a chain of stateful servers. The problem is to ensure that all messages of the session pass through the same set of stateful servers. The reason I started to think about things in this fashion is because Glen was concerned that if one of the stateful proxies goes down, a lot of sessions go down with it. Wouldn't that also happen with server failure? If not, wouldn't the same techniques work to cope with failure of a stateful proxy? Tom _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 16:59:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2713A6C8D; Wed, 26 Nov 2008 16:59:58 -0800 (PST) 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 3807328C0F2 for ; Wed, 26 Nov 2008 16:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 U75upT9xDwHN for ; Wed, 26 Nov 2008 16:59:56 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 72E713A6C8D for ; Wed, 26 Nov 2008 16:59:56 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id joj31a00H0x6nqcA90zuca; Thu, 27 Nov 2008 00:59:54 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id k0zr1a00H0sGXSz8Y0zs5x; Thu, 27 Nov 2008 00:59:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=ojSADC9T464A:10 a=rU1O-1HZZG6BPYb2t30A:9 a=AYEbiTw-RWo_QedfKl4A:7 a=0gGp82yvg096LS5oPvAejqoFePMA:4 a=Ma507JNFj8MA:10 a=DFZ4TeuG6JwA:10 From: "Glen Zorn" To: "'Tom Taylor'" References: <492DCE94.1070802@rogers.com> In-Reply-To: <492DCE94.1070802@rogers.com> Date: Wed, 26 Nov 2008 16:58:59 -0800 Message-ID: <000001c9502b$55e2c2f0$01a848d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AclQFusQ+C7ILdAJQ0qRVsC2KvoBdQAEglmQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Reference on routing problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tom Taylor [mailto://tom.taylor@rogers.com] writes: > Bernard Aboba suggested in the meeting we check out an RFC relating to > the > much-discussed second-pass stateful proxy routing problem. I believe my > meeting > notes caught the wrong number. Bernard, could you give that reference > again? > > It seems to me one way of looking at the problem is that the session is > being > processed by a chain of stateful servers. The problem is to ensure that > all > messages of the session pass through the same set of stateful servers. > The > reason I started to think about things in this fashion is because Glen > was > concerned that if one of the stateful proxies goes down, a lot of > sessions go > down with it. AFAICT, that problem is endemic to strict source routing in general: it makes the network extremely brittle in the face of even minor network problems. It doesn't really matter if it is enforced by stateful boxes in the path, a special AVP or whatever. As I've mentioned before, that's not my problem: if somebody wants to design a network that way, it's their problem. I prefer the stateful proxy method of providing this "functionality" (if necessary) because it requires no changes to the Diameter protocol. Basically, I'm opposed to breaking Diameter (more ;-) in order to help people who've designed broken networks. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 19:13:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15993A6806; Wed, 26 Nov 2008 19:13:04 -0800 (PST) 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 88EB93A6806 for ; Wed, 26 Nov 2008 19:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 CuVy+K5g1dkm for ; Wed, 26 Nov 2008 19:13:02 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id 9AD303A67AF for ; Wed, 26 Nov 2008 19:13:02 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id mAR39DT3009014; Thu, 27 Nov 2008 12:09:13 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id mAR39DcD019477; Thu, 27 Nov 2008 12:09:13 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id mAR39DGd019473; Thu, 27 Nov 2008 12:09:13 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id DC0444451; Thu, 27 Nov 2008 12:09:12 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id BBF204349; Thu, 27 Nov 2008 12:09:12 +0900 (JST) Message-ID: <492E0F42.4080803@nict.go.jp> Date: Thu, 27 Nov 2008 12:08:50 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Victor Fajardo References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> In-Reply-To: <492D8F3B.5000505@tari.toshiba.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, > So far, more people are in favor of option (1) above. So if anybody > has any new comments, objections, suggestions etc other than those > already raised, pls speak up. Otherwise, we will move forward with the > solution above. I just want to highlight the following fact for implementations: In case option 1 (separate port for TLS) is selected, it will change the validation of the credentials as described by 13.1. These credentials can not be verified at the time of TLS handshake, but the connection must be accepted, and the information saved until the CER/CEA is received. I think this may open a possibility of DoS-type attacks, since the TLS handshake is quite computational operation. I would be more in favor of a splitting the CER/CEA exchange in two messages. The first exchange would act as a STARTTLS command, by identifying each peers (and eventually doing the Election). The second exchange after the TLS is negotiated contains the remaining of the current CER/CEA: supported applications, product information, ... This allows to maintain a local configuration of what security mechanism must be used with what peer (IPsec, TLS) and reject a non-TLS protected connection with a peer for which the local configuration requires this mechanism. Any thoughts? Thanks, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 26 22:59:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DC23A6CC9; Wed, 26 Nov 2008 22:59:45 -0800 (PST) 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 BFEFB3A6CC9 for ; Wed, 26 Nov 2008 22:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 v8dIbJCg6uRc for ; Wed, 26 Nov 2008 22:59:44 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id D407A3A6CC8 for ; Wed, 26 Nov 2008 22:59:43 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id EB24FAB7C5; Thu, 27 Nov 2008 07:59:39 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id DAD58AF038; Thu, 27 Nov 2008 07:59:39 +0100 (CET) Message-ID: <492E455B.6050806@restena.lu> Date: Thu, 27 Nov 2008 07:59:39 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Sebastien Decugis References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> In-Reply-To: <492E0F42.4080803@nict.go.jp> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, > In case option 1 (separate port for TLS) is selected, it will change the > validation of the credentials as described by 13.1. These credentials > can not be verified at the time of TLS handshake, but the connection > must be accepted, and the information saved until the CER/CEA is received. > > I think this may open a possibility of DoS-type attacks, since the TLS > handshake is quite computational operation. > > I would be more in favor of a splitting the CER/CEA exchange in two > messages. The first exchange would act as a STARTTLS command, by > identifying each peers (and eventually doing the Election). Identifying a peer can not be trusted in this unprotected CER, right? So, for the sake of getting a TLS connection to the server (and subsequently a DoS attack based on that) any host could send forged peer IDs. So essentially, the same attack remains possible, regardless if a split CER is used or a separate port. > The second > exchange after the TLS is negotiated contains the remaining of the > current CER/CEA: supported applications, product information, ... > = The second CER would need to repeat everything that was in the first CER again since this one wasn't integrity-protected. > This allows to maintain a local configuration of what security mechanism > must be used with what peer (IPsec, TLS) and reject a non-TLS protected > connection with a peer for which the local configuration requires this > mechanism. > > Any thoughts? > = Wouldn't the same access restriction policy be achievable by using a firewall towards the TLS-secured port of the Diameter peer? Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 27 00:21:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DB73A6B82; Thu, 27 Nov 2008 00:21:18 -0800 (PST) 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 6B67B3A6B82 for ; Thu, 27 Nov 2008 00:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 EM6XQvzKEY-3 for ; Thu, 27 Nov 2008 00:21:16 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id 4A4FA3A6405 for ; Thu, 27 Nov 2008 00:21:16 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id mAR8HRkM016045; Thu, 27 Nov 2008 17:17:27 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id mAR8HRmF021176; Thu, 27 Nov 2008 17:17:27 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id mAR8HRDL021173; Thu, 27 Nov 2008 17:17:27 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 74E636F3D; Thu, 27 Nov 2008 17:17:26 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id DA5C36ECD; Thu, 27 Nov 2008 17:17:25 +0900 (JST) Message-ID: <492E5780.7070402@nict.go.jp> Date: Thu, 27 Nov 2008 17:17:04 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Stefan Winter References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> <492E455B.6050806@restena.lu> In-Reply-To: <492E455B.6050806@restena.lu> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, > Identifying a peer can not be trusted in this unprotected CER, right? > Right, but... > So, for the sake of getting a TLS connection to the server (and > subsequently a DoS attack based on that) any host could send forged peer > IDs. So essentially, the same attack remains possible, regardless if a > split CER is used or a separate port. > ... it allows anyway to do some simple filtering (such as "no more than 3 attempts within X seconds from this Diameter ID, and reject all unknown peers). Forging a DoS attack with such constaints becomes lot more difficult. >> The second >> exchange after the TLS is negotiated contains the remaining of the >> current CER/CEA: supported applications, product information, ... >> > The second CER would need to repeat everything that was in the first CER > again since this one wasn't integrity-protected. > I agree, but the first message would basically contains only the Origin-Host AVP and the (TBD) Start-TLS AVP, so its content will be repeated in every subsequent message anyway... > Wouldn't the same access restriction policy be achievable by using a > firewall towards the TLS-secured port of the Diameter peer? > Probably, yes. It means that when your Diameter topology changes, you have to update not only the Diameter configuration, but also the firewall configuration of your peers. IMHO it adds complexity to rely on another component for security, but I agree it is a possible solution. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 27 13:18:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DF93A6A6B; Thu, 27 Nov 2008 13:18:51 -0800 (PST) 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 002BC3A6A6B for ; Thu, 27 Nov 2008 13:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 Z9L28IugqxRg for ; Thu, 27 Nov 2008 13:18:49 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 3F0BE3A6A65 for ; Thu, 27 Nov 2008 13:18:49 -0800 (PST) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id kMC21a00D1GXsucA4MJm8m; Thu, 27 Nov 2008 21:18:46 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id kMJl1a0080sGXSz8TMJlcd; Thu, 27 Nov 2008 21:18:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=kwaOENA8wDcA:10 a=XPR3u3Bb0gsA:10 a=TLCGA-shOe1eiCpVGLkA:9 a=SJF5r1f1Z8MRtn8Z6Joc-IRr0JkA:4 a=BDXKcin-EtgA:10 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> In-Reply-To: <492E0F42.4080803@nict.go.jp> Date: Thu, 27 Nov 2008 13:18:44 -0800 Message-ID: <000f01c950d5$bba26cd0$32e74670$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclQPhD9yfuoN7NGRICPT2Ugd6JtXgAleWcQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > In case option 1 (separate port for TLS) is selected, it will change > the > validation of the credentials as described by 13.1. These credentials > can not be verified at the time of TLS handshake, but the connection > must be accepted, and the information saved until the CER/CEA is > received. > > I think this may open a possibility of DoS-type attacks, since the TLS > handshake is quite computational operation. The problem with this conjecture is that the credential "verification" is really no verification at all: the comparison is between a signed identity from a PK cert and an unprotected assertion of identity. I think that a DoS attack mounted by modifying the unprotected identity is more likely than one based upon the compute-intensity of the TLS handshake; if a peer doesn't have enough computing power to handle the handshake w/o falling over it has bigger problems ;-). ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 28 01:35:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E613A6879; Fri, 28 Nov 2008 01:35:29 -0800 (PST) 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 E65D73A6879 for ; Fri, 28 Nov 2008 01:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 uCXXPM31kUif for ; Fri, 28 Nov 2008 01:35:26 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id EBAF43A682F for ; Fri, 28 Nov 2008 01:35:25 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAS9Z1BN080390; Fri, 28 Nov 2008 04:35:01 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492FBB57.2060205@tari.toshiba.com> Date: Fri, 28 Nov 2008 04:35:19 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Glen Zorn References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> <000f01c950d5$bba26cd0$32e74670$@net> In-Reply-To: <000f01c950d5$bba26cd0$32e74670$@net> Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Sebastien, >> In case option 1 (separate port for TLS) is selected, it will change >> the >> validation of the credentials as described by 13.1. These credentials >> can not be verified at the time of TLS handshake, but the connection >> must be accepted, and the information saved until the CER/CEA is >> received. >> >> I think this may open a possibility of DoS-type attacks, since the TLS >> handshake is quite computational operation. >> > > The problem with this conjecture is that the credential "verification" is > really no verification at all: the comparison is between a signed identity > from a PK cert and an unprotected assertion of identity. I think that a DoS > attack mounted by modifying the unprotected identity is more likely than one > based upon the compute-intensity of the TLS handshake; if a peer doesn't > have enough computing power to handle the handshake w/o falling over it has > bigger problems ;-). > > ... > > > > I would agree with Glen in this case. If option 1 is performed, validation in Sec 13.1 is no longer necessary since your doing mutual authentication via TLS certs already. If you allow the TLS handshake to succeed but somehow you don't trust the credentials in the certs you received (... which is strange to begin with) then you have a bigger security issues outside of Diameter and no amount of CER/CEA exchanges will help you with that. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 28 01:51:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337A33A6AB2; Fri, 28 Nov 2008 01:51:42 -0800 (PST) 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 696C83A6AB5 for ; Fri, 28 Nov 2008 01:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 pp+udK-7skxB for ; Fri, 28 Nov 2008 01:51:39 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 911AD3A691E for ; Fri, 28 Nov 2008 01:51:39 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id mAS9pHQD080446; Fri, 28 Nov 2008 04:51:17 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <492FBF27.2020802@tari.toshiba.com> Date: Fri, 28 Nov 2008 04:51:35 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Sebastien Decugis References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> <492E455B.6050806@restena.lu> <492E5780.7070402@nict.go.jp> In-Reply-To: <492E5780.7070402@nict.go.jp> Cc: "dime@ietf.org" Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Sebastien, > >> Identifying a peer can not be trusted in this unprotected CER, right? >> >> > Right, but... > >> So, for the sake of getting a TLS connection to the server (and >> subsequently a DoS attack based on that) any host could send forged peer >> IDs. So essentially, the same attack remains possible, regardless if a >> split CER is used or a separate port. >> >> > ... it allows anyway to do some simple filtering (such as "no more than > 3 attempts within X seconds from this Diameter ID, and reject all > unknown peers). Forging a DoS attack with such constaints becomes lot > more difficult. > Do we really want to use Diameter protocol itself to prevent TLS DoS attacks ? This should be a general TLS/security issue that is independent of overlying protocol and that's why there's cryptographic work dedicated only to this issue. Otherwise its like forcing every other protocol that uses TLS to invent some sort of DoS prevention scheme. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 28 06:36:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F2D28C15F; Fri, 28 Nov 2008 06:36:31 -0800 (PST) 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 A7CF728C15F for ; Fri, 28 Nov 2008 06:36:30 -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 40f0I0QoPE-U for ; Fri, 28 Nov 2008 06:36:30 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id E127D28C15E for ; Fri, 28 Nov 2008 06:36:29 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 28 Nov 2008 09:36:26 -0500 From: Mark Jones To: "dime@ietf.org" Date: Fri, 28 Nov 2008 09:36:24 -0500 Thread-Topic: [Dime] Options for securing CER/CEA Thread-Index: AclRPvhCNtXk/7ZSS+KqtXrXP9vH9QAJQpmg Message-ID: References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> <492E455B.6050806@restena.lu> <492E5780.7070402@nict.go.jp> <492FBF27.2020802@tari.toshiba.com> In-Reply-To: <492FBF27.2020802@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org My vote goes to option 1 on this. Clean and straightforward as already stated. I'm not seeing the advantage of option 2 in terms of impact on existing implementations. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 28 09:11:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513443A67A7; Fri, 28 Nov 2008 09:11:48 -0800 (PST) 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 1BAFC3A67A7 for ; Fri, 28 Nov 2008 09:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TmcCwVFzjPD for ; Fri, 28 Nov 2008 09:11:46 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id E51043A676A for ; Fri, 28 Nov 2008 09:11:45 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 18:11:41 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Nov 2008 18:11:39 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026060A0A7A@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Options for securing CER/CEA Thread-index: AclRPvhCNtXk/7ZSS+KqtXrXP9vH9QAJQpmgAAXTg/A= References: <492C158B.7090400@tari.toshiba.com><492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp><492E455B.6050806@restena.lu> <492E5780.7070402@nict.go.jp><492FBF27.2020802@tari.toshiba.com> From: To: , X-OriginalArrivalTime: 28 Nov 2008 17:11:41.0785 (UTC) FILETIME=[61F28C90:01C9517C] Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org IMHO, based on the current discussion, saying that the backwards compatibil= ity is not a big issue in that case, especially when we are specifying a RF= C-bis, I consider "Option 1" as good and simple enough to be adopted. Optio= n 2, option 2-bis or option 3 do not provide significant added-value compar= ed to option 1 to be selected. Regards, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De = > la part de Mark Jones > Envoy=E9 : vendredi 28 novembre 2008 15:36 > =C0 : dime@ietf.org > Objet : Re: [Dime] Options for securing CER/CEA > = > My vote goes to option 1 on this. Clean and straightforward = > as already stated. I'm not seeing the advantage of option 2 = > in terms of impact on existing implementations. > = > Regards > Mark > _______________________________________________ > 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 From dime-bounces@ietf.org Sun Nov 30 18:00:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503F83A68C1; Sun, 30 Nov 2008 18:00:56 -0800 (PST) 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 68FCE28C19B for ; Sun, 30 Nov 2008 18:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 NjCOhwuF81OZ for ; Sun, 30 Nov 2008 18:00:54 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id EBB4B3A67EE for ; Sun, 30 Nov 2008 18:00:53 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id mB11v1ng015430; Mon, 1 Dec 2008 10:57:01 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id mB11v1eJ012978; Mon, 1 Dec 2008 10:57:01 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id mB11v1Zg012975; Mon, 1 Dec 2008 10:57:01 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 0C34A44CA; Mon, 1 Dec 2008 10:57:01 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id DD568441D; Mon, 1 Dec 2008 10:57:00 +0900 (JST) Message-ID: <49334456.4060706@nict.go.jp> Date: Mon, 01 Dec 2008 10:56:38 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Victor Fajardo References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> <000f01c950d5$bba26cd0$32e74670$@net> <492FBB57.2060205@tari.toshiba.com> In-Reply-To: <492FBB57.2060205@tari.toshiba.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Thank you for your answers. See my comment inline. Victor Fajardo a =E9crit : > > I would agree with Glen in this case. If option 1 is performed, > validation in Sec 13.1 is no longer necessary since your doing mutual > authentication via TLS certs already. If you allow the TLS handshake > to succeed but somehow you don't trust the credentials in the certs > you received (... which is strange to begin with) then you have a > bigger security issues outside of Diameter and no amount of CER/CEA > exchanges will help you with that. I understand the point now, thank you. I anyway wonder why this validation was suggested ("SHOULD") in the previous specification, since I think the same trust to TLS credentials already applied... Best regards, Sebastien. > > regards, > victor > > > -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 30 20:42:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD113A67EE; Sun, 30 Nov 2008 20:42:18 -0800 (PST) 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 7FC7E3A67EE for ; Sun, 30 Nov 2008 20:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 utroQXslNk1P for ; Sun, 30 Nov 2008 20:42:16 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 841B43A67B6 for ; Sun, 30 Nov 2008 20:42:16 -0800 (PST) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id lSxJ1a00N0mlR8UA2giD19; Mon, 01 Dec 2008 04:42:13 +0000 Received: from gwzPC ([67.170.97.40]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id lgiB1a00B0sGXSz8XgiCVZ; Mon, 01 Dec 2008 04:42:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=kwaOENA8wDcA:10 a=XPR3u3Bb0gsA:10 a=VjrYsxeIuwSRlgMElUUA:9 a=EsQ6ctNUpfqTbY9EFpFMwrYzUfkA:4 a=BDXKcin-EtgA:10 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <492C158B.7090400@tari.toshiba.com> <492D8F3B.5000505@tari.toshiba.com> <492E0F42.4080803@nict.go.jp> <000f01c950d5$bba26cd0$32e74670$@net> <492FBB57.2060205@tari.toshiba.com> <49334456.4060706@nict.go.jp> In-Reply-To: <49334456.4060706@nict.go.jp> Date: Sun, 30 Nov 2008 20:41:39 -0800 Message-ID: <00b501c9536f$1aa620a0$4ff261e0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclTWBwSLAmu0tr3R2mhRMMX0syDGQAE1FNQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Options for securing CER/CEA 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hi, > = > Thank you for your answers. See my comment inline. > = > Victor Fajardo a =E9crit : > > > > I would agree with Glen in this case. If option 1 is performed, > > validation in Sec 13.1 is no longer necessary since your doing mutual > > authentication via TLS certs already. If you allow the TLS handshake > > to succeed but somehow you don't trust the credentials in the certs > > you received (... which is strange to begin with) then you have a > > bigger security issues outside of Diameter and no amount of CER/CEA > > exchanges will help you with that. > I understand the point now, thank you. I anyway wonder why this > validation was suggested ("SHOULD") in the previous specification, > since > I think the same trust to TLS credentials already applied... True, but then I can't believe that (apparently) nobody noticed until now the problems with CER/CEA security 8-{. Any way, it's not a bad idea, although its actual purpose, I think, is authorization of the peer connection rather than verification of credentials. If only TLS supported them, the same (or a better) job could be done with attribute certs... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime