From bclaise@cisco.com Mon Sep 3 09:27:12 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC6F21F86B7 for ; Mon, 3 Sep 2012 09:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qin2T9i-24kv for ; Mon, 3 Sep 2012 09:27:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BE98B21F86B6 for ; Mon, 3 Sep 2012 09:27:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q83GR81G012322; Mon, 3 Sep 2012 18:27:09 +0200 (CEST) Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q83GR8W7006634; Mon, 3 Sep 2012 18:27:08 +0200 (CEST) Message-ID: <5044DA5B.10804@cisco.com> Date: Mon, 03 Sep 2012 18:27:07 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Glen Zorn References: <20120715054226.4612.98302.idtracker@ietfa.amsl.com> <500F08AF.4010102@cisco.com> <1343202545.7688.181.camel@gwz-laptop> In-Reply-To: <1343202545.7688.181.camel@gwz-laptop> Content-Type: multipart/alternative; boundary="------------070502000905080505050304" Cc: dime mailing list Subject: Re: [Dime] Fwd: New Version Notification - draft-ietf-dime-rfc4005bis-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 16:27:12 -0000 This is a multi-part message in MIME format. --------------070502000905080505050304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Glen, I'll progress the draft. Regards, Benoit. > On Tue, 2012-07-24 at 13:42 -0700, Benoit Claise wrote: >> Hi Glen, >> >> Thanks for this new version. >> Two points that need to be addressed. >> >> >> 1. It seems that you have forgotten what we agreed upon on the >> mailing list. >> >> How about this? >> >> OLD: >> 3. Diameter NAS Application Messages >> >> This section defines the Diameter message Command-Code >> [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all >> Diameter implementations conforming to this specification. The >> Command Codes are as follows: >> >> +-----------------------------------+---------+------+--------------+ >> | Command Name | Abbrev. | Code | >> Reference | >> +-----------------------------------+---------+------+--------------+ >> | AA-Request | AAR | 265 | Section >> 3.1 | >> | AA-Answer | AAA | 265 | Section >> 3.2 | >> | Re-Auth-Request | RAR | 258 | Section >> 3.3 | >> | Re-Auth-Answer | RAA | 258 | Section >> 3.4 | >> | Session-Termination-Request | STR | 275 | Section >> 3.5 | >> | Session-Termination-Answer | STA | 275 | Section >> 3.6 | >> | Abort-Session-Request | ASR | 274 | Section >> 3.7 | >> | Abort-Session-Answer | ASA | 274 | Section >> 3.8 | >> | Accounting-Request | ACR | 271 | Section >> 3.9 | >> | Accounting-Answer | ACA | 271 | Section >> 3.10 | >> +-----------------------------------+---------+------+--------------+ >> >> NEW: >> 3. Diameter NAS Application Messages >> >> This section defines the Diameter message Command-Code >> [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all >> Diameter implementations conforming to this specification. The >> Command Codes are as follows: >> >> +-----------------------------------+---------+------+--------------+ >> | Command Name | Abbrev. | Code | >> Reference | >> +-----------------------------------+---------+------+--------------+ >> | AA-Request | AAR | 265 | Section >> 3.1 | >> | AA-Answer | AAA | 265 | Section >> 3.2 | >> | Re-Auth-Request | RAR | 258 | Section >> 3.3 | >> | Re-Auth-Answer | RAA | 258 | Section >> 3.4 | >> | Session-Termination-Request | STR | 275 | Section >> 3.5 | >> | Session-Termination-Answer | STA | 275 | Section >> 3.6 | >> | Abort-Session-Request | ASR | 274 | Section >> 3.7 | >> | Abort-Session-Answer | ASA | 274 | Section >> 3.8 | >> | Accounting-Request | ACR | 271 | Section >> 3.9 | >> | Accounting-Answer | ACA | 271 | Section >> 3.10 | >> +-----------------------------------+---------+------+--------------+ >> >> Note that the message formats in the following sub-sections use >> the standard Diameter Command Code Format >> ([I-D.ietf-dime-rfc3588bis], Section 3.2). >> >> >> >> 2. To be complete, and to let the DIME WG know, let me include what >> we have exchanged in a private email regarding the IANA pointer for >> the application id 1. >> >> You asked for a statement and some consistency from the IESG. >> - statement: The reference should be where the item in question is >> documented, not what registered it. >> - consistency: right, we need to make this clear and not change it. >> Michelle Coton and Barry Leiba are working on an update to BCP 26 >> that will, in part, do just that, and you are welcome to comment on >> it when it's posted (during or shortly after IETF 84). >> >> I propose that you add an "IANA note" in the IANA security section of >> draft-ietf-dime-rfc4005bis-09.txt expressing something such as: as >> discussed with the IESG, application id 1 should point to >> >> >> >> Please include those two points in the next revision of the draft, >> and I'll progress the draft to IETF LC. > > I'll submit it Monday evening. > > ... --------------070502000905080505050304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Thanks Glen,

I'll progress the draft.

Regards, Benoit.
On Tue, 2012-07-24 at 13:42 -0700, Benoit Claise wrote:
Hi Glen,

Thanks for this new version.
Two points that need to be addressed.


1. It seems that you have forgotten what we agreed upon on the mailing list.

How about this?

OLD:
3.  Diameter NAS Application Messages

   This section defines the Diameter message Command-Code
   [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all
   Diameter implementations conforming to this specification.  The
   Command Codes are as follows:

   +-----------------------------------+---------+------+--------------+
   | Command Name                      | Abbrev. | Code | Reference    |
   +-----------------------------------+---------+------+--------------+
   | AA-Request                        |   AAR   |  265 | Section 3.1  |
   | AA-Answer                         |   AAA   |  265 | Section 3.2  |
   | Re-Auth-Request                   |   RAR   |  258 | Section 3.3  |
   | Re-Auth-Answer                    |   RAA   |  258 | Section 3.4  |
   | Session-Termination-Request       |   STR   |  275 | Section 3.5  |
   | Session-Termination-Answer        |   STA   |  275 | Section 3.6  |
   | Abort-Session-Request             |   ASR   |  274 | Section 3.7  |
   | Abort-Session-Answer              |   ASA   |  274 | Section 3.8  |
   | Accounting-Request                |   ACR   |  271 | Section 3.9  |
   | Accounting-Answer                 |   ACA   |  271 | Section 3.10 |
   +-----------------------------------+---------+------+--------------+

NEW:
3.  Diameter NAS Application Messages

   This section defines the Diameter message Command-Code
   [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all
   Diameter implementations conforming to this specification.  The
   Command Codes are as follows:

   +-----------------------------------+---------+------+--------------+
   | Command Name                      | Abbrev. | Code | Reference    |
   +-----------------------------------+---------+------+--------------+
   | AA-Request                        |   AAR   |  265 | Section 3.1  |
   | AA-Answer                         |   AAA   |  265 | Section 3.2  |
   | Re-Auth-Request                   |   RAR   |  258 | Section 3.3  |
   | Re-Auth-Answer                    |   RAA   |  258 | Section 3.4  |
   | Session-Termination-Request       |   STR   |  275 | Section 3.5  |
   | Session-Termination-Answer        |   STA   |  275 | Section 3.6  |
   | Abort-Session-Request             |   ASR   |  274 | Section 3.7  |
   | Abort-Session-Answer              |   ASA   |  274 | Section 3.8  |
   | Accounting-Request                |   ACR   |  271 | Section 3.9  |
   | Accounting-Answer                 |   ACA   |  271 | Section 3.10 |
   +-----------------------------------+---------+------+--------------+

Note that the message formats in the following sub-sections use the standard Diameter Command Code Format ([I-D.ietf-dime-rfc3588bis], Section 3.2).


2. To be complete, and to let the DIME WG know, let me include what we have exchanged in a private email regarding the IANA pointer for the application id 1.

You asked for a statement and some consistency from the IESG.
- statement: The reference should be where the item in question is documented, not what registered it.
- consistency: right, we need to make this clear and not change it. Michelle Coton and Barry Leiba are working on an update to BCP 26 that will, in part, do just that, and you are welcome to comment on it when it's posted (during or shortly after IETF 84).

I propose that you add an "IANA note" in the IANA security section of draft-ietf-dime-rfc4005bis-09.txt expressing something such as: as discussed with the IESG, application id 1 should point to <RFC4005bis.>



Please include those two points in the next revision of the draft, and I'll progress the draft to IETF LC.

I'll submit it Monday evening.

...

--------------070502000905080505050304-- From jouni.nospam@gmail.com Tue Sep 4 00:15:47 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80F121F8513 for ; Tue, 4 Sep 2012 00:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQbM3i-RxJgq for ; Tue, 4 Sep 2012 00:15:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D626B21F8470 for ; Tue, 4 Sep 2012 00:15:46 -0700 (PDT) Received: by eaai11 with SMTP id i11so1812471eaa.31 for ; Tue, 04 Sep 2012 00:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=VAi2fGwSySMszgjg7Txi7/2oeP5kdTtzJZcNs4HyARc=; b=YtqnBGvs4+w+fHUqz+jcMotj305gpSCvRwDnuMRjGj3QYRJYir5nNa4OhedjAkTjJ5 DLBiKwDyn5Yx37uSP+BmnaLnQ31mtD9O94tzKtVEOnCJhS6LbhQv7uSdxUtpf20pUS3N aaoU/8I3XRcKjHKt4pyX0xKPrVG9xrurrJG/P5fz2s+M/M+CeiFezoAlVUGum4xspRhI 8Tg/6y+xx6LDmMNCtwUrCjOSGwTlPrR/LcFw3uMaxAa6NpL5ZwGubKHoj/5hCHcKHpFK C3+WJpkn8Agqdptu12NFpJQpjflrPR4LSfS9ABHL3CY5tmvGrIWlAcjz4yXKi37vqiF7 Dxqg== Received: by 10.14.225.200 with SMTP id z48mr24600472eep.39.1346742945815; Tue, 04 Sep 2012 00:15:45 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id h2sm42786191eeo.3.2012.09.04.00.15.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 00:15:44 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 4 Sep 2012 10:15:42 +0300 Message-Id: <1BB474D6-DE82-4C2F-8C88-105B4377E49A@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dime-app-design-guide@tools.ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 07:15:48 -0000 The WGLC ended for the design guidelines document last week. We got a couple of extensive reviews: http://www.ietf.org/mail-archive/web/dime/current/msg05333.html http://www.ietf.org/mail-archive/web/dime/current/msg05331.html The authors should address the comments and post a revision. Once the new revision is out, we'll determine whether the changes were large enough that we need to run another WGLC. None of the posted issues were entered into the issue tracker so I recon there were no major blocking issues. - Jouni From iesg-secretary@ietf.org Tue Sep 4 08:51:36 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1222121F8674; Tue, 4 Sep 2012 08:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2tYUUpQF3xm; Tue, 4 Sep 2012 08:51:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CED21F8498; Tue, 4 Sep 2012 08:51:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120904155135.17976.44392.idtracker@ietfa.amsl.com> Date: Tue, 04 Sep 2012 08:51:35 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Network Access Server Application) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 04 Sep 2012 15:51:36 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Network Access Server Application' as 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 2012-09-18. 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. Abstract This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/ballot/ No IPR declarations have been submitted directly on this I-D. From jouni.nospam@gmail.com Wed Sep 5 00:38:30 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ACE21F844C for ; Wed, 5 Sep 2012 00:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMCMRxuj6MHl for ; Wed, 5 Sep 2012 00:38:29 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5639721F84C8 for ; Wed, 5 Sep 2012 00:38:29 -0700 (PDT) Received: by eekb45 with SMTP id b45so75945eek.31 for ; Wed, 05 Sep 2012 00:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=9hZp/FIGbUOzKfacmj7QWqiumiFJMDpkS6TdLnfucjo=; b=j0Lh76OmtXeMGgUl5psFN5Lm1pA1ivVYYCL+pCAS2xDSBNuBg71DO3+MN1vIsFP8op cFzJu4EQNYnyutCo5jS5QJEbXg12+zZmre2m7u1lQFmrzKK1Bg99cIKCSXc1ZUSYlV2T hfMYDhnFS3PK5D+gQ0pLEiPH0nLGKb4YNWPYZGP1KQ+OvHm5GRc/h7Nrohjho+qAuKVc qv5p0VVQ4yTMObNoKaWIlFOMrI+5/XhitfXe0bWF6nqdSLkXvzoLwsuBFqW12uZTfQ5p P6bgDbVN1xUUV+mOLfrYGOrM4iBvOJtJ9XuxwjtctINlN9K4Vp63+ltb2yvLa9tcBn9W FsZw== Received: by 10.14.224.4 with SMTP id w4mr29632431eep.21.1346830708531; Wed, 05 Sep 2012 00:38:28 -0700 (PDT) Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id l42sm1859594eep.1.2012.09.05.00.38.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 00:38:27 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 5 Sep 2012 10:38:25 +0300 Message-Id: <87E87DDF-35A9-4EB4-BDED-62657A65B364@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] About the recent charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:38:30 -0000 Folks, Some of you might have noticed that the latest charter text is not the piece of text we ended up to in the mailing list: http://www.ietf.org/mail-archive/web/dime/current/msg05326.html This was a result of the chairs being sluggish asking comments for the proposed charter text (cough) and the rest of the IESG process being surprisingly agile, thus an intermediate snapshot of the text slipped into the process. We apologize for the mess. Except for a slightly less fine tuned wording no harm was done. I'd think we can live with the current text. Milestones for the overload requirements will eventually change from standards track to informational (as that part can be done now with minor effort). What comes to new additional charter items, we can resume the discussion and see during the November meeting where we are. - Jouni & Lionel From bclaise@cisco.com Wed Sep 5 00:42:17 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A602F21F8441 for ; Wed, 5 Sep 2012 00:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.531 X-Spam-Level: X-Spam-Status: No, score=-8.531 tagged_above=-999 required=5 tests=[AWL=3.467, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5beZVFd1A1Y for ; Wed, 5 Sep 2012 00:42:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0408221F8550 for ; Wed, 5 Sep 2012 00:42:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q857g5To009371; Wed, 5 Sep 2012 09:42:05 +0200 (CEST) Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q857g415002001; Wed, 5 Sep 2012 09:42:04 +0200 (CEST) Message-ID: <5047024C.5070806@cisco.com> Date: Wed, 05 Sep 2012 09:42:04 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dime mailing list References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------020306080509020904020402" Cc: xkiranj.1980@gmail.com Subject: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:42:17 -0000 This is a multi-part message in MIME format. --------------020306080509020904020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, This errata has been submitted. While this looks right me, I always prefer to have a confirmation from the experts... Regards, Benoit. -------- Original Message -------- Subject: Re: [Editorial Errata Reported] RFC4006 (3329) Date: Thu, 23 Aug 2012 12:00:03 +0200 From: Kiran Jadhav To: RFC Errata System CC: Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, david@mitton.com Hello All, I have reported an Editorial Errata for RFC4006. This small editorial errata in the RFC4006 is causing issues in some call scenarios where the end user is given an option by the Service Provider to replenish his credit if it is found at the start of a call that the end-user's account balance is zero/insufficient. This is basically due to mis-interpretation of the sentence in the RFC by different vendors. Please have a look at the suggested change which will help a common implementation of the behavior across all vendors. Best Regards, Kiran Jadhav On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System > wrote: The following errata report has been submitted for RFC4006, "Diameter Credit-Control Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=3329 -------------------------------------- Type: Editorial Reported by: Kiran Jadhav > Section: 5.6.2 Original Text ------------- " Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A." Corrected Text -------------- " Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A." Notes ----- In the sentence "The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is not clear whether the sentence refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=0 (Granted-Service-Unit AVP with value 0". Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=0. This causes the call to enter a loop and terminate with an error. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4006 (draft-ietf-aaa-diameter-cc-06) -------------------------------------- Title : Diameter Credit-Control Application Publication Date : August 2005 Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG --------------020306080509020904020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

This errata has been submitted.
While this looks right me, I always prefer to have a confirmation from the experts...

Regards, Benoit.


-------- Original Message --------
Subject: Re: [Editorial Errata Reported] RFC4006 (3329)
Date: Thu, 23 Aug 2012 12:00:03 +0200
From: Kiran Jadhav <xkiranj.1980@gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
CC: Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, david@mitton.com


Hello All,

I have reported an Editorial Errata  for RFC4006.

This small editorial errata in the RFC4006 is causing issues in some call scenarios where the end user is given an option by the Service Provider to replenish his credit if it is found at the start of a call that the end-user's account balance is zero/insufficient. This is basically due to mis-interpretation of the sentence in the RFC by different vendors.

Please have a look at the suggested change which will help a common implementation of the behavior across all vendors.

Best Regards,
Kiran Jadhav

On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=3329

--------------------------------------
Type: Editorial
Reported by: Kiran Jadhav <xkiranj.1980@gmail.com>

Section: 5.6.2

Original Text
-------------
" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Corrected Text
--------------
" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Notes
-----
In the sentence "The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is not clear whether the sentence refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=0 (Granted-Service-Unit AVP with value 0".

Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=0. This causes the call to enter a loop and terminate with an error.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title               : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG




--------------020306080509020904020402-- From bclaise@cisco.com Tue Sep 4 05:58:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE53D21F863F for ; Tue, 4 Sep 2012 05:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGl8DDnTOx7E for ; Tue, 4 Sep 2012 05:58:26 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 014D321F863C for ; Tue, 4 Sep 2012 05:58:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q84CwLtf018586; Tue, 4 Sep 2012 14:58:21 +0200 (CEST) Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q84CwJlp014640; Tue, 4 Sep 2012 14:58:20 +0200 (CEST) Message-ID: <5045FAEA.4010503@cisco.com> Date: Tue, 04 Sep 2012 14:58:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Glen Zorn , dime mailing list References: <50161436.8080900@bbiw.net> In-Reply-To: <50161436.8080900@bbiw.net> X-Forwarded-Message-Id: <50161436.8080900@bbiw.net> Content-Type: multipart/alternative; boundary="------------020802080904080003040108" X-Mailman-Approved-At: Wed, 05 Sep 2012 08:17:18 -0700 Subject: [Dime] Fwd: Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 12:58:32 -0000 This is a multi-part message in MIME format. --------------020802080904080003040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Glen, DIME WG, Can you please address/answer Dave's points in his initial email. Regards, Benoit. -------- Original Message -------- Subject: Review of: draft-ietf-dime-rfc4005bis-09 Date: Sun, 29 Jul 2012 21:57:26 -0700 From: Dave Crocker Organisation: Brandenburg InternetWorking To: apps-discuss@ietf.org, draft-ietf-dime-rfc4005bis.all@tools.ietf.org CC: iesg G'day. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dime-rfc4005bis-09 Title: Diameter Network Access Server Application Reviewer: Dave Crocker Review Date: 18 June 2012 Summary: This draft continues problems from the original, at a minimum lacking definitions of terms, citation or definition of notational conventions, apparent normative redundancy with base documents. Major Issues: Active vs. passive voice -- the documents use of passive voice greatly expands the verbiage but also sometimes make it difficult to discern which participating entity is the identified actor. Apparently redundant normative text -- this document appears to contain restatements of normative text from the base Diameter document. This is extremely poor practice, since it invites divergence. Possibly inconsistent use of terminology -- Some of the terms used appear to have equivalent meaning but are not defines; to the extent that they are meant to have different meaning I could not tell what that was. Most significantly, it appears that this document cannot readily be read without very deep familiarity with other Diameter documentation, making this nearly an appendix to those. At the least, the dependencies should be made explicit and detailed. The Introduction's opening paragraph might have been thought to take care of this requirement, but it doesn't, at least not for me. For one thing, it isn't phrase so as to accomplish this. For another, the references are to entire documents, implying -- but not saying -- don't read this until you are deeply familiar with all of these other documents. The broader comments appear to apply to the original documents as well as this (and related) current ones. It's likely that making changes accordingly would be a major effort. Whether that's worth the effort isn't something I can judge. I think the revisions would make for tighter, clearer specifications that are probably easier to maintain, but I can't offer an opinion about the benefit this would have in terms of existing implementers or better market adoption, since I'm not familiar with Diameter's degree of market penetration nor the skills of those who have (or might) adopt it. Minor Issues: -- Nits: -- Detailed comments: > Network Working Group G. Zorn, Ed. > Internet-Draft Network Zen > Obsoletes: 4005 (if approved) May 18, 2012 > Intended status: Standards Track > Expires: November 19, 2012 > > > Diameter Network Access Server Application > draft-ietf-dime-rfc4005bis-09 > > Abstract > > This document describes the Diameter protocol application used for When summarizing the nature or purpose of a document, it is best for the abstract and Introduction to use different words than are in the title. Simply repeating the language of the title does not explain the title. The simple rule should be to assume that the new reader does not automatically understand the meaning of the title. In this case, I also have no idea what "the Diameter protocol application" means here. "protocol application" is not typical phrasing. Does it really mean that details are being specified for software implementation of Diameter at the server? Typically, the IETF does not specify details about software implementation, nevermind put such a specification on the standards track. (And, yes, I see that this is a -bis document; but that does not change the underlying concern.) What is the motivation for this version of the document? What problems or improvements are being provided? That is, why was it worth the effort to revise the previous document? These are not explained in the bis document. > Authentication, Authorization, and Accounting (AAA) services in the > Network Access Server (NAS) environment; it obsoletes RFC 4005. When > combined with the Diameter Base protocol, Transport Profile, and > Extensible Authentication Protocol specifications, this application > specification satisfies typical network access services requirements. ... > 1. Introduction > > This document describes the Diameter protocol application used for > AAA in the Network Access Server (NAS) environment. When combined > with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], Transport > Profile [RFC3539], and EAP [RFC4072] specifications, this > specification satisfies the NAS-related requirements defined in > Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169]. This assertion raises a dilemma: The cited documents are extensive and the topic(s?) complex. There is no way to know what details are being referred to, to evaluate the assertion. Worse, fixing this deficiency is certain to be a large effort. > First, this document describes the operation of a Diameter NAS > application. What is "a Diameter NAS application"? It does not seem to be explained in this document, nor is there a citation to its definition. > Then it defines the Diameter message Command-Codes. > The following sections list the AVPs used in these messages, grouped AVPs? Define acronyms when they are introduced. Explain their meaning. If the acronym is not destined for regular use within the document, consider replacing the acronym with the full term. If this document is a case of "this document only makes sense when you are intimately familiar with these other documents", then specify those other documents. As the document stands now, it does not formally citte foundational documents, although it does seem to rely on some. In general, this document's frequent use of "AVP" appears to be an oddly syntactic focus. Typical specifications refer to attributes, without such frequent, explicit reference to the form of their having values. On its own, this point could seem like quibbling, but it's part of the reaction I had when reading the document, that is seemed less accessible than one would wish for a new reader. > by common usage. These are session identification, authentication, > authorization, tunneling, and accounting. The authorization AVPs are > further broken down by service type. This document appears to require deep knowledge of The Diameter Base Protocol. In reality, I don't think this document can be meaningfully read without that knowledge. So this document should say that. (The language in the first paragraph of the Intro doesn't actually say it.) > 1.1. Changes from RFC 4005 > > This document obsoletes RFC 4005 and is not backward compatible with > that document. An overview of some the major changes are given > below. "not backward compatible" automatically raises basic questions about transition from old to new and support during an extended transition. The word 'transition' does not appear in this document. > o All of the material regarding RADIUS/Diameter protocol > interactions has been removed. > > o The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for the presumably the references to I-Ds need to be changed for RFC publication? > Accounting-Request and Accounting-Answer messages has been changed > to explicitly require the inclusion of the Acct-Application-Id AVP > and exclude the Vendor-Specific-Application-Id AVP. Normally, > this type of change would also require the allocation of a new > command code and consequently, a new application-id (See Section > 1.3.3 of [I-D.ietf-dime-rfc3588bis]). However, the presence of an > instance of the Acct-Application-Id AVP was required in RFC 4005, > as well: > > The ACR message [BASE] is sent by the NAS to report its session > information to a target server downstream. > > Either of Acct-Application-Id or Vendor-Specific-Application-Id > AVPs MUST be present. If the Vendor-Specific-Application-Id > grouped AVP is present, it must have an Acct-Application-Id > inside. > > Thus, though the syntax of the commands has changed, the semantics > have not (with the caveat that the Acct-Application-Id AVP can no > longer be contained in the Vendor-Specific-Application-Id AVP). Sounds oddly disruptive. /Why/ has the syntax been changed? What problem is this solving? > > > > > Zorn Expires November 19, 2012 [Page 5] > > Internet-Draft Diameter NASREQ May 2012 > > > o The lists of RADIUS attribute values have been deleted in favor of > references to the appropriate IANA registries. > > o The accounting model to be used is now specified. > > There are many other many miscellaneous fixes that have been > introduced in this document that may not be considered significant > but they are useful nonetheless. Examples are fixes to example IP Useful, but not significant. Interesting concept. Perhaps what is meant is not major or not substantive or not normative? > addresses, addition of clarifying references, etc. All of the errata > previously filed against RFC 4005 have been fixed. A comprehensive > list of changes is not shown here for practical reasons. > > 1.2. Terminology > > Section 1.2 of the base Diameter specification > [I-D.ietf-dime-rfc3588bis] defines most of the terminology used in > this document. Additionally, the following terms and acronyms are > used in this application: > > NAS (Network Access Server) > A device that provides an access service for a user to a network. > The service may be a network connection or a value-added service > such as terminal emulation [RFC2881]. Do not define a term by re-using the words in the term. In this case, even a word as obvious as 'access' could mean a variety of things. Everything is "a network connection". Perhaps the distinction here is between host-level attachment service, versus user-level application service? I can't tell. ... > VPN (Virtual Private Network) > In this document, this term is used to describe access services > that use tunneling methods. Since VPN is a well-entrenched, standard term of art, it seems odd -- and likely counterproductive -- to imply that use in this document will be non-standard, especially since the definition provided seems on a par with usual definitions, such as wikipedia's. > 1.4. Advertising Application Support > > Diameter nodes conforming to this specification MUST advertise > support by including the value of one (1) in the Auth-Application-Id > of the Capabilities-Exchange-Request (CER) message. "this specification' -> this version of specification [???] There is no other reference to the CER message in this document. As such, it's not clear what context for the message is meant. Offhand, it appears that advertising support of the spec is made during a session that implements the spec? This seems at least odd. Since this version of the spec uses a different syntax, it's not likely that any implementation will be speaking a different version of the protocol. > 1.5. Application Identification > > When used in this application, the Auth-Application-Id AVP MUST be > set to the value one (1) in the following messages > > o AA-Request (Section 3.1) > > > > > > Zorn Expires November 19, 2012 [Page 7] > > Internet-Draft Diameter NASREQ May 2012 > > > o Re-Auth-Request(Section 3.3) > > o Session-Termination-Request (Section 3.5) > > o Abort-Session-Request (Section 3.7) > > 1.6. Accounting Model > > It is RECOMMENDED that the coupled accounting model (Section 9.3 of > [I-D.ietf-dime-rfc3588bis]) be used with this application; therefore, > the value of the Acct-Application-Id AVP in the Accounting-Request > (Section 3.10) and Accounting-Answer (Section 3.9) messages SHOULD be > set to one (1). All of the values in those two sections (except the "271") are symbolic. As such, setting a value to "1" has no obvious meaning. I assume that the issue would be fixed by using symbolic values here? > 2. NAS Calls, Ports, and Sessions > > The arrival of a new call or service connection at a port of a "a port"? is this a reference to a transport-level port? That's the only use of the word in the base diameter document. What is a 'call' and what does it mean for it to "arrive", in this context? How is it different from a service connection? The word 'call' in the base document does not have a usage that seems relevant here. Is this document really trying to specify how a host dispatches a server? If so, that means it's discussing implementation details rather than protocol details. > Network Access Server (NAS) starts a Diameter NAS message exchange. I would guess that the Diameter-level initiation of a NAS message exchange is caused by a Diameter-level message, not the transport connection it triggers. If so, what message would that be? > Information about the call, the identity of the user, and the user's The base Diameter document does not specify the concept of a 'call'. > authentication information are packaged into a Diameter AA-Request > (AAR) message and sent to a server. > > The server processes the information and responds with a Diameter AA- "processes the information"? What does this mean, in protocol interoperability terms? I'd expect some statement about the semantics of the processes, relative to the overall exchange. > Answer (AAA) message that contains authorization information for the > NAS, or a failure code (Result-Code AVP). A value of > DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication > exchange, and several AAR and AAA messages may be exchanged until the > transaction completes. "may"? This paragraph appears to be largely redundant with the base Diameter document. Redundancy like this invites divergence over time and ambiguity about which text is controlling. > Depending on the value of the Auth-Request-Type AVP, the Diameter The reader is supposed to guess what values produce what results or actions? I don't see the choices/mappings/whatever documented. > 3.1. AA-Request (AAR) Command > > The AA-Request (AAR), which is indicated by setting the Command-Code > field to 265 and the 'R' bit in the Command Flags field, is used to > request authentication and/or authorization for a given NAS user. The text provides detail about the internals of the AAR, but doesn't say who sends it. By the way, does the AA- mean Authentication/Authorization? That's implied but not stated. Since the labels are symbolic, mnemonic utility is improved by explaining the basis of the string. > The type of request is identified through the Auth-Request-Type AVP > [I-D.ietf-dime-rfc3588bis] The recommended value for most situations > is AUTHORIZE_AUTHENTICATE. > > If Authentication is requested, the User-Name attribute SHOULD be > present, as well as any additional authentication AVPs that would > carry the password information. A request for authorization SHOULD > only include the information from which the authorization will be > performed, such as the User-Name, Called-Station-Id, or Calling- This implies that some other sorts of information SHOULD NOT be included, but gives no indication what it is (or why). > Station-Id AVPs. All requests SHOULD contain AVPs uniquely > identifying the source of the call, such as Origin-Host and NAS-Port. This is a classic and frequent bit of guidance, but lacks any technical substance. The "such as" gives a concrete example, but otherwise the implementer has no idea what will satisfy the SHOULD. > Certain networks MAY use different AVPs for authorization purposes. > A request for authorization will include some AVPs defined in > Section 4.4. Which ones? How is the implementer to know? > It is possible for a single session to be authorized first and then > for an authentication request to follow. What is the implementer to do with this statement? > This AA-Request message MAY be the result of a multi-round > authentication exchange, which occurs when the AA-Answer message is > received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. > A subsequent AAR message SHOULD be sent, with the User-Password AVP > that includes the user's response to the prompt, and MUST include any > State AVPs that were present in the AAA message. > > Message Format What meta-syntax is being used for specifying formats? It isn't ABNF and it isn't cited. > 3.2. AA-Answer (AAA) Command > > The AA-Answer (AAA) message is indicated by setting the Command-Code > field to 265 and clearing the 'R' bit in the Command Flags field. It Is it really helpful to have each of these say how to set the command, given that it's already listed in a table? Having prose that merely repeats details, rather than explaining them, expands the size of the document but, I believe, actually makes the substance less accessible. Worse, isn't that already done in the base Diameter document? And by the way, the base document defines a command as a request/answer pair. As such neither one, on its own, is a command. That is, this one appears to be the a "command answer", rather than a command. (And yes, that's painfully redundant, given the symbolic name.) I notice that the text often uses the word 'message' to refer to one of these transaction components of a command. That looks like a simple and reasonable choice. Hence, AA-Answer (AAA) Message? This assumes that "command" means a request/response pair. > is sent in response to the AA-Request (AAR) message. If > authorization was requested, a successful response will include the > authorization AVPs appropriate for the service being provided, as > defined in Section 4.4. The "if" seems odd, since the preceding sentence declares the necessary (and obvious) predicate. > > For authentication exchanges requiring more than a single round trip, > the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH. > An AAA message with this result code MAY include one Reply-Message or > > > > Zorn Expires November 19, 2012 [Page 12] > > Internet-Draft Diameter NASREQ May 2012 > > > more and MAY include zero or one State AVPs. > > If the Reply-Message AVP was present, the network access server > SHOULD send the text to the user's client to display to the user, "was present" suffers the problem of passive sentence form in a protocol specification -- and using past tense adds to the challenge: it isn't clear who does what. Offhand, I would think that it is, in fact, the server that generates replies (and presumably, therefore, chooses to include Reply-Message text.) However the above sentence implies otherwise. Since Diameter is a protocol specification, what does it mean for a server to send text to the user's client? What is the protocol mechanism for doing this? > instructing the client to prompt the user for a response. For > example, this capability can be achieved in PPP via PAP. If the > access client is unable to prompt the user for a new response, it > MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an error > and deny access. The 'it' means the client? The client must deny access? > 3.3. Re-Auth-Request (RAR) Command > > A Diameter server may initiate a re-authentication and/or re- may? > authorization service for a particular session by issuing a Re-Auth- > Request (RAR) message [I-D.ietf-dime-rfc3588bis]. Re-authorization "service"? I don't understand what the word means here and didn't find any obvious guidance in the base Diameter document. The additional uses of the word in the next paragraph added to my confusion. > For example, for pre-paid services, the Diameter server that > originally authorized a session may need some confirmation that the > user is still using the services. I have no idea what this is about, what it's basis is or what it means. It seems to presume that the reader knows exactly what is being referred to, as 'pre-paid services' and why it would need some (additional) confirmation. > If a NAS receives an RAR message with Session-Id equal to a currently > active session and a Re-Auth-Type that includes authentication, it > MUST initiate a re-authentication toward the user, if the service > supports this particular feature. and if it doesn't, then what? > 3.4. Re-Auth-Answer (RAA) Command > > The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is sent > in response to the RAR. The Result-Code AVP MUST be present and > indicates the disposition of the request. > > A successful RAA transaction MUST be followed by an AAR message. transaction -> command { ? } > 3.5. Session-Termination-Request (STR) Command > > The Session-Termination-Request (STR) message > [I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the Diameter > Server that an authenticated and/or authorized session is being > terminated. "is being". Again, this is passive voice for a 'command'. Consequently it is not clear whether the requestor has done the termination or is requesting that the server terminate. I assume the latter, but the text leaves this open. > 3.6. Session-Termination-Answer (STA) Command > > The Session-Termination-Answer (STA) message > [I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to > acknowledge the notification that the session has been terminated. > The Result-Code AVP MUST be present and MAY contain an indication > that an error occurred while the STR was being serviced. > > Upon sending or receiving the STA, the Diameter Server MUST release > all resources for the session indicated by the Session-Id AVP. Any > intermediate server in the Proxy-Chain MAY also release any > resources, if necessary. The server can /receive/ an STA? That appears to be at odds with the first paragraph. > 3.7. Abort-Session-Request (ASR) Command > > The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis] > may be sent by any server to the NAS providing session service, to > request that the session identified by the Session-Id be stopped. "by any server" suggests a multi-server model, with a NAS talking to more than one at a time (for a given session...?) As I understand it, NAS/Server sessions are bilateral, not multi-lateral. In addition, the "providing session service" implies that a NAS could be relevant to this text when it is /not/ providing session service. This seems unlikely. So the language here probably should be: MAY be sent by the server to the NAS to request that... > 3.8. Abort-Session-Answer (ASA) Command > > The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to the > ASR. The Result-Code AVP MUST be present and indicates the > disposition of the request. Who sends to whom? > 3.9. Accounting-Request (ACR) Command > > The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to > report its session information to a target server downstream. 'downstream'? Is it relayed through intermediaries? What does 'downstream' mean here, beyond simply having a client/server dialogue? > The Acct-Application-Id AVP MUST be present. > > The AVPs listed in the Base protocol specification > [I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as What does "assumed to be present" mean? What is the point behind "assuming" and does this just mean supported by client and server software? Required to be used in the protocol exchanges? Something else? > 3.10. Accounting-Answer (ACA) Command > > The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge an is used to acknowledge -> acknowledges > Accounting-Request command. The Accounting-Answer command contains > the same Session-Id as the Request. The same level of security MUST > be applied to both the Accounting-Request and the corresponding Is this security requirement special to this command or is it univeral? Why? > Accounting-Answer message. For example, if the ACR was protected > using end-to-end security techniques then the corresponding ACA > message MUST be protected in the same way; note, however, that the > definition of such techniques is outside the scope of this document. > > Only the target Diameter Server or home Diameter Server SHOULD > respond with the Accounting-Answer command. target vs. home. What distinguishes which is to respond? How are they to know? > 4. Diameter NAS Application AVPs > > The following sections define a new derived AVP data format, a set of "new" will not mean much 10 years from now. RFCs should be written for long-term reading. "derived"? What does this mean? > application-specific AVPs and describe the use of AVPs defined in > other documents by the Diameter NAS Application. > > 4.1. Derived AVP Data Formats > > 4.1.1. QoSFilterRule What is the /purpose/ of this? Presumably it has something to do with filtering, but there's no context for it established. > The QosFilterRule format is derived from the OctetString AVP Base > Format. It uses the ASCII charset. Packets may be marked or metered > based on the following information: > marked vs. metered ? > > > Zorn Expires November 19, 2012 [Page 23] > > Internet-Draft Diameter NASREQ May 2012 > > > o Direction (in or out) > > o Source and destination IP address (possibly masked) > > o Protocol > > o Source and destination port (lists or ranges) > > o DSCP values (no mask or range) DSCP? > Rules for the appropriate direction are evaluated in order; the first "Rules for the appropriate direction"? What does this mean? > matched rule terminates the evaluation. Each packet is evaluated > once. If no rule matches, the packet is treated as best effort. An > access device unable to interpret or apply a QoS rule SHOULD NOT > terminate the session. This appears to be discussing a /set/ of rules, but there's been no discussion of a set. This appears to presume a model that hasn't been introduced. > > QoSFilterRule filters MUST follow the following format: There is more than one filter? Does this mean multiple sets or multiple rules within a single set? > action dir proto from src to dst [options] Where are the /semantics/ of these defined? > where > > action > tag Mark packet with a specific DSCP [RFC2474] > meter Meter traffic > > dir The format is as described under IPFilterRule > [I-D.ietf-dime-rfc3588bis] > > proto The format is as described under IPFilterRule > [I-D.ietf-dime-rfc3588bis] > > src and dst The format is as described under IPFilterRule > [I-D.ietf-dime-rfc3588bis] > > The options are described in Section 4.4.9. I didn't see them there. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the > ipfw.c code may provide a useful base for implementations. "may be provided"??? I thought this was a protocol specification which defines its details or cites them formally. > 4.2. NAS Session AVPs > > Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that > are implemented in Diameter. > > 4.2.1. Call and Session Information > > This section describes the AVPs specific to Diameter applications > that are needed to identify the call and session context and status > > > > Zorn Expires November 19, 2012 [Page 24] > > Internet-Draft Diameter NASREQ May 2012 > > > information. On a request, this information allows the server to > qualify the session. "on a request"? > These AVPs are used in addition to the following AVPs from the base > protocol specification [I-D.ietf-dime-rfc3588bis]: > > Session-Id > Auth-Application-Id > Origin-Host > Origin-Realm > Auth-Request-Type > Termination-Cause > > The following table gives the possible flag values for the session > level AVPs. "session-level"? > +----------+ > | AVP Flag | > | rules | > |----+-----+ > |MUST| MUST| > Attribute Name Section Defined | | NOT| > -----------------------------------------|----+-----| > NAS-Port 4.2.2 | M | V | > NAS-Port-Id 4.2.3 | M | V | > NAS-Port-Type 4.2.4 | M | V | > Called-Station-Id 4.2.5 | M | V | > Calling-Station-Id 4.2.6 | M | V | > Connect-Info 4.2.7 | M | V | > Originating-Line-Info 4.2.8 | M | V | > Reply-Message 4.2.9 | M | V | > -----------------------------------------|----+-----| > > 4.2.2. NAS-Port AVP > > The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the > physical or virtual port number of the NAS which is authenticating > the user. Note that "port" is meant in its sense as a service > connection on the NAS, not as an IP protocol identifier. "service connection on the NAS"? "virtual" port number? This is the only time the term is used, and I don't see it in the base Diameter document and I don't know what it means. > Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) SHOULD > be present in the AA-Request (AAR, Section 3.1) command if the NAS > differentiates among its ports. > > 4.2.3. NAS-Port-Id AVP > > The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists > of ASCII text identifying the port of the NAS authenticating the > > > > Zorn Expires November 19, 2012 [Page 25] > > Internet-Draft Diameter NASREQ May 2012 > > > user. Note that "port" is meant in its sense as a service connection > on the NAS, not as an IP protocol identifier. Although this doesn't distinguish physical from virtual, it does explain the term port. I suspect such explanations should be broken out into an earlier section that provides some framework and terminology. This will avoid having definitions buried deeply and possibly after first use. This can be especially helpful for sections, like this one, that seem likely to be used for reference, and therefore not read sequentially. > > Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) SHOULD > be present in the AA-Request (AAR, Section 3.1) command if the NAS > differentiates among its ports. NAS-Port-Id is intended for use by > NASes that cannot conveniently number their ports. > > 4.2.4. NAS-Port-Type AVP > > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and "Enumerated"? Where are the types defined? > 4.2.9. Reply-Message AVP > > The Reply-Message AVP (AVP Code 18) is of type UTF8String and > contains text that MAY be displayed to the user. When used in an AA- Since I doubt that this specification is intended to cover user interface design -- and hope that it is not -- I think that the normative, semantic point in specification terms is that the strings MUST be created with the intent of displaying them to humans. That is, these are human-consumable strings, not (necessarily) computer-consumable. > 4.4.1. Service-Type AVP > > The Service-Type AVP (AVP Code 6) is of type Enumerated and contains > the type of service the user has requested or the type of service to > be provided. One such AVP MAY be present in an authentication and/or > authorization request or response. A NAS is not required to > implement all of these service types. It MUST treat unknown or > unsupported Service-Types received in a response as a failure and end > the session with a DIAMETER_INVALID_AVP_VALUE Result-Code. > > When used in a request, the Service-Type AVP SHOULD be considered a > hint to the server that the NAS believes the user would prefer the > kind of service indicated. The server is not required to honor the A hint is a hint. It would be odd and probably wrong for an implementer to be "required to honor the hint". If they are required, it's not a hint. I believe the simpler and more useful phrasing would simply be: When used in a request, the Service-Type AVP is only a hint to the server that the NAS believes... And then delete the sentence after. > hint. Furthermore, if the service specified by the server is > supported, but not compatible with the current mode of access, the > NAS MUST fail to start the session. The NAS MUST also generate the > appropriate error message(s). Doesn't "MUST fail to start" equate to "MUST NOT start" and wouldn't that be the simpler and more typical phrasing? "appropriate"? What are the criteria and how is the implementer to know? > 4.4.10.5.4. Framed-Pool AVP > > The Framed-Pool AVP (AVP Code 88) is of type OctetString and contains > the name of an assigned address pool that SHOULD be used to assign an > address for the user. If a NAS does not support multiple address > pools, the NAS SHOULD ignore this AVP. Address pools are usually > used for IP addresses but can be used for other protocols if the NAS > supports pools for those protocols. Hmmm. If the NAS does not support multiple address pools and doesn't ignore this AVP, what happens and how will it be interoperable? This seems like something that requires an exact, shared model between the two sides, or else it's merely a notational convenience without interoperability substance. That is, either it's a MAY or a MUST? Or there needs to be some explanation of how to deal with the mismatch between the two sides. // d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------020802080904080003040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen, DIME WG,

Can you please address/answer Dave's points in his initial email.

Regards, Benoit.


-------- Original Message --------
Subject: Review of: draft-ietf-dime-rfc4005bis-09
Date: Sun, 29 Jul 2012 21:57:26 -0700
From: Dave Crocker <dcrocker@bbiw.net>
Organisation: Brandenburg InternetWorking
To: apps-discuss@ietf.org, draft-ietf-dime-rfc4005bis.all@tools.ietf.org
CC: iesg <iesg@ietf.org>


G'day.


I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see


http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.


Document:     draft-ietf-dime-rfc4005bis-09
Title:        Diameter Network Access Server Application
Reviewer:     Dave Crocker
Review Date:  18 June 2012


Summary:

This draft continues problems from the original, at a minimum lacking 
definitions of terms, citation or definition of notational conventions, 
apparent normative redundancy with base documents.


Major Issues:

   Active vs. passive voice -- the documents use of passive voice 
greatly expands the verbiage but also sometimes make it difficult to 
discern which participating entity is the identified actor.

   Apparently redundant normative text -- this document appears to 
contain restatements of normative text from the base Diameter document. 
 This is extremely poor practice, since it invites divergence.

   Possibly inconsistent use of terminology -- Some of the terms used 
appear to have equivalent meaning but are not defines; to the extent 
that they are meant to have different meaning I could not tell what that 
was.

   Most significantly, it appears that this document cannot readily be 
read without very deep familiarity with other Diameter documentation, 
making this nearly an appendix to those.  At the least, the dependencies 
should be made explicit and detailed.  The Introduction's opening 
paragraph might have been thought to take care of this requirement, but 
it doesn't, at least not for me.  For one thing, it isn't phrase so as 
to accomplish this.  For another, the references are to entire 
documents, implying -- but not saying -- don't read this until you are 
deeply familiar with all of these other documents.

   The broader comments appear to apply to the original documents as 
well as this (and related) current ones.  It's likely that making 
changes accordingly would be a major effort.  Whether that's worth the 
effort isn't something I can judge.  I think the revisions would make 
for tighter, clearer specifications that are probably easier to 
maintain, but I can't offer an opinion about the benefit this would have 
in terms of existing implementers or better market adoption, since I'm 
not familiar with Diameter's degree of market penetration nor the skills 
of those who have (or might) adopt it.



Minor Issues: --


Nits:  --


Detailed comments:


> Network Working Group                                       G. Zorn, Ed.
> Internet-Draft                                               Network Zen
> Obsoletes: 4005 (if approved)                               May 18, 2012
> Intended status: Standards Track
> Expires: November 19, 2012
>
>
>                Diameter Network Access Server Application
>                      draft-ietf-dime-rfc4005bis-09
>
> Abstract
>
>    This document describes the Diameter protocol application used for

When summarizing the nature or purpose of a document, it is best for the 
abstract and Introduction to use different words than are in the title. 
 Simply repeating the language of the title does not explain the title. 
 The simple rule should be to assume that the new reader does not 
automatically understand the meaning of the title.

In this case, I also have no idea what "the Diameter protocol 
application" means here.  "protocol application" is not typical 
phrasing.  Does it really mean that details are being specified for 
software implementation of Diameter at the server?

Typically, the IETF does not specify details about software 
implementation, nevermind put such a specification on the standards 
track.  (And, yes, I see that this is a -bis document; but that does not 
change the underlying concern.)

What is the motivation for this version of the document?  What problems 
or improvements are being provided?  That is, why was it worth the 
effort to revise the previous document?  These are not explained in the 
bis document.


>    Authentication, Authorization, and Accounting (AAA) services in the
>    Network Access Server (NAS) environment; it obsoletes RFC 4005.  When
>    combined with the Diameter Base protocol, Transport Profile, and
>    Extensible Authentication Protocol specifications, this application
>    specification satisfies typical network access services requirements.

...
> 1.  Introduction
>
>    This document describes the Diameter protocol application used for
>    AAA in the Network Access Server (NAS) environment.  When combined
>    with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], Transport
>    Profile [RFC3539], and EAP [RFC4072] specifications, this
>    specification satisfies the NAS-related requirements defined in
>    Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169].

This assertion raises a dilemma:  The cited documents are extensive and 
the topic(s?) complex.  There is no way to know what details are being 
referred to, to evaluate the assertion.  Worse, fixing this deficiency 
is certain to be a large effort.


>    First, this document describes the operation of a Diameter NAS
>    application.

What is "a Diameter NAS application"?  It does not seem to be explained 
in this document, nor is there a citation to its definition.


>                   Then it defines the Diameter message Command-Codes.
>    The following sections list the AVPs used in these messages, grouped

AVPs?

Define acronyms when they are introduced.  Explain their meaning. If the 
acronym is not destined for regular use within the document, consider 
replacing the acronym with the full term.

If this document is a case of "this document only makes sense when you 
are intimately familiar with these other documents", then specify those 
other documents.  As the document stands now, it does not formally citte 
foundational documents, although it does seem to rely on some.

In general, this document's frequent use of "AVP" appears to be an oddly 
syntactic focus.  Typical specifications refer to attributes, without 
such frequent, explicit reference to the form of their having values. On 
its own, this point could seem like quibbling, but it's part of the 
reaction I had when reading the document, that is seemed less accessible 
than one would wish for a new reader.


>    by common usage.  These are session identification, authentication,
>    authorization, tunneling, and accounting.  The authorization AVPs are
>    further broken down by service type.

This document appears to require deep knowledge of The Diameter Base 
Protocol.  In reality, I don't think this document can be meaningfully 
read without that knowledge.  So this document should say that.  (The 
language in the first paragraph of the Intro doesn't actually say it.)


> 1.1.  Changes from RFC 4005
>
>    This document obsoletes RFC 4005 and is not backward compatible with
>    that document.  An overview of some the major changes are given
>    below.

"not backward compatible" automatically raises basic questions about 
transition from old to new and support during an extended transition. 
The word 'transition' does not appear in this document.


>    o  All of the material regarding RADIUS/Diameter protocol
>       interactions has been removed.
>
>    o  The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for the

presumably the references to I-Ds need to be changed for RFC publication?


>       Accounting-Request and Accounting-Answer messages has been changed
>       to explicitly require the inclusion of the Acct-Application-Id AVP
>       and exclude the Vendor-Specific-Application-Id AVP.  Normally,
>       this type of change would also require the allocation of a new
>       command code and consequently, a new application-id (See Section
>       1.3.3 of [I-D.ietf-dime-rfc3588bis]).  However, the presence of an
>       instance of the Acct-Application-Id AVP was required in RFC 4005,
>       as well:
>
>          The ACR message [BASE] is sent by the NAS to report its session
>          information to a target server downstream.
>
>          Either of Acct-Application-Id or Vendor-Specific-Application-Id
>          AVPs MUST be present.  If the Vendor-Specific-Application-Id
>          grouped AVP is present, it must have an Acct-Application-Id
>          inside.
>
>       Thus, though the syntax of the commands has changed, the semantics
>       have not (with the caveat that the Acct-Application-Id AVP can no
>       longer be contained in the Vendor-Specific-Application-Id AVP).

Sounds oddly disruptive.  /Why/ has the syntax been changed?  What 
problem is this solving?

>
>
>
>
> Zorn                    Expires November 19, 2012               [Page 5]
> 
> Internet-Draft               Diameter NASREQ                    May 2012
>
>
>    o  The lists of RADIUS attribute values have been deleted in favor of
>       references to the appropriate IANA registries.
>
>    o  The accounting model to be used is now specified.
>
>    There are many other many miscellaneous fixes that have been
>    introduced in this document that may not be considered significant
>    but they are useful nonetheless.  Examples are fixes to example IP

Useful, but not significant.  Interesting concept.  Perhaps what is 
meant is not major or not substantive or not normative?


>    addresses, addition of clarifying references, etc.  All of the errata
>    previously filed against RFC 4005 have been fixed.  A comprehensive
>    list of changes is not shown here for practical reasons.
>
> 1.2.  Terminology
>
>    Section 1.2 of the base Diameter specification
>    [I-D.ietf-dime-rfc3588bis] defines most of the terminology used in
>    this document.  Additionally, the following terms and acronyms are
>    used in this application:
>
>    NAS (Network Access Server)
>       A device that provides an access service for a user to a network.
>       The service may be a network connection or a value-added service
>       such as terminal emulation [RFC2881].

Do not define a term by re-using the words in the term.  In this case, 
even a word as obvious as 'access' could mean a variety of things.

Everything is "a network connection".  Perhaps the distinction here is 
between host-level attachment service, versus user-level application 
service?  I can't tell.


...
>    VPN (Virtual Private Network)
>       In this document, this term is used to describe access services
>       that use tunneling methods.

Since VPN is a well-entrenched, standard term of art, it seems odd -- 
and likely counterproductive -- to imply that use in this document will 
be non-standard, especially since the definition provided seems on a par 
with usual definitions, such as wikipedia's.



> 1.4.  Advertising Application Support
>
>    Diameter nodes conforming to this specification MUST advertise
>    support by including the value of one (1) in the Auth-Application-Id
>    of the Capabilities-Exchange-Request (CER) message.

"this specification' -> this version of specification  [???]

There is no other reference to the CER message in this document.  As 
such, it's not clear what context for the message is meant.  Offhand, it 
appears that advertising support of the spec is made during a session 
that implements the spec?  This seems at least odd.

Since this version of the spec uses a different syntax, it's not likely 
that any implementation will be speaking a different version of the 
protocol.


> 1.5.  Application Identification
>
>    When used in this application, the Auth-Application-Id AVP MUST be
>    set to the value one (1) in the following messages
>
>    o  AA-Request (Section 3.1)
>
>
>
>
>
> Zorn                    Expires November 19, 2012               [Page 7]
> 
> Internet-Draft               Diameter NASREQ                    May 2012
>
>
>    o  Re-Auth-Request(Section 3.3)
>
>    o  Session-Termination-Request (Section 3.5)
>
>    o  Abort-Session-Request (Section 3.7)
>
> 1.6.  Accounting Model
>
>    It is RECOMMENDED that the coupled accounting model (Section 9.3 of
>    [I-D.ietf-dime-rfc3588bis]) be used with this application; therefore,
>    the value of the Acct-Application-Id AVP in the Accounting-Request
>    (Section 3.10) and Accounting-Answer (Section 3.9) messages SHOULD be
>    set to one (1).

All of the values in those two sections (except the "271") are symbolic. 
 As such, setting a value to "1" has no obvious meaning.

I assume that the issue would be fixed by using symbolic values here?


> 2.  NAS Calls, Ports, and Sessions
>
>    The arrival of a new call or service connection at a port of a

"a port"?  is this a reference to a transport-level port?  That's the 
only use of the word in the base diameter document.

What is a 'call' and what does it mean for it to "arrive", in this 
context?  How is it different from a service connection?

The word 'call' in the base document does not have a usage that seems 
relevant here.

Is this document really trying to specify how a host dispatches a 
server?  If so, that means it's discussing implementation details rather 
than protocol details.


>    Network Access Server (NAS) starts a Diameter NAS message exchange.

I would guess that the Diameter-level initiation of a NAS message 
exchange is caused by a Diameter-level message, not the transport 
connection it triggers.  If so, what message would that be?


>    Information about the call, the identity of the user, and the user's

The base Diameter document does not specify the concept of a 'call'.


>    authentication information are packaged into a Diameter AA-Request
>    (AAR) message and sent to a server.
>
>    The server processes the information and responds with a Diameter AA-

"processes the information"?  What does this mean, in protocol 
interoperability terms?  I'd expect some statement about the semantics 
of the processes, relative to the overall exchange.


>    Answer (AAA) message that contains authorization information for the
>    NAS, or a failure code (Result-Code AVP).  A value of
>    DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication
>    exchange, and several AAR and AAA messages may be exchanged until the
>    transaction completes.

"may"?

This paragraph appears to be largely redundant with the base Diameter 
document.  Redundancy like this invites divergence over time and 
ambiguity about which text is controlling.


>    Depending on the value of the Auth-Request-Type AVP, the Diameter

The reader is supposed to guess what values produce what results or 
actions?  I don't see the choices/mappings/whatever documented.



> 3.1.  AA-Request (AAR) Command
>
>    The AA-Request (AAR), which is indicated by setting the Command-Code
>    field to 265 and the 'R' bit in the Command Flags field, is used to
>    request authentication and/or authorization for a given NAS user.

The text provides detail about the internals of the AAR, but doesn't say 
who sends it.

By the way, does the AA- mean Authentication/Authorization?  That's 
implied but not stated.  Since the labels are symbolic, mnemonic utility 
is improved by explaining the basis of the string.


>    The type of request is identified through the Auth-Request-Type AVP
>    [I-D.ietf-dime-rfc3588bis] The recommended value for most situations
>    is AUTHORIZE_AUTHENTICATE.
>
>    If Authentication is requested, the User-Name attribute SHOULD be
>    present, as well as any additional authentication AVPs that would
>    carry the password information.  A request for authorization SHOULD
>    only include the information from which the authorization will be
>    performed, such as the User-Name, Called-Station-Id, or Calling-

This implies that some other sorts of information SHOULD NOT be 
included, but gives no indication what it is (or why).


>    Station-Id AVPs.  All requests SHOULD contain AVPs uniquely
>    identifying the source of the call, such as Origin-Host and NAS-Port.

This is a classic and frequent bit of guidance, but lacks any technical 
substance. The "such as" gives a concrete example, but otherwise the 
implementer has no idea what will satisfy the SHOULD.


>    Certain networks MAY use different AVPs for authorization purposes.
>    A request for authorization will include some AVPs defined in
>    Section 4.4.

Which ones?  How is the implementer to know?


>    It is possible for a single session to be authorized first and then
>    for an authentication request to follow.

What is the implementer to do with this statement?


>    This AA-Request message MAY be the result of a multi-round
>    authentication exchange, which occurs when the AA-Answer message is
>    received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH.
>    A subsequent AAR message SHOULD be sent, with the User-Password AVP
>    that includes the user's response to the prompt, and MUST include any
>    State AVPs that were present in the AAA message.
>
>       Message Format

What meta-syntax is being used for specifying formats?  It isn't ABNF 
and it isn't cited.



> 3.2.  AA-Answer (AAA) Command
>
>    The AA-Answer (AAA) message is indicated by setting the Command-Code
>    field to 265 and clearing the 'R' bit in the Command Flags field.  It

Is it really helpful to have each of these say how to set the command, 
given that it's already listed in a table?  Having prose that merely 
repeats details, rather than explaining them, expands the size of the 
document but, I believe, actually makes the substance less accessible.

Worse, isn't that already done in the base Diameter document?

And by the way, the base document defines a command as a request/answer 
pair.  As such neither one, on its own, is a command.  That is, this one 
appears to be the a "command answer", rather than a command.  (And yes, 
that's painfully redundant, given the symbolic name.)

I notice that the text often uses the word 'message' to refer to one of 
these transaction components of a command.  That looks like a simple and 
reasonable choice.  Hence, AA-Answer (AAA) Message?  This assumes that 
"command" means a request/response pair.


>    is sent in response to the AA-Request (AAR) message.  If
>    authorization was requested, a successful response will include the
>    authorization AVPs appropriate for the service being provided, as
>    defined in Section 4.4.

The "if" seems odd, since the preceding sentence declares the necessary 
(and obvious) predicate.


>
>    For authentication exchanges requiring more than a single round trip,
>    the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH.
>    An AAA message with this result code MAY include one Reply-Message or
>
>
>
> Zorn                    Expires November 19, 2012              [Page 12]
> 
> Internet-Draft               Diameter NASREQ                    May 2012
>
>
>    more and MAY include zero or one State AVPs.
>
>    If the Reply-Message AVP was present, the network access server
>    SHOULD send the text to the user's client to display to the user,

"was present" suffers the problem of passive sentence form in a protocol 
specification -- and using past tense adds to the challenge:  it isn't 
clear who does what.  Offhand, I would think that it is, in fact, the 
server that generates replies (and presumably, therefore, chooses to 
include Reply-Message text.)  However the above sentence implies otherwise.

Since Diameter is a protocol specification, what does it mean for a 
server to send text to the user's client?  What is the protocol 
mechanism for doing this?


>    instructing the client to prompt the user for a response.  For
>    example, this capability can be achieved in PPP via PAP.  If the
>    access client is unable to prompt the user for a new response, it
>    MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an error
>    and deny access.

The 'it' means the client?  The client must deny access?


> 3.3.  Re-Auth-Request (RAR) Command
>
>    A Diameter server may initiate a re-authentication and/or re-

may?


>    authorization service for a particular session by issuing a Re-Auth-
>    Request (RAR) message [I-D.ietf-dime-rfc3588bis].

Re-authorization "service"?  I don't understand what the word means here 
and didn't find any obvious guidance in the base Diameter document.

The additional uses of the word in the next paragraph added to my confusion.


>    For example, for pre-paid services, the Diameter server that
>    originally authorized a session may need some confirmation that the
>    user is still using the services.

I have no idea what this is about, what it's basis is or what it means. 
It seems to presume that the reader knows exactly what is being referred 
to, as 'pre-paid services' and why it would need some (additional) 
confirmation.


>    If a NAS receives an RAR message with Session-Id equal to a currently
>    active session and a Re-Auth-Type that includes authentication, it
>    MUST initiate a re-authentication toward the user, if the service
>    supports this particular feature.

and if it doesn't, then what?



> 3.4.  Re-Auth-Answer (RAA) Command
>
>    The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is sent
>    in response to the RAR.  The Result-Code AVP MUST be present and
>    indicates the disposition of the request.
>
>    A successful RAA transaction MUST be followed by an AAR message.

transaction -> command { ? }


> 3.5.  Session-Termination-Request (STR) Command
>
>    The Session-Termination-Request (STR) message
>    [I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the Diameter
>    Server that an authenticated and/or authorized session is being
>    terminated.

"is being".  Again, this is passive voice for a 'command'.  Consequently 
it is not clear whether the requestor has done the termination or is 
requesting that the server terminate.  I assume the latter, but the text 
leaves this open.


> 3.6.  Session-Termination-Answer (STA) Command
>
>    The Session-Termination-Answer (STA) message
>    [I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to
>    acknowledge the notification that the session has been terminated.
>    The Result-Code AVP MUST be present and MAY contain an indication
>    that an error occurred while the STR was being serviced.
>
>    Upon sending or receiving the STA, the Diameter Server MUST release
>    all resources for the session indicated by the Session-Id AVP.  Any
>    intermediate server in the Proxy-Chain MAY also release any
>    resources, if necessary.

The server can /receive/ an STA?  That appears to be at odds with the 
first paragraph.


> 3.7.  Abort-Session-Request (ASR) Command
>
>    The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis]
>    may be sent by any server to the NAS providing session service, to
>    request that the session identified by the Session-Id be stopped.

"by any server" suggests a multi-server model, with a NAS talking to 
more than one at a time (for a given session...?)  As I understand it, 
NAS/Server sessions are bilateral, not multi-lateral.  In addition, the 
"providing session service" implies that a NAS could be relevant to this 
text when it is /not/ providing session service.  This seems unlikely.

So the language here probably should be:

   MAY be sent by the server to the NAS to request that...



> 3.8.  Abort-Session-Answer (ASA) Command
>
>    The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to the
>    ASR.  The Result-Code AVP MUST be present and indicates the
>    disposition of the request.

Who sends to whom?


> 3.9.  Accounting-Request (ACR) Command
>
>    The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to
>    report its session information to a target server downstream.

'downstream'?  Is it relayed through intermediaries?  What does 
'downstream' mean here, beyond simply having a client/server dialogue?


>    The Acct-Application-Id AVP MUST be present.
>
>    The AVPs listed in the Base protocol specification
>    [I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as

What does "assumed to be present" mean?  What is the point behind 
"assuming" and does this just mean supported by client and server 
software?  Required to be used in the protocol exchanges?  Something else?



> 3.10.  Accounting-Answer (ACA) Command
>
>    The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge an

   is used to acknowledge -> acknowledges


>    Accounting-Request command.  The Accounting-Answer command contains
>    the same Session-Id as the Request.  The same level of security MUST
>    be applied to both the Accounting-Request and the corresponding

Is this security requirement special to this command or is it univeral? 
 Why?


>    Accounting-Answer message.  For example, if the ACR was protected
>    using end-to-end security techniques then the corresponding ACA
>    message MUST be protected in the same way; note, however, that the
>    definition of such techniques is outside the scope of this document.
>
>    Only the target Diameter Server or home Diameter Server SHOULD
>    respond with the Accounting-Answer command.

target vs. home.  What distinguishes which is to respond?  How are they 
to know?



> 4.  Diameter NAS Application AVPs
>
>    The following sections define a new derived AVP data format, a set of

"new" will not mean much 10 years from now.  RFCs should be written for 
long-term reading.

"derived"?  What does this mean?


>    application-specific AVPs and describe the use of AVPs defined in
>    other documents by the Diameter NAS Application.
>
> 4.1.  Derived AVP Data Formats
>
> 4.1.1.  QoSFilterRule

What is the /purpose/ of this?  Presumably it has something to do with 
filtering, but there's no context for it established.


>    The QosFilterRule format is derived from the OctetString AVP Base
>    Format.  It uses the ASCII charset.  Packets may be marked or metered
>    based on the following information:
>

marked vs. metered ?


>
>
> Zorn                    Expires November 19, 2012              [Page 23]
> 
> Internet-Draft               Diameter NASREQ                    May 2012
>
>
>    o  Direction (in or out)
>
>    o  Source and destination IP address (possibly masked)
>
>    o  Protocol
>
>    o  Source and destination port (lists or ranges)
>
>    o  DSCP values (no mask or range)

DSCP?


>    Rules for the appropriate direction are evaluated in order; the first

"Rules for the appropriate direction"?  What does this mean?


>    matched rule terminates the evaluation.  Each packet is evaluated
>    once.  If no rule matches, the packet is treated as best effort.  An
>    access device unable to interpret or apply a QoS rule SHOULD NOT
>    terminate the session.

This appears to be discussing a /set/ of rules, but there's been no 
discussion of a set.  This appears to presume a model that hasn't been 
introduced.


>
>    QoSFilterRule filters MUST follow the following format:

There is more than one filter?  Does this mean multiple sets or multiple 
rules within a single set?


>       action dir proto from src to dst [options]

Where are the /semantics/ of these defined?


>       where
>
>       action
>                   tag         Mark packet with a specific DSCP [RFC2474]
>                   meter       Meter traffic
>
>       dir         The format is as described under IPFilterRule
>                   [I-D.ietf-dime-rfc3588bis]
>
>       proto       The format is as described under IPFilterRule
>                   [I-D.ietf-dime-rfc3588bis]
>
>       src and dst The format is as described under IPFilterRule
>                   [I-D.ietf-dime-rfc3588bis]
>
>    The options are described in Section 4.4.9.

I didn't see them there.

>
>    The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the
>    ipfw.c code may provide a useful base for implementations.

"may be provided"???  I thought this was a protocol specification which 
defines its details or cites them formally.


> 4.2.  NAS Session AVPs
>
>    Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that
>    are implemented in Diameter.
>
> 4.2.1.  Call and Session Information
>
>    This section describes the AVPs specific to Diameter applications
>    that are needed to identify the call and session context and status
>
>
>
> Zorn                    Expires November 19, 2012              [Page 24]
> 
> Internet-Draft               Diameter NASREQ                    May 2012
>
>
>    information.  On a request, this information allows the server to
>    qualify the session.

"on a request"?


>    These AVPs are used in addition to the following AVPs from the base
>    protocol specification [I-D.ietf-dime-rfc3588bis]:
>
>       Session-Id
>       Auth-Application-Id
>       Origin-Host
>       Origin-Realm
>       Auth-Request-Type
>       Termination-Cause
>
>    The following table gives the possible flag values for the session
>    level AVPs.

"session-level"?


>                                                     +----------+
>                                                     | AVP Flag |
>                                                     |   rules  |
>                                                     |----+-----+
>                                                     |MUST| MUST|
>            Attribute Name          Section Defined  |    |  NOT|
>            -----------------------------------------|----+-----|
>            NAS-Port                4.2.2            | M  |  V  |
>            NAS-Port-Id             4.2.3            | M  |  V  |
>            NAS-Port-Type           4.2.4            | M  |  V  |
>            Called-Station-Id       4.2.5            | M  |  V  |
>            Calling-Station-Id      4.2.6            | M  |  V  |
>            Connect-Info            4.2.7            | M  |  V  |
>            Originating-Line-Info   4.2.8            | M  |  V  |
>            Reply-Message           4.2.9            | M  |  V  |
>            -----------------------------------------|----+-----|
>
> 4.2.2.  NAS-Port AVP
>
>    The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the
>    physical or virtual port number of the NAS which is authenticating
>    the user.  Note that "port" is meant in its sense as a service
>    connection on the NAS, not as an IP protocol identifier.

"service connection on the NAS"?

"virtual" port number?  This is the only time the term is used, and I 
don't see it in the base Diameter document and I don't know what it means.


>    Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) SHOULD
>    be present in the AA-Request (AAR, Section 3.1) command if the NAS
>    differentiates among its ports.
>
> 4.2.3.  NAS-Port-Id AVP
>
>    The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists
>    of ASCII text identifying the port of the NAS authenticating the
>
>
>
> Zorn                    Expires November 19, 2012              [Page 25]
> 
> Internet-Draft               Diameter NASREQ                    May 2012
>
>
>    user.  Note that "port" is meant in its sense as a service connection
>    on the NAS, not as an IP protocol identifier.

Although this doesn't distinguish physical from virtual, it does explain 
the term port.  I suspect such explanations should be broken out into an 
earlier section that provides some framework and terminology.  This will 
avoid having definitions buried deeply and possibly after first use. 
This can be especially helpful for sections, like this one, that seem 
likely to be used for reference, and therefore not read sequentially.


>
>    Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) SHOULD
>    be present in the AA-Request (AAR, Section 3.1) command if the NAS
>    differentiates among its ports.  NAS-Port-Id is intended for use by
>    NASes that cannot conveniently number their ports.
>
> 4.2.4.  NAS-Port-Type AVP
>
>    The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and

"Enumerated"?  Where are the types defined?


> 4.2.9.  Reply-Message AVP
>
>    The Reply-Message AVP (AVP Code 18) is of type UTF8String and
>    contains text that MAY be displayed to the user.  When used in an AA-

Since I doubt that this specification is intended to cover user 
interface design -- and hope that it is not -- I think that the 
normative, semantic point in specification terms is that the strings 
MUST be created with the intent of displaying them to humans.  That is, 
these are human-consumable strings, not (necessarily) computer-consumable.



> 4.4.1.  Service-Type AVP
>
>    The Service-Type AVP (AVP Code 6) is of type Enumerated and contains
>    the type of service the user has requested or the type of service to
>    be provided.  One such AVP MAY be present in an authentication and/or
>    authorization request or response.  A NAS is not required to
>    implement all of these service types.  It MUST treat unknown or
>    unsupported Service-Types received in a response as a failure and end
>    the session with a DIAMETER_INVALID_AVP_VALUE Result-Code.
>
>    When used in a request, the Service-Type AVP SHOULD be considered a
>    hint to the server that the NAS believes the user would prefer the
>    kind of service indicated.  The server is not required to honor the

A hint is a hint.  It would be odd and probably wrong for an implementer 
to be "required to honor the hint".  If they are required, it's not a hint.

I believe the simpler and more useful phrasing would simply be:

   When used in a request, the Service-Type AVP is only a hint to the 
server that the NAS believes...

And then delete the sentence after.

>    hint.  Furthermore, if the service specified by the server is
>    supported, but not compatible with the current mode of access, the
>    NAS MUST fail to start the session.  The NAS MUST also generate the
>    appropriate error message(s).

Doesn't "MUST fail to start" equate to "MUST NOT start" and wouldn't 
that be the simpler and more typical phrasing?

"appropriate"?  What are the criteria and how is the implementer to know?



> 4.4.10.5.4.  Framed-Pool AVP
>
>    The Framed-Pool AVP (AVP Code 88) is of type OctetString and contains
>    the name of an assigned address pool that SHOULD be used to assign an
>    address for the user.  If a NAS does not support multiple address
>    pools, the NAS SHOULD ignore this AVP.  Address pools are usually
>    used for IP addresses but can be used for other protocols if the NAS
>    supports pools for those protocols.

Hmmm.  If the NAS does not support multiple address pools and doesn't 
ignore this AVP, what happens and how will it be interoperable?

This seems like something that requires an exact, shared model between 
the two sides, or else it's merely a notational convenience without 
interoperability substance.  That is, either it's a MAY or a MUST?  Or 
there needs to be some explanation of how to deal with the mismatch 
between the two sides.



//

d/
-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net





--------------020802080904080003040108-- From lionel.morand@orange.com Wed Sep 5 09:10:23 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C1A21F86AF for ; Wed, 5 Sep 2012 09:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LQnuKj9lzus for ; Wed, 5 Sep 2012 09:10:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3591D21F86A7 for ; Wed, 5 Sep 2012 09:10:22 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 04DEF22C9BD; Wed, 5 Sep 2012 18:10:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DE81E27C0F6; Wed, 5 Sep 2012 18:10:20 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 18:10:20 +0200 From: To: Ben Campbell , "dime@ietf.org" Thread-Topic: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 Thread-Index: AQHNhWfG0n03DPqst0+L3ckUm0TZFpd7ZFlg Date: Wed, 5 Sep 2012 16:10:19 +0000 Message-ID: <3092_1346861420_5047796C_3092_8625_1_6B7134B31289DC4FAF731D844122B36E049B19@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.5.152414 Subject: Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:10:23 -0000 Hi Ben, Thank you for this detailed review! Please see below the proposed treatments. I'm preparing a new version of th= e draft but I will wait for ack and other comments before publication. Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: mardi 28 ao=FBt 2012 23:55 =C0=A0: dime@ietf.org; draft-ietf-dime-app-design-guide@tools.ietf.org Objet=A0: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 Hi, The draft gives good guidance overall. I do have a few comments, though: Substantive Comments: -- section 4: The section seems to talk mainly about syntax, rather than semantics. Is th= ere any guidance to give about things (applications, commands, avps) that m= ight be syntactically similar but mean very different things? [LM] good point! The main problem is about syntax when regarding the protoc= ol itself. But semantic is also essential for the application, as mentioned= in the RFC3588bis. I will add some words to clarify that change of the sem= antic of an AVP/command may/should/must result in the allocation of a new c= ode value. -- 4.3.2, last paragraph: Does it become an error if a peer uses the "no-longer-used-but-not-deleted"= avp? [LM] what is really meant is that you don't have to delete optional AVPs fr= om a command. Obsolete AVP that would be received anyway would be simply ig= nored. It is not an error case but the normal handling of optional AVPs. -- 5.9 Does the advice in this section open up an unmanaged extension vector? In t= he extreme case, would this encourage an external group to register a singl= e application id for a highly extensible application, then bypass IETF exte= nsion processes by just adding more functions to the original application? [LM] in the vendor-specific space, IETF will have no control at all but it = is exactly the principle of vendor-specific application. So this possibilit= y exists. Anyway, as soon as interoperability with the external world is re= quired, application designers will have to adopt common rules and this is t= he aim of this document. =20 -- 8: The security considerations say that this draft does not define nor address= security related protocols or schemes. But there was an entire section ded= icated to the use of IPSec, which certainly seems to address a security rel= ated protocol and scheme.=20 [LM] this section was there before the introduction of the one on IPsec. I = will fix it :) Editorial Comments: -- section 1: I'm confused by list item 2. It seems to talk both about adding new functio= n to an existing application and creating a new application. I suspect this= is about the case of using two applications together to effectively add fu= nction--if so, that could be more clear. [LM] A typical example would be the addition of a new command to an existin= g application and the consequence of such addition would be the creation of= a new application i.e. assignment of a new application-id value. -- section 3, Major Extension case: "... in such a way that this implies ba= ckward compatible change to the existing application ..." Do you mean a _non_ backwards compatible change? [LM] Yes -- section 4.1, third bullet: " Care should be taken to avoid a liberal met= hod of importing existing command's CCF syntax specification." I'm not sure I understand what you mean by a "liberal method of importing"? [LM] "liberal" can be replaced by "general", I think.=20 "This would result in a monolithic and hard to manage applications..."=20 singular/plural disagreement [LM] OK -- 4.2, 2nd paragraph s/" indicates of a flawed design"/"indicates a flawed design" -- 4.3, 2nd paragraph: s/"It is worth to note that"/"It is worth noting that" [Or even better, s= kip the whole clause] s/"in the [RFC3588]"/"in [RFC3588]" [LM] ok -- 4.3.1, title: s/ommand/command [LM] OK -- 4.3.1, 2nd bullet list, 3rd bullet: The second half of this bullet item seems redundant with the previous bulle= t. [LM] OK. I propose to just keep the "different number of roundtrips"=20 -- 5.8 The section may have some meaning obscured by passive voice. In particular,= who foresaw that translation would be easy, who acknowledged that it wasn'= t, and who might foresee the need for RADIUS interworking? (I think those a= re the work group, the work group, and application designers, respectively) [LM] OK. Will use the active voice instead. -- 5.9, third bullet: "Applications that do not understand these AVP can di= scard it ..." singular/plural disagreement [LM] OK. -- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms such= as IPsec can also be deployed to secure connections between Diameter peers= ." Do you mean "IPSec can also be deployed...", or "Additional security mechan= isms such as IPSec can also be deployed..."? [LM] Obviously, something needs to be fixed. Thanks! Ben. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Wed Sep 5 12:21:48 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFC221F8648 for ; Wed, 5 Sep 2012 12:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pIc1jHxYaEM for ; Wed, 5 Sep 2012 12:21:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8621F852A for ; Wed, 5 Sep 2012 12:21:48 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q85JLi0H031573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 14:21:45 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <3092_1346861420_5047796C_3092_8625_1_6B7134B31289DC4FAF731D844122B36E049B19@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Wed, 5 Sep 2012 14:21:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C8502B9-BFCC-4B45-A582-1323E6E68B86@nostrum.com> References: <3092_1346861420_5047796C_3092_8625_1_6B7134B31289DC4FAF731D844122B36E049B19@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:21:48 -0000 Thanks for the response! I've removed sections that appear to be = resoved. Thanks! Ben. On Sep 5, 2012, at 11:10 AM, wrote: >=20 [...] >=20 > -- 5.9 >=20 > Does the advice in this section open up an unmanaged extension vector? = In the extreme case, would this encourage an external group to register = a single application id for a highly extensible application, then bypass = IETF extension processes by just adding more functions to the original = application? >=20 > [LM] in the vendor-specific space, IETF will have no control at all = but it is exactly the principle of vendor-specific application. So this = possibility exists. Anyway, as soon as interoperability with the = external world is required, application designers will have to adopt = common rules and this is the aim of this document. >=20 I agree we can't control what people do in the vendor-specific space. We = have so little control there that there is little point in saying much = about it. My concern is still true for the IETF controlled space, which = is controlled by IETF Review. My concern is that encouraging the use of = AVPs to negotiation features could be used to invoke extensions that = really should be treated as separate applications. The text here seems = to condone that behavior, which could lead an expert reviewer to decide = it was okay for all cases. If we are going to encourage the use of AVPs to negotiation arbitrary = features, we probably need some guidance for said expert reviewer. I = realize this sort of thing would be case-by-case and fairly subjective, = but it seems like we need more guidance than is there now. [...] > Editorial Comments: >=20 [...] >=20 > -- 4.3.1, 2nd bullet list, 3rd bullet: >=20 > The second half of this bullet item seems redundant with the previous = bullet. >=20 > [LM] OK. I propose to just keep the "different number of roundtrips"=20= WFM >=20 > -- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms = such as IPsec can also be deployed to secure connections between = Diameter peers." >=20 > Do you mean "IPSec can also be deployed...", or "Additional security = mechanisms such as IPSec can also be deployed..."? >=20 > [LM] Obviously, something needs to be fixed. >=20 >=20 Do you have thoughts on whether this text is intended to allow just the = use of IPSec (in addition to TLS and DTLS, of course) , or to allow the = more generic "additional mechanisms such as IPSec"? From lionel.morand@orange.com Wed Sep 5 22:57:47 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C139621F845D for ; Wed, 5 Sep 2012 22:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa-XBjc8kzxP for ; Wed, 5 Sep 2012 22:57:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 007BB21F845C for ; Wed, 5 Sep 2012 22:57:45 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 919ED26458D; Thu, 6 Sep 2012 07:57:43 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4254627C115; Thu, 6 Sep 2012 07:57:43 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 18:36:53 +0200 From: To: "A. Jean Mahoney" , "dime@ietf.org" Thread-Topic: [Dime] WGLC review of draft-ietf-dime-app-design-guide-15 Thread-Index: AQHNhSWG0n03DPqst0+L3ckUm0TZFpd7+Qrw Date: Wed, 5 Sep 2012 16:36:52 +0000 Message-ID: <20635_1346911063_50483B57_20635_16166_9_6B7134B31289DC4FAF731D844122B36E049B6B@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <503CCF08.5070008@nostrum.com> In-Reply-To: <503CCF08.5070008@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.5.130618 Subject: Re: [Dime] WGLC review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 05:57:47 -0000 Hi Jean, Thank you very much for this very detailed review and the proposed changes. I'm even surprised to see that there are still some sentences (maybe one or= two) unchanged or without any mistake :) No need to go through all my responses. A global "OK" is enough. Again, thank you! Regards, Lionel=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de A= . Jean Mahoney Envoy=E9=A0: mardi 28 ao=FBt 2012 16:01 =C0=A0: dime@ietf.org; draft-ietf-dime-app-design-guide@tools.ietf.org Objet=A0: [Dime] WGLC review of draft-ietf-dime-app-design-guide-15 Hi all, I didn't find any major issues while reviewing the document. However, I=20 did come up with a long list of nits. The first part of the review offers suggested wording changes to=20 sentences and paragraphs. The second section covers typographical and=20 punctuation errors. Jean 4. p1 s1 (Section 4, paragraph 1, sentence 1): Current: . protocol designers are advised to try to re-use as much as possible existing Diameter applications to simplify standardization, implementation and avoid potential interoperability issues. Suggested: . protocol designers are advised to reuse as much as possible existing Diameter applications in order to simplify standardization and implementation, and to avoid potential interoperability issues. [LM] ok 4.3 p2 s3: Current: Therefore, if it is still recommended to re-use as much as possible existing commands, protocol designers can consider more easily the definition of a new command when it is a solution more suitable than twisting existing command use and applications. Suggested: Although reuse of existing commands is still recommended, protocol designers can consider defining a new command when it provides a solution more suitable than the twisting of an existing command's use and applications. [LM] ok 4.3.1 p2 s5: Current: Here is a list of few common questions that application designers should wonder when trying to decide: Suggested: Application designers should consider the following questions when deciding to set the M-bit for a new AVP: [LM] ok 4.3.2 p1 s1: Current: When deleting an AVP from a command, the following cases need to be differentiated: Suggested: The impacts of deleting an AVP from a command depend on its command code format specification and M-bit setting: [LM] ok 5.4 p1 s2: Current: When a new application is being defined that cannot clearly be categorized into any of these services it is recommended that the application itself define its own session state machine. The existing session state machines defined by [I-D.ietf-dime-rfc3588bis] is not intended for general use beyond AAA services, therefore any behavior not covered by that category would not fit well. Suggested: If a new application cannot clearly be categorized into any of these services, it is recommended that the application define its own session state machine. The session state machines defined by [I-D.ietf-dime-rfc3588bis] are not intended to cover behavior outside of AAA. [LM] ok 5.6 p2 s2: Current: This has to be considered as a sub-optimal design as this limits the extensibility of the application: any new capability/permission would have to be supported by a new AVP or new Enumerated value of the already defined AVP that would cause in consequence backwards compatibility issues with existing implementations. Suggested: This is a sub-optimal design since it limits the extensibility of the application: any new capability/permission would have to be supported by a new AVP or new Enumerated value of the already defined AVP, causing backwards compatibility issues with existing implementations. [LM] ok 5.6 p3: Current: Instead of defining Enumerated AVP when the AVP simply used as a Boolean flag, protocol designers are encouraged to rely on AVP defined in the form of a bit mask with the interpretation of the setting of each bit described in the relevant Diameter application specification. Such AVPs can be reused and extended to multiplex several indications without major impact on the Diameter application. The bit-mask should be therefore long enough to leave room for future additions. Examples of AVP defined as bit mask are the Session- Binding AVP defined in [I-D.ietf-dime-rfc3588bis] and the MIP6- Feature-Vector AVP defined in [RFC5447] Suggested: Instead of using an Enumerated AVP for a Boolean flag, protocol designers are encouraged to use a bit mask AVP whose bit settings are described in the relevant Diameter application specification. Such AVPs can be reused and extended without major impact on the Diameter application. The bit mask AVP should leave room for future additions. Examples of bit mask AVPs are the Session-Binding AVP [I-D.ietf-dime-rfc3588bis] and the MIP6-Feature-Vector AVP [RFC5447]. [LM] ok 5.7 p3: Current: Example of such specific routing function can be found the applications defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx applications ([TS29.228] and [TS29.229]) in which the Subscriber Location Function (SLF) is defined a proxy agent (or enhanced Redirect agent) using specific application-level identities found in the request to determine the final destination of the message. Suggested: Examples of such application-specific routing functions can be found in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP Multimedia Subsystem, in which the proxy agent (Subscriber Location Function) uses application-level identities found in the request to determine the final destination of the message. [LM] ok 5.7 p4 s2: Current: In particular, this ensures that Diameter agents in the request routing path (Relay or Proxy agents) will be able to correctly release the transaction state associated to the request upon receipt of the answer, avoiding thus unnecessary failover triggering due to non reception of the answer corresponding to the request. Application designers are strongly recommended to not attempt to modify the answer routing principles described in [I-D.ietf-dime-rfc3588bis] when defining a new application. Suggested: In particular, this ensures that the Diameter Relay or Proxy agents in the request routing path will be able to release the transaction state upon receipt of the corresponding answer, avoiding unnecessary failovers. Application designers are strongly dissuaded from modifying the answer-routing principles described in [I-D.ietf-dime-rfc3588bis] when defining a new application. [LM] ok 5.8 p2: Current: In the specific case of RADIUS, it was initially foreseen that the translation function would have been straightforward to define and deploy by adopting few basic principles e.g. use of a shared range of code values for RADIUS attributes and Diameter AVPs, some guidelines on translation and management of key information (such as authentication parameter, routing/accounting or states), etc. And all this material was put in the RFC 4005 ([RFC4005]) to be used as generic guideline for implementation of RADIUS-Diameter translation agent. Suggested: In the case of RADIUS, it was initially thought that defining the translation function would be straightforward. Guidelines for implementing a RADIUS-Diameter translation agent were put into RFC 4005 ([RFC4005]). [LM] ok. 5.8 p4 s1: Current: Therefore, when interoperability with RADIUS infrastructure is foreseen, protocol designers are advised that they cannot assume the availability of "standard" Diameter-to-RADIUS gateways agent and the required translation mechanism should be then specified along with the Diameter application. And the recommendation in the case of RADIUS-Diameter interworking applies of course for any other kind of translation (e.g. Diameter/MAP). Suggested: Therefore, protocol designers cannot assume the availability of a "standard" Diameter-to-RADIUS gateways agent when planning to interoperate with the RADIUS infrastructure. They should specify the required translation mechanism along with the Diameter application. This recommendation applies for any kind of translation (e.g. Diameter/MAP). [LM] ok 5.9 p2 and bullets: Current: The end-to-end capabilities AVPs can aid in the following cases: o Formalizing the way new functionality is added to existing applications by announcing support for it. o Applications that do not understand these AVP can discard it upon receipt. In such case, senders of the AVP can also safely assume the receiving end-point does not support any functionality carried by the AVP if it is not present in subsequent responses. o Useful in cases where deployment choices are offered and the generic design can be made available for a number of applications. Suggested: The end-to-end capabilities AVPs formalize the addition of new functionality to existing applications by announcing support for it. Applications that do not understand these AVPs can discard them upon receipt. Senders of the AVP can safely assume the receiving end-point does not support any functionality carried by the AVP if it is not present in subsequent responses. This is useful in cases where deployment choices are offered, and the generic design can be made available for a number of applications. [LM] ok 6. p2 b3 s3: Current: However, the drawback is that the timing of sending extension data will be tied to when the application would be sending a message. This has consequences if the application and the extensions have different timing requirements. Suggested: However, this ties the sending of extension data to the application's transmission of a message. This has consequences if the application and the extensions have different timing requirements. [LM] ok 6. p3 s1: Current: In practice, it is often the case that the generic extensions use optional AVPs because it's simple and not intrusive to the application that would carry it. Suggested: In practice, generic extensions often use optional AVPs because they are simple and nonintrusive to the application that would carry them. [LM] ok Nits: 3. p2 s2: "completly" -> "completely" 4.1 p1 s3: "create an new" -> "create a new" 4.1 p3 s1: "case by case" -> "case-by-base" 4.1 p3 b3 s1: "importing existing" -> "importing an existing" 4.1 p3 b3 s2: "applications" -> "application" remove the stray period at the end. 4.2 p1 s1: "to an application" -> "from an application" 4.2 p1 s2: "this" -> "This" 4.2 p2 s3: "which" -> "that" 4.3.1 heading: "ommand" -> "Command" 4.3.1 p1 b1 s2: "node receiving are" -> "node receiving them is" 4.3.1 p1 b2 s1: "receiving these AVP" -> "receiving these AVPs" 4.3.1 p2 b4 s1: "application related" -> "application-related" 4.3.1 p4 s1: "contemplating on the" -> "contemplating the" 4.3.1 p4 b2: "applications data" -> "application data" 4.3.1 p4 b3: "a mandatory AVPs" -> "a mandatory AVP" 4.4.1 p2 s1: add period after "unchanged" 5.1 p3 s1: add comma after "extensibility" 5.2 p1 s1: "Reusing" -> "reusing" 5.2 p1 s3: "pratices" -> "practices" 5.3 p1 s1 and s2: "session level" -> "session-level" 5.4 p1 s4: "server initiated" -> "server-initiated" 5.5 p3 s1: delete "really" 5.5 p3 s3: "by the application the" -> "by the application, the" 5.6 p1 s1: "provide list" -> "provide a list" 5.6 p1 s2: "perform on" -> "perform upon" 5.6 p2 s1: "as simple" -> "as a simple" 5.7 p2 s1: add comma after "suitable" 5.7 p4 s1: ", the answer" -> ", with the answer" "Hop-by-hop" -> "hop-by-hop" 5.8 p3 s2: remove "will likely" add comma after "specification" 5.10 p1 s1: "which" -> "that" 5.10 p2 s4: delete "generally" 5.10 p3 s2: delete "somehow" 5.10 p3 s3: "to be have" -> "to have" delete "uniquely" 5.10 p3 s4: add comma after "existing AVPs" "records" -> "record" 5.11 p1 s2: "However, IPsec Additional" -> "However, additional" 5.11 p2 s3: add comma after "pre-shared key" 5.11 p3 s1: "as security mechanisms" -> "as the security mechanism" 6 p2 b3 s2: "applications; However" -> "applications. However" 6 p2 b3 s5: add comma after "issue" 6 p3 s4: add comma after "set of applications" 8 p1 s1: delete "does" 8 p1 s2: "security related" -> "security-related" Throughout the document: "Diameter Base protocol" -> "Diameter base protocol" "application specific" -> application-specific" "tradeoff" -> "trade-off" _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From lionel.morand@orange.com Thu Sep 6 00:09:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6379921F850D for ; Thu, 6 Sep 2012 00:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmWIt+GJHBDF for ; Thu, 6 Sep 2012 00:09:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8664321F850C for ; Thu, 6 Sep 2012 00:09:52 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3413122C576 for ; Thu, 6 Sep 2012 09:09:51 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D3AB4C108 for ; Thu, 6 Sep 2012 09:09:51 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 09:09:50 +0200 From: To: "dime@ietf.org" Thread-Topic: Help the NomCom: Nominations and Feedback Thread-Index: AQHNi8WSlbjpuxTY2EOKYLI5QOei4Zd85Wvw Date: Thu, 6 Sep 2012 07:09:50 +0000 Message-ID: <2438_1346915391_50484C3F_2438_4855_1_6B7134B31289DC4FAF731D844122B36E04FEE5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.6.55415 Subject: [Dime] Help the NomCom: Nominations and Feedback X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:09:53 -0000 RllJIGFuZCBhY3Rpb24hDQoNClJlZ2FyZHMsDQoNCkxpb25lbCBhbmQgSm91bmkNCg0KLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiB3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86d2djaGFpcnMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBOb21Db20gQ2hh aXINCkVudm95w6nCoDogamV1ZGkgNiBzZXB0ZW1icmUgMjAxMiAwMjoyMQ0Kw4DCoDogV29ya2lu ZyBHcm91cCBDaGFpcnMNCk9iamV0wqA6IEhlbHAgdGhlIE5vbUNvbTogTm9taW5hdGlvbnMgYW5k IEZlZWRiYWNrDQoNClRoZSBJRVRGIE5vbWluYXRpb25zIENvbW1pdHRlZSAoTm9tQ29tKSBpcyBj dXJyZW50bHkgc2Vla2luZyANCm5vbWluYXRpb25zIGZvciBpbmRpdmlkdWFscyB0byBzZXJ2ZSBv biB0aGUgSUVTRywgSUFCLCBhbmQgSUFPQy4gDQpBZGRpdGlvbmFsbHksIHRoaXMgaXMgYW4gYW5u b3VuY2VtZW50IHRoYXQgdGhlIE5vbUNvbSBpcyBzZWVraW5nIA0KZmVlZGJhY2sgb24gaW5kaXZp ZHVhbHMgd2hvIGhhdmUgYWNjZXB0ZWQgbm9taW5hdGlvbnMgZm9yIElFVEYgDQpsZWFkZXJzaGlw IHBvc2l0aW9ucy4gDQoNCkl0IGlzIHZlcnkgaW1wb3J0YW50IHRvIHRoZSBOb21Db20gcHJvY2Vz cyB0aGF0IHdlIGdldCBpbnB1dCBmcm9tIGEgDQpicm9hZCBzcGVjdHJ1bSBvZiB0aGUgY29tbXVu aXR5LiBUaGVyZWZvcmUsIGluIGNhc2UgbWVtYmVycyBvZiB5b3VyIA0Kd29ya2luZyBncm91cCBk byBub3QgcmVhZCB0aGUgSUVURiBhbm5vdW5jZW1lbnQgYW5kIGRpc2N1c3Npb24gbGlzdHMsIA0K dGhlIE5vbUNvbSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgaGVscCBpbiBkaXNzZW1pbmF0aW5nIHRo ZSBmb2xsb3dpbmcgDQppbmZvcm1hdGlvbi4NCg0KVGhlIE5vbUNvbSB3ZWJzaXRlIGNvbnRhaW5z IGluZm9ybWF0aW9uIGFib3V0IHRoaXMgeWVhcidzIE5vbUNvbSANCmluY2x1ZGluZyB0aGUgcG9z aXRpb25zIHdlIGFyZSBzZWVraW5nIHRvIGZpbGwsIGFuZCB0aGUgcXVhbGlmaWNhdGlvbnMgDQpy ZXF1aXJlZCBmb3IgdGhlc2UgcG9zaXRpb25zOg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9ncm91 cC9ub21jb20vMjAxMi8NCg0KVGhlIE5vbUNvbSBpcyBhY2NlcHRpbmcgbm9taW5hdGlvbnMgdW50 aWwgU2VwdGVtYmVyIDI0LiBOb21pbmF0aW9ucyANCmZvciBhbnkgcG9zaXRpb24gY2FuIGJlIG1h ZGUgdXNpbmcgdGhlIGZvbGxvd2luZyB3ZWIgdG9vbDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv Z3JvdXAvbm9tY29tLzIwMTIvbm9taW5hdGUNCg0KRmVlZGJhY2sgYWJvdXQgaW5kaXZpZHVhbHMg d2hvIHRoZSBOb21Db20gaXMgY29uc2lkZXJpbmcgY2FuIGJlIA0KcHJvdmlkaW5nIHVzaW5nIHRo ZSBmb2xsb3dpbmcgd2ViIHRvb2w6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNv bS8yMDEyL2lucHV0DQoNClRoZSBmZWVkYmFjayB0b29sIHByb3ZpZGVzIGEgbGlzdCBvZiBpbmRp dmlkdWFscyB3aG8gaGF2ZSBhZ3JlZWQgdG8gYmUgDQpjb25zaWRlcmVkIGZvciBlYWNoIHBvc2l0 aW9uLiBXZSB3aWxsIGJlIHVwZGF0aW5nIHRoaXMgbGlzdCBpbiB0aGUgY29taW5nIA0Kd2Vla3Mg YXMgbW9yZSBpbmRpdmlkdWFscyBhY2NlcHQgbm9taW5hdGlvbnMuDQoNCkZlZWRiYWNrIHByb3Zp ZGVkIHRvIHRoZSBOb21Db20gaXMga2VwdCBzdHJpY3RseSBjb25maWRlbnRpYWwhDQoNCk5vdGUg dGhhdCB1c2Ugb2YgdGhlIE5vbUNvbSB3ZWIgdG9vbHMgcmVxdWlyZSBhbiBpZXRmLm9yZyAoaS5l LiwNCmRhdGF0cmFja2VyKSBhY2NvdW50LiBZb3UgY2FuIGNyZWF0ZSBhbiBpZXRmLm9yZyBhY2Nv dW50IGJ5IHZpc2l0aW5nIHRoZQ0KZm9sbG93aW5nIFVSTDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvDQoNCkFzIGFuIGFsdGVybmF0aXZlIHRvIHVzaW5n IHRoZSB3ZWIgdG9vbHMsICB5b3UgY2FuIHNlbmQgZW1haWwgdG8gdGhlDQpOb21Db20gYXQgbm9t Y29tMTJAaWV0Zi5vcmcgdG8gbWFrZSBhIG5vbWluYXRpb24gb3IgcHJvdmlkZSBpbnB1dCB0bw0K dGhlIGNvbW1pdHRlZS4NCg0KVGhhbmsgeW91IGZvciB5b3VyIGhlbHAsDQotIE1hdHQgTGVwaW5z a2kNCiAgbm9tY29tLWNoYWlyQGlldGYub3JnDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZy YW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From jouni.nospam@gmail.com Thu Sep 6 01:31:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20421F847B for ; Thu, 6 Sep 2012 01:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKel+R8GqZcD for ; Thu, 6 Sep 2012 01:31:09 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC221F8468 for ; Thu, 6 Sep 2012 01:31:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so872338wgb.13 for ; Thu, 06 Sep 2012 01:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=TeRB507zaTJui3P31sG7j2g/nON92XDqZr1GwL7Xa44=; b=mAxSGYvpzexUWNOXHhz9+FzlgsRlQeY/oUuUmC9TV7OkfpZTk4xuv+zR6+phCi3/ea O2smWDjFbOsLpckR2j/rrffCyCuE4lTDFbMofjuUfKSDk1tHgg5jbzNqzZhx33SyE2LM J+xghKghv8OJgYCvKjjkq6b700jEXSBkASIxIdO6PuGIqMhtVMFP+UdINNYju+KGK4uV 1YslI5x43HVQyi8CFMzc0bQ2CbMAVARFVj8WUA5Vl+jthYx+x/UJuwRZvPMiWmVPvk7N xvsFHn/OCW4Fq+81TuTD2qMhCep6lWARC++tWuQ03aB0jz327JQZFWApH0p8yNEeKiGo Gd9Q== Received: by 10.216.153.207 with SMTP id f57mr810497wek.196.1346920267766; Thu, 06 Sep 2012 01:31:07 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id l5sm4217321wix.5.2012.09.06.01.31.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2012 01:31:06 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Sep 2012 11:31:04 +0300 Message-Id: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:31:09 -0000 Folks, This email starts a two week consensus call on adopting: Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-mcmurry-dime-overload-reqs-02.txt Pages : 25 Date : 2012-08-28 as a Dime WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to the chairs. This call will end September 20, 2012. - Jouni & Lionel From ben@nostrum.com Thu Sep 6 06:51:37 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302BA21F866A for ; Thu, 6 Sep 2012 06:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m76zspcp8bj for ; Thu, 6 Sep 2012 06:51:36 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4D621F84B6 for ; Thu, 6 Sep 2012 06:51:36 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q86DpQt3040414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2012 08:51:27 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Date: Thu, 6 Sep 2012 08:51:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0BF1FFDF-FD6A-4122-A58A-61BB7905BC00@nostrum.com> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:51:37 -0000 I support making this draft a work group item. (I assume that's obvious, = but still worth stating for the record :-) ) Thanks! Ben. On Sep 6, 2012, at 3:31 AM, jouni korhonen = wrote: > Folks, >=20 > This email starts a two week consensus call on adopting: >=20 > Title : Diameter Overload Control Requirements > Author(s) : Eric McMurry > Ben Campbell > Filename : draft-mcmurry-dime-overload-reqs-02.txt > Pages : 25 > Date : 2012-08-28 >=20 > as a Dime WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or > to the chairs. This call will end September 20, 2012. >=20 > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From adam@nostrum.com Thu Sep 6 06:58:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3B321F8546 for ; Thu, 6 Sep 2012 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.976 X-Spam-Level: X-Spam-Status: No, score=-100.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K11EsWsYuft4 for ; Thu, 6 Sep 2012 06:58:50 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id DF6CE21F8530 for ; Thu, 6 Sep 2012 06:58:43 -0700 (PDT) Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q86DwREA099513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2012 08:58:39 -0500 (CDT) (envelope-from adam@nostrum.com) References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> <0BF1FFDF-FD6A-4122-A58A-61BB7905BC00@nostrum.com> In-Reply-To: <0BF1FFDF-FD6A-4122-A58A-61BB7905BC00@nostrum.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6A704613-9DD9-42BC-9399-A02AF650EC74@nostrum.com> X-Mailer: iPad Mail (9B206) From: Adam Roach Date: Thu, 6 Sep 2012 08:58:26 -0500 To: Ben Campbell Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:58:51 -0000 I do as well. /a On Sep 6, 2012, at 8:51, Ben Campbell wrote: > I support making this draft a work group item. (I assume that's obvious, b= ut still worth stating for the record :-) ) >=20 > Thanks! >=20 > Ben. >=20 > On Sep 6, 2012, at 3:31 AM, jouni korhonen wrote:= >=20 >> Folks, >>=20 >> This email starts a two week consensus call on adopting: >>=20 >> Title : Diameter Overload Control Requirements >> Author(s) : Eric McMurry >> Ben Campbell >> Filename : draft-mcmurry-dime-overload-reqs-02.txt >> Pages : 25 >> Date : 2012-08-28 >>=20 >> as a Dime WG document. Please state your opinion (either for or >> against) on making this draft a WG draft either on the mailing list or >> to the chairs. This call will end September 20, 2012. >>=20 >> - Jouni & Lionel >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jens.schendel@nsn.com Thu Sep 6 07:19:19 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CC121F867C for ; Thu, 6 Sep 2012 07:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdWIYRS45IAy for ; Thu, 6 Sep 2012 07:19:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D2BA421F8630 for ; Thu, 6 Sep 2012 07:19:17 -0700 (PDT) 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 q86EJDe4003574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Sep 2012 16:19:13 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q86EJCUW025397; Thu, 6 Sep 2012 16:19:13 +0200 Received: from DEMUEXC027.nsn-intra.net ([10.150.128.19]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Sep 2012 16:19:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD8C3A.924F9BBA" Date: Thu, 6 Sep 2012 16:19:04 +0200 Message-ID: In-Reply-To: <5047024C.5070806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) Thread-Index: Ac2LOf4lanhHdIrgRoirTgQcdfatZAA/XGdQ References: <5047024C.5070806@cisco.com> From: "Schendel, Jens (NSN - DE/Berlin)" To: "ext Benoit Claise" , "dime mailing list" X-OriginalArrivalTime: 06 Sep 2012 14:19:06.0118 (UTC) FILETIME=[92B8AA60:01CD8C3A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 18630 X-purgate-ID: 151667::1346941153-00006F5F-6DB84154/0-0/0-0 Cc: xkiranj.1980@gmail.com Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:19:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD8C3A.924F9BBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I agree with the proposed change. Actually, the Credit Control Server may decide to apply immediate redirect for some other reason than zero balance (which is given as explanation in the RFC text), i.e. for some other advice like charge rate or so. I also believe that the original wording (even if not completed) would have been different if zero GSU were indented. So, pretty clear to me. =20 Jens =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Benoit Claise Sent: Wednesday, September 05, 2012 9:42 AM To: dime mailing list Cc: xkiranj.1980@gmail.com Subject: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) =20 Dear all, This errata has been submitted. While this looks right me, I always prefer to have a confirmation from the experts... Regards, Benoit. -------- Original Message --------=20 Subject:=20 Re: [Editorial Errata Reported] RFC4006 (3329) Date:=20 Thu, 23 Aug 2012 12:00:03 +0200 From:=20 Kiran Jadhav =20 To:=20 RFC Errata System =20 CC:=20 Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, david@mitton.com Hello All,=20 =20 I have reported an Editorial Errata for RFC4006. =20 This small editorial errata in the RFC4006 is causing issues in some call scenarios where the end user is given an option by the Service Provider to replenish his credit if it is found at the start of a call that the end-user's account balance is zero/insufficient. This is basically due to mis-interpretation of the sentence in the RFC by different vendors. =20 Please have a look at the suggested change which will help a common implementation of the behavior across all vendors. =20 Best Regards, Kiran Jadhav On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System wrote: The following errata report has been submitted for RFC4006, "Diameter Credit-Control Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=3D3329 -------------------------------------- Type: Editorial Reported by: Kiran Jadhav Section: 5.6.2 Original Text ------------- " Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A." Corrected Text -------------- " Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A." Notes ----- In the sentence "The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is not clear whether the sentence refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=3D0 (Granted-Service-Unit AVP with value 0". Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=3D0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=3D0. This causes = the call to enter a loop and terminate with an error. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4006 (draft-ietf-aaa-diameter-cc-06) -------------------------------------- Title : Diameter Credit-Control Application Publication Date : August 2005 Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG =20 =20 =20 ------_=_NextPart_001_01CD8C3A.924F9BBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

H= i,

<= o:p> 

I= agree with the proposed change. Actually, the Credit Control Server may = decide to apply immediate redirect for some other reason than zero = balance (which is given as explanation in the RFC text), i.e. for some = other advice like charge rate or so.

I= also believe that the original wording (even if not completed) would = have been different if zero GSU were indented.

S= o, pretty clear to me.

<= o:p> 

J= ens

<= o:p> 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of ext Benoit Claise
Sent: Wednesday, September 05, 2012 = 9:42 AM
To: dime mailing list
Cc: = xkiranj.1980@gmail.com
Subject: [Dime] Fwd: Re: [Editorial = Errata Reported] RFC4006 (3329)

 

Dear = all,

This errata has been submitted.
While this looks right = me, I always prefer to have a confirmation from the = experts...

Regards, Benoit.



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

=

Subject:

Re: [Editorial = Errata Reported] RFC4006 (3329)

Date: =

Thu, 23 Aug 2012 12:00:03 = +0200

From:

Kiran Jadhav <xkiranj.1980@gmail.com>=

To:

RFC Errata System = <rfc-editor@rfc-editor.org&g= t;

CC:

Harri.Hakala@ericsson.com, = Leena.Mattila@ericsson.com= , juha-pekka.koskinen@nokia.c= om, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, = david@mitton.com



Hello All, =

 

I = have reported an Editorial Errata  for RFC4006.

 

This small = editorial errata in the RFC4006 is causing issues in some call scenarios = where the end user is given an option by the Service Provider to = replenish his credit if it is found at the start of a call that the = end-user's account balance is zero/insufficient. This is basically due = to mis-interpretation of the sentence in the RFC by different = vendors.

 

Please have a = look at the suggested change which will help a common implementation of = the behavior across all vendors.

 

Best = Regards,

Kiran = Jadhav

On Thu, Aug 23, = 2012 at 11:13 AM, RFC Errata System <rfc-editor@rfc-editor.org> = wrote:


The following errata = report has been submitted for RFC4006,
"Diameter Credit-Control = Application".

--------------------------------------
You = may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4006&= amp;eid=3D3329

--------------------------------------
Type:= Editorial
Reported by: Kiran Jadhav <xkiranj.1980@gmail.com>
=
Section: 5.6.2

Original Text
-------------
" Note = that the credit-control server may already have initiated = the
above-described process for the first interrogation. However, = the
user's account might be empty when this first interrogation = is
performed. In this case, the subscriber can be offered a chance = to
replenish the account and continue the service. The = credit-control
client receives a Credit-Control-Answer or service = specific
authorization answer with the Final-Unit-Indication and = Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts = the graceful
service termination without sending any message to the = server. An
example of this case is illustrated in Appendix = A."

Corrected Text
--------------
" Note that the = credit-control server may already have initiated the
above-described = process for the first interrogation. However, the
user's account = might be empty when this first interrogation is
performed. In this = case, the subscriber can be offered a chance to
replenish the account = and continue the service. The credit-control
client receives a = Credit-Control-Answer or service specific
authorization answer with = the Final-Unit-Indication and Validity-Time
AVPs but no = Granted-Service-Unit AVP. It immediately starts the graceful
service = termination without sending any message to the server. An
example of = this case is illustrated in Appendix = A."

Notes
-----
In the sentence "The = credit-control
client receives a Credit-Control-Answer or service = specific
authorization answer with the Final-Unit-Indication and = Validity-Time
AVPs but no Granted-Service-Unit." it is important = that we add the letters "AVP" after Granted-Service-Units as = it is not clear whether the sentence refers to "Not sending = Granted-Service-Unit AVP at all" or "sending GSU=3D0 = (Granted-Service-Unit AVP with value 0".

Different OCS = vendors interpret the sentence above in a different way, some do not = send the Granted-Service-Unit AVP at all, while some others send the = Granted_Service-Unit=3D0. And this causes problem in the call scenario = where FUI+Redirect is sent together with GSU=3D0. This causes the call = to enter a loop and terminate with an = error.

Instructions:
-------------
This errata is currently = posted as "Reported". If necessary, please
use "Reply = All" to discuss whether it should be verified or
rejected. When = a decision is reached, the verifying party (IESG)
can log in to = change the status and edit the report, if = necessary.

--------------------------------------
RFC4006 = (draft-ietf-aaa-diameter-cc-06)
--------------------------------------=
Title               : Diameter = Credit-Control Application
Publication Date    : August = 2005
Author(s)           : H. Hakala, L. = Mattila, J-P. Koskinen, M. Stura, J. Loughney
Category     =        : PROPOSED STANDARD
Source     =          : Authentication, Authorization and = Accounting
Area               =  : Operations and Management
Stream         =      : IETF
Verifying Party     : = IESG

 

 

 

------_=_NextPart_001_01CD8C3A.924F9BBA-- From emcmurry@estacado.net Thu Sep 6 07:56:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EE321F86B3 for ; Thu, 6 Sep 2012 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMUOsw6eUwHQ for ; Thu, 6 Sep 2012 07:56:14 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 440F121F857A for ; Thu, 6 Sep 2012 07:56:14 -0700 (PDT) Received: from ericlaptop.casamcmurry.com (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q86Eu5ak011684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2012 09:56:11 -0500 (CDT) (envelope-from emcmurry@estacado.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Eric McMurry In-Reply-To: <6A704613-9DD9-42BC-9399-A02AF650EC74@nostrum.com> Date: Thu, 6 Sep 2012 09:56:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <07F875B8-9FDA-4C07-BF22-3F56951AB574@estacado.net> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> <0BF1FFDF-FD6A-4122-A58A-61BB7905BC00@nostrum.com> <6A704613-9DD9-42BC-9399-A02AF650EC74@nostrum.com> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1486) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:56:14 -0000 I add my own obvious support also :-) On Sep 6, 2012, at 8:58 , Adam Roach wrote: > I do as well. >=20 > /a >=20 > On Sep 6, 2012, at 8:51, Ben Campbell wrote: >=20 >> I support making this draft a work group item. (I assume that's = obvious, but still worth stating for the record :-) ) >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> On Sep 6, 2012, at 3:31 AM, jouni korhonen = wrote: >>=20 >>> Folks, >>>=20 >>> This email starts a two week consensus call on adopting: >>>=20 >>> Title : Diameter Overload Control Requirements >>> Author(s) : Eric McMurry >>> Ben Campbell >>> Filename : draft-mcmurry-dime-overload-reqs-02.txt >>> Pages : 25 >>> Date : 2012-08-28 >>>=20 >>> as a Dime WG document. Please state your opinion (either for or >>> against) on making this draft a WG draft either on the mailing list = or >>> to the chairs. This call will end September 20, 2012. >>>=20 >>> - Jouni & Lionel >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 lionel.morand@orange.com Thu Sep 6 08:37:23 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283A321F8462 for ; Thu, 6 Sep 2012 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSZWneO8Je7O for ; Thu, 6 Sep 2012 08:37:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 42EDA21F8722 for ; Thu, 6 Sep 2012 08:37:21 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2874E3240F3; Thu, 6 Sep 2012 17:37:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 071382380E8; Thu, 6 Sep 2012 17:37:20 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 17:37:19 +0200 From: To: "Schendel, Jens (NSN - DE/Berlin)" , "ext Benoit Claise" , dime mailing list Thread-Topic: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) Thread-Index: AQHNizn7NiAnaqbguUKjJAabOrmBl5d9PScAgAA3CWA= Date: Thu, 6 Sep 2012 15:37:18 +0000 Message-ID: <30054_1346945840_5048C330_30054_2332_1_6B7134B31289DC4FAF731D844122B36E059579@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5047024C.5070806@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E059579PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.6.104516 Cc: "xkiranj.1980@gmail.com" Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:37:23 -0000 --_000_6B7134B31289DC4FAF731D844122B36E059579PEXCVZYM11corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The EDITORIAL change is correct. Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Sch= endel, Jens (NSN - DE/Berlin) Envoy=E9 : jeudi 6 septembre 2012 16:19 =C0 : ext Benoit Claise; dime mailing list Cc : xkiranj.1980@gmail.com Objet : Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) Hi, I agree with the proposed change. Actually, the Credit Control Server may d= ecide to apply immediate redirect for some other reason than zero balance (= which is given as explanation in the RFC text), i.e. for some other advice = like charge rate or so. I also believe that the original wording (even if not completed) would have= been different if zero GSU were indented. So, pretty clear to me. Jens From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext= Benoit Claise Sent: Wednesday, September 05, 2012 9:42 AM To: dime mailing list Cc: xkiranj.1980@gmail.com Subject: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) Dear all, This errata has been submitted. While this looks right me, I always prefer to have a confirmation from the = experts... Regards, Benoit. -------- Original Message -------- Subject: Re: [Editorial Errata Reported] RFC4006 (3329) Date: Thu, 23 Aug 2012 12:00:03 +0200 From: Kiran Jadhav To: RFC Errata System CC: Harri.Hakala@ericsson.com, Leena.Mattila@= ericsson.com, juha-pekka.koskinen@nokia.= com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, david@mitton.com Hello All, I have reported an Editorial Errata for RFC4006. This small editorial errata in the RFC4006 is causing issues in some call s= cenarios where the end user is given an option by the Service Provider to r= eplenish his credit if it is found at the start of a call that the end-user= 's account balance is zero/insufficient. This is basically due to mis-inter= pretation of the sentence in the RFC by different vendors. Please have a look at the suggested change which will help a common impleme= ntation of the behavior across all vendors. Best Regards, Kiran Jadhav On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System > wrote: The following errata report has been submitted for RFC4006, "Diameter Credit-Control Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=3D3329 -------------------------------------- Type: Editorial Reported by: Kiran Jadhav > Section: 5.6.2 Original Text ------------- " Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A." Corrected Text -------------- " Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A." Notes ----- In the sentence "The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit." it is important that we add the letters = "AVP" after Granted-Service-Units as it is not clear whether the sentence r= efers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=3D0 = (Granted-Service-Unit AVP with value 0". Different OCS vendors interpret the sentence above in a different way, some= do not send the Granted-Service-Unit AVP at all, while some others send th= e Granted_Service-Unit=3D0. And this causes problem in the call scenario wh= ere FUI+Redirect is sent together with GSU=3D0. This causes the call to ent= er a loop and terminate with an error. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4006 (draft-ietf-aaa-diameter-cc-06) -------------------------------------- Title : Diameter Credit-Control Application Publication Date : August 2005 Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Lo= ughney Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E059579PEXCVZYM11corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

The EDITORIAL change is correct.

 

Regards,

 

Lionel

 

De : dime-bounces@i= etf.org [mailto:dime-bounces@ietf.org] De la part de Schendel, Jens (NSN - DE/Berlin)
Envoy=E9 : jeudi 6 septembre 2012 16:19
=C0 : ext Benoit Claise; dime mailing list
Cc : xkiranj.1980@gmail.com
Objet : Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006= (3329)

 

Hi,

 

I agree with the proposed change. Actually, the Credit Control = Server may decide to apply immediate redirect for some other reason than ze= ro balance (which is given as explanation in the RFC text), i.e. for some other advic= e like charge rate or so.

I also believe that the original wording (even if not completed= ) would have been different if zero GSU were indented.

So, pretty clear to me.

 

Jens

 

From: dime-bounces@ietf.org [mailto= :dime-bounces@ietf.org] On Behalf Of ext Benoit Claise
Sent: Wednesday, September 05, 2012 9:42 AM
To: dime mailing list
Cc: xkiranj.1980@gmail.com
Subject: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)<= o:p>

 

Dear all,

This errata has been submitted.
While this looks right me, I always prefer to have a confirmation from the = experts...

Regards, Benoit.



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

Subjec= t:

Re: [Editorial Errata Reported] RFC4006 (3329)<= /o:p>

Date: =

Thu, 23 Aug 2012 12:00:03 +0200

From: =

Kiran Jadhav <xkiranj.1980@gmail.com>

To:

RFC Errata System <rfc-editor@rfc-editor.org>

CC:

Harri.H= akala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco= .com, Bernard_Aboba@hotmail.com,= david@mitton.com



Hello All,

 

I have reported an Editorial Errat= a  for RFC4006.

 

This small editorial errata in the RFC4006 is causing issues= in some call scenarios where the end user is given an option by the Servic= e Provider to replenish his credit if it is found at the start of a call that the end-user's account b= alance is zero/insufficient. This is basically due to mis-interpretation of= the sentence in the RFC by different vendors.

 

Please have a look at the suggested change which will help a= common implementation of the behavior across all vendors.

 

Best Regards,

Kiran Jadhav=

On Thu, Aug 23, 2012 at 11:13 AM, = RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D4006&eid=3D3329

--------------------------------------
Type: Editorial
Reported by: Kiran Jadhav <xki= ranj.1980@gmail.com>

Section: 5.6.2

Original Text
-------------
" Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Corrected Text
--------------
" Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Notes
-----
In the sentence "The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit." it is important that we add the let= ters "AVP" after Granted-Service-Units as it is not clear whether= the sentence refers to "Not sending Granted-Service-Unit AVP at all&q= uot; or "sending GSU=3D0 (Granted-Service-Unit AVP with value 0".

Different OCS vendors interpret the sentence above in a different way, some= do not send the Granted-Service-Unit AVP at all, while some others send th= e Granted_Service-Unit=3D0. And this causes problem in the call scenario wh= ere FUI+Redirect is sent together with GSU=3D0. This causes the call to enter a loop and terminate with an e= rror.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title               : Diameter Credit-Co= ntrol Application
Publication Date    : August 2005
Author(s)           : H. Hakala, L. Mattila, J-P. = Koskinen, M. Stura, J. Loughney
Category            : PROPOSED STANDARD
Source              : Authentication, Au= thorization and Accounting
Area                : Operations an= d Management
Stream              : IETF
Verifying Party     : IESG

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E059579PEXCVZYM11corpora_-- From wc5257@att.com Thu Sep 6 08:44:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A321F8738 for ; Thu, 6 Sep 2012 08:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEGMPHW8kE9h for ; Thu, 6 Sep 2012 08:44:55 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 55EFD21F8736 for ; Thu, 6 Sep 2012 08:44:55 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 7f4c8405.69879940.945702.00-540.2616138.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 06 Sep 2012 15:44:55 +0000 (UTC) X-MXL-Hash: 5048c4f74ec037fd-3449ab617feaf921d0a16e80235949384347ed4f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 2f4c8405.0.945690.00-425.2616078.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 06 Sep 2012 15:44:51 +0000 (UTC) X-MXL-Hash: 5048c4f375f51f3d-ef76ceb9dc2b0990666e27a01ceb9dd2d9aa0597 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q86FioPg032309; Thu, 6 Sep 2012 11:44:50 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q86Fi7gE031198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2012 11:44:45 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 6 Sep 2012 11:42:52 -0400 Received: from GAALPA1MSGUSR9E.ITServices.sbc.com ([130.8.36.62]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 11:42:51 -0400 From: "CHASTAIN, COOPER" To: jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 Thread-Index: AQHNjAn+Y4AjiNaRkEChdGPtm1eDRZd9dFOw Date: Thu, 6 Sep 2012 15:42:51 +0000 Message-ID: <38927D426F44264DA4453D7332485FE31CC6F5CF@GAALPA1MSGUSR9E.ITServices.sbc.com> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.217.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=6PEw_R5fP7cA:10 a=J9lxzYzTKNEA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=T87uLF-L] X-AnalysisOut: [NVleN1eeAAkA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10] Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:44:56 -0000 I support this work. Cooper Chastain -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Thursday, September 06, 2012 4:31 AM To: dime@ietf.org Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-= 02 Folks, This email starts a two week consensus call on adopting: Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-mcmurry-dime-overload-reqs-02.txt Pages : 25 Date : 2012-08-28 as a Dime WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to the chairs. This call will end September 20, 2012. - Jouni & Lionel From mahoney@nostrum.com Thu Sep 6 15:56:16 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEAE21F853F for ; Thu, 6 Sep 2012 15:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0k9Xa7jl6Hz for ; Thu, 6 Sep 2012 15:56:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C77A21F8539 for ; Thu, 6 Sep 2012 15:56:15 -0700 (PDT) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q86MuCLT094289 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Sep 2012 17:56:12 -0500 (CDT) (envelope-from mahoney@nostrum.com) Message-ID: <50492A0B.7010508@nostrum.com> Date: Thu, 06 Sep 2012 17:56:11 -0500 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <503CCF08.5070008@nostrum.com> <20635_1346911063_50483B57_20635_16166_9_6B7134B31289DC4FAF731D844122B36E049B6B@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <20635_1346911063_50483B57_20635_16166_9_6B7134B31289DC4FAF731D844122B36E049B6B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] WGLC review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 22:56:17 -0000 Hi Lionel, OK and thanks for making the changes! Jean On 9/5/12 11:36 AM, lionel.morand@orange.com wrote: > Hi Jean, > > Thank you very much for this very detailed review and the proposed changes. > I'm even surprised to see that there are still some sentences (maybe one or two) unchanged or without any mistake :) > > No need to go through all my responses. A global "OK" is enough. > > Again, thank you! > > Regards, > > Lionel > > > -----Message d'origine----- > De :dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de A. Jean Mahoney > Envoy : mardi 28 aot 2012 16:01 > :dime@ietf.org;draft-ietf-dime-app-design-guide@tools.ietf.org > Objet : [Dime] WGLC review of draft-ietf-dime-app-design-guide-15 > > Hi all, > > I didn't find any major issues while reviewing the document. However, I > did come up with a long list of nits. > > The first part of the review offers suggested wording changes to > sentences and paragraphs. The second section covers typographical and > punctuation errors. > > Jean > > > > 4. p1 s1 (Section 4, paragraph 1, sentence 1): > > Current: > > . protocol designers are advised to try to re-use as > much as possible existing Diameter applications to simplify > standardization, implementation and avoid potential interoperability > issues. > > Suggested: > > . protocol designers are advised to reuse as > much as possible existing Diameter applications in order to simplify > standardization and implementation, and to avoid potential > interoperability issues. > > [LM] ok > > 4.3 p2 s3: > > Current: > > Therefore, if it is still recommended to re-use as much as possible > existing commands, protocol designers can consider more easily the > definition of a new command when it is a solution more suitable than > twisting existing command use and applications. > > Suggested: > > Although reuse of existing commands is still recommended, protocol > designers can consider defining a new command when it provides > a solution more suitable than the twisting of an existing command's > use and applications. > > [LM] ok > > 4.3.1 p2 s5: > > Current: > Here is a list of few > common questions that application designers should wonder when trying > to decide: > > Suggested: > > Application designers should consider the following questions when > deciding to set the M-bit for a new AVP: > > [LM] ok > > 4.3.2 p1 s1: > > Current: > > When deleting an AVP from a command, the following cases need to be > differentiated: > > Suggested: > > The impacts of deleting an AVP from a command depend on its > command code format specification and M-bit setting: > > [LM] ok > > 5.4 p1 s2: > > Current: > When a new application is being defined that cannot > clearly be categorized into any of these services it is recommended > that the application itself define its own session state machine. > The existing session state machines defined by > [I-D.ietf-dime-rfc3588bis] is not intended for general use beyond AAA > services, therefore any behavior not covered by that category would > not fit well. > > Suggested: > If a new application cannot clearly be categorized into any > of these services, it is recommended that the application define its > own session state machine. The session state machines defined by > [I-D.ietf-dime-rfc3588bis] are not intended to cover behavior outside > of AAA. > > [LM] ok > > 5.6 p2 s2: > > Current: > This has to be > considered as a sub-optimal design as this limits the extensibility > of the application: any new capability/permission would have to be > supported by a new AVP or new Enumerated value of the already defined > AVP that would cause in consequence backwards compatibility issues > with existing implementations. > > Suggested: > This is a > sub-optimal design since it limits the extensibility of the application: > any new capability/permission would have to be supported by a new AVP > or new Enumerated value of the already defined AVP, causing backwards > compatibility issues with existing implementations. > > [LM] ok > > 5.6 p3: > > Current: > > Instead of defining Enumerated AVP when the AVP simply used as a > Boolean flag, protocol designers are encouraged to rely on AVP > defined in the form of a bit mask with the interpretation of the > setting of each bit described in the relevant Diameter application > specification. Such AVPs can be reused and extended to multiplex > several indications without major impact on the Diameter application. > The bit-mask should be therefore long enough to leave room for future > additions. Examples of AVP defined as bit mask are the Session- > Binding AVP defined in [I-D.ietf-dime-rfc3588bis] and the MIP6- > Feature-Vector AVP defined in [RFC5447] > > Suggested: > > Instead of using an Enumerated AVP for a Boolean flag, protocol > designers are encouraged to use a bit mask AVP whose bit settings > are described in the relevant Diameter application specification. > Such AVPs can be reused and extended without major impact on the > Diameter application. The bit mask AVP should leave room for future > additions. Examples of bit mask AVPs are the Session-Binding AVP > [I-D.ietf-dime-rfc3588bis] and the MIP6-Feature-Vector AVP [RFC5447]. > > [LM] ok > > > 5.7 p3: > > Current: > > Example of such specific routing function can be found the > applications defined for the IP Multimedia Subsystem of 3GPP, i.e. > Cx/Dx applications ([TS29.228] and [TS29.229]) in which the > Subscriber Location Function (SLF) is defined a proxy agent (or > enhanced Redirect agent) using specific application-level identities > found in the request to determine the final destination of the > message. > > Suggested: > > Examples of such application-specific routing functions can be found > in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP > IP Multimedia Subsystem, in which the proxy agent (Subscriber Location > Function) uses application-level identities found in the request to > determine the final destination of the message. > > [LM] ok > > 5.7 p4 s2: > > Current: > > In particular, this > ensures that Diameter agents in the request routing path (Relay or > Proxy agents) will be able to correctly release the transaction state > associated to the request upon receipt of the answer, avoiding thus > unnecessary failover triggering due to non reception of the answer > corresponding to the request. Application designers are strongly > recommended to not attempt to modify the answer routing principles > described in [I-D.ietf-dime-rfc3588bis] when defining a new > application. > > Suggested: > > In particular, this > ensures that the Diameter Relay or Proxy agents in the request routing > path will be able to release the transaction state upon receipt of the > corresponding answer, avoiding unnecessary failovers. Application > designers are strongly dissuaded from modifying the answer-routing > principles described in [I-D.ietf-dime-rfc3588bis] when defining a new > application. > > [LM] ok > > 5.8 p2: > > Current: > > In the specific case of RADIUS, it was initially foreseen that the > translation function would have been straightforward to define and > deploy by adopting few basic principles e.g. use of a shared range of > code values for RADIUS attributes and Diameter AVPs, some guidelines > on translation and management of key information (such as > authentication parameter, routing/accounting or states), etc. And > all this material was put in the RFC 4005 ([RFC4005]) to be used as > generic guideline for implementation of RADIUS-Diameter translation > agent. > > Suggested: > > In the case of RADIUS, it was initially thought that defining the > translation function would be straightforward. Guidelines for > implementing a RADIUS-Diameter translation agent were put into > RFC 4005 ([RFC4005]). > > [LM] ok. > > 5.8 p4 s1: > > Current: > > Therefore, when interoperability with RADIUS infrastructure is > foreseen, protocol designers are advised that they cannot assume the > availability of "standard" Diameter-to-RADIUS gateways agent and the > required translation mechanism should be then specified along with > the Diameter application. And the recommendation in the case of > RADIUS-Diameter interworking applies of course for any other kind of > translation (e.g. Diameter/MAP). > > Suggested: > > Therefore, protocol designers cannot assume the availability of a > "standard" Diameter-to-RADIUS gateways agent when planning to > interoperate with the RADIUS infrastructure. They should specify > the required translation mechanism along with the Diameter application. > This recommendation applies for any kind of translation (e.g. > Diameter/MAP). > > [LM] ok > > 5.9 p2 and bullets: > > Current: > > The end-to-end capabilities AVPs can aid in the following cases: > > o Formalizing the way new functionality is added to existing > applications by announcing support for it. > > o Applications that do not understand these AVP can discard it upon > receipt. In such case, senders of the AVP can also safely assume > the receiving end-point does not support any functionality carried > by the AVP if it is not present in subsequent responses. > > o Useful in cases where deployment choices are offered and the > generic design can be made available for a number of applications. > > > Suggested: > > The end-to-end capabilities AVPs formalize the addition of new > functionality to existing applications by announcing support for it. > Applications that do not understand these AVPs can discard them upon > receipt. Senders of the AVP can safely assume the receiving end-point > does not support any functionality carried by the AVP if it is not > present in subsequent responses. This is useful in cases where > deployment choices are offered, and the generic design can be made > available for a number of applications. > > [LM] ok > > 6. p2 b3 s3: > > Current: > > However, the drawback is that the timing of sending extension data > will be tied to when the application would be sending a message. > This has consequences if the application and the extensions have > different timing requirements. > > Suggested: > > However, this ties the sending of extension data to the application's > transmission of a message. This has consequences if the application > and the extensions have different timing requirements. > > [LM] ok > > 6. p3 s1: > > Current: > > In practice, it is often the case that the generic extensions use > optional AVPs because it's simple and not intrusive to the > application that would carry it. > > Suggested: > > In practice, generic extensions often use optional AVPs because > they are simple and nonintrusive to the application that would carry > them. > > [LM] ok > > Nits: > > 3. p2 s2: "completly" -> "completely" > > 4.1 p1 s3: "create an new" -> "create a new" > > 4.1 p3 s1: "case by case" -> "case-by-base" > > 4.1 p3 b3 s1: "importing existing" -> "importing an existing" > > 4.1 p3 b3 s2: "applications" -> "application" > remove the stray period at the end. > > 4.2 p1 s1: "to an application" -> "from an application" > > 4.2 p1 s2: "this" -> "This" > > 4.2 p2 s3: "which" -> "that" > > 4.3.1 heading: "ommand" -> "Command" > > 4.3.1 p1 b1 s2: "node receiving are" -> "node receiving them is" > > 4.3.1 p1 b2 s1: "receiving these AVP" -> "receiving these AVPs" > > 4.3.1 p2 b4 s1: "application related" -> "application-related" > > 4.3.1 p4 s1: "contemplating on the" -> "contemplating the" > > 4.3.1 p4 b2: "applications data" -> "application data" > > 4.3.1 p4 b3: "a mandatory AVPs" -> "a mandatory AVP" > > 4.4.1 p2 s1: add period after "unchanged" > > 5.1 p3 s1: add comma after "extensibility" > > 5.2 p1 s1: "Reusing" -> "reusing" > > 5.2 p1 s3: "pratices" -> "practices" > > 5.3 p1 s1 and s2: "session level" -> "session-level" > > 5.4 p1 s4: "server initiated" -> "server-initiated" > > 5.5 p3 s1: delete "really" > > 5.5 p3 s3: "by the application the" -> "by the application, the" > > 5.6 p1 s1: "provide list" -> "provide a list" > > 5.6 p1 s2: "perform on" -> "perform upon" > > 5.6 p2 s1: "as simple" -> "as a simple" > > 5.7 p2 s1: add comma after "suitable" > > 5.7 p4 s1: ", the answer" -> ", with the answer" > "Hop-by-hop" -> "hop-by-hop" > > 5.8 p3 s2: remove "will likely" > add comma after "specification" > > 5.10 p1 s1: "which" -> "that" > > 5.10 p2 s4: delete "generally" > > 5.10 p3 s2: delete "somehow" > > 5.10 p3 s3: "to be have" -> "to have" > delete "uniquely" > > 5.10 p3 s4: add comma after "existing AVPs" > "records" -> "record" > > 5.11 p1 s2: "However, IPsec Additional" -> "However, additional" > > 5.11 p2 s3: add comma after "pre-shared key" > > 5.11 p3 s1: "as security mechanisms" -> "as the security mechanism" > > 6 p2 b3 s2: "applications; However" -> "applications. However" > > 6 p2 b3 s5: add comma after "issue" > > 6 p3 s4: add comma after "set of applications" > > 8 p1 s1: delete "does" > > 8 p1 s2: "security related" -> "security-related" > > Throughout the document: > "Diameter Base protocol" -> "Diameter base protocol" > "application specific" -> application-specific" > "tradeoff" -> "trade-off" > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From mahoney@nostrum.com Thu Sep 6 15:57:47 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4121F84D3 for ; Thu, 6 Sep 2012 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a01uMCmOJIK for ; Thu, 6 Sep 2012 15:57:47 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0EA21F84D4 for ; Thu, 6 Sep 2012 15:57:45 -0700 (PDT) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q86MvidN094456 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 17:57:44 -0500 (CDT) (envelope-from mahoney@nostrum.com) Message-ID: <50492A68.6040208@nostrum.com> Date: Thu, 06 Sep 2012 17:57:44 -0500 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dime@ietf.org References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> <0BF1FFDF-FD6A-4122-A58A-61BB7905BC00@nostrum.com> <6A704613-9DD9-42BC-9399-A02AF650EC74@nostrum.com> <07F875B8-9FDA-4C07-BF22-3F56951AB574@estacado.net> In-Reply-To: <07F875B8-9FDA-4C07-BF22-3F56951AB574@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 22:57:47 -0000 I support making this draft a WG item. Jean On 9/6/12 9:56 AM, Eric McMurry wrote: > I add my own obvious support also :-) > > > On Sep 6, 2012, at 8:58 , Adam Roach wrote: > >> I do as well. >> >> /a >> >> On Sep 6, 2012, at 8:51, Ben Campbell wrote: >> >>> I support making this draft a work group item. (I assume that's obvious, but still worth stating for the record :-) ) >>> >>> Thanks! >>> >>> Ben. >>> >>> On Sep 6, 2012, at 3:31 AM, jouni korhonen wrote: >>> >>>> Folks, >>>> >>>> This email starts a two week consensus call on adopting: >>>> >>>> Title : Diameter Overload Control Requirements >>>> Author(s) : Eric McMurry >>>> Ben Campbell >>>> Filename : draft-mcmurry-dime-overload-reqs-02.txt >>>> Pages : 25 >>>> Date : 2012-08-28 >>>> >>>> as a Dime WG document. Please state your opinion (either for or >>>> against) on making this draft a WG draft either on the mailing list or >>>> to the chairs. This call will end September 20, 2012. >>>> >>>> - Jouni & Lionel >>>> _______________________________________________ >>>> 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 ecnoel@research.att.com Thu Sep 6 11:45:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFC521F8763 for ; Thu, 6 Sep 2012 11:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wXQ59jvtP20 for ; Thu, 6 Sep 2012 11:45:51 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECB721F8754 for ; Thu, 6 Sep 2012 11:45:51 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id D1B4E120599; Thu, 6 Sep 2012 14:44:12 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-blue.research.att.com (Postfix) with ESMTP id CA47EF0515; Thu, 6 Sep 2012 14:45:50 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Thu, 6 Sep 2012 14:44:45 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'jouni korhonen' , "dime@ietf.org" Date: Thu, 6 Sep 2012 14:44:42 -0400 Thread-Topic: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 Thread-Index: Ac2MCeRCA4jEqr7MTN6FfV3MW85fIAAVZvtQ Message-ID: <5EBD159DE88147488A3B1590E0900184031C909B8116@njfpsrvexg2.research.att.com> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 07 Sep 2012 08:04:59 -0700 Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:45:51 -0000 I support making this draft a WG draft. Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jou= ni korhonen Sent: Thursday, September 06, 2012 4:31 AM To: dime@ietf.org Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-= 02 Folks, This email starts a two week consensus call on adopting: Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-mcmurry-dime-overload-reqs-02.txt Pages : 25 Date : 2012-08-28 as a Dime WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to t= he chairs. This call will end September 20, 2012. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From md3135@att.com Fri Sep 7 09:37:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78721E808A for ; Fri, 7 Sep 2012 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BSdIfuqbvFS for ; Fri, 7 Sep 2012 09:37:50 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id D9A5321E8054 for ; Fri, 7 Sep 2012 09:37:49 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id dd22a405.6b809940.1438372.00-599.3979726.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 07 Sep 2012 16:37:49 +0000 (UTC) X-MXL-Hash: 504a22dd7ed397a9-c8a07b211b352f8fc6488ca7597d6c0262fdc80f Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 6d22a405.0.1438301.00-297.3979518.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 07 Sep 2012 16:37:43 +0000 (UTC) X-MXL-Hash: 504a22d72bdefb32-1730eca585d80bcf4d2506e25af38fd2d511c0b3 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q87Gbgim028111; Fri, 7 Sep 2012 09:37:42 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q87GbTX2027858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 09:37:33 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 7 Sep 2012 09:37:13 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 12:37:12 -0400 From: "DOLLY, MARTIN C" To: jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 Thread-Index: AQHNjAn+Eyfl9OVxrE6Vyi151m+wgZd/Fcuw Date: Fri, 7 Sep 2012 16:37:11 +0000 Message-ID: References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.93.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=SZEwKcAtUsoA:10 a=J9lxzYzTKNEA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=T87uLF-LNVleN1eeAAkA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:37:51 -0000 I support adopting as a WG document -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jou= ni korhonen Sent: Thursday, September 06, 2012 4:31 AM To: dime@ietf.org Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-= 02 Folks, This email starts a two week consensus call on adopting: Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-mcmurry-dime-overload-reqs-02.txt Pages : 25 Date : 2012-08-28 as a Dime WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to the chairs. This call will end September 20, 2012. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From abooth@pt.com Fri Sep 7 10:21:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C6A21F865D for ; Fri, 7 Sep 2012 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxoFUzp9RKvu for ; Fri, 7 Sep 2012 10:21:40 -0700 (PDT) Received: from ottgw.pt.com (ottgw.pt.com [209.217.107.194]) by ietfa.amsl.com (Postfix) with ESMTP id 93F8A21F865B for ; Fri, 7 Sep 2012 10:21:39 -0700 (PDT) Received: from notes4.pt.com (notes4.corp.pt.com [10.81.15.15]) by ottgw.pt.com (Postfix) with ESMTP id 0AEF642545; Fri, 7 Sep 2012 12:48:49 -0400 (EDT) X-Disclaimed: 1 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> From: Andrew Booth To: jouni korhonen Message-ID: Date: Fri, 7 Sep 2012 13:21:35 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.3 September 15, 2011 X-MIMETrack: Serialize by Notes Server on notes4/PTI(Release 8.5.3|September 15, 2011) at 09/07/2012 01:21:35 PM, Serialize complete at 09/07/2012 01:21:35 PM, Itemize by Notes Server on notes4/PTI(Release 8.5.3|September 15, 2011) at 09/07/2012 01:21:35 PM, Serialize by Router on notes4/PTI(Release 8.5.3|September 15, 2011) at 09/07/2012 01:21:35 PM Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 17:21:41 -0000 I support making this a working group item.

Andrew

-----dime-bounces@ietf.org wrote: -----
To: dime@ietf.org
From: jouni korhonen
Sent by: dime-bounces@ietf.org
Date: 09/06/2012 = 04:31AM
Cc: dime-chairs@tools.ietf.org
Subject: [Dime] DIME WG Call f= or adoption draft-mcmurry-dime-overload-reqs-02

Folks,

This email starts a = two week consensus call on adopting:

Title       &nb= sp;   : Diameter Overload Control Requirements
Author(s)   &n= bsp;   : Eric McMurry
           &nbs= p;             Ben Campbell
Filename &nbs= p;      : draft-mcmurry-dime-overload-reqs-02.txt
Pages =           : 25
Date        = ;    : 2012-08-28

as a Dime WG document.  Please stat= e your opinion (either for or
against) on making this draft a WG draft e= ither on the mailing list or
to the chairs.  This call will end Sep= tember 20, 2012.

- Jouni & Lionel
=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
DiME mailing list
DiME@ietf.o= rg
https://www.ie= tf.org/mailman/listinfo/dime
<= /div>
= From tom.taylor.stds@gmail.com Sat Sep 8 13:43:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2692C21F8493 for ; Sat, 8 Sep 2012 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k9JYivE8Vgi for ; Sat, 8 Sep 2012 13:43:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A05CA21F8491 for ; Sat, 8 Sep 2012 13:43:58 -0700 (PDT) Received: by ieak13 with SMTP id k13so978364iea.31 for ; Sat, 08 Sep 2012 13:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=Hojfy4g1yWeGMxL6Kw54YRxQWOzXvA6UOoXN4NHjA00=; b=BuURudPdDk9t4JE11LvzYDuXuMxFt7NHG78jjiosQmw1a/d/oK8EsJ1SJt8EM8Iqaz 4y4JavQRF0SIcgzsIRsUIkgBfXYGw/A9AnY7MoV7O/PcLyS3bWV3jJil9FhHR2iRLzdB wYOir9NL6Zq526VED3DPMttKzeZ9IWoB66/cKQ1er7gF+iQt1tXINlj4RMU6+jJGQ9+1 332Zo2Nceh7BF3zh5AehhHWtNvS/ttx/2xVOx0Bl/ampQUqrDRggOR/lVdNLl8Gb1vle AWnLIPhtB6myP4OB6z1x0GcbdG+lhVQuaaFDAzzKCfhRpI06okc3C+H9YS96T5hq8l58 734w== Received: by 10.50.10.163 with SMTP id j3mr2303924igb.18.1347137038239; Sat, 08 Sep 2012 13:43:58 -0700 (PDT) Received: from [127.0.0.1] ([64.56.253.240]) by mx.google.com with ESMTPS id wn5sm3775497igc.7.2012.09.08.13.43.56 (version=SSLv3 cipher=OTHER); Sat, 08 Sep 2012 13:43:57 -0700 (PDT) Message-ID: <504BAE0C.6080503@gmail.com> Date: Sat, 08 Sep 2012 16:43:56 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: jouni korhonen References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120908-1, 08/09/2012), Outbound message X-Antivirus-Status: Clean Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 20:43:59 -0000 Support. On 06/09/2012 4:31 AM, jouni korhonen wrote: > Folks, > > This email starts a two week consensus call on adopting: > > Title : Diameter Overload Control Requirements > Author(s) : Eric McMurry > Ben Campbell > Filename : draft-mcmurry-dime-overload-reqs-02.txt > Pages : 25 > Date : 2012-08-28 > > as a Dime WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or > to the chairs. This call will end September 20, 2012. > > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From bclaise@cisco.com Mon Sep 10 03:38:05 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF2C21F861A for ; Mon, 10 Sep 2012 03:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.023 X-Spam-Level: X-Spam-Status: No, score=-9.023 tagged_above=-999 required=5 tests=[AWL=2.091, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soVXv4BAzHHm for ; Mon, 10 Sep 2012 03:38:04 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2FC21F8619 for ; Mon, 10 Sep 2012 03:38:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AAc1rh000113; Mon, 10 Sep 2012 12:38:01 +0200 (CEST) Received: from [10.149.0.91] (dhcp-10-149-0-91.cisco.com [10.149.0.91]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AAc17V004938; Mon, 10 Sep 2012 12:38:01 +0200 (CEST) Message-ID: <504DC309.6040202@cisco.com> Date: Mon, 10 Sep 2012 12:38:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Stura, Marco, Vodafone Italy" References: <5047024C.5070806@cisco.com> <1B49CAB6E1212B40BDB75660BDF2B4A50FDF164E@OIVMEXO02.omnitel.it> In-Reply-To: <1B49CAB6E1212B40BDB75660BDF2B4A50FDF164E@OIVMEXO02.omnitel.it> Content-Type: multipart/alternative; boundary="------------030009070603070601090308" Cc: xkiranj.1980@gmail.com, dime mailing list Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:38:05 -0000 This is a multi-part message in MIME format. --------------030009070603070601090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to all. Accepted as "Hold for document update" Regards, Benoit. > > Hi, > > Yes I agree with proposed change. Indeed the intention is that GSU AVP > is not sent at all, this was supposed to be clear looking at Flow VIII > (fro example) in Annex A. > > BR, > > Marco > > ------------------------------------------------------------------------ > > *From:*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf > Of *Schendel, Jens (NSN - DE/Berlin) > *Sent:* Thursday, September 06, 2012 4:19 PM > *To:* ext Benoit Claise; dime mailing list > *Cc:* xkiranj.1980@gmail.com > *Subject:* Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) > *Importance:* Low > > Hi, > > I agree with the proposed change. Actually, the Credit Control Server > may decide to apply immediate redirect for some other reason than zero > balance (which is given as explanation in the RFC text), i.e. for some > other advice like charge rate or so. > > I also believe that the original wording (even if not completed) would > have been different if zero GSU were indented. > > So, pretty clear to me. > > Jens > > *From:*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf > Of *ext Benoit Claise > *Sent:* Wednesday, September 05, 2012 9:42 AM > *To:* dime mailing list > *Cc:* xkiranj.1980@gmail.com > *Subject:* [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) > > Dear all, > > This errata has been submitted. > While this looks right me, I always prefer to have a confirmation from > the experts... > > Regards, Benoit. > > > > -------- Original Message -------- > > *Subject: * > > > > Re: [Editorial Errata Reported] RFC4006 (3329) > > *Date: * > > > > Thu, 23 Aug 2012 12:00:03 +0200 > > *From: * > > > > Kiran Jadhav > > *To: * > > > > RFC Errata System > > > *CC: * > > > > Harri.Hakala@ericsson.com , > Leena.Mattila@ericsson.com , > juha-pekka.koskinen@nokia.com , > marco.stura@nokia.com , > John.Loughney@nokia.com , > rbonica@juniper.net , bclaise@cisco.com > , Bernard_Aboba@hotmail.com > , david@mitton.com > > > > > Hello All, > > I have reported an Editorial Errata for RFC4006. > > This small editorial errata in the RFC4006 is causing issues in some > call scenarios where the end user is given an option by the Service > Provider to replenish his credit if it is found at the start of a call > that the end-user's account balance is zero/insufficient. This is > basically due to mis-interpretation of the sentence in the RFC by > different vendors. > > Please have a look at the suggested change which will help a common > implementation of the behavior across all vendors. > > Best Regards, > > Kiran Jadhav > > On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System > > wrote: > > > The following errata report has been submitted for RFC4006, > "Diameter Credit-Control Application". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=3329 > > -------------------------------------- > Type: Editorial > Reported by: Kiran Jadhav > > > Section: 5.6.2 > > Original Text > ------------- > " Note that the credit-control server may already have initiated the > above-described process for the first interrogation. However, the > user's account might be empty when this first interrogation is > performed. In this case, the subscriber can be offered a chance to > replenish the account and continue the service. The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit. It immediately starts the graceful > service termination without sending any message to the server. An > example of this case is illustrated in Appendix A." > > Corrected Text > -------------- > " Note that the credit-control server may already have initiated the > above-described process for the first interrogation. However, the > user's account might be empty when this first interrogation is > performed. In this case, the subscriber can be offered a chance to > replenish the account and continue the service. The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful > service termination without sending any message to the server. An > example of this case is illustrated in Appendix A." > > Notes > ----- > In the sentence "The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit." it is important that we add the > letters "AVP" after Granted-Service-Units as it is not clear whether > the sentence refers to "Not sending Granted-Service-Unit AVP at all" > or "sending GSU=0 (Granted-Service-Unit AVP with value 0". > > Different OCS vendors interpret the sentence above in a different way, > some do not send the Granted-Service-Unit AVP at all, while some > others send the Granted_Service-Unit=0. And this causes problem in the > call scenario where FUI+Redirect is sent together with GSU=0. This > causes the call to enter a loop and terminate with an error. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4006 (draft-ietf-aaa-diameter-cc-06) > -------------------------------------- > Title : Diameter Credit-Control Application > Publication Date : August 2005 > Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, > J. Loughney > Category : PROPOSED STANDARD > Source : Authentication, Authorization and Accounting > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > --------------030009070603070601090308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks to all.
Accepted as "Hold for document update"

Regards, Benoit.

Hi,

 

Yes I agree with proposed change. Indeed the intention is that GSU AVP is not sent at all, this was supposed to be clear looking at Flow VIII (fro example) in Annex A.

 

BR,

Marco

 


From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Schendel, Jens (NSN - DE/Berlin)
Sent: Thursday, September 06, 2012 4:19 PM
To: ext Benoit Claise; dime mailing list
Cc: xkiranj.1980@gmail.com
Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)
Importance: Low

 

Hi,

 

I agree with the proposed change. Actually, the Credit Control Server may decide to apply immediate redirect for some other reason than zero balance (which is given as explanation in the RFC text), i.e. for some other advice like charge rate or so.

I also believe that the original wording (even if not completed) would have been different if zero GSU were indented.

So, pretty clear to me.

 

Jens

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Benoit Claise
Sent: Wednesday, September 05, 2012 9:42 AM
To: dime mailing list
Cc: xkiranj.1980@gmail.com
Subject: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)

 

Dear all,

This errata has been submitted.
While this looks right me, I always prefer to have a confirmation from the experts...

Regards, Benoit.



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

Subject:

Re: [Editorial Errata Reported] RFC4006 (3329)

Date:

Thu, 23 Aug 2012 12:00:03 +0200

From:

Kiran Jadhav <xkiranj.1980@gmail.com>

To:

RFC Errata System <rfc-editor@rfc-editor.org>

CC:

Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, david@mitton.com



Hello All,

 

I have reported an Editorial Errata  for RFC4006.

 

This small editorial errata in the RFC4006 is causing issues in some call scenarios where the end user is given an option by the Service Provider to replenish his credit if it is found at the start of a call that the end-user's account balance is zero/insufficient. This is basically due to mis-interpretation of the sentence in the RFC by different vendors.

 

Please have a look at the suggested change which will help a common implementation of the behavior across all vendors.

 

Best Regards,

Kiran Jadhav

On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=3329

--------------------------------------
Type: Editorial
Reported by: Kiran Jadhav <xkiranj.1980@gmail.com>

Section: 5.6.2

Original Text
-------------
" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Corrected Text
--------------
" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Notes
-----
In the sentence "The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is not clear whether the sentence refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=0 (Granted-Service-Unit AVP with value 0".

Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=0. This causes the call to enter a loop and terminate with an error.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title               : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

 

 

 


--------------030009070603070601090308-- From xkiranj.1980@gmail.com Mon Sep 10 03:46:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4296421F864A for ; Mon, 10 Sep 2012 03:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.114 X-Spam-Level: X-Spam-Status: No, score=-4.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uN-AENRg38Pw for ; Mon, 10 Sep 2012 03:46:36 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 049B721F863F for ; Mon, 10 Sep 2012 03:46:35 -0700 (PDT) Received: by eaai11 with SMTP id i11so817230eaa.31 for ; Mon, 10 Sep 2012 03:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YFy5OPMFKo6QJ4KKdSj19qbz/Kilhlim/wpLhOHzFnc=; b=P1cf3bCBOIOJXwAcSkePZy7UG37QX+OH9V6C5chIjAOzwgjkZvyPpJp+TXgY+kVPmg cZVxqH295iOuBPB/ZEVqls1/lBmUX9n9HusRugf4QMkdZxShUd4eMEKadlNTX5tpspdv 6VC58FATur2byo7NkJ6fn/repta6X0iaJ7TCUXJlxNeCduR+gA9il8dGfiaYiQiw7cOH DXZ0gwGQb9Fv8RmMsx2LXeO+Nq1ORDvDjc+rrhihjX7wdVCi1C6tg1WpCkgML6qPv64h kQKCD7Pd4G45SJYlkZj6KDdSDdqoo9pX0FY61K+xYDu8cZWiP/nGYcyeKhUqShRapuS6 iJjg== MIME-Version: 1.0 Received: by 10.14.0.198 with SMTP id 46mr18952281eeb.30.1347273995136; Mon, 10 Sep 2012 03:46:35 -0700 (PDT) Received: by 10.14.221.199 with HTTP; Mon, 10 Sep 2012 03:46:34 -0700 (PDT) In-Reply-To: <504DC309.6040202@cisco.com> References: <5047024C.5070806@cisco.com> <1B49CAB6E1212B40BDB75660BDF2B4A50FDF164E@OIVMEXO02.omnitel.it> <504DC309.6040202@cisco.com> Date: Mon, 10 Sep 2012 12:46:34 +0200 Message-ID: From: Kiran Jadhav To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b62275ee52ec504c956ab09 X-Mailman-Approved-At: Mon, 10 Sep 2012 03:50:03 -0700 Cc: dime mailing list Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:49:21 -0000 --047d7b62275ee52ec504c956ab09 Content-Type: text/plain; charset=ISO-8859-1 Thank you every one for the consideration. Best Regards, Kiran On Mon, Sep 10, 2012 at 12:38 PM, Benoit Claise wrote: > Thanks to all. > Accepted as "Hold for document update" > > Regards, Benoit. > > Hi,**** > > ** ** > > Yes I agree with proposed change. Indeed the intention is that GSU AVP is > not sent at all, this was supposed to be clear looking at Flow VIII (fro > example) in Annex A.**** > > ** ** > > BR,**** > > Marco**** > > ** ** > ------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > *On Behalf Of *Schendel, Jens (NSN - DE/Berlin) > *Sent:* Thursday, September 06, 2012 4:19 PM > *To:* ext Benoit Claise; dime mailing list > *Cc:* xkiranj.1980@gmail.com > *Subject:* Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) > *Importance:* Low**** > > ** ** > > Hi,**** > > ** ** > > I agree with the proposed change. Actually, the Credit Control Server may > decide to apply immediate redirect for some other reason than zero balance > (which is given as explanation in the RFC text), i.e. for some other advice > like charge rate or so.**** > > I also believe that the original wording (even if not completed) would > have been different if zero GSU were indented.**** > > So, pretty clear to me.**** > > ** ** > > Jens**** > > ** ** > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > *On Behalf Of *ext Benoit Claise > *Sent:* Wednesday, September 05, 2012 9:42 AM > *To:* dime mailing list > *Cc:* xkiranj.1980@gmail.com > *Subject:* [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)**** > > ** ** > > Dear all, > > This errata has been submitted. > While this looks right me, I always prefer to have a confirmation from the > experts... > > Regards, Benoit.**** > > > > -------- Original Message -------- **** > > *Subject: * > > Re: [Editorial Errata Reported] RFC4006 (3329)**** > > *Date: * > > Thu, 23 Aug 2012 12:00:03 +0200**** > > *From: * > > Kiran Jadhav **** > > *To: * > > RFC Errata System * > *** > > *CC: * > > Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, > juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, > John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, > Bernard_Aboba@hotmail.com, david@mitton.com**** > > > > Hello All, **** > > ** ** > > I have reported an Editorial Errata for RFC4006.**** > > ** ** > > This small editorial errata in the RFC4006 is causing issues in some call > scenarios where the end user is given an option by the Service Provider to > replenish his credit if it is found at the start of a call that the > end-user's account balance is zero/insufficient. This is basically due to > mis-interpretation of the sentence in the RFC by different vendors.**** > > ** ** > > Please have a look at the suggested change which will help a common > implementation of the behavior across all vendors.**** > > ** ** > > Best Regards,**** > > Kiran Jadhav**** > > On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote:**** > > > The following errata report has been submitted for RFC4006, > "Diameter Credit-Control Application". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=3329 > > -------------------------------------- > Type: Editorial > Reported by: Kiran Jadhav > > Section: 5.6.2 > > Original Text > ------------- > " Note that the credit-control server may already have initiated the > above-described process for the first interrogation. However, the > user's account might be empty when this first interrogation is > performed. In this case, the subscriber can be offered a chance to > replenish the account and continue the service. The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit. It immediately starts the graceful > service termination without sending any message to the server. An > example of this case is illustrated in Appendix A." > > Corrected Text > -------------- > " Note that the credit-control server may already have initiated the > above-described process for the first interrogation. However, the > user's account might be empty when this first interrogation is > performed. In this case, the subscriber can be offered a chance to > replenish the account and continue the service. The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful > service termination without sending any message to the server. An > example of this case is illustrated in Appendix A." > > Notes > ----- > In the sentence "The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit." it is important that we add the letters > "AVP" after Granted-Service-Units as it is not clear whether the sentence > refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=0 > (Granted-Service-Unit AVP with value 0". > > Different OCS vendors interpret the sentence above in a different way, > some do not send the Granted-Service-Unit AVP at all, while some others > send the Granted_Service-Unit=0. And this causes problem in the call > scenario where FUI+Redirect is sent together with GSU=0. This causes the > call to enter a loop and terminate with an error. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4006 (draft-ietf-aaa-diameter-cc-06) > -------------------------------------- > Title : Diameter Credit-Control Application > Publication Date : August 2005 > Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. > Loughney > Category : PROPOSED STANDARD > Source : Authentication, Authorization and Accounting > Area : Operations and Management > Stream : IETF > Verifying Party : IESG**** > > ** ** > > ** ** > > ** ** > > > --047d7b62275ee52ec504c956ab09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you every one for the consideration.

Best Regards,=
Kiran

On Mon, Sep 10, 2012 at = 12:38 PM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Thanks to all.
Accepted as "Hold for document update"

Regards, Benoit.
=20 =20 =20 =20

Hi,

=A0

Yes I agree with proposed change. Indeed the intention is that GSU AVP is not sent at all, this was supposed to be clear looking at Flow VIII (fro example) in Annex A.<= /span>

=A0

BR,

Marco

=A0


<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:windowtext;font-wei= ght:bold">From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On B= ehalf Of Schendel, Jens (NSN - DE/Berlin)
Sent: Thursday, September 06, 2012 4:19 PM
To: ext Benoit Claise; dime mailing list
Cc: xkiranj.1980@gmail.com
Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)
Importance: Low

=A0

Hi,<= /u>

= =A0

I agree with the proposed change. Actually, the Credit Control Server may decide to apply immediate redirect for some other reason than zero balance (which is given as explanation in the RFC text), i.e. for some other advice like charge rate or so.<= /u>

I also believe that the original wording (even if not completed) would have been different if zero GSU were indented.

So, pretty clear to me.

=A0

Jens<= /span>

=A0

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On= Behalf Of ext Benoit Claise
Sent: Wednesday, September 05, 2012 9:42 AM
To: dime mailing list
Cc: xkiranj.1980@gmail.com
Subject: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)<= /span>

=A0

Dear all,

This errata has been submitted.
While this looks right me, I always prefer to have a confirmation from the experts...

Regards, Benoit.



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

Subject:

Re: [Editorial Errata Reported] RFC4006 (3329)

Date:

Thu, 23 Aug 2012 12:00:03 +0200

From:

Kiran Jadhav <xkiranj.1980@gmail.com>

To:

RFC Errata System <rfc-editor@rfc-editor.org>

CC:

Harri.Haka= la@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com, Bernard_Aboba@hotmail.com, david@mitton.com



Hello All,

=A0

I have reported an Editorial Errata=A0 for RFC4006.

=A0

This small editorial errata in the RFC4006 is causing issues in some call scenarios where the end user is given an option by the Service Provider to replenish his credit if it is found at the start of a call that the end-user's account balance is zero/insufficient. This is basically due to mis-interpretation of the sentence in the RFC by different vendors.

=A0

Please have a look at the suggested change which will help a common implementation of the behavior across all vendors.

=A0

Best Regards,

Kiran Jadhav

On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/erra= ta_search.php?rfc=3D4006&eid=3D3329

--------------------------------------
Type: Editorial
Reported by: Kiran Jadhav <xkiranj.1980@gmail.com>

Section: 5.6.2

Original Text
-------------
" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."= ;

Corrected Text
--------------
" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."= ;

Notes
-----
In the sentence "The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is no= t clear whether the sentence refers to "Not sending Granted-Service-Un= it AVP at all" or "sending GSU=3D0 (Granted-Service-Unit AVP with va= lue 0".

Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=3D0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=3D0. This causes the call to enter a loop and terminate with an error.

Instructions:
-------------
This errata is currently posted as "Reported"= . If necessary, please
use "Reply All" to discuss whether it should = be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Diameter Credit-Control Application
Publication Date =A0 =A0: August 2005
Author(s) =A0 =A0 =A0 =A0 =A0 : H. Hakala, L. Mattila, = J-P. Koskinen, M. Stura, J. Loughney
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Authentication, Authorization and Accounting
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and Management
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG

=A0

=A0

=A0



--047d7b62275ee52ec504c956ab09-- From bclaise@cisco.com Mon Sep 10 07:50:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA5E21F867E for ; Mon, 10 Sep 2012 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.921 X-Spam-Level: X-Spam-Status: No, score=-4.921 tagged_above=-999 required=5 tests=[AWL=-2.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C0G+xSZ4DEA for ; Mon, 10 Sep 2012 07:50:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id B7A6D21F8697 for ; Mon, 10 Sep 2012 07:50:49 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AEolsV000504 for ; Mon, 10 Sep 2012 16:50:47 +0200 (CEST) Received: from [10.149.0.91] (dhcp-10-149-0-91.cisco.com [10.149.0.91]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AEokHh009067 for ; Mon, 10 Sep 2012 16:50:46 +0200 (CEST) Message-ID: <504DFE46.2030601@cisco.com> Date: Mon, 10 Sep 2012 16:50:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dime mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] AD review of draft-ietf-dime-erp-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:50:53 -0000 Dear authors, Only a minor comment on this draft. Please ease the IANA job (and most importantly avoid any potential confusions) by using TBD1, TBD2, ... instead of a single TBD for AVPs and application. I'll progress the draft now, but keep that in mind for the next version, including the feedback from the IETF LC. Regards, Benoit. From iesg-secretary@ietf.org Mon Sep 10 08:58:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0D21F869F; Mon, 10 Sep 2012 08:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJIOby2oBmfN; Mon, 10 Sep 2012 08:58:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7127121F8581; Mon, 10 Sep 2012 08:58:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910155813.8869.24453.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 08:58:13 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Support for the EAP Re-authentication Protocol (ERP)) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Mon, 10 Sep 2012 15:58:14 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Support for the EAP Re-authentication Protocol (ERP)' as 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 2012-09-24. 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. Abstract The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ballot/ No IPR declarations have been submitted directly on this I-D. From lionel.morand@orange.com Wed Sep 12 10:00:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F45221F866B for ; Wed, 12 Sep 2012 10:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyyLfhUlcPuu for ; Wed, 12 Sep 2012 10:00:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6821F865F for ; Wed, 12 Sep 2012 10:00:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3D1932644F6; Wed, 12 Sep 2012 19:00:54 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2363535C08F; Wed, 12 Sep 2012 19:00:54 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 19:00:53 +0200 From: To: Ben Campbell Thread-Topic: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 Thread-Index: AQHNi5uu0n03DPqst0+L3ckUm0TZFpeG9Ofw Date: Wed, 12 Sep 2012 17:00:53 +0000 Message-ID: <28577_1347469254_5050BFC6_28577_9048_1_6B7134B31289DC4FAF731D844122B36E0634A9@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <3092_1346861420_5047796C_3092_8625_1_6B7134B31289DC4FAF731D844122B36E049B19@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1C8502B9-BFCC-4B45-A582-1323E6E68B86@nostrum.com> In-Reply-To: <1C8502B9-BFCC-4B45-A582-1323E6E68B86@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.12.151515 Cc: "dime@ietf.org" Subject: Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:00:56 -0000 Hi Ben, Please see below. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mercredi 5 septembre 2012 21:22 =C0=A0: MORAND Lionel RD-CORE Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 Thanks for the response! I've removed sections that appear to be resoved. Thanks! Ben. On Sep 5, 2012, at 11:10 AM, wrote: >=20 [...] >=20 > -- 5.9 >=20 > Does the advice in this section open up an unmanaged extension vector? In= the extreme case, would this encourage an external group to register a sin= gle application id for a highly extensible application, then bypass IETF ex= tension processes by just adding more functions to the original application? >=20 > [LM] in the vendor-specific space, IETF will have no control at all but i= t is exactly the principle of vendor-specific application. So this possibil= ity exists. Anyway, as soon as interoperability with the external world is = required, application designers will have to adopt common rules and this is= the aim of this document. >=20 I agree we can't control what people do in the vendor-specific space. We ha= ve so little control there that there is little point in saying much about = it. My concern is still true for the IETF controlled space, which is contro= lled by IETF Review. My concern is that encouraging the use of AVPs to nego= tiation features could be used to invoke extensions that really should be t= reated as separate applications. The text here seems to condone that behavi= or, which could lead an expert reviewer to decide it was okay for all cases. If we are going to encourage the use of AVPs to negotiation arbitrary featu= res, we probably need some guidance for said expert reviewer. I realize thi= s sort of thing would be case-by-case and fairly subjective, but it seems l= ike we need more guidance than is there now. [LM] it is true that the mechanism is not only used by external SDOs but al= so in IETF RFCs, such as RFC5447. I think that we can clarify the way these= E2E negotiation AVPs are meant to be used. The idea is that you add a new = feature to an existing application that can be supported by an optional AVP= or when client and server can support new optional functions that was not = initially part of the specification. In such a case, as it is purely option= al, using E2E negotiation AVPs is helpful. The limit is if any single agent= in the path needs be updated to support this new feature, that would the c= ase for the definition of a new application. Would it be OK if the text is = clarified in that sense? [...] > Editorial Comments: >=20 [...] >=20 > -- 4.3.1, 2nd bullet list, 3rd bullet: >=20 > The second half of this bullet item seems redundant with the previous bul= let. >=20 > [LM] OK. I propose to just keep the "different number of roundtrips"=20 WFM >=20 > -- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms su= ch as IPsec can also be deployed to secure connections between Diameter pee= rs." >=20 > Do you mean "IPSec can also be deployed...", or "Additional security mech= anisms such as IPSec can also be deployed..."? >=20 > [LM] Obviously, something needs to be fixed. >=20 >=20 Do you have thoughts on whether this text is intended to allow just the use= of IPSec (in addition to TLS and DTLS, of course) , or to allow the more g= eneric "additional mechanisms such as IPSec"? [LM] the whole text is only about IPsec. I will even change the title of th= e section to reflect this point. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From John.Kaippallimalil@huawei.com Thu Sep 13 06:52:37 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C5221F8546 for ; Thu, 13 Sep 2012 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9-UiVuvWc9v for ; Thu, 13 Sep 2012 06:52:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 754BC21F844D for ; Thu, 13 Sep 2012 06:52:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ22899; Thu, 13 Sep 2012 13:52:25 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 14:52:17 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 14:52:24 +0100 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.239]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 13 Sep 2012 06:52:21 -0700 From: John Kaippallimalil To: jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 Thread-Index: AQHNjAowYJ8c5IoqTka0tKCE/uOtlpeIVYDQ Date: Thu, 13 Sep 2012 13:52:20 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA117125306@dfweml511-mbx.china.huawei.com> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 13:52:37 -0000 I support the adoption of this draft as a working group document. Best Regards, John -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jou= ni korhonen Sent: Thursday, September 06, 2012 3:31 AM To: dime@ietf.org Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-= 02 Folks, This email starts a two week consensus call on adopting: Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-mcmurry-dime-overload-reqs-02.txt Pages : 25 Date : 2012-08-28 as a Dime WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to the chairs. This call will end September 20, 2012. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From pedro.viton@alcatel-lucent.com Mon Sep 17 02:03:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607CC21F8532 for ; Mon, 17 Sep 2012 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpJjee4w3Z26 for ; Mon, 17 Sep 2012 02:03:17 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id EDD7621F852B for ; Mon, 17 Sep 2012 02:03:16 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8H92AIf020500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 17 Sep 2012 11:03:07 +0200 Received: from FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 17 Sep 2012 11:02:28 +0200 From: "VITON HORCAJO, Pedro (Pedro)" To: "dime@ietf.org" Date: Mon, 17 Sep 2012 11:02:26 +0200 Thread-Topic: [RFC3588bis-34] - Host-IP-Address AVP Thread-Index: Ac2UsyjKbBR6VKnRTmqPj8ebKl4/ZA== Message-ID: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 09:07:20 -0000 --_000_5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6FRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: After reviewing original RFC3588 and the lastest draft for 3588bis-34, I ha= ve a couple of comments/questions related to the Host-IP-Address AVP 1.- I don't have clear the behavior of a diameter peer when SENDING the Hos= t-IP-Address AVP in the CER/CEA messages, if using TCP to transport Diamete= r. In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5 (Host-IP-Address AVP), it ind= icates the behavior with respect to that AVP when using SCTP or DTLS/SCTP a= s transport mechanism. 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 [RFC4960] or DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by including a Host-IP-Address AVP for each address. When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083], which allow connections to span multiple interfaces, hence, multiple IP addresses, the Capabilities-Exchange-Answer message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages. That might lead to think that if using TCP, that AVP might/needs not be sen= t. However, not sending it would be a contradiction with the CER/CEA ABNF mess= age format, that states that the Host-IP-Address AVP is a mandatory AVP wit= h at least 1 ocurrence : ::=3D < Diameter Header: 257, REQ > { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } <------------ ... I think it would be a good idea to clarify: A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA messages if= using TCP B.- if it is not needed, indicate that AVP as opcional 1*[Host-IP-Address] = in the CER/CEA ABNF. However, leaving it as optional, might lead to interop= erability issues between an implementation not sending it, and another impl= ementation expecting it as mandatory (as per current RFC 3588) -------------------- 2.- On the other side, I haven't been able to find anywhere the behavior a = Diameter implementation should have when RECEIVING that AVP, both with TCP = and SCTP as transport methods. A.- Should it check the source IP address of the received CER/CEA message b= elongs to the values of the Host-IP-Address AVP? But what would be the purpose of that? Prevent NAT traversal? And what to do then if the Source IP Address doesn't match? B.- With SCTP, I thought initially the Diameter implementation could interf= ace with a SCTP layer primitive to add the rest of the advertised IP addres= ses in Host-IP-Address, as possible addresses for this endpoint in the alre= ady established SCTP association. However, after glancing over SCTP RFC 4960 (sections 3.3.2.1 & 5.1.2), it s= eems that the remote IP addresses of an association may be exchanged/learnt= only during the association establishment by using the Options in the INIT= chunk. Therefore, if my assumption is right that it is not possible to add/remove = a remote endpoint IP address to an already established association, what's the point in having a Host-IP-Address AVP in the CER/CEA message? Just for historical reasons? In any case, I think it would be nice to clarify the utility of Host-IP-Add= ress AVP, as well as a diameter implementation expected behavior, both when= sending it and receiving it, when using TCP and SCTP. Thanks, Pedro \\\|/// \\ ~ ~ // (/ @ @ /) ___oOOo-(_)-OOo_________________________ Pedro Viton Tlf:+(34) 690 96 4740 pedro.viton@alcatel-lucent.com C/ Maria Tubau 9 (28050) Madrid SPAIN ___________Oooo.____________________________ .oooO ( ) ( ) ) / \ ( (_/ \_) --_000_5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6FRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi:
 
After rev= iewing=20 original RFC3588 and the lastest draft for 3588bis-34, I have a couple of=20 comments/questions related to the Host-IP-Address AVP
 
 
1.- I don= 't have=20 clear the behavior of a diameter peer when SENDING the Host-IP-Address AVP = in=20 the CER/CEA messages, if using TCP to transport Diameter.
 
In sectio= ns 5.3.1=20 (CER), 5.3.2(CEA) and 5.3.5 (Host-IP-Address AVP), it indicates the behavio= r=20 with respect to that AVP when using SCTP or DTLS/SCTP as transport=20 mechanism.
   T=
he 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 [RFC4960] or
   DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by
   including a Host-IP-Address AVP for each address.
   W=
hen Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
   which allow connections to span multiple interfaces, hence, multiple
   IP addresses, the Capabilities-Exchange-Answer message MUST contain
   one Host-IP-Address AVP for each potential IP address that MAY be
   locally used when transmitting Diameter messages.
That migh= t lead to=20 think that if using TCP, that AVP might/needs not be sent.
 
However, = not sending=20 it would be a contradiction with the CER/CEA ABNF message format, that stat= es=20 that the Host-IP-Address AVP is a mandatory AVP with at least 1=20 ocurrence :
        = =20 <CER> ::=3D < Diameter Header: 257, REQ=20 >
           &= nbsp;      =20 { Origin-Host=20 }
           &nbs= p;      =20 { Origin-Realm=20 }
           &nbs= p;   =20 1* { Host-IP-Address } <------------
...
 
I think i= t would be=20 a good idea to clarify:
A.- wheth= er=20 Host-IP-Address MUST/SHOULD/MAY included in CER/CEA messages if using=20 TCP
B.- if it= is not=20 needed, indicate that AVP as opcional 1*[Host-IP-Address] in the CER/CEA AB= NF.=20 However, leaving it as optional, might lead to interoperability issues betw= een=20 an implementation not sending it, and another implementation expecting it a= s=20 mandatory (as per current RFC 3588)
 
--------------------
2.- On th= e other=20 side, I haven't been able to find anywhere the behavior a Diameter=20 implementation should have when RECEIVING that AVP, both with TCP and SCTP = as=20 transport methods.
 
A.- Shoul= d it check=20 the source IP address of the received CER/CEA message belongs to the values= of=20 the Host-IP-Address AVP?
But what = would be=20 the purpose of that? Prevent NAT traversal?
 
And what = to do then=20 if the Source IP Address doesn't match?
 
 
 
B.- With = SCTP, I=20 thought initially the Diameter implementation could interface with a S= CTP=20 layer primitive to add the rest of the advertised IP addresses in=20 Host-IP-Address, as possible addresses for this endpoint in the already=20 established SCTP association.
 
However, after glancing over SCTP RFC 4960=20 (sections 3.3.2.1 & 5.1.2), it seems that the remote IP addresse= s of=20 an association may be exchanged/learnt only during the association establis= hment=20 by using the Options in the INIT chunk.
 =
Therefore= , if my=20 assumption is right that it is not possible to add/remove a remote endpoint  IP address to an a= lready=20 established association,
what's th= e point in=20 having a Host-IP-Address AVP in the CER/CEA message?
 
Just for historical reasons?
 
 
In any case, I think it would be nice to clarify= the=20 utility of Host-IP-Address AVP, as well as a diameter implementation expect= ed=20 behavior, both when sending it and receiving it, when using TCP and=20 SCTP.
 
 
 
Thanks,
  Pedro
 

   &nb= sp; =20 \\\|///
   &nb= sp; \\=20 ~ ~ //
   &nb= sp; (/=20 @ @ /)
___oOOo-(_)-OOo_________________________
Pedro=20 Viton         Tlf:+(34) 690 96 4740 =

pedro.viton@alcatel-lucent.com



.oooO  (  =20 )

   =20 (   )   ) /
   &nb= sp; \=20 (   (_/
   &nb= sp; =20 \_) 

 
--_000_5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6FRMRSSXCHMBSC_-- From glenzorn@gmail.com Mon Sep 17 04:06:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9D921F8604 for ; Mon, 17 Sep 2012 04:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObKd4wtLYtiM for ; Mon, 17 Sep 2012 04:06:00 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADC521F8602 for ; Mon, 17 Sep 2012 04:05:59 -0700 (PDT) Received: by oagk14 with SMTP id k14so5127324oag.31 for ; Mon, 17 Sep 2012 04:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1jG0QmMiKpeaYom88FMJa1y1wPvIV6dNniZahzS/zXk=; b=L8jpntCfXKzEGwaFBFbYJd7NUuKXkcVZ8JGDJumS1fW3xViWo6gdEjlqD47ClQFUQo 4ccD5vn0Ws/mHfreOGdyLfNEJ6I8fKzJ3Weh1E8O0Tg21TZteoO0ng6Py5z2zDsKnn58 QnTLCPInxqvB01RlXvrq3ZaGqSm8mqP3AoZwCFUmsKh6TDcPUYFP4dPUllnI3T2nxWsT 0Veg1rWgvJHsBmEQSZkTKGp82xj7bfLORQjTxCE+YtFVaO4OyHSd0fdA7QY6YvhR1EYr TXRHs/NZlrllrWtUwMeKXuSZSV8iOfQnQBG1QirLJvgQrxmwpdgUH9xFpA0CxDNQi0e5 ZAcQ== Received: by 10.60.26.41 with SMTP id i9mr9797035oeg.65.1347879959673; Mon, 17 Sep 2012 04:05:59 -0700 (PDT) Received: from [192.168.0.102] (ppp-171-96-23-182.revip8.asianet.co.th. [171.96.23.182]) by mx.google.com with ESMTPS id o4sm8279068oef.11.2012.09.17.04.05.55 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:05:58 -0700 (PDT) Message-ID: <50570410.9000708@gmail.com> Date: Mon, 17 Sep 2012 18:05:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: "VITON HORCAJO, Pedro (Pedro)" References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> In-Reply-To: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:06:00 -0000 On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote: > Hi: > After reviewing original RFC3588 and the lastest draft for 3588bis-34, > I have a couple of comments/questions related to the Host-IP-Address AVP > 1.- I don't have clear the behavior of a diameter peer when SENDING > the Host-IP-Address AVP in the CER/CEA messages, if using TCP to > transport Diameter. > In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5 (Host-IP-Address AVP), > it indicates the behavior with respect to that AVP when using SCTP or > DTLS/SCTP as transport mechanism. > 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 [RFC4960] or > DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by > including a Host-IP-Address AVP for each address. > When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083], > which allow connections to span multiple interfaces, hence, multiple > IP addresses, the Capabilities-Exchange-Answer message MUST contain > one Host-IP-Address AVP for each potential IP address that MAY be > locally used when transmitting Diameter messages. > That might lead to think that if using TCP, that AVP might/needs not > be sent. > However, not sending it would be a contradiction with the CER/CEA ABNF > message format, that states that the Host-IP-Address AVP is a > mandatory AVP with at least 1 ocurrence : > ::= < Diameter Header: 257, REQ > > { Origin-Host } > { Origin-Realm } > 1* { Host-IP-Address } <------------ > ... > I think it would be a good idea to clarify: > A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA > messages if using TCP As you point out, the command definition for the CER requires at least on instance of the AVP. What is unclear? ... From pedro.viton@alcatel-lucent.com Mon Sep 17 05:09:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4F221F864D for ; Mon, 17 Sep 2012 05:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ovP1P4PdFbe for ; Mon, 17 Sep 2012 05:09:11 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0B21F8618 for ; Mon, 17 Sep 2012 05:09:10 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8HC97aq014949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Sep 2012 14:09:08 +0200 Received: from FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 17 Sep 2012 14:09:08 +0200 From: "VITON HORCAJO, Pedro (Pedro)" To: Glen Zorn Date: Mon, 17 Sep 2012 14:09:07 +0200 Thread-Topic: [Dime] [RFC3588bis-34] - Host-IP-Address AVP Thread-Index: Ac2UxHAWDXI4lr6LTHWLwqDGFb4gPAACFJUQ Message-ID: <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> In-Reply-To: <50570410.9000708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:09:14 -0000 Glen, Thanks for answering. Maybe my original mail was too long, and I might have not have been clear = enough. Let me rephase my questions, in a shorter way: 1.- The current text for Host-IP-Address AVP indicates the value to send wh= en transporting over SCTP. But which value should be sent when transporting over TCP? 2.- What should a Diameter implementation do when receiving the Host-IP-Add= ress AVP? Best Regards, Pedro >> -----Original Message----- >> From: Glen Zorn [mailto:glenzorn@gmail.com]=20 >> Sent: Monday, September 17, 2012 1:06 PM >> To: VITON HORCAJO, Pedro (Pedro) >> Cc: dime@ietf.org; glenzorn@gmail.com >> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >>=20 >>=20 >> On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote: >> > Hi: >> > After reviewing original RFC3588 and the lastest draft for=20 >> 3588bis-34,=20 >> > I have a couple of comments/questions related to the=20 >> Host-IP-Address AVP >> > 1.- I don't have clear the behavior of a diameter peer=20 >> when SENDING=20 >> > the Host-IP-Address AVP in the CER/CEA messages, if using TCP to=20 >> > transport Diameter. >> > In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5=20 >> (Host-IP-Address AVP),=20 >> > it indicates the behavior with respect to that AVP when=20 >> using SCTP or=20 >> > DTLS/SCTP as transport mechanism. >> > The Host-IP-Address AVP (AVP Code 257) is of type=20 >> Address and is used >> > to inform a Diameter peer of the sender's IP address. =20 >> All source >> > addresses that a Diameter node expects to use with=20 >> SCTP [RFC4960] or >> > DTLS/SCTP [RFC6083] MUST be advertised in the CER and=20 >> CEA messages by >> > including a Host-IP-Address AVP for each address. >> > When Diameter is run over SCTP [RFC4960] or DTLS/SCTP=20 >> [RFC6083], >> > which allow connections to span multiple interfaces,=20 >> hence, multiple >> > IP addresses, the Capabilities-Exchange-Answer message=20 >> MUST contain >> > one Host-IP-Address AVP for each potential IP address=20 >> that MAY be >> > locally used when transmitting Diameter messages. >> > That might lead to think that if using TCP, that AVP=20 >> might/needs not=20 >> > be sent. >> > However, not sending it would be a contradiction with the=20 >> CER/CEA ABNF=20 >> > message format, that states that the Host-IP-Address AVP is a=20 >> > mandatory AVP with at least 1 ocurrence : >> > ::=3D < Diameter Header: 257, REQ > >> > { Origin-Host } >> > { Origin-Realm } >> > 1* { Host-IP-Address } <------------ >> > ... >> > I think it would be a good idea to clarify: >> > A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA=20 >> > messages if using TCP >>=20 >> As you point out, the command definition for the CER=20 >> requires at least=20 >> on instance of the AVP. What is unclear? >>=20 >> ... >>=20 >> = From jouni.nospam@gmail.com Mon Sep 17 13:07:11 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C022921E803C for ; Mon, 17 Sep 2012 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKjCU-VxtoUZ for ; Mon, 17 Sep 2012 13:07:11 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67E7521E8047 for ; Mon, 17 Sep 2012 13:07:10 -0700 (PDT) Received: by bkty12 with SMTP id y12so2613961bkt.31 for ; Mon, 17 Sep 2012 13:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=S1rvRUx89FMuJ8hWSZIX205EFHaCTi1qk8ojSIoD7Mw=; b=VVuckCQm7bQ8BZmecMsy/4/N/HXf1i/eA/4YyGyUXi8iAxAgVLmPDsgyCpQ/V8jqHV E2yaWTKIeZ9IwLrStV7RKhKBUQzf6ofqqQC+W5AFQheugLRIlUtXikbhD+dPTbYfmDFk HvN4beiRUzSjVxXVd9qrby7o/uCIpcB6+qMlDt7wrxtZ+Ybjnm2qaBI3zQTBDQrjwFVJ IbJiG/16qdHDRiYoya8OeoX6EqrU+gbo9914XOW5SYQ/Mn22rjk5JgKmod9JsDElbBA5 RcRZGSeykLnNmWQ7xvwJqvwu8+vIlUM0oX68njApskO89ms8NILAO5fw7BDKoVWO10bn MaxQ== Received: by 10.205.117.4 with SMTP id fk4mr5058362bkc.64.1347912420800; Mon, 17 Sep 2012 13:07:00 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id n17sm6518748bks.6.2012.09.17.13.06.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 13:06:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> Date: Mon, 17 Sep 2012 23:06:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> To: "VITON HORCAJO, Pedro (Pedro)" X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:07:11 -0000 Hi, Few quick comments inline. On Sep 17, 2012, at 3:09 PM, VITON HORCAJO, Pedro (Pedro) wrote: > Glen, >=20 > Thanks for answering. > Maybe my original mail was too long, and I might have not have been = clear enough. >=20 > Let me rephase my questions, in a shorter way: >=20 > 1.- The current text for Host-IP-Address AVP indicates the value to = send when transporting over SCTP. > But which value should be sent when transporting over TCP? RFC3588bis says: 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.=20 This part is not SCTP specific. So at minimum you include the address = the very TCP connection comes from. Repetition but acceptable. Also, = Diameter host's DiameterIdentity may resolve to one or more IP addresses but not necessarily to all of those. It is a DNS provisioning matter. The = Diameter node would know all its addresses it can use, so those additional = addresses would be included. > 2.- What should a Diameter implementation do when receiving the = Host-IP-Address AVP? In case of TCP.. that is more like FYI (unless someone plans to hack = MPTCP into Diameter some day). Or in case of transport failure, the peer can select = other IP for retrying the transport connection. With SCTP, there is always RFC5061. Addresses can be added to and = deleted from an existing association. So for the responder it is good to know that = some IP=20 address maps to a DiameterIdentity of the initiator as those might be = added later on. - JOuni >=20 > Best Regards, > Pedro >=20 >>> -----Original Message----- >>> From: Glen Zorn [mailto:glenzorn@gmail.com]=20 >>> Sent: Monday, September 17, 2012 1:06 PM >>> To: VITON HORCAJO, Pedro (Pedro) >>> Cc: dime@ietf.org; glenzorn@gmail.com >>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >>>=20 >>>=20 >>> On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote: >>>> Hi: >>>> After reviewing original RFC3588 and the lastest draft for=20 >>> 3588bis-34,=20 >>>> I have a couple of comments/questions related to the=20 >>> Host-IP-Address AVP >>>> 1.- I don't have clear the behavior of a diameter peer=20 >>> when SENDING=20 >>>> the Host-IP-Address AVP in the CER/CEA messages, if using TCP to=20 >>>> transport Diameter. >>>> In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5=20 >>> (Host-IP-Address AVP),=20 >>>> it indicates the behavior with respect to that AVP when=20 >>> using SCTP or=20 >>>> DTLS/SCTP as transport mechanism. >>>> The Host-IP-Address AVP (AVP Code 257) is of type=20 >>> Address and is used >>>> to inform a Diameter peer of the sender's IP address. =20 >>> All source >>>> addresses that a Diameter node expects to use with=20 >>> SCTP [RFC4960] or >>>> DTLS/SCTP [RFC6083] MUST be advertised in the CER and=20 >>> CEA messages by >>>> including a Host-IP-Address AVP for each address. >>>> When Diameter is run over SCTP [RFC4960] or DTLS/SCTP=20 >>> [RFC6083], >>>> which allow connections to span multiple interfaces,=20 >>> hence, multiple >>>> IP addresses, the Capabilities-Exchange-Answer message=20 >>> MUST contain >>>> one Host-IP-Address AVP for each potential IP address=20 >>> that MAY be >>>> locally used when transmitting Diameter messages. >>>> That might lead to think that if using TCP, that AVP=20 >>> might/needs not=20 >>>> be sent. >>>> However, not sending it would be a contradiction with the=20 >>> CER/CEA ABNF=20 >>>> message format, that states that the Host-IP-Address AVP is a=20 >>>> mandatory AVP with at least 1 ocurrence : >>>> ::=3D < Diameter Header: 257, REQ > >>>> { Origin-Host } >>>> { Origin-Realm } >>>> 1* { Host-IP-Address } <------------ >>>> ... >>>> I think it would be a good idea to clarify: >>>> A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA=20 >>>> messages if using TCP >>>=20 >>> As you point out, the command definition for the CER=20 >>> requires at least=20 >>> on instance of the AVP. What is unclear? >>>=20 >>> ... >>>=20 >>>=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From pedro.viton@alcatel-lucent.com Mon Sep 17 23:43:34 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2B11E808D for ; Mon, 17 Sep 2012 23:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2l9Mn6+yG3E for ; Mon, 17 Sep 2012 23:43:34 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id AC99C11E808A for ; Mon, 17 Sep 2012 23:43:33 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8I6e2dA017552 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Sep 2012 08:43:30 +0200 Received: from FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 18 Sep 2012 08:43:11 +0200 From: "VITON HORCAJO, Pedro (Pedro)" To: jouni korhonen Date: Tue, 18 Sep 2012 08:43:09 +0200 Thread-Topic: [Dime] [RFC3588bis-34] - Host-IP-Address AVP Thread-Index: Ac2VEANlKuDiJ/SKSKGWNePHoxgg4QAU2GCw Message-ID: <5F42DFF905CBA544A7BBB0909003E1A3148F14FCDB@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 06:43:34 -0000 Thanks for your replies, These questions came due to some interoperability small issue found with an= other vendor Diameter implementation. I fully agree with your answers and interpretation, but sometimes in IOT's = between different vendors, I think these little details are important. Extra comments inline: Thanks, Pedro >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >> Sent: Monday, September 17, 2012 10:07 PM >> To: VITON HORCAJO, Pedro (Pedro) >> Cc: Glen Zorn; dime@ietf.org >> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >>=20 >>=20 >> Hi, >>=20 >> Few quick comments inline. >>=20 >> On Sep 17, 2012, at 3:09 PM, VITON HORCAJO, Pedro (Pedro) wrote: >>=20 >> > Glen, >> >=20 >> > Thanks for answering. >> > Maybe my original mail was too long, and I might have not=20 >> have been clear enough. >> >=20 >> > Let me rephase my questions, in a shorter way: >> >=20 >> > 1.- The current text for Host-IP-Address AVP indicates the=20 >> value to send when transporting over SCTP. >> > But which value should be sent when transporting over TCP? >>=20 >> RFC3588bis says: >>=20 >> The Host-IP-Address AVP (AVP Code 257) is of type Address=20 >> and is used >> to inform a Diameter peer of the sender's IP address.=20 >>=20 >> This part is not SCTP specific. So at minimum you include=20 >> the address the >> very TCP connection comes from. Repetition but acceptable.=20 >> Also, Diameter >> host's DiameterIdentity may resolve to one or more IP=20 >> addresses but not >> necessarily to all of those. It is a DNS provisioning=20 >> matter. The Diameter >> node would know all its addresses it can use, so those=20 >> additional addresses >> would be included. I agree with this point, and all the possible addresses should also be sent= with TCP, as well as with SCTP. But then,=20 what's the difference with respect to SCTP? Why does the RFC explicitely indicates SCTP for sending all possible IP add= resses? >>=20 >> > 2.- What should a Diameter implementation do when=20 >> receiving the Host-IP-Address AVP? >>=20 >> In case of TCP.. that is more like FYI (unless someone plans=20 >> to hack MPTCP into >> Diameter some day). Or in case of transport failure, the=20 >> peer can select other >> IP for retrying the transport connection. This retrying of the transport connection to the other advertised Host-IP-A= ddress(es) sounds really interesting. But the current RFC text, doesn't even say that a peer MAY retry the transp= ort connection to any of the other advertised Host-IP-Addresses. >>=20 >> With SCTP, there is always RFC5061. Addresses can be added=20 >> to and deleted from >> an existing association. So for the responder it is good to=20 >> know that some IP=20 >> address maps to a DiameterIdentity of the initiator as those=20 >> might be added >> later on. Sounds reasonable.=20 But as 3588bis doesn't say anything of doing any of this, an implementation= doing nothing with the received Host-IP-Address values would be perfectly = valid and compliant, I suppose. Thanks, Pedro >>=20 >> - JOuni >>=20 >>=20 >> >=20 >> > Best Regards, >> > Pedro >> >=20 >> >>> -----Original Message----- >> >>> From: Glen Zorn [mailto:glenzorn@gmail.com]=20 >> >>> Sent: Monday, September 17, 2012 1:06 PM >> >>> To: VITON HORCAJO, Pedro (Pedro) >> >>> Cc: dime@ietf.org; glenzorn@gmail.com >> >>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >> >>>=20 >> >>>=20 >> >>> On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote: >> >>>> Hi: >> >>>> After reviewing original RFC3588 and the lastest draft for=20 >> >>> 3588bis-34,=20 >> >>>> I have a couple of comments/questions related to the=20 >> >>> Host-IP-Address AVP >> >>>> 1.- I don't have clear the behavior of a diameter peer=20 >> >>> when SENDING=20 >> >>>> the Host-IP-Address AVP in the CER/CEA messages, if=20 >> using TCP to=20 >> >>>> transport Diameter. >> >>>> In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5=20 >> >>> (Host-IP-Address AVP),=20 >> >>>> it indicates the behavior with respect to that AVP when=20 >> >>> using SCTP or=20 >> >>>> DTLS/SCTP as transport mechanism. >> >>>> The Host-IP-Address AVP (AVP Code 257) is of type=20 >> >>> Address and is used >> >>>> to inform a Diameter peer of the sender's IP address. =20 >> >>> All source >> >>>> addresses that a Diameter node expects to use with=20 >> >>> SCTP [RFC4960] or >> >>>> DTLS/SCTP [RFC6083] MUST be advertised in the CER and=20 >> >>> CEA messages by >> >>>> including a Host-IP-Address AVP for each address. >> >>>> When Diameter is run over SCTP [RFC4960] or DTLS/SCTP=20 >> >>> [RFC6083], >> >>>> which allow connections to span multiple interfaces,=20 >> >>> hence, multiple >> >>>> IP addresses, the Capabilities-Exchange-Answer message=20 >> >>> MUST contain >> >>>> one Host-IP-Address AVP for each potential IP address=20 >> >>> that MAY be >> >>>> locally used when transmitting Diameter messages. >> >>>> That might lead to think that if using TCP, that AVP=20 >> >>> might/needs not=20 >> >>>> be sent. >> >>>> However, not sending it would be a contradiction with the=20 >> >>> CER/CEA ABNF=20 >> >>>> message format, that states that the Host-IP-Address AVP is a=20 >> >>>> mandatory AVP with at least 1 ocurrence : >> >>>> ::=3D < Diameter Header: 257, REQ > >> >>>> { Origin-Host } >> >>>> { Origin-Realm } >> >>>> 1* { Host-IP-Address } <------------ >> >>>> ... >> >>>> I think it would be a good idea to clarify: >> >>>> A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA=20 >> >>>> messages if using TCP >> >>>=20 >> >>> As you point out, the command definition for the CER=20 >> >>> requires at least=20 >> >>> on instance of the AVP. What is unclear? >> >>>=20 >> >>> ... >> >>>=20 >> >>>=20 >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www.ietf.org/mailman/listinfo/dime >>=20 >> = From jouni.nospam@gmail.com Tue Sep 18 01:41:49 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAAE21F877E for ; Tue, 18 Sep 2012 01:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyIK1qA6CQ93 for ; Tue, 18 Sep 2012 01:41:48 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52D0621F8752 for ; Tue, 18 Sep 2012 01:41:48 -0700 (PDT) Received: by bkty12 with SMTP id y12so2833592bkt.31 for ; Tue, 18 Sep 2012 01:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=otw5S7T5gOVC2Ya/Kfb0WdWFXZZ1eLcQBMqylQCYGbg=; b=tJMEseV2MygFJ+Om1EWNn8NI3NE0smOW/57x4GvzwDT9bYRA/N420HhIITex1xW0cY XIkdPPJ8AMLWYldxoGORs0JWsne5BBpBvNfs7LWzd7aeUNGvrKdTGSLEpzi2rweQ54BS eWR1Sd/7OWcYlzTPIBYJ+iod0R4uwj86xFq+pXj1Nv3TPOD3QvnoMxW0o9JbwGnOLrVh 7aWZA+L+lfsgEQlT0mKotuncc3CfY+H6oBQP7zMoeeT9jG4sf3zpoFJi+mfkGb51s2IS K6g2qsfuzDp6CRt5Vu9viYU890sra/3wTrbcyKWX2M71lnhQRAS8euGi5FoVqp0YKhl/ Kd8Q== Received: by 10.204.154.215 with SMTP id p23mr5330817bkw.53.1347957707312; Tue, 18 Sep 2012 01:41:47 -0700 (PDT) Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id f7sm7036578bkv.1.2012.09.18.01.41.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 01:41:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <5F42DFF905CBA544A7BBB0909003E1A3148F14FCDB@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> Date: Tue, 18 Sep 2012 11:41:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14FCDB@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> To: "VITON HORCAJO, Pedro (Pedro)" X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:41:49 -0000 Hi, On Sep 18, 2012, at 9:43 AM, VITON HORCAJO, Pedro (Pedro) wrote: > Thanks for your replies, >=20 > These questions came due to some interoperability small issue found = with another vendor Diameter implementation. >=20 > I fully agree with your answers and interpretation, but sometimes in = IOT's between different vendors, I think these little details are = important. >=20 > Extra comments inline: >=20 > Thanks, > Pedro >=20 >=20 >>> -----Original Message----- >>> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >>> Sent: Monday, September 17, 2012 10:07 PM >>> To: VITON HORCAJO, Pedro (Pedro) >>> Cc: Glen Zorn; dime@ietf.org >>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >>>=20 >>>=20 >>> Hi, >>>=20 >>> Few quick comments inline. >>>=20 >>> On Sep 17, 2012, at 3:09 PM, VITON HORCAJO, Pedro (Pedro) wrote: >>>=20 >>>> Glen, >>>>=20 >>>> Thanks for answering. >>>> Maybe my original mail was too long, and I might have not=20 >>> have been clear enough. >>>>=20 >>>> Let me rephase my questions, in a shorter way: >>>>=20 >>>> 1.- The current text for Host-IP-Address AVP indicates the=20 >>> value to send when transporting over SCTP. >>>> But which value should be sent when transporting over TCP? >>>=20 >>> RFC3588bis says: >>>=20 >>> The Host-IP-Address AVP (AVP Code 257) is of type Address=20 >>> and is used >>> to inform a Diameter peer of the sender's IP address.=20 >=20 >>>=20 >>> This part is not SCTP specific. So at minimum you include=20 >>> the address the >>> very TCP connection comes from. Repetition but acceptable.=20 >>> Also, Diameter >>> host's DiameterIdentity may resolve to one or more IP=20 >>> addresses but not >>> necessarily to all of those. It is a DNS provisioning=20 >>> matter. The Diameter >>> node would know all its addresses it can use, so those=20 >>> additional addresses >>> would be included. >=20 >=20 > I agree with this point, and all the possible addresses should also be = sent with TCP, as well as with SCTP. > But then,=20 > what's the difference with respect to SCTP? > Why does the RFC explicitely indicates SCTP for sending all possible = IP addresses? Because current TCP has no use of multiple addresses (except for failure recovery.. maybe). On the other hand, SCTP is made for = multi-addressing/homing. And as I said, whether or not all IP addresses are provisioned e.g. into DNS or statically is an operational issue. The less you provision the easier. Let the underlying protocol take care of multiple addressing if it is able to do that. >>>=20 >>>> 2.- What should a Diameter implementation do when=20 >>> receiving the Host-IP-Address AVP? >>>=20 >>> In case of TCP.. that is more like FYI (unless someone plans=20 >>> to hack MPTCP into >>> Diameter some day). Or in case of transport failure, the=20 >>> peer can select other >>> IP for retrying the transport connection. >=20 > This retrying of the transport connection to the other advertised = Host-IP-Address(es) sounds really interesting. > But the current RFC text, doesn't even say that a peer MAY retry the = transport connection to any of the other advertised Host-IP-Addresses. The RFC says a DiameterIdentity may resolve to multiple IP addresses of the peer. There is no restriction why a peer would not try to connect to any of those.. just an implementation detail allowed by the protocol. If a peer is willing to reveal multiple IP addresses that it can be reachable at, it must have a reason for it, specifically in a case of TCP. >>>=20 >>> With SCTP, there is always RFC5061. Addresses can be added=20 >>> to and deleted from >>> an existing association. So for the responder it is good to=20 >>> know that some IP=20 >>> address maps to a DiameterIdentity of the initiator as those=20 >>> might be added >>> later on. >=20 > Sounds reasonable.=20 > But as 3588bis doesn't say anything of doing any of this, an = implementation doing nothing with the received Host-IP-Address values = would be perfectly valid and compliant, I suppose. Yes. Slightly dumb implementation but valid and compliant. There are a lot of things that are unsaid regarding transport. For example, = RFC3588(bis) only refers to RFC793/5461 regarding the TCP protocol itself. However, = for a proper TCP implementation something +20 RFCs are needed (see RFC4614). - Jouni >=20 > Thanks, > Pedro >=20 >>>=20 >>> - JOuni >>>=20 >>>=20 >>>>=20 >>>> Best Regards, >>>> Pedro >>>>=20 >>>>>> -----Original Message----- >>>>>> From: Glen Zorn [mailto:glenzorn@gmail.com]=20 >>>>>> Sent: Monday, September 17, 2012 1:06 PM >>>>>> To: VITON HORCAJO, Pedro (Pedro) >>>>>> Cc: dime@ietf.org; glenzorn@gmail.com >>>>>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >>>>>>=20 >>>>>>=20 >>>>>> On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote: >>>>>>> Hi: >>>>>>> After reviewing original RFC3588 and the lastest draft for=20 >>>>>> 3588bis-34,=20 >>>>>>> I have a couple of comments/questions related to the=20 >>>>>> Host-IP-Address AVP >>>>>>> 1.- I don't have clear the behavior of a diameter peer=20 >>>>>> when SENDING=20 >>>>>>> the Host-IP-Address AVP in the CER/CEA messages, if=20 >>> using TCP to=20 >>>>>>> transport Diameter. >>>>>>> In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5=20 >>>>>> (Host-IP-Address AVP),=20 >>>>>>> it indicates the behavior with respect to that AVP when=20 >>>>>> using SCTP or=20 >>>>>>> DTLS/SCTP as transport mechanism. >>>>>>> The Host-IP-Address AVP (AVP Code 257) is of type=20 >>>>>> Address and is used >>>>>>> to inform a Diameter peer of the sender's IP address. =20 >>>>>> All source >>>>>>> addresses that a Diameter node expects to use with=20 >>>>>> SCTP [RFC4960] or >>>>>>> DTLS/SCTP [RFC6083] MUST be advertised in the CER and=20 >>>>>> CEA messages by >>>>>>> including a Host-IP-Address AVP for each address. >>>>>>> When Diameter is run over SCTP [RFC4960] or DTLS/SCTP=20 >>>>>> [RFC6083], >>>>>>> which allow connections to span multiple interfaces,=20 >>>>>> hence, multiple >>>>>>> IP addresses, the Capabilities-Exchange-Answer message=20 >>>>>> MUST contain >>>>>>> one Host-IP-Address AVP for each potential IP address=20 >>>>>> that MAY be >>>>>>> locally used when transmitting Diameter messages. >>>>>>> That might lead to think that if using TCP, that AVP=20 >>>>>> might/needs not=20 >>>>>>> be sent. >>>>>>> However, not sending it would be a contradiction with the=20 >>>>>> CER/CEA ABNF=20 >>>>>>> message format, that states that the Host-IP-Address AVP is a=20 >>>>>>> mandatory AVP with at least 1 ocurrence : >>>>>>> ::=3D < Diameter Header: 257, REQ > >>>>>>> { Origin-Host } >>>>>>> { Origin-Realm } >>>>>>> 1* { Host-IP-Address } <------------ >>>>>>> ... >>>>>>> I think it would be a good idea to clarify: >>>>>>> A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA=20= >>>>>>> messages if using TCP >>>>>>=20 >>>>>> As you point out, the command definition for the CER=20 >>>>>> requires at least=20 >>>>>> on instance of the AVP. What is unclear? >>>>>>=20 >>>>>> ... >>>>>>=20 >>>>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 From glenzorn@gmail.com Tue Sep 18 04:32:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B426D21F87D8 for ; Tue, 18 Sep 2012 04:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8-nR13WTeP6 for ; Tue, 18 Sep 2012 04:32:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8921F87D5 for ; Tue, 18 Sep 2012 04:32:18 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11429813obb.31 for ; Tue, 18 Sep 2012 04:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TzrnqaUXUI6OTTbLzWbTVu8h8p/EFBsfqx4NEJGD7f0=; b=HXbAIxj3Px4rgSqMTZG+cvhZjcsOfMqGfLFFHYcL1DMIHLibFOAARzpJNkAPMTdwxS wtGugtxreTr69EH/XHLKn7CnFpu/v2YalbFX8H5eu2r3BJgb32xFVfgP2rYFC65n0dT7 hZvwqGZjoBS3CtIt3Vi5ZT6Qp2ejLn8tvU2d7FTjpRwoE5sRwNMo8PwsOYXWK8D5EEsF +cyvS6KjoxGoWHSBsKVhoMqIM7O4JP/4cqNryEbwo3X7NH6m4iWQuaY367X6egrS5YQG +Jt/fscn9gNCn+qN6OVN0lFCxv7ktiGBqwpcVJgTmUoBpNdQZ8DmsWag3P+mzUkZ/B3M BwAQ== Received: by 10.60.7.99 with SMTP id i3mr14386579oea.86.1347967937480; Tue, 18 Sep 2012 04:32:17 -0700 (PDT) Received: from [192.168.0.102] (ppp-58-11-235-161.revip2.asianet.co.th. [58.11.235.161]) by mx.google.com with ESMTPS id jd10sm14103425obb.13.2012.09.18.04.32.15 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 04:32:16 -0700 (PDT) Message-ID: <50585BBD.6040008@gmail.com> Date: Tue, 18 Sep 2012 18:32:13 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: "VITON HORCAJO, Pedro (Pedro)" References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> In-Reply-To: <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:32:18 -0000 On 09/17/2012 07:09 PM, VITON HORCAJO, Pedro (Pedro) wrote: > Glen, > > Thanks for answering. > Maybe my original mail was too long, and I might have not have been clear enough. > > Let me rephase my questions, in a shorter way: > > 1.- The current text for Host-IP-Address AVP indicates the value to send when transporting over SCTP. > But which value should be sent when transporting over TCP? I think that a TCP pseudo-connection can only have two end-points, so the value should probably be the IP address of the sender. I suppose that it could be different, though, in some load balancing scheme: "I'm sending this from address 'A', but from now on I'll be using address 'B'"; of course, the connection w/that address would need to be authenticated, etc. > > 2.- What should a Diameter implementation do when receiving the Host-IP-Address AVP? Any thing it likes, I suppose ;-). > > Best Regards, > Pedro > >>> -----Original Message----- >>> From: Glen Zorn [mailto:glenzorn@gmail.com] >>> Sent: Monday, September 17, 2012 1:06 PM >>> To: VITON HORCAJO, Pedro (Pedro) >>> Cc: dime@ietf.org; glenzorn@gmail.com >>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP >>> >>> >>> On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote: >>>> Hi: >>>> After reviewing original RFC3588 and the lastest draft for >>> 3588bis-34, >>>> I have a couple of comments/questions related to the >>> Host-IP-Address AVP >>>> 1.- I don't have clear the behavior of a diameter peer >>> when SENDING >>>> the Host-IP-Address AVP in the CER/CEA messages, if using TCP to >>>> transport Diameter. >>>> In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5 >>> (Host-IP-Address AVP), >>>> it indicates the behavior with respect to that AVP when >>> using SCTP or >>>> DTLS/SCTP as transport mechanism. >>>> 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 [RFC4960] or >>>> DTLS/SCTP [RFC6083] MUST be advertised in the CER and >>> CEA messages by >>>> including a Host-IP-Address AVP for each address. >>>> When Diameter is run over SCTP [RFC4960] or DTLS/SCTP >>> [RFC6083], >>>> which allow connections to span multiple interfaces, >>> hence, multiple >>>> IP addresses, the Capabilities-Exchange-Answer message >>> MUST contain >>>> one Host-IP-Address AVP for each potential IP address >>> that MAY be >>>> locally used when transmitting Diameter messages. >>>> That might lead to think that if using TCP, that AVP >>> might/needs not >>>> be sent. >>>> However, not sending it would be a contradiction with the >>> CER/CEA ABNF >>>> message format, that states that the Host-IP-Address AVP is a >>>> mandatory AVP with at least 1 ocurrence : >>>> ::= < Diameter Header: 257, REQ > >>>> { Origin-Host } >>>> { Origin-Realm } >>>> 1* { Host-IP-Address } <------------ >>>> ... >>>> I think it would be a good idea to clarify: >>>> A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA >>>> messages if using TCP >>> As you point out, the command definition for the CER >>> requires at least >>> on instance of the AVP. What is unclear? >>> >>> ... >>> From glenzorn@gmail.com Tue Sep 18 04:40:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70BA21E80C2 for ; Tue, 18 Sep 2012 04:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+fJwauoPelH for ; Tue, 18 Sep 2012 04:40:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2921E80A7 for ; Tue, 18 Sep 2012 04:40:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11439693obb.31 for ; Tue, 18 Sep 2012 04:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pMBYg5vn8/PHOraJfv/lom48qPwQVhmnNb4jP21BjYQ=; b=j9tuZyA/9vCvG3jFTjWHBRv5/Sl59A3uJwoir1xLN4+HV6Xy5fKcgi6gGU5h8GHeqS 3Kw1iaQ9w2RhTYoTQOf0hoBT2I+s842u4AcLOw70xMcYaoofMAnBKchqUP09QfFr9ZbK wiTH79FSFgHBQKLnUjwYgcW4nyhQ6BOAxUvvna2OKqS7QU7rkS5HWt4INqyF2L5yF3yG SklbvRLpGPGP+08ArtbOeoMDC4KsKCotfKlXLBqQJ6CjMs/rVeCfn/mwo8kbmjw4VitE oTEyCKk6BQr4xevfUZErs1x9caIhWoO51NXynIiKUjR+c8j9UVVK4WbNrZfcl4AuVn+F NkOw== Received: by 10.182.111.74 with SMTP id ig10mr7055330obb.14.1347968451947; Tue, 18 Sep 2012 04:40:51 -0700 (PDT) Received: from [192.168.0.102] (ppp-58-11-235-161.revip2.asianet.co.th. [58.11.235.161]) by mx.google.com with ESMTPS id qd7sm14135920obc.5.2012.09.18.04.40.49 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 04:40:51 -0700 (PDT) Message-ID: <50585DBF.20502@gmail.com> Date: Tue, 18 Sep 2012 18:40:47 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: jouni korhonen References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:40:52 -0000 On 09/18/2012 03:06 AM, jouni korhonen wrote: > Hi, > > Few quick comments inline. > > On Sep 17, 2012, at 3:09 PM, VITON HORCAJO, Pedro (Pedro) wrote: > >> Glen, >> >> Thanks for answering. >> Maybe my original mail was too long, and I might have not have been clear enough. >> >> Let me rephase my questions, in a shorter way: >> >> 1.- The current text for Host-IP-Address AVP indicates the value to send when transporting over SCTP. >> But which value should be sent when transporting over TCP? > RFC3588bis says: > > 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. > > This part is not SCTP specific. So at minimum you include the address the > very TCP connection comes from. Repetition but acceptable. Also, Diameter > host's DiameterIdentity may resolve to one or more IP addresses but not > necessarily to all of those. It is a DNS provisioning matter. The Diameter > node would know all its addresses it can use, so those additional addresses > would be included. This doesn't really make sense to me: I was under the impression that a TCP connection was between two unique addresses. Yes, a box might ___have_ a whole bunch of addresses it _could_ use, but that seems irrelevant in the case of TCP (but not SCTP). > >> 2.- What should a Diameter implementation do when receiving the Host-IP-Address AVP? > In case of TCP.. that is more like FYI (unless someone plans to hack MPTCP into > Diameter some day). Or in case of transport failure, the peer can select other > IP for retrying the transport connection. Surely it makes more sense just to start over, doesn't it? That behavior also seems to be prescribed by the state machine... ... From jouni.nospam@gmail.com Tue Sep 18 05:07:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961A221F8629 for ; Tue, 18 Sep 2012 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNe5hPlyAo8j for ; Tue, 18 Sep 2012 05:07:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B525A21F876D for ; Tue, 18 Sep 2012 05:07:00 -0700 (PDT) Received: by bkty12 with SMTP id y12so2965292bkt.31 for ; Tue, 18 Sep 2012 05:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6ETBfWnAAZLbh9GLlh2tjayFxjysU624zW1oQP4MiEk=; b=YDps8RZr7Idb/d2+FHM1bfLUymbuJ2DyZJqInj+Cw0holNGl/UmclB20B+frzkpcBL kma+FcmIEtKbgVdENkoJX6Fla27S5gA35yYTR2xMsML66+Ft8CUToRA1+2LvpQNMAO9C QvZeuiKoR64ZNcT8x39URDtJJQooYoxesK3VOsEBPihltm6zW7mci6NUw59l87eWnwey 95q29IRIGkuqjh/n8c6DOcqxhnDATqYVerDCFtpgC6vancoRyb/RJNtpON4of+PMUwav SrPnzgRg2WgSZ5qRIwbn9l3m7EJIyQaACtjdPy5i/AwRr1Z+wAF5pU3NFCnDJsGMbHAw TYPw== Received: by 10.204.152.216 with SMTP id h24mr5614938bkw.42.1347970019784; Tue, 18 Sep 2012 05:06:59 -0700 (PDT) Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id t23sm7657708bks.4.2012.09.18.05.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 05:06:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <50585DBF.20502@gmail.com> Date: Tue, 18 Sep 2012 15:06:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:07:01 -0000 On Sep 18, 2012, at 2:40 PM, Glen Zorn wrote: >>>=20 >>> 1.- The current text for Host-IP-Address AVP indicates the value to = send when transporting over SCTP. >>> But which value should be sent when transporting over TCP? >> RFC3588bis says: >>=20 >> 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. >>=20 >> This part is not SCTP specific. So at minimum you include the address = the >> very TCP connection comes from. Repetition but acceptable. Also, = Diameter >> host's DiameterIdentity may resolve to one or more IP addresses but = not >> necessarily to all of those. It is a DNS provisioning matter. The = Diameter >> node would know all its addresses it can use, so those additional = addresses >> would be included. >=20 > This doesn't really make sense to me: I was under the impression that = a TCP connection was between two unique addresses. Yes, a box might = ___have_ a whole bunch of addresses it _could_ use, but that seems = irrelevant in the case of TCP (but not SCTP). Sure TCP is between just two IPs. I never claimed otherwise. What I mean that say a Diameter node has IP1 to IP5. Only IP1 has a A/AAAA record or given out to other parties for static configuration. During the CER/CEA (and the TCP connection established to IP1) it tell in CEA that "I btw also have IP2 to IP5". A clever implementation can make use of this e.g. for the transport failure case I described. - Jouni From ben@nostrum.com Tue Sep 18 07:15:42 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5BD11E8097 for ; Tue, 18 Sep 2012 07:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoNv9g9o-gxB for ; Tue, 18 Sep 2012 07:15:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA3D411E808E for ; Tue, 18 Sep 2012 07:15:40 -0700 (PDT) Received: from [10.0.1.3] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8IEFZpi057543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 09:15:36 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> Date: Tue, 18 Sep 2012 09:15:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 14:15:42 -0000 On Sep 18, 2012, at 7:06 AM, jouni korhonen = wrote: >=20 > On Sep 18, 2012, at 2:40 PM, Glen Zorn wrote: >>=20 >> This doesn't really make sense to me: I was under the impression that = a TCP connection was between two unique addresses. Yes, a box might = ___have_ a whole bunch of addresses it _could_ use, but that seems = irrelevant in the case of TCP (but not SCTP). >=20 > Sure TCP is between just two IPs. I never claimed otherwise. What I = mean > that say a Diameter node has IP1 to IP5. Only IP1 has a A/AAAA record = or > given out to other parties for static configuration. During the = CER/CEA > (and the TCP connection established to IP1) it tell in CEA that > "I btw also have IP2 to IP5". A clever implementation can make use of > this e.g. for the transport failure case I described. >=20 This actually leads me to agree with the original poster that the = behavior surrounding Host-IP-Address is underspecified. The problem is, = "clever implementations" are bad for interoperability. If that (or = other) behavior is desired, it should be documented. Otherwise any = behavior beyond "use it for informational purposes only" is not likely = to work across implementations. I'm do not propose we fix this in 3588bis--it's too late in the process = for that. But it might be worth a follow-on effort down the road. Thanks! Ben. > - Jouni >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Sep 18 08:14:42 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057C321F8668 for ; Tue, 18 Sep 2012 08:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhnaPpP9Uxl3 for ; Tue, 18 Sep 2012 08:14:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD6A521F8666 for ; Tue, 18 Sep 2012 08:14:40 -0700 (PDT) Received: by bkty12 with SMTP id y12so3087537bkt.31 for ; Tue, 18 Sep 2012 08:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ndp20DCzfUhOTZ02CRlTQ+GCm3I9AT/9Sopw3h0ziFQ=; b=Zqkxx2vLDap14sKkhAi6uv/91qgTGwm6jhpDSn2oKv7yFQn0uE+Onk6VZmVn35haOZ Ug0u8h/9exScvgHY2wwSPapTCpFynfDj+AV9Xy3eXxHmvW/8zWmhG6SAf/++2lnNpEua gsHA5YTZdsv+DlVweB72dn/kGLB/zxbfEcM1o6+YSeYslNVW4ysAoCF98TJhlSywsDKV WgkfMctYLu4VOLiruc23rp5+3a2Xb19ukcY/pJnmkLZoMDLry6ZWjt6Y0YTmG8aGtGoL pKaejgTeapoBe1NPWCNMwiicLxU/NyoVzvp2+nQaiFVXO/viUfRc8zPqEu758E/D9tAh efXQ== Received: by 10.204.128.202 with SMTP id l10mr51439bks.127.1347981279909; Tue, 18 Sep 2012 08:14:39 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id g12sm8180021bkt.7.2012.09.18.08.14.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:14:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> Date: Tue, 18 Sep 2012 18:14:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:14:42 -0000 Ben, On Sep 18, 2012, at 5:15 PM, Ben Campbell wrote: >=20 > On Sep 18, 2012, at 7:06 AM, jouni korhonen = wrote: >=20 >>=20 >> On Sep 18, 2012, at 2:40 PM, Glen Zorn wrote: >>>=20 >=20 >>> This doesn't really make sense to me: I was under the impression = that a TCP connection was between two unique addresses. Yes, a box = might ___have_ a whole bunch of addresses it _could_ use, but that seems = irrelevant in the case of TCP (but not SCTP). >>=20 >> Sure TCP is between just two IPs. I never claimed otherwise. What I = mean >> that say a Diameter node has IP1 to IP5. Only IP1 has a A/AAAA record = or >> given out to other parties for static configuration. During the = CER/CEA >> (and the TCP connection established to IP1) it tell in CEA that >> "I btw also have IP2 to IP5". A clever implementation can make use of >> this e.g. for the transport failure case I described. >>=20 >=20 > This actually leads me to agree with the original poster that the = behavior surrounding Host-IP-Address is underspecified. The problem is, = "clever implementations" are bad for interoperability. If that (or = other) behavior is desired, it should be documented. Otherwise any = behavior beyond "use it for informational purposes only" is not likely = to work across implementations. First, we all agree that having more than one Host-IP-Address in case of TCP is unnecessary. However, I am interested what possible (error) case you have in mind that could cause interoperability issue? - Jouni >=20 > I'm do not propose we fix this in 3588bis--it's too late in the = process for that. But it might be worth a follow-on effort down the = road. >=20 > Thanks! >=20 > Ben. >=20 >=20 >=20 >=20 >> - Jouni >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From ben@nostrum.com Thu Sep 20 11:24:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB76421F86A2 for ; Thu, 20 Sep 2012 11:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOpRe5xIHQkG for ; Thu, 20 Sep 2012 11:24:15 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D2FF621F84F9 for ; Thu, 20 Sep 2012 11:24:14 -0700 (PDT) Received: from [10.0.1.3] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8KIOBns043313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2012 13:24:12 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Ben Campbell In-Reply-To: <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> Date: Thu, 20 Sep 2012 13:24:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1498) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:24:15 -0000 On Sep 18, 2012, at 10:14 AM, jouni korhonen = wrote: > Ben, >=20 > On Sep 18, 2012, at 5:15 PM, Ben Campbell wrote: >=20 >>=20 >> On Sep 18, 2012, at 7:06 AM, jouni korhonen = wrote: >>=20 >>>=20 >>> On Sep 18, 2012, at 2:40 PM, Glen Zorn wrote: >>>>=20 >>=20 >>>> This doesn't really make sense to me: I was under the impression = that a TCP connection was between two unique addresses. Yes, a box = might ___have_ a whole bunch of addresses it _could_ use, but that seems = irrelevant in the case of TCP (but not SCTP). >>>=20 >>> Sure TCP is between just two IPs. I never claimed otherwise. What I = mean >>> that say a Diameter node has IP1 to IP5. Only IP1 has a A/AAAA = record or >>> given out to other parties for static configuration. During the = CER/CEA >>> (and the TCP connection established to IP1) it tell in CEA that >>> "I btw also have IP2 to IP5". A clever implementation can make use = of >>> this e.g. for the transport failure case I described. >>>=20 >>=20 >> This actually leads me to agree with the original poster that the = behavior surrounding Host-IP-Address is underspecified. The problem is, = "clever implementations" are bad for interoperability. If that (or = other) behavior is desired, it should be documented. Otherwise any = behavior beyond "use it for informational purposes only" is not likely = to work across implementations. >=20 > First, we all agree that having more than one Host-IP-Address in case = of > TCP is unnecessary. However, I am interested what possible (error) = case > you have in mind that could cause interoperability issue? I don't have a specific error in mind. My intent was to point out that = while there may be interesting things you can do with Host-IP-Address = (like the example you gave), anything that requires a mutual = understanding between the client and server aren't going to work unless = the understanding exists. In you example, using Host-IP-Address to tell = the peer about other available addresses to be used for load balancing = and/or failover won't work across implementations unless it's documented = somewhere. The original poster pointed out that they were seeing real IOT issues = because different implementors interpreted the spec differently in = regards to Host-IP-Address. Assuming that these differences were due to = reasonable interpretations of the spec, rather than simple = misunderstandings, that's a pretty big indicator that there's a problem. >=20 > - Jouni >=20 From glenzorn@gmail.com Thu Sep 20 23:54:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F6921F8692 for ; Thu, 20 Sep 2012 23:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXl5I00jNuF0 for ; Thu, 20 Sep 2012 23:54:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98A8621F8661 for ; Thu, 20 Sep 2012 23:54:13 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so4530639pbb.31 for ; Thu, 20 Sep 2012 23:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Km3FrFPCG6efEvH0j3yOYAArZnrbwbW7mOL6LgLX1ys=; b=D6r5FZSGJNjeHz3izuYoYsywcUbVgSxVQElcehAFxXWI+kRdpFXpTVElOHgwoetyRy trq8IpxibCzskr8ZcnTAiP+ti4AtL6uaMuMgfdlhh3eazxOw3c5gUtgQsrgcw69CWf0u AeJSroKBKYcTfh3Z3bnv/oZoVkDuv9gOIgXC5mjR+kruDju3rvNMaD7kMKS4SVoKvkLe PLrMCDnVJ9Lp8siL5Cwpp516CwKjL3Qog77hUV+vtu8CwSjvKbNm8yShxqW4kRn/68+f yienBX9PqHEVdPEftn1LN1j9hOCokvjahVHshyc7dPn6Zf2AzlCeDlKvG9GMWB9E4OgN L2Ew== Received: by 10.68.229.201 with SMTP id ss9mr12915837pbc.80.1348210452898; Thu, 20 Sep 2012 23:54:12 -0700 (PDT) Received: from [192.168.0.102] (ppp-110-169-206-48.revip5.asianet.co.th. [110.169.206.48]) by mx.google.com with ESMTPS id nt7sm4700699pbb.33.2012.09.20.23.54.10 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 23:54:12 -0700 (PDT) Message-ID: <505C0F10.3020106@gmail.com> Date: Fri, 21 Sep 2012 13:54:08 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:54:15 -0000 On 09/21/2012 01:24 AM, Ben Campbell wrote: > This doesn't really make sense to me: I was under the impression that > a TCP connection was between two unique addresses. Yes, a box might > ___have_ a whole bunch of addresses it _could_ use, but that seems > irrelevant in the case of TCP (but not SCTP). >>>> >>>> Sure TCP is between just two IPs. I never claimed otherwise. >>>> What I mean that say a Diameter node has IP1 to IP5. Only IP1 >>>> has a A/AAAA record or given out to other parties for static >>>> configuration. During the CER/CEA (and the TCP connection >>>> established to IP1) it tell in CEA that "I btw also have IP2 to >>>> IP5". A clever implementation can make use of this e.g. for the >>>> transport failure case I described. >>>> >>> >>> This actually leads me to agree with the original poster that the >>> behavior surrounding Host-IP-Address is underspecified. The >>> problem is, "clever implementations" are bad for >>> interoperability. If that (or other) behavior is desired, it >>> should be documented. Otherwise any behavior beyond "use it for >>> informational purposes only" is not likely to work across >>> implementations. >> >> First, we all agree that having more than one Host-IP-Address in >> case of TCP is unnecessary. However, I am interested what possible >> (error) case you have in mind that could cause interoperability >> issue? The draft says: 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. Suppose that I send, instead of one address, three (assuming the use of TCP). Which one do you use? What if the list doesn't contain the address from which the CEr/CEA command was sent? If my solution to transport failure is to send you three addresses assuming that you'll try them sequentially and you don't understand that, my scheme fails and since you only have one registered address for me, this could cause a much longer outage than if my network admins just did their job and registered all the available addresses in the DNS. >> > > I don't have a specific error in mind. My intent was to point out > that while there may be interesting things you can do with > Host-IP-Address (like the example you gave), anything that requires a > mutual understanding between the client and server aren't going to > work unless the understanding exists. In you example, using > Host-IP-Address to tell the peer about other available addresses to > be used for load balancing and/or failover won't work across > implementations unless it's documented somewhere. > > The original poster pointed out that they were seeing real IOT issues > because different implementors interpreted the spec differently in > regards to Host-IP-Address. Assuming that these differences were due > to reasonable interpretations of the spec, rather than simple > misunderstandings, that's a pretty big indicator that there's a > problem. I would be inclined to write a short draft clarifying that, in the case of TCP, exactly one instance of the Host-IP-Address MUST be included in the CER/CEA messages. ... From prvs=6042266eb=ankur.garg@rancoretech.com Fri Sep 21 00:11:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5501621F86B8 for ; Fri, 21 Sep 2012 00:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkgJFKER80rb for ; Fri, 21 Sep 2012 00:11:30 -0700 (PDT) Received: from mx01.relbio.com (mx01.relbio.com [203.199.41.240]) by ietfa.amsl.com (Postfix) with ESMTP id DDF4621F858F for ; Fri, 21 Sep 2012 00:11:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,460,1344191400"; d="scan'208,217";a="564977647" Received: from unknown (HELO outpostfix01.ril.com) ([10.66.8.167]) by gwsmtp020.ril.com with ESMTP; 21 Sep 2012 12:39:33 +0530 Received: from rdmail.rancoretech.com (unknown [10.22.140.196]) by outpostfix01.ril.com (Postfix) with SMTP id 2501F12FBC8; Fri, 21 Sep 2012 12:29:00 +0530 (IST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rdmail.rancoretech.com (Postfix) with ESMTP id 5CF724A885C0; Fri, 21 Sep 2012 12:39:33 +0530 (IST) X-Virus-Scanned: amavisd-new at rancoretech.com Received: from rdmail.rancoretech.com ([127.0.0.1]) by localhost (rdmail.rancoretech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04I9555ldHC4; Fri, 21 Sep 2012 12:39:33 +0530 (IST) Received: from rdmail.rancoretech.com (rdmail01.rancoretech.com [10.22.140.196]) by rdmail.rancoretech.com (Postfix) with ESMTP id 40AB64A8857A; Fri, 21 Sep 2012 12:39:33 +0530 (IST) Date: Fri, 21 Sep 2012 12:39:33 +0530 (IST) From: Ankur Garg To: Glen Zorn Message-ID: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> In-Reply-To: <505C0F10.3020106@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1858134_1966231818.1348211373192" X-Originating-IP: [10.34.61.22] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE7 (Win)/6.0.15_GA_2995) Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:11:31 -0000 ------=_Part_1858134_1966231818.1348211373192 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 Is it possible to have two Host-IP-Address AVPs; one containing IPv4 and ot= her is IPv6 address while stack working on dual mode(IPv4 and IPv6) and Con= figured Peer listening on IPv4 only? It would be correct to send both IPv4 = and IPv6 address in such case?=20 =C2=A0=20 Ankur Garg ----- Original Message ----- From: "Glen Zorn" =20 To: "Ben Campbell" =20 Cc: dime@ietf.org=20 Sent: Friday, September 21, 2012 12:24:08 PM=20 Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP=20 On 09/21/2012 01:24 AM, Ben Campbell wrote:=20 > This doesn't really make sense =C2=A0to me: I was under the impression th= at=20 =C2=A0> a TCP connection was between two unique addresses. Yes, a box might= =20 =C2=A0> ___have_ a whole bunch of addresses it _could_ use, but that seems= =20 =C2=A0> irrelevant in the case of TCP (but not SCTP).=20 =C2=A0>>>>=20 =C2=A0>>>> Sure TCP is between just two IPs. I never claimed otherwise.=20 =C2=A0>>>> What I mean that say a Diameter node has IP1 to IP5. Only IP1=20 =C2=A0>>>> has a A/AAAA record or given out to other parties for static=20 =C2=A0>>>> configuration. During the CER/CEA (and the TCP connection=20 =C2=A0>>>> established to IP1) it tell in CEA that "I btw also have IP2 to= =20 =C2=A0>>>> IP5". A clever implementation can make use of this e.g. for the= =20 =C2=A0>>>> transport failure case I described.=20 =C2=A0>>>>=20 =C2=A0>>>=20 =C2=A0>>> This actually leads me to agree with the original poster that the= =20 =C2=A0>>> behavior surrounding Host-IP-Address is underspecified. The=20 =C2=A0>>> problem is, "clever implementations" are bad for=20 =C2=A0>>> interoperability. If that (or other) behavior is desired, it=20 =C2=A0>>> should be documented. Otherwise any behavior beyond "use it for= =20 =C2=A0>>> informational purposes only" is not likely to work across=20 =C2=A0>>> implementations.=20 =C2=A0>>=20 =C2=A0>> First, we all agree that having more than one Host-IP-Address in= =20 =C2=A0>> case of TCP is unnecessary. However, I am interested what possible= =20 =C2=A0>> (error) case you have in mind that could cause interoperability=20 =C2=A0>> issue?=20 The draft says:=20 =C2=A0=C2=A0 =C2=A0The Host-IP-Address AVP (AVP Code 257) is of type Addres= s and is used=20 =C2=A0=C2=A0 =C2=A0to inform a Diameter peer of the sender's IP address.=20 Suppose that I send, instead of one address, three (assuming the use of=20 TCP). =C2=A0Which one do you use? =C2=A0What if the list doesn't contain th= e=20 address from which the CEr/CEA command was sent? =C2=A0If my solution to=20 transport failure is to send you three addresses assuming that you'll=20 try them sequentially and you don't understand that, my scheme fails and=20 since you only have one registered address for me, this could cause a=20 much longer outage than if my network admins just did their job and=20 registered all the available addresses in the DNS.=20 >>=20 =C2=A0>=20 =C2=A0> I don't have a specific error in mind. My intent was to point out= =20 =C2=A0> that while there may be interesting things you can do with=20 =C2=A0> Host-IP-Address (like the example you gave), anything that requires= a=20 =C2=A0> mutual understanding between the client and server aren't going to= =20 =C2=A0> work unless the understanding exists. In you example, using=20 =C2=A0> Host-IP-Address to tell the peer about other available addresses to= =20 =C2=A0> be used for load balancing and/or failover won't work across=20 =C2=A0> implementations unless it's documented somewhere.=20 =C2=A0>=20 =C2=A0> The original poster pointed out that they were seeing real IOT issu= es=20 =C2=A0> because different implementors interpreted the spec differently in= =20 =C2=A0> regards to Host-IP-Address. Assuming that these differences were du= e=20 =C2=A0> to reasonable interpretations of the spec, rather than simple=20 =C2=A0> misunderstandings, that's a pretty big indicator that there's a=20 =C2=A0> problem.=20 I would be inclined to write a short draft clarifying that, in the case=20 of TCP, exactly one instance of the Host-IP-Address MUST be included in=20 the CER/CEA messages.=20 ...=20 _______________________________________________=20 DiME mailing list=20 DiME@ietf.org=20 https://www.ietf.org/mailman/listinfo/dime=20 ------=_Part_1858134_1966231818.1348211373192 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>

Hello,

Is it possible to have two Host-IP-Address AVPs; one containing IPv4 and= other is IPv6 address while stack working on dual mode(IPv4 and IPv6) and = Configured Peer listening on IPv4 only? It would be correct to send both IP= v4 and IPv6 address in such case?

 

Ankur Garg=20



From: "Glen Zorn" <glenzorn@gmail.com>
To: "Ben Campbell" &= lt;ben@nostrum.com>
Cc: dime@ietf.org
Sent: Friday, September 21, = 2012 12:24:08 PM
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address A= VP

On 09/21/2012 01:24 AM, Ben Campbell wrote:

> This does= n't really make sense  to me: I was under the impression that
 = ;> a TCP connection was between two unique addresses. Yes, a box might > ___have_ a whole bunch of addresses it _could_ use, but that s= eems
 > irrelevant in the case of TCP (but not SCTP).
 &= gt;>>>
 >>>> Sure TCP is between just two IPs.= I never claimed otherwise.
 >>>> What I mean that say = a Diameter node has IP1 to IP5. Only IP1
 >>>> has a A/= AAAA record or given out to other parties for static
 >>>&= gt; configuration. During the CER/CEA (and the TCP connection
 >= >>> established to IP1) it tell in CEA that "I btw also have IP2 t= o
 >>>> IP5". A clever implementation can make use of t= his e.g. for the
 >>>> transport failure case I describ= ed.
 >>>>
 >>>
 >>> T= his actually leads me to agree with the original poster that the
 &= gt;>> behavior surrounding Host-IP-Address is underspecified. The
=  >>> problem is, "clever implementations" are bad for
&nbs= p;>>> interoperability. If that (or other) behavior is desired, it=
 >>> should be documented. Otherwise any behavior beyond = "use it for
 >>> informational purposes only" is not likel= y to work across
 >>> implementations.
 >> >> First, we all agree that having more than one Host-IP-Addr= ess in
 >> case of TCP is unnecessary. However, I am interest= ed what possible
 >> (error) case you have in mind that could= cause interoperability
 >> issue?

The draft says:
=
    The Host-IP-Address AVP (AVP Code 257) is of type Ad= dress and is used
    to inform a Diameter peer of the se= nder's IP address.

Suppose that I send, instead of one address, thre= e (assuming the use of
TCP).  Which one do you use?  What if = the list doesn't contain the
address from which the CEr/CEA command was= sent?  If my solution to
transport failure is to send you three a= ddresses assuming that you'll
try them sequentially and you don't under= stand that, my scheme fails and
since you only have one registered addr= ess for me, this could cause a
much longer outage than if my network ad= mins just did their job and
registered all the available addresses in t= he DNS.

>>
 >
 > I don't have a specific= error in mind. My intent was to point out
 > that while there m= ay be interesting things you can do with
 > Host-IP-Address (lik= e the example you gave), anything that requires a
 > mutual unde= rstanding between the client and server aren't going to
 > work = unless the understanding exists. In you example, using
 > Host-I= P-Address to tell the peer about other available addresses to
 >= be used for load balancing and/or failover won't work across
 >= implementations unless it's documented somewhere.
 >
 &= gt; The original poster pointed out that they were seeing real IOT issues > because different implementors interpreted the spec differentl= y in
 > regards to Host-IP-Address. Assuming that these differen= ces were due
 > to reasonable interpretations of the spec, rathe= r than simple
 > misunderstandings, that's a pretty big indicato= r that there's a
 > problem.

I would be inclined to write= a short draft clarifying that, in the case
of TCP, exactly one instanc= e of the Host-IP-Address MUST be included in
the CER/CEA messages.
<= BR>...

_______________________________________________
DiME maili= ng list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
<= /P>

------=_Part_1858134_1966231818.1348211373192-- From jouni.nospam@gmail.com Fri Sep 21 00:24:47 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2807821E8083 for ; Fri, 21 Sep 2012 00:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5avgfKMUwD3q for ; Fri, 21 Sep 2012 00:24:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29021E8051 for ; Fri, 21 Sep 2012 00:24:45 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so752440wgb.13 for ; Fri, 21 Sep 2012 00:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XxlRYBeZcPIN1RhHwb2hdMMwWVXLSt9jpE9UCmhVYRE=; b=UC9eLFV/la2azpja03PmaQNn09O6ek8Maq/oxe3HvyzIQU9ByllFAVP6IJ2zvodyGM cocBIPUesjdR21ROOtK2hubAi2uoT0+bcebnMc3uzxm6NTp3SVC2ydx7IBenesP6Wg+v punUu2FFFAxYJf91dbmKFel8B+ZQCDAE5S8KDRWZwALRuLUhw90gB2pI4AXlLc9JCM8Q 0hjoyW2lPE3I5VjOKXUm7mX+aSVaZuOVMeil6N25lk62JyXf3BVSTiZDK8lRmCta07VM Y9bzsFv+ZpJ1zzdTxDQk7rkEChfOwgHXyIcTme+YwwZ89QhhM8HOYCtnGSOH7kogAQC0 BFag== Received: by 10.180.91.169 with SMTP id cf9mr1983660wib.1.1348212285094; Fri, 21 Sep 2012 00:24:45 -0700 (PDT) Received: from [10.255.134.5] ([194.251.119.201]) by mx.google.com with ESMTPS id hv8sm2932091wib.0.2012.09.21.00.24.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 00:24:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <505C0F10.3020106@gmail.com> Date: Fri, 21 Sep 2012 10:24:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8314502B-CD54-460C-B3E0-A3401E3F6BC5@gmail.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> <505C0F10.3020106@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:24:47 -0000 Glen, On Sep 21, 2012, at 9:54 AM, Glen Zorn wrote: > On 09/21/2012 01:24 AM, Ben Campbell wrote: >=20 >> This doesn't really make sense to me: I was under the impression = that > > a TCP connection was between two unique addresses. Yes, a box might > > ___have_ a whole bunch of addresses it _could_ use, but that seems > > irrelevant in the case of TCP (but not SCTP). > >>>> > >>>> Sure TCP is between just two IPs. I never claimed otherwise. > >>>> What I mean that say a Diameter node has IP1 to IP5. Only IP1 > >>>> has a A/AAAA record or given out to other parties for static > >>>> configuration. During the CER/CEA (and the TCP connection > >>>> established to IP1) it tell in CEA that "I btw also have IP2 to > >>>> IP5". A clever implementation can make use of this e.g. for the > >>>> transport failure case I described. > >>>> > >>> > >>> This actually leads me to agree with the original poster that the > >>> behavior surrounding Host-IP-Address is underspecified. The > >>> problem is, "clever implementations" are bad for > >>> interoperability. If that (or other) behavior is desired, it > >>> should be documented. Otherwise any behavior beyond "use it for > >>> informational purposes only" is not likely to work across > >>> implementations. > >> > >> First, we all agree that having more than one Host-IP-Address in > >> case of TCP is unnecessary. However, I am interested what possible > >> (error) case you have in mind that could cause interoperability > >> issue? >=20 > The draft says: >=20 > 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. >=20 > Suppose that I send, instead of one address, three (assuming the use = of TCP). Which one do you use? What if the list doesn't contain the = address from which the CEr/CEA command was sent? If my solution to = transport failure is to send you three addresses=20 Obviously you use the address you received CER/CEA from.. and if that = address is not included in the list of Host-IP-Addresses then the other end is on weeds. > assuming that you'll try them sequentially and you don't understand = that, my scheme fails and since you only have one registered address for = me, this could cause a much longer outage than if my network admins just = did their job and registered all the available addresses in the DNS. >=20 >>>=20 > > > > I don't have a specific error in mind. My intent was to point out > > that while there may be interesting things you can do with > > Host-IP-Address (like the example you gave), anything that requires = a > > mutual understanding between the client and server aren't going to > > work unless the understanding exists. In you example, using > > Host-IP-Address to tell the peer about other available addresses to > > be used for load balancing and/or failover won't work across > > implementations unless it's documented somewhere. > > > > The original poster pointed out that they were seeing real IOT = issues > > because different implementors interpreted the spec differently in > > regards to Host-IP-Address. Assuming that these differences were due > > to reasonable interpretations of the spec, rather than simple > > misunderstandings, that's a pretty big indicator that there's a > > problem. >=20 > I would be inclined to write a short draft clarifying that, in the = case of TCP, exactly one instance of the Host-IP-Address MUST be = included in the CER/CEA messages. Might be a good thing. - Jouni >=20 > ... >=20 From jouni.nospam@gmail.com Fri Sep 21 00:41:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A58B21F86B7 for ; Fri, 21 Sep 2012 00:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0ayhTfZMj7v for ; Fri, 21 Sep 2012 00:41:37 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD3C21F86AF for ; Fri, 21 Sep 2012 00:41:37 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1326393wib.13 for ; Fri, 21 Sep 2012 00:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4CCu8AQXGjMCwnlpUeX/6U20XR6Ed+5cgDacr3H6yTE=; b=CsQzWVZMlJEGtavQILFO/JQ99AznF4Gm303DqI4+yJPRHLFLciGXtXtBg4d9y54kC3 4Pnq+PVERYGCzYKkEAargVTN4+LeoFdV4XGN3Nyjv+BQU4mpEyEm5jLohXc7ZyBeC2fe mog7lu+JO9DkO/hURYiw9j8mUYvvsACVXEsrrbIgYV5ds2IhnQeUXz9JBCyczX4IQxNP /SOCm4BeL6uUrkJZJDGrqWMKhxqIP0WY6RCFOG+v1PVOMQekK7NnOa6SSc6GlY3/0EN4 L4TDcTpvMHSdUcvuBN06vtz2u02iRZV2sLpVVpFUNruXQkkKuTRYJ/QFaNezyWbqE8PM X69A== Received: by 10.216.201.24 with SMTP id a24mr2544980weo.102.1348213296695; Fri, 21 Sep 2012 00:41:36 -0700 (PDT) Received: from [10.255.134.5] ([194.251.119.201]) by mx.google.com with ESMTPS id j6sm15213215wiy.4.2012.09.21.00.41.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 00:41:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> Date: Fri, 21 Sep 2012 10:41:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6D280149-BF41-4741-9188-3CC981433D61@gmail.com> References: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> To: Ankur Garg X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:41:38 -0000 On Sep 21, 2012, at 10:09 AM, Ankur Garg wrote: > Hello, > Is it possible to have two Host-IP-Address AVPs; one containing IPv4 = and other is IPv6 address while stack working on dual mode(IPv4 and = IPv6) and Configured Peer listening on IPv4 only? It would be correct to = send both IPv4 and IPv6 address in such case? Yes for the first part and no for the second part.. you are not supposed = to send addresses that you cannot be connected at. - Jouni > =20 > Ankur Garg >=20 From jouni.nospam@gmail.com Fri Sep 21 01:05:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7885221F87B5 for ; Fri, 21 Sep 2012 01:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIztVxMJXDH8 for ; Fri, 21 Sep 2012 01:05:50 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF50321F87E9 for ; Fri, 21 Sep 2012 01:05:49 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so770541wgb.13 for ; Fri, 21 Sep 2012 01:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QwpiEBRL4xmNBU9KL+Kza4bwt1hvNKJodh1PUhZdGzg=; b=Dj2gzY6R2vaQXX18YGp40lkOUYLzomemsfmb20NU0nxiGQg3LIg2ZooKQ8vSUziwiY 2wS6U1rLEOcl7mXaCpUGEsnwu3ikOJHCCr4kZYkWPYev8NXdEjeB+n6HrVdhkAerKVBo 9MiBSVYie4hlsEnGHPI3O288h7fiwMes/v2Dq/54uGtKG4sJYxo0ruf7W/cwEnAce+5O tEtOgSR/2fitTF8/u43eEnjvLAjaHU+RS5jSoGcLcB061c7PEANqcl9DUEbLzc44a1Gb 60SPhrv7IdjJI6KdfazV2GycrQamBBI+TSaTEaOyX4LgM5SYM+/pBdJ7w7EHvjhUFtye HvVw== Received: by 10.180.108.45 with SMTP id hh13mr2795264wib.15.1348214748918; Fri, 21 Sep 2012 01:05:48 -0700 (PDT) Received: from [10.255.134.5] ([194.251.119.201]) by mx.google.com with ESMTPS id cl8sm36713084wib.10.2012.09.21.01.05.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 01:05:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> Date: Fri, 21 Sep 2012 11:05:41 +0300 Content-Transfer-Encoding: 7bit Message-Id: <15B788C9-6080-462B-96FF-417C93448DC8@gmail.com> References: <1FD6C07D-675B-4190-832C-D07F59DF1CF1@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] DIME WG Call for adoption draft-mcmurry-dime-overload-reqs-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:05:50 -0000 Folks, The support for the adoption of this I-D was overwhelming. Authors, go ahead and submit draft-ietf-*-00 version of the document. Note that document shall be Informational. The milestone update is already in process but has not materialized yet. - Jouni & Lionel On Sep 6, 2012, at 11:31 AM, jouni korhonen wrote: > Folks, > > This email starts a two week consensus call on adopting: > > Title : Diameter Overload Control Requirements > Author(s) : Eric McMurry > Ben Campbell > Filename : draft-mcmurry-dime-overload-reqs-02.txt > Pages : 25 > Date : 2012-08-28 > > as a Dime WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or > to the chairs. This call will end September 20, 2012. > > - Jouni & Lionel From pedro.viton@alcatel-lucent.com Fri Sep 21 02:24:33 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A372221F8731 for ; Fri, 21 Sep 2012 02:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.173 X-Spam-Level: X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu4TmUL6kB7j for ; Fri, 21 Sep 2012 02:24:32 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C44CF21F86FD for ; Fri, 21 Sep 2012 02:24:31 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8L9Lb0c020708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Sep 2012 11:24:30 +0200 Received: from FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 21 Sep 2012 11:24:14 +0200 From: "VITON HORCAJO, Pedro (Pedro)" To: "dime@ietf.org" Date: Fri, 21 Sep 2012 11:24:13 +0200 Thread-Topic: [Dime] [RFC3588bis-34] - Host-IP-Address AVP Thread-Index: Ac2XyFp4jjluNl+bTGW8FsBAUPzC+QAAHqXA Message-ID: <5F42DFF905CBA544A7BBB0909003E1A3148F1BB846@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> References: <505C0F10.3020106@gmail.com> <979805090.1858135.1348211373193.JavaMail.root@rdmail01> In-Reply-To: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5F42DFF905CBA544A7BBB0909003E1A3148F1BB846FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:24:33 -0000 --_000_5F42DFF905CBA544A7BBB0909003E1A3148F1BB846FRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me step in again: I've read you're making references to DNS and that valid IP addresses to re= ceive/send Diameter messages should be registerd in DNS. In that case, what extra information does the Host-IP-Address AVP add with = respecto to DNS? If it provides duplicate information, it can be a source of conflict betwee= n DNS A/AAAA records and the advertised Host-IP-Address(es). I think it would be better to use only 1 source of information between Orig= in-Host and IP address(es): either DNS or Host-IP-Address But I suppose that at this stage, removing Host-IP-Address would create mor= e interoperability issues that leaving it, and indicating which value(s) to= send with TCP and specifying what a receiver should do with that informati= on. Let me put an example, where it might be interesting to have 2 Host-IP-Addr= esses with TCP, which I don't know if it would be feasable (and desirable) = or not (or is a "mischievious" interpretation of the RFC's) Imagine we have 2 servers (for Acct application for instance), each one con= figured with its own IP address (named IP1 & IP2). But configured to be the backup of the other, sharing state between them, a= nd sharing the same Origin-Host !!! Server1 could advertise in Host-IP-Address 2 IP's: IP1 (its own) & IP2 (it= s mated server) in its CEA messages. And similarly for server2, also advertising the 2 IP's- If the Diameter client (for Accounting I'm supposing that the client is the= one always trying to establish the TCP connection) loses connectivity with= IP1, and that IP1 is no longer reachable (or its Diameter server is tempor= arily down), then the Diameter client could try to contact IP2. As the 2 servers are sharing state & Origin-Host, the Diameter client would= n't be able to distinguish if IP1 & IP2 are 2 interfaces of the same server= , or not. But that would be a way for the Diameter server to have High Availability, = without the need for 3rd party software to configure a Cluster sharing a vi= rtual IP address. And that redundancy could even be geographical, as IP1 & IP2 need not be in= the same subnet. But for that: 1.- Several Host-IP-Address ocurrences should be allowed to be sent in the = CER/CEA messages, both with TCP & SCTP (or alternatively configured in the = DNS servers) 2.- It should be specified somewhere in a RFC that the Diameter peers estab= lishing a Diameter transport connection should retry secuentially to the ad= vertised Host-IP-Addresses in the last received CER/CEA message (or configu= red addresses in DNS) Best Regards, Pedro ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ank= ur Garg Sent: Friday, September 21, 2012 9:10 AM To: Glen Zorn Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP Hello, Is it possible to have two Host-IP-Address AVPs; one containing IPv4 and ot= her is IPv6 address while stack working on dual mode(IPv4 and IPv6) and Con= figured Peer listening on IPv4 only? It would be correct to send both IPv4 = and IPv6 address in such case? Ankur Garg ________________________________ From: "Glen Zorn" To: "Ben Campbell" Cc: dime@ietf.org Sent: Friday, September 21, 2012 12:24:08 PM Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP On 09/21/2012 01:24 AM, Ben Campbell wrote: > This doesn't really make sense to me: I was under the impression that > a TCP connection was between two unique addresses. Yes, a box might > ___have_ a whole bunch of addresses it _could_ use, but that seems > irrelevant in the case of TCP (but not SCTP). >>>> >>>> Sure TCP is between just two IPs. I never claimed otherwise. >>>> What I mean that say a Diameter node has IP1 to IP5. Only IP1 >>>> has a A/AAAA record or given out to other parties for static >>>> configuration. During the CER/CEA (and the TCP connection >>>> established to IP1) it tell in CEA that "I btw also have IP2 to >>>> IP5". A clever implementation can make use of this e.g. for the >>>> transport failure case I described. >>>> >>> >>> This actually leads me to agree with the original poster that the >>> behavior surrounding Host-IP-Address is underspecified. The >>> problem is, "clever implementations" are bad for >>> interoperability. If that (or other) behavior is desired, it >>> should be documented. Otherwise any behavior beyond "use it for >>> informational purposes only" is not likely to work across >>> implementations. >> >> First, we all agree that having more than one Host-IP-Address in >> case of TCP is unnecessary. However, I am interested what possible >> (error) case you have in mind that could cause interoperability >> issue? The draft says: 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. Suppose that I send, instead of one address, three (assuming the use of TCP). Which one do you use? What if the list doesn't contain the address from which the CEr/CEA command was sent? If my solution to transport failure is to send you three addresses assuming that you'll try them sequentially and you don't understand that, my scheme fails and since you only have one registered address for me, this could cause a much longer outage than if my network admins just did their job and registered all the available addresses in the DNS. >> > > I don't have a specific error in mind. My intent was to point out > that while there may be interesting things you can do with > Host-IP-Address (like the example you gave), anything that requires a > mutual understanding between the client and server aren't going to > work unless the understanding exists. In you example, using > Host-IP-Address to tell the peer about other available addresses to > be used for load balancing and/or failover won't work across > implementations unless it's documented somewhere. > > The original poster pointed out that they were seeing real IOT issues > because different implementors interpreted the spec differently in > regards to Host-IP-Address. Assuming that these differences were due > to reasonable interpretations of the spec, rather than simple > misunderstandings, that's a pretty big indicator that there's a > problem. I would be inclined to write a short draft clarifying that, in the case of TCP, exactly one instance of the Host-IP-Address MUST be included in the CER/CEA messages. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_5F42DFF905CBA544A7BBB0909003E1A3148F1BB846FRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Let me=20 step in again:
 
 
I've=20 read you're making references to DNS and that valid IP addresses to receive= /send=20 Diameter messages should be registerd in DNS.
In=20 that case, what extra information does the Host-IP-Address AVP add with res= pecto=20 to DNS?
 
If it=20 provides duplicate information, it can be a source of conflict between= DNS=20 A/AAAA records and the advertised Host-IP-Address(es).
I=20 think it would be better to use only 1 source of information between Origin= -Host=20 and IP address(es): either DNS or Host-IP-Address
 
But I=20 suppose that at this stage, removing Host-IP-Address would create more=20 interoperability issues that leaving it, and indicating which value(s) to s= end=20 with TCP and specifying what a receiver should do with that=20 information.
 
 
 
Let me=20 put an example, where it might be interesting to have 2 Host-IP-Addresses w= ith=20 TCP, which I don't know if it would be feasable (and desirable) or not= (or=20 is a "mischievious" interpretation of the RFC's)
 
Imagine we have 2 servers (for Acct application for instance), eac= h one=20 configured with its own IP address (named IP1 & IP2).
But=20 configured to be the backup of the other, sharing state between them, and=20 sharing the same Origin-Host !!!
Server1 could advertise  in Host-IP-Address 2 IP's: IP1 = (its=20 own) & IP2 (its mated server) in its CEA messages.
And=20 similarly for server2, also advertising the 2 IP's-
 
If the=20 Diameter client (for Accounting I'm supposing that the client is the one al= ways=20 trying to establish the TCP connection) loses connectivity with IP1, and th= at=20 IP1 is no longer reachable (or its Diameter server is temporarily down), th= en=20 the Diameter client could try to contact IP2.
As the=20 2 servers are sharing state & Origin-Host, the Diameter client wouldn't= be=20 able to distinguish if IP1 & IP2 are 2 interfaces of the same server, o= r=20 not.
But=20 that would be a way for the Diameter server to have High Availability, with= out=20 the need for 3rd party software to configure a Cluster sharing a virtual IP= =20 address.
And=20 that redundancy could even be geographical, as IP1 & IP2 need not be in= the=20 same subnet.
 
But=20 for that:
1.-=20 Several Host-IP-Address ocurrences should be allowed to be sent in the CER/= CEA=20 messages, both with TCP & SCTP (or alternatively configured in the DNS= =20 servers)
2.- It=20 should be specified somewhere in a RFC that the Diameter peers establishing= =20 a Diameter transport connection should retry secuentially to the= =20 advertised Host-IP-Addresses in the last received CER/CEA message (or= =20 configured addresses in DNS)
 
 
Best=20 Regards,
 =20 Pedro


From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Ankur Garg
Sent:= =20 Friday, September 21, 2012 9:10 AM
To: Glen Zorn
Cc:= =20 dime@ietf.org
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Add= ress=20 AVP

Hello,

Is it possible to have two Host-IP-Address AVPs; one containing IPv4 a= nd=20 other is IPv6 address while stack working on dual mode(IPv4 and IPv6) and= =20 Configured Peer listening on IPv4 only? It would be correct to send both = IPv4=20 and IPv6 address in such case?

 

Ankur Garg=20



From: "Glen Zorn" <glenzorn@gmail.com>
To: "Ben Campbell"= =20 <ben@nostrum.com>
Cc: dime@ietf.org
Sent: Friday, September 2= 1,=20 2012 12:24:08 PM
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address= =20 AVP

On 09/21/2012 01:24 AM, Ben Campbell wrote:

> This=20 doesn't really make sense  to me: I was under the impression=20 that
 > a TCP connection was between two unique addresses. Yes= , a=20 box might
 > ___have_ a whole bunch of addresses it _could_ us= e,=20 but that seems
 > irrelevant in the case of TCP (but not=20 SCTP).
 >>>>
 >>>> Sure TCP is be= tween=20 just two IPs. I never claimed otherwise.
 >>>> What I= mean=20 that say a Diameter node has IP1 to IP5. Only IP1
 >>>&g= t;=20 has a A/AAAA record or given out to other parties for=20 static
 >>>> configuration. During the CER/CEA (and t= he=20 TCP connection
 >>>> established to IP1) it tell in C= EA=20 that "I btw also have IP2 to
 >>>> IP5". A clever=20 implementation can make use of this e.g. for the
 >>>>= ;=20 transport failure case I=20 described.
 >>>>
 >>>
 >&= gt;>=20 This actually leads me to agree with the original poster that=20 the
 >>> behavior surrounding Host-IP-Address is=20 underspecified. The
 >>> problem is, "clever implementat= ions"=20 are bad for
 >>> interoperability. If that (or other)=20 behavior is desired, it
 >>> should be documented. Other= wise=20 any behavior beyond "use it for
 >>> informational purpo= ses=20 only" is not likely to work across
 >>>=20 implementations.
 >>
 >> First, we all agree = that=20 having more than one Host-IP-Address in
 >> case of TCP is= =20 unnecessary. However, I am interested what possible
 >> (er= ror)=20 case you have in mind that could cause interoperability
 >>= =20 issue?

The draft says:

    The Host-IP-Addre= ss=20 AVP (AVP Code 257) is of type Address and is used
    t= o=20 inform a Diameter peer of the sender's IP address.

Suppose that I = send,=20 instead of one address, three (assuming the use of
TCP).  Which = one=20 do you use?  What if the list doesn't contain the
address from w= hich=20 the CEr/CEA command was sent?  If my solution to
transport failu= re is=20 to send you three addresses assuming that you'll
try them sequentiall= y and=20 you don't understand that, my scheme fails and
since you only have on= e=20 registered address for me, this could cause a
much longer outage than= if=20 my network admins just did their job and
registered all the available= =20 addresses in the DNS.

>>
 >
 > I don't= have=20 a specific error in mind. My intent was to point out
 > that w= hile=20 there may be interesting things you can do with
 > Host-IP-Add= ress=20 (like the example you gave), anything that requires a
 > mutua= l=20 understanding between the client and server aren't going to
 >= work=20 unless the understanding exists. In you example, using
 >=20 Host-IP-Address to tell the peer about other available addresses=20 to
 > be used for load balancing and/or failover won't work=20 across
 > implementations unless it's documented=20 somewhere.
 >
 > The original poster pointed out th= at=20 they were seeing real IOT issues
 > because different implemen= tors=20 interpreted the spec differently in
 > regards to Host-IP-Addr= ess.=20 Assuming that these differences were due
 > to reasonable=20 interpretations of the spec, rather than simple
 >=20 misunderstandings, that's a pretty big indicator that there's a
 = >=20 problem.

I would be inclined to write a short draft clarifying tha= t, in=20 the case
of TCP, exactly one instance of the Host-IP-Address MUST be= =20 included in
the CER/CEA=20 messages.

...

_____________________________________________= __
DiME=20 mailing=20 list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--_000_5F42DFF905CBA544A7BBB0909003E1A3148F1BB846FRMRSSXCHMBSC_-- From aleksas.vytautas@gmail.com Fri Sep 21 04:13:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0421F85B4 for ; Fri, 21 Sep 2012 04:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrV-6fHfcIxq for ; Fri, 21 Sep 2012 04:13:31 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5748C21F8554 for ; Fri, 21 Sep 2012 04:13:31 -0700 (PDT) Received: by oagn5 with SMTP id n5so2931551oag.31 for ; Fri, 21 Sep 2012 04:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JWohSMAbRvCQOss3IKDG396yNldFq6hhCvksyKc83ts=; b=CdO8Ud8teXXPx32aEsjCLZK/7+3FhkFiDqFDE0shakgRKqZyn/FQmgwej2tyO6bFe8 /5okI365bQCsO6EG+ISfZj2++w3emlpzeVu3r9ZTMGg8xrXtOeFAq8FZRTjJI5/VlWK0 nvcis2x5/6gRjShqwfM1HcD3BgxKEWpzbxy/GK0byoaIDSPgUdo+h0Iv8Xzl3wxvn3aC lkA+fu/XxG7yj9jpa1g2Y+I2NFnvceRxu8Hnor6Xj1WxNYMVFbn6pk2opvwmIEPBy/an 0tAjMWcjf9lTYf0rizm6lnFIMFCPwfIIsMeUf7Js0Oe+t5zG8asdHWLuF3ELJ2JmWDpW HhcA== MIME-Version: 1.0 Received: by 10.60.170.83 with SMTP id ak19mr3191569oec.113.1348226010915; Fri, 21 Sep 2012 04:13:30 -0700 (PDT) Received: by 10.76.151.35 with HTTP; Fri, 21 Sep 2012 04:13:30 -0700 (PDT) Date: Fri, 21 Sep 2012 12:13:30 +0100 Message-ID: From: aleksas vytautas To: dime@ietf.org Content-Type: multipart/alternative; boundary=bcaec54a336875236b04ca345443 Subject: [Dime] Timeline for the next Diameter Base Protocol RFC? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 11:13:31 -0000 --bcaec54a336875236b04ca345443 Content-Type: text/plain; charset=ISO-8859-1 Hi all, As per the announcement in: http://www.ietf.org/mail-archive/web/dime/current/msg05200.html What is the expected timeline for this draft to become RFC? Should there be anything holding one back treating it as RFC? Thank you, Aleksas --bcaec54a336875236b04ca345443 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

As per the announcement in:

=A0=A0 http://www.ietf.o= rg/mail-archive/web/dime/current/msg05200.html

What is the expec= ted timeline for this draft to become RFC? Should there be anything holding= one back treating it as RFC?


Thank you,

Aleksas
--bcaec54a336875236b04ca345443-- From internet-drafts@ietf.org Fri Sep 21 06:16:37 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E31D21F8815; Fri, 21 Sep 2012 06:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHCtGLmelijv; Fri, 21 Sep 2012 06:16:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E102B21F8807; Fri, 21 Sep 2012 06:16:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921131636.23167.68720.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 06:16:36 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:16:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-ietf-dime-overload-reqs-00.txt Pages : 25 Date : 2012-09-21 Abstract: When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in congestion collapse. The existing mechanisms provided by Diameter are not sufficient for this purpose. This document describes the limitations of the existing mechanisms, and provides requirements for new overload management mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.nospam@gmail.com Fri Sep 21 06:24:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69FC21F8812 for ; Fri, 21 Sep 2012 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYd7dvNULpTy for ; Fri, 21 Sep 2012 06:24:56 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C238D21F847B for ; Fri, 21 Sep 2012 06:24:55 -0700 (PDT) Received: by lboj14 with SMTP id j14so3703394lbo.31 for ; Fri, 21 Sep 2012 06:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Y0EG6ykXUiWrX6TbgItQGnVqt/M9B4wthJMvtSHDAoE=; b=yAGhD2YIHz357Tur/zulisvrKHMzUf8+B//97i+v9d3hVe2TgU+XQeASYQtZ0yTofH zkPpcWOGi/mq6NpjPufEFMl+EwaiE/46R/tXB1+QIzFXPiThlzFnd+RoJRVIWIzf+Evs 2HQCJ2ekABwTg+X4WeHEA4XtyFuyHeIqFu36a/YHCuClI8vg+octkuRQAI/nfd0NA0/M heZHtCf3YfEf99xGD2NtmG8U6FdKtKrbMckRh2KKXie4mJy8XT1RmKKrZaGWeEypF/wI rZ5B6cVzNlvq6az953j7nualk2nNrOnM8PT+bOPyld0dAoTKmcRmJSSC406ynVnCR8VA sMKg== Received: by 10.152.110.101 with SMTP id hz5mr4271364lab.39.1348233894712; Fri, 21 Sep 2012 06:24:54 -0700 (PDT) Received: from [10.37.156.104] ([77.95.242.69]) by mx.google.com with ESMTPS id bc2sm2294994lbb.3.2012.09.21.06.24.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:24:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 21 Sep 2012 16:24:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <89A40B35-38A2-4B74-BA0A-CFED80EA801A@gmail.com> References: To: aleksas vytautas X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] Timeline for the next Diameter Base Protocol RFC? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:24:56 -0000 http://www.rfc-editor.org/auth48/rfc6733 On Sep 21, 2012, at 2:13 PM, aleksas vytautas wrote: > Hi all, >=20 > As per the announcement in: >=20 > http://www.ietf.org/mail-archive/web/dime/current/msg05200.html >=20 > What is the expected timeline for this draft to become RFC? Should = there be anything holding one back treating it as RFC? >=20 >=20 > Thank you, >=20 > Aleksas > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Fri Sep 21 06:27:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEEE21F8812 for ; Fri, 21 Sep 2012 06:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xo2NSb+ybpU for ; Fri, 21 Sep 2012 06:27:32 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB2821F847B for ; Fri, 21 Sep 2012 06:27:32 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5256368pbb.31 for ; Fri, 21 Sep 2012 06:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=19w5OOxw8wctgKPH1I/G1mfFhDrSD6f9Y2IjSwx5BfU=; b=QBymyagtySs7qkvlfkvD7Hf0fsSfBb9CoSAjjXa7xPLxUaQbXpksNnPXo7Z11IbD4l raWM+pkJ754PMbUblgDykmWBet3HsA5crVjrQdn8/HTIKCdVokQKoakQRAy3cPF73DuE C6JjEoRhkzQxv8ty3m++8YW+eG86G8CydQKqk7Wjf69ymSmWd7s9ZFbuwZhLpgeh2ZAR GaaVhKvGQ43c6LvBsvyjs4VUBWDVHxhyONG5cR1fHxYg1CX/ZoQ2qtkIaV+DxEoCik/P jxgvF3NhEmQ+PBD2X70rnf+GEqzYiKtRouJvpkr+sIK2sQhMBdmlrjZSFainRunzOW8+ Ec0w== Received: by 10.68.212.70 with SMTP id ni6mr15670021pbc.22.1348234050526; Fri, 21 Sep 2012 06:27:30 -0700 (PDT) Received: from [192.168.0.102] (ppp-110-169-206-48.revip5.asianet.co.th. [110.169.206.48]) by mx.google.com with ESMTPS id pj8sm5133487pbb.60.2012.09.21.06.27.28 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:27:29 -0700 (PDT) Message-ID: <505C6B3E.7010303@gmail.com> Date: Fri, 21 Sep 2012 20:27:26 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: aleksas vytautas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Timeline for the next Diameter Base Protocol RFC? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:27:32 -0000 On 09/21/2012 06:13 PM, aleksas vytautas wrote: > Hi all, > > As per the announcement in: > > http://www.ietf.org/mail-archive/web/dime/current/msg05200.html > > What is the expected timeline for this draft to become RFC? A little while. > Should there be anything holding one back treating it as RFC? That would be me ;-). I found a few more errors & am working on fixing them now. > > > Thank you, > > Aleksas > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From bclaise@cisco.com Sun Sep 23 23:55:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4475D21E803C for ; Sun, 23 Sep 2012 23:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.604 X-Spam-Level: X-Spam-Status: No, score=-4.604 tagged_above=-999 required=5 tests=[AWL=-2.006, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hl9BgNnBLdn for ; Sun, 23 Sep 2012 23:54:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE4321E8045 for ; Sun, 23 Sep 2012 23:54:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O6suHN021568; Mon, 24 Sep 2012 08:54:56 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O6stH3001307; Mon, 24 Sep 2012 08:54:55 +0200 (CEST) Message-ID: <506003BF.5050501@cisco.com> Date: Mon, 24 Sep 2012 08:54:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Glen Zorn References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------030309050602090207000908" Cc: dime mailing list Subject: [Dime] Fwd: SecDir review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 06:55:00 -0000 This is a multi-part message in MIME format. --------------030309050602090207000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Glen, The IETF LC is now finished. Can you please answer/address Kathleen's points Regards, Benoit. -------- Original Message -------- Subject: SecDir review of draft-ietf-dime-rfc4005bis-11 Date: Fri, 21 Sep 2012 18:25:15 -0400 From: Moriarty, Kathleen To: secdir@ietf.org , iesg@ietf.org , draft-ietf-dime-rfc4005bis.all@tools.ietf.org , glenzorn@gmail.com I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document describes the extension of Diameter for the NAS application. As such, should the abstract be updated to ensure the reader is aware of the scope limitation in the first sentence? In reading through the draft, I agree with the summary in the Security considerations section. This document is limited in scope, it extends the definition and doesn't go into the details of the protocol and the associated security considerations. The base protocol is defined in RFC3588bis along with the security requirements. I think a reference to the authentication security requirements/considerations defined in ietf-dime-rfc3588bis would be very helpful so that the reader knows the extent of possible security issues and solutions since they go beyond what is described in this document. Having the reference either in Sections 4.3.1 and 4.5.6 or the Security Considerations section would ensure the reader is aware this is addressed elsewhere. Some issues are addressed in these sections, but they do not go as far as the base protocol and there could be issues as this document just relies on session encryption to protect plaintext passwords, etc. The base protocol describes other mechanisms and risks. Editorial nit: Section 1.1, first sentence of last paragraph Change from: "There are many other many miscellaneous" To: "There are many other miscellaneous" --------------030309050602090207000908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Glen,

The IETF LC is now finished.
Can you please answer/address Kathleen's points

Regards, Benoit.


-------- Original Message --------
Subject: SecDir review of draft-ietf-dime-rfc4005bis-11
Date: Fri, 21 Sep 2012 18:25:15 -0400
From: Moriarty, Kathleen <kathleen.moriarty@emc.com>
To: secdir@ietf.org <secdir@ietf.org>, iesg@ietf.org <iesg@ietf.org>, draft-ietf-dime-rfc4005bis.all@tools.ietf.org <draft-ietf-dime-rfc4005bis.all@tools.ietf.org>, glenzorn@gmail.com <glenzorn@gmail.com>


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: 
This document describes the extension of Diameter for the NAS application. 

As such, should the abstract be updated to ensure the reader is aware of the scope limitation in the first sentence?

In reading through the draft, I agree with the summary in the Security considerations section.  This document is limited in scope, it extends the definition and doesn't go into the details of the protocol and the associated security considerations. The base protocol is defined in RFC3588bis along with the security requirements.  

I think a reference to the authentication security requirements/considerations defined in ietf-dime-rfc3588bis would be very helpful so that the reader knows the extent of possible security issues and solutions since they go beyond what is described in this document.  Having the reference either in Sections 4.3.1 and 4.5.6 or the Security Considerations section would ensure the reader is aware this is addressed elsewhere.  Some issues are addressed in these sections, but they do not go as far as the base protocol and there could be issues as this document just relies on session encryption to protect plaintext passwords, etc.  The base protocol describes other mechanisms and risks.

Editorial nit:
Section 1.1, first sentence of last paragraph
Change from:
"There are many other many miscellaneous"
To: 
"There are many other miscellaneous"





--------------030309050602090207000908-- From bclaise@cisco.com Sun Sep 23 23:56:13 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5047F21E803C for ; Sun, 23 Sep 2012 23:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.576 X-Spam-Level: X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[AWL=-1.978, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAcZMPWEFkwn for ; Sun, 23 Sep 2012 23:56:12 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8341421E8043 for ; Sun, 23 Sep 2012 23:56:11 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O6uACA021826; Mon, 24 Sep 2012 08:56:10 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O6u9oY002245; Mon, 24 Sep 2012 08:56:09 +0200 (CEST) Message-ID: <50600409.6080900@cisco.com> Date: Mon, 24 Sep 2012 08:56:09 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Glen Zorn References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> X-Forwarded-Message-Id: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> Content-Type: multipart/alternative; boundary="------------080603090402020808090709" Cc: dime mailing list Subject: [Dime] Fwd: Gen-ART review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 06:56:13 -0000 This is a multi-part message in MIME format. --------------080603090402020808090709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Glen, The IETF LC is now finished. Can you please answer/address David's points Regards, Benoit. -------- Original Message -------- Subject: Gen-ART review of draft-ietf-dime-rfc4005bis-11 Date: Mon, 17 Sep 2012 19:53:10 -0400 From: Black, David To: glenzorn@gmail.com , lionel.morand@orange.com , gen-art@ietf.org CC: dime-chairs@tools.ietf.org , draft-ietf-dime-rfc4005bis@tools.ietf.org , Black, David , ietf@ietf.org , dime@ietf.org , Benoit Claise I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-rfc4005bis-11 Reviewer: David L. Black Review Date: September 17, 2012 IETF LC End Date: September 18, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft is part of a set of drafts that updates the DIAMETER protocol; this draft specifies the application of DIAMETER to AAA for network access. The draft is heavily based on RFC 4005, which it obsoletes, and requires significant DIAMETER familiarity (including familiarity with its companion drafts, starting with the rfc3588bis draft) for complete understanding. The draft is in good shape and reads well. I found one major open issue, a few minor issues, and several nits. Major issues: This draft makes significant use of UTF-8 in its formats (some subsections of sections 4.2, 4.4 and 4.5) for strings that are intended to be compared for equality or processed by protocol participants, but does not contain considerations for Unicode processing that are sufficient to support this usage. Examples of UTF-8 usage in this draft include: - 4.2.5 and 4.2.6: The NAS server may perform authorization based on the Called-Station-Id and Calling-Station-Id AVPs under some circumstances. - 4.4.3: The Callback-Id AVP is intended to be interpreted by the NAS. All use of UTF-8 in this draft relies upon the specification of the UTF8String format in the rfc3588bis draft. That specification is insufficient to support the usage in the above examples, and there are no Unicode considerations in this draft. Even binary comparison of Unicode strings for equality generally requires specification of string preparation (e.g., normalization) in order for string comparison to work as expected. The variety of Unicode strings in this draft makes it important to lay out the Unicode requirements and considerations for each AVP. I see at least 5 classes of possible Unicode requirements/considerations: 1) String preparation so that tests for equality work as expected. This may suffice for the Called-Station-ID AVP (4.2.5) and Calling-Station-ID AVP (4.2.6) if the internal structure of those strings is not used in authorization. 2) Detailed string format for a string that is processed by a protocol participant, e.g., the Callback-ID AVP (4.4.3). 3) Restriction of the string to ASCII-only, e.g., as already stated for the Framed-Route AVP (4.4.10.5.3). 4) Specification that the string is for display to human users only, e.g., as already stated for the Reply-Message AVP (4.2.9). 5) Statement that the string contains an FQDN, as stated for one case of the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is incomplete, as it needs to be accompanied by a normative reference to a document that specifies the format of internationalized domain names, and probably needs to also state which types of labels (e.g., A-label, U-label) are allowed. Every use of UTF8String in this draft needs to be checked, and most of them are likely to need some attention. The ongoing work in the precis WG may help with some of this, and I would suggest talking to the APP ADs, especially Pete Resnick (hi Pete) before embarking on significant work in this area in order to avoid wasted or duplicated efforts. Minor Issues: [1] End of Section 2 on p.8: As a result, service cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability. Please explain what to do about this - a simple rewrite with a "SHOULD NOT" would suffice, e.g.: As a result, service SHOULD NOT be started as a result of a response to an authorization-only request because that may introduce a significant security vulnerability. This should also be noted in the Security Considerations section. [2] In the message formats in Section 3, QoS-Filter-Rule is inconsistently capitalized. Also the use of QoSFilterRule as the format for the QoS-Filter-Rule AVP in Section 4.1.1 is potentially confusing. Please add a sentence in 4.1.1 to say that QoSFilterRule is the format for the QoS-Filter-Rule AVP. [3] Section 4.2.1. In this and the other AVP Flag Rules tables, please explain what the values in the MUST and MUST NOT columns mean. [4] Based on this text in 4.4.9: The use of this AVP is NOT RECOMMENDED; the AVPs defined by Korhonen, et al. [RFC5777] SHOULD be used instead. I would have expected RFC5777 to be a Normative Reference, not an Informative Reference. Nits/editorial comments: After the command table in Section 3 and other similar tables, please add a sentence to say that the -Request and -Answer commands in each similarly-named command pair are distinguished by the value of the 'R' bit in the Command Flags field of the command. This is already stated in the command definitions, but the sentence should be added after the table for clarity because each command pair shares a Command Code. idnits 2.12.13 found a few potential nits: == There are 7 instances of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. That can probably be ignored, as these instances are likely generated by text such as cross-references to Section 4.4.10.1 == Missing Reference: 'BASE' is mentioned on line 219, but not defined That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis] intended? -- Possible downref: Non-RFC (?) normative reference: ref. 'ANITypes' That reference would be: [ANITypes] NANPA Number Resource Info, "ANI Assignments", . Is that reference sufficiently stable (e.g., IANA-class or better management)? My guess is that it is sufficiently stable, but I'm not the expert. -- Obsolete informational reference (is this intentional?): RFC 1334 (Obsoleted by RFC 1994) That reference may be intentional, as it's cited exactly once: 263 PAP (Password Authentication Protocol) 264 A deprecated PPP authentication process, but often used for 265 backward compatibility [RFC1334]. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- --------------080603090402020808090709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Glen,

The IETF LC is now finished.
Can you please answer/address David's points

Regards, Benoit.


-------- Original Message --------
Subject: Gen-ART review of draft-ietf-dime-rfc4005bis-11
Date: Mon, 17 Sep 2012 19:53:10 -0400
From: Black, David <david.black@emc.com>
To: glenzorn@gmail.com <glenzorn@gmail.com>, lionel.morand@orange.com <lionel.morand@orange.com>, gen-art@ietf.org <gen-art@ietf.org>
CC: dime-chairs@tools.ietf.org <dime-chairs@tools.ietf.org>, draft-ietf-dime-rfc4005bis@tools.ietf.org <draft-ietf-dime-rfc4005bis@tools.ietf.org>, Black, David <david.black@emc.com>, ietf@ietf.org <ietf@ietf.org>, dime@ietf.org <dime@ietf.org>, Benoit Claise <bclaise@cisco.com>


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dime-rfc4005bis-11
Reviewer: David L. Black
Review Date: September 17, 2012
IETF LC End Date: September 18, 2012
IESG Telechat date: (if known)

Summary:

This draft is on the right track but has open issues, described in the review.

This draft is part of a set of drafts that updates the DIAMETER protocol;
this draft specifies the application of DIAMETER to AAA for network access.
The draft is heavily based on RFC 4005, which it obsoletes, and requires
significant DIAMETER familiarity (including familiarity with its companion
drafts, starting with the rfc3588bis draft) for complete understanding.

The draft is in good shape and reads well.  I found one major open issue,
a few minor issues, and several nits.

Major issues:

This draft makes significant use of UTF-8 in its formats (some subsections
of sections 4.2, 4.4 and 4.5) for strings that are intended to be compared
for equality or processed by protocol participants, but does not contain
considerations for Unicode processing that are sufficient to support this
usage.  Examples of UTF-8 usage in this draft include:

- 4.2.5 and 4.2.6: The NAS server may perform authorization based on the
	Called-Station-Id and Calling-Station-Id AVPs under some
	circumstances.
- 4.4.3: The Callback-Id AVP is intended to be interpreted by the NAS.

All use of UTF-8 in this draft relies upon the specification of the
UTF8String format in the rfc3588bis draft.  That specification is
insufficient to support the usage in the above examples, and there are
no Unicode considerations in this draft. Even binary comparison of
Unicode strings for equality generally requires specification of
string preparation (e.g., normalization) in order for string comparison
to work as expected.

The variety of Unicode strings in this draft makes it important to lay
out the Unicode requirements and considerations for each AVP.  I see
at least 5 classes of possible Unicode requirements/considerations:

1) String preparation so that tests for equality work as expected.
	This may suffice for the Called-Station-ID AVP (4.2.5) and
	Calling-Station-ID AVP (4.2.6) if the internal structure of
	those strings is not used in authorization.
2) Detailed string format for a string that is processed by a protocol	
	participant, e.g., the Callback-ID AVP (4.4.3).
3) Restriction of the string to ASCII-only, e.g., as already stated
	for the Framed-Route AVP (4.4.10.5.3).
4) Specification that the string is for display to human users only,
	e.g., as already stated for the Reply-Message AVP (4.2.9).
5) Statement that the string contains an FQDN, as stated for one
	case of the Tunnel-Client-Endpoint AVP in 4.5.4.  That specific
	statement is incomplete, as it needs to be accompanied by a
	normative reference to a document that specifies the format
	of internationalized domain names, and probably needs to also
	state which types of labels (e.g., A-label, U-label) are allowed.

Every use of UTF8String in this draft needs to be checked, and most of
them are likely to need some attention. The ongoing work in the precis
WG may help with some of this, and I would suggest talking to the APP
ADs, especially Pete Resnick (hi Pete) before embarking on significant
work in this area in order to avoid wasted or duplicated efforts.

Minor Issues:

[1] End of Section 2 on p.8:

   As a result,
   service cannot be started as a result of a response to an
   authorization-only request without introducing a significant security
   vulnerability.

Please explain what to do about this - a simple rewrite with a
"SHOULD NOT" would suffice, e.g.:

   As a result,
   service SHOULD NOT be started as a result of a response to an
   authorization-only request because that may introduce a significant
   security vulnerability.

This should also be noted in the Security Considerations section.

[2] In the message formats in Section 3, QoS-Filter-Rule is inconsistently
capitalized.  Also the use of QoSFilterRule as the format for the
QoS-Filter-Rule AVP in Section 4.1.1 is potentially confusing.  Please
add a sentence in 4.1.1 to say that QoSFilterRule is the format for the
QoS-Filter-Rule AVP.

[3] Section 4.2.1.  In this and the other AVP Flag Rules tables, please
explain what the values in the MUST and MUST NOT columns mean.

[4] Based on this text in 4.4.9:

   The use of this AVP is NOT RECOMMENDED; the AVPs defined by Korhonen,
   et al. [RFC5777] SHOULD be used instead.

I would have expected RFC5777 to be a Normative Reference, not an
Informative Reference.

Nits/editorial comments:

After the command table in Section 3 and other similar tables, please add a
sentence to say that the -Request and -Answer commands in each similarly-named
command pair are distinguished by the value of the 'R' bit in the Command
Flags field of the command.  This is already stated in the command definitions,
but the sentence should be added after the table for clarity because each command
pair shares a Command Code.

idnits 2.12.13 found a few potential nits:

  == There are 7 instances of lines with non-RFC5735-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.

That can probably be ignored, as these instances are likely generated by
text such as cross-references to Section 4.4.10.1

  == Missing Reference: 'BASE' is mentioned on line 219, but not defined

That's definitely a problem.  Was [I-D.ietf-dime-rfc3588bis] intended?

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ANITypes'

That reference would be:

	[ANITypes]            NANPA Number Resource Info, "ANI
                            Assignments", <http://www.nanpa.com/
                            number_resource_info/
                            ani_ii_assignments.html>.

Is that reference sufficiently stable (e.g., IANA-class or better management)?
My guess is that it is sufficiently stable, but I'm not the expert.

  -- Obsolete informational reference (is this intentional?): RFC 1334
     (Obsoleted by RFC 1994)

That reference may be intentional, as it's cited exactly once:

263	   PAP (Password Authentication Protocol)
264	      A deprecated PPP authentication process, but often used for
265	      backward compatibility [RFC1334].


Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------







--------------080603090402020808090709-- From dieter.jacobsohn@telekom.de Mon Sep 24 00:45:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAB821F849D for ; Mon, 24 Sep 2012 00:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A52Qwu6pekjP for ; Mon, 24 Sep 2012 00:45:14 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5CC21F84A1 for ; Mon, 24 Sep 2012 00:45:11 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 24 Sep 2012 09:45:05 +0200 Received: from HE113456.emea1.cds.t-internal.com ([169.254.3.121]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 24 Sep 2012 09:45:05 +0200 From: To: Date: Mon, 24 Sep 2012 09:45:04 +0200 Thread-Topic: definition of edge agent in draft-ietf-dime-overload-reqs-00 Thread-Index: Ac2aKIJnrwTJwnc+TZq70qgaT+/yqg== Message-ID: <1836CE1BA4F81F46921CA0334F7E427458311165E1@HE113456.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_1836CE1BA4F81F46921CA0334F7E427458311165E1HE113456emea1_" MIME-Version: 1.0 Subject: [Dime] definition of edge agent in draft-ietf-dime-overload-reqs-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 07:45:15 -0000 --_000_1836CE1BA4F81F46921CA0334F7E427458311165E1HE113456emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All by reading the draft-ietf-dime-overload-reqs-00 I found some problems with = the definition of the Edge Agent. At first I could not find any definition what an Edge Agent is. Furthermore if I use a definition having in my mind that an Edge Agent is t= he entry point into an operators network I have some problems with Figure 7= . If the "Interconnect" means a Diameter aware network than could be an Edg= e Agent there too but more important from my point of view would be Edge Ag= ents within Network Operator 1 and Network Operator 2. Best Regards Dieter Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de www.telekom.com Erleben, was verbindet. Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Sch= ick Handelsregister: Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft: Bonn Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. --_000_1836CE1BA4F81F46921CA0334F7E427458311165E1HE113456emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All
by reading the draft-ietf-dime-overload-reqs-00 I found some problems = with the definition of the Edge Agent.
 
At first I could not find any definition what an Edge Agent is.
Furthermore if I use a definition having in my mind that an Edge Agent= is the entry point into an operators network I have some problems with Fig= ure 7. If the "Interconnect" means a Diameter aware network than = could be an Edge Agent there too but more important from my point of view would be Edge Agents within Network Operato= r 1 and Network Operator 2.
 
Best Regards
Dieter
 
 
Deutsche Telekom AG
Group Technology
Dieter Jacobsohn
Landgrabenweg 151, 53227 Bonn
+49 228 936-18445 (Tel.)=
+49 391 5801 46624 (Fax)=
+49 171 2088 710 (Mobil)=
 
Erleben, was verbindet. Deutsche Te= lekom AG
Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender)
Vorstand: Ren=E9 Obermann (Vorsitzender),
Reinhard Clemens, Niek Jan van Damme,
Timotheus H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Sch= ick
Handelsregister: Amtsgericht Bonn HRB 6794
Sitz der Gesellschaft: Bonn
Gro=DFe Ver=E4nderungen fangen klein an – Ressourcen schonen und nich= t jede E-Mail drucken.
 
 
--_000_1836CE1BA4F81F46921CA0334F7E427458311165E1HE113456emea1_-- From glenzorn@gmail.com Mon Sep 24 01:10:22 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480A521F8540; Mon, 24 Sep 2012 01:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO4PgHNKTlOm; Mon, 24 Sep 2012 01:10:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5413A21F8543; Mon, 24 Sep 2012 01:10:20 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so1198527pbb.31 for ; Mon, 24 Sep 2012 01:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jNKhBF1L8UGWd20NLhk1koARGrm9fmR4Y0K4edBFNlw=; b=IkLYi7DGTYNc41DDF/QqTxI7N+MkQCw4zowhfIEhM++L4UM4SJN/iehUGz+Db/X1wQ u7uF72TdW/Ktv384i8I3Ry12JVSBt+TPKpEPk+l32fspkp6I4dO5J1bGmqvK0Tx0wuGJ YhLcEdQHfp17FtUzGFN2FE7xSVgrhidW4SQdz6YaGMEjiVCGPKZwimNZV2qB6+ImlgK6 IrbMA8ov/hYF+dbLFLyMqBcIB5cRKRDCkg155ULrfVdkiS0rtUKflp+mFWRBoyzONiqM MaRM1Z5QGje5unsmROzE3aXoL3AxNZTPXiB6cx215AHermjHPc0hgbrF6uVknfxh5Zza Milw== Received: by 10.66.74.100 with SMTP id s4mr30638227pav.27.1348474219820; Mon, 24 Sep 2012 01:10:19 -0700 (PDT) Received: from [192.168.0.102] (ppp-58-11-133-109.revip2.asianet.co.th. [58.11.133.109]) by mx.google.com with ESMTPS id ho7sm9295503pbc.3.2012.09.24.01.10.16 (version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 01:10:19 -0700 (PDT) Message-ID: <50601567.3010008@gmail.com> Date: Mon, 24 Sep 2012 15:10:15 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime mailing list , "iesg@ietf.org" , "draft-ietf-dime-rfc4005bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [Dime] SecDir review of draft-ietf-dime-rfc4005bis-11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 08:10:22 -0000 On 09/22/2012 05:25 AM, Moriarty, Kathleen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: This document describes the extension of Diameter for the > NAS application. > > As such, should the abstract be updated to ensure the reader is aware > of the scope limitation in the first sentence? I don't understand: the first sentence of the introduction is virtually identical to the first sentence of Section 1. What do you want me to do? > > In reading through the draft, I agree with the summary in the > Security considerations section. This document is limited in scope, > it extends the definition and doesn't go into the details of the > protocol and the associated security considerations. The base > protocol is defined in RFC3588bis along with the security > requirements. > > I think a reference to the authentication security > requirements/considerations defined in ietf-dime-rfc3588bis would be > very helpful so that the reader knows the extent of possible security > issues and solutions since they go beyond what is described in this > document. Having the reference either in Sections 4.3.1 and 4.5.6 or > the Security Considerations section would ensure the reader is aware > this is addressed elsewhere. Since the reader must have read & understood RFC 3588bis to expect to be able to read & understand this doc (draft-ietf-dime-rfc3588bis is cited as a normative reference), presumably the reader is already aware of this. Some issues are addressed in these > sections, but they do not go as far as the base protocol and there > could be issues as this document just relies on session encryption to > protect plaintext passwords, etc. ?? > The base protocol describes other > mechanisms and risks. > > Editorial nit: Section 1.1, first sentence of last paragraph Change > from: "There are many other many miscellaneous" To: "There are many > other miscellaneous" Fixed, thanks! From emcmurry@estacado.net Mon Sep 24 06:12:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB73C21F869D for ; Mon, 24 Sep 2012 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkoRks6uea8I for ; Mon, 24 Sep 2012 06:12:43 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id CA7E321F866E for ; Mon, 24 Sep 2012 06:12:42 -0700 (PDT) Received: from ericlaptop.casamcmurry.com (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q8ODCbVr069631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Sep 2012 08:12:41 -0500 (CDT) (envelope-from emcmurry@estacado.net) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F104662-8BEF-4E33-AD53-473894A5B891" Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Eric McMurry In-Reply-To: <1836CE1BA4F81F46921CA0334F7E427458311165E1@HE113456.emea1.cds.t-internal.com> Date: Mon, 24 Sep 2012 08:12:31 -0500 Message-Id: <699773C8-C09C-43A1-A874-8B04762B11E1@estacado.net> References: <1836CE1BA4F81F46921CA0334F7E427458311165E1@HE113456.emea1.cds.t-internal.com> To: dieter.jacobsohn@telekom.de X-Mailer: Apple Mail (2.1498) X-Mailman-Approved-At: Mon, 24 Sep 2012 06:41:18 -0700 Cc: "dime@ietf.org" Subject: Re: [Dime] definition of edge agent in draft-ietf-dime-overload-reqs-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 13:12:43 -0000 --Apple-Mail=_4F104662-8BEF-4E33-AD53-473894A5B891 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 thanks for the comment Dieter. I agree, the severs shown in the operator networks in figure 7 would be = edge agents. I think from the perspective of an overload control = mechanism, there wouldn't be anything special about an edge agent = though. Perhaps it would be best to remove the mention of edge agents = from this diagram to avoid confusion. What do you think? Eric On Sep 24, 2012, at 2:45 , dieter.jacobsohn@telekom.de wrote: > Hello All > by reading the draft-ietf-dime-overload-reqs-00 I found some problems = with the definition of the Edge Agent. > =20 > At first I could not find any definition what an Edge Agent is. > Furthermore if I use a definition having in my mind that an Edge Agent = is the entry point into an operators network I have some problems with = Figure 7. If the "Interconnect" means a Diameter aware network than = could be an Edge Agent there too but more important from my point of = view would be Edge Agents within Network Operator 1 and Network Operator = 2. > =20 > Best Regards > Dieter > =20 > =20 > Deutsche Telekom AG > Group Technology > Dieter Jacobsohn > Landgrabenweg 151, 53227 Bonn > +49 228 936-18445 (Tel.) > +49 391 5801 46624 (Fax) > +49 171 2088 710 (Mobil) > E-Mail: dieter.jacobsohn@telekom.de > www.telekom.com =20 > =20 > Erleben, was verbindet. Deutsche Telekom AG > Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) > Vorstand: Ren=E9 Obermann (Vorsitzender), > Reinhard Clemens, Niek Jan van Damme, > Timotheus H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. = Marion Schick > Handelsregister: Amtsgericht Bonn HRB 6794 > Sitz der Gesellschaft: Bonn > Gro=DFe Ver=E4nderungen fangen klein an =96 Ressourcen schonen und = nicht jede E-Mail drucken. > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_4F104662-8BEF-4E33-AD53-473894A5B891 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 dieter.jacobsohn@telekom.de wrote:

Hello All
by reading the = draft-ietf-dime-overload-reqs-00 I found some problems with the = definition of the Edge Agent.
 
At first I = could not find any definition what an Edge Agent = is.
Furthermore if I use a definition having in my mind that = an Edge Agent is the entry point into an operators network I have some = problems with Figure 7. If the "Interconnect" means a Diameter aware = network than could be an Edge Agent there too but more important from my = point of view would be Edge Agents within Network Operator 1 and Network = Operator 2.
 
Best = Regards
Dieter
 
 
Deutsche Telekom AG
Group Technology
Dieter Jacobsohn
Landgrabenweg 151, 53227 = Bonn
+49 228 = 936-18445 (Tel.)
+49 = 391 5801 46624 (Fax)
+49 171 2088 710 (Mobil)
 
Erleben, was verbindet. Deutsche Telekom = AG
Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender)
Vorstand: = Ren=E9 Obermann (Vorsitzender),
Reinhard Clemens, Niek Jan van = Damme,
Timotheus H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. = Dr. Marion Schick
Handelsregister: Amtsgericht Bonn HRB 6794
Sitz = der Gesellschaft: Bonn
Gro=DFe Ver=E4nderungen fangen klein an =96 = Ressourcen schonen und nicht jede E-Mail drucken.
 
 
____________________________________= ___________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime

= --Apple-Mail=_4F104662-8BEF-4E33-AD53-473894A5B891-- From suckfish@ihug.co.nz Mon Sep 24 12:31:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CEA21F88B9 for ; Mon, 24 Sep 2012 12:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05wd3f8MGyIy for ; Mon, 24 Sep 2012 12:31:53 -0700 (PDT) Received: from mailfilter2.ihug.co.nz (mailfilter2.ihug.co.nz [203.109.136.2]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8F21F88B8 for ; Mon, 24 Sep 2012 12:31:52 -0700 (PDT) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=nmCe0FMyaKF/ge3QFJPfD13wzr301mOl5zN2rlwg0Sc= c=1 sm=2 a=MJAIyVhDqfoA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=ZXppjb4CpoOqQLmYSaEA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=c95RI8W7jIfAQZnE:21 a=CActkR_2ZhLkD3bi:21 X-IronPort-AV: E=Sophos;i="4.80,477,1344168000"; d="scan'208";a="11307652" Received: from 203-173-201-7.nzwide.ihug.co.nz (HELO i.geek.nz) ([203.173.201.7]) by cust.filter2.content.vf.net.nz with SMTP; 25 Sep 2012 07:31:51 +1200 Date: Tue, 25 Sep 2012 07:31:50 +1200 From: Ralph Loader To: Glen Zorn Message-Id: <20120925073150.46e47860ae2f9db88035def0@ihug.co.nz> In-Reply-To: <505C0F10.3020106@gmail.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> <505C0F10.3020106@gmail.com> X-Mailer: Sylpheed 3.2.0beta9 (GTK+ 2.24.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 19:31:54 -0000 > The draft says: > > 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. > > Suppose that I send, instead of one address, three (assuming the use of > TCP). Which one do you use? What if the list doesn't contain the > address from which the CEr/CEA command was sent? There are other problems with using the AVP to obtain IP addresses: 1. The set of IP addresses assigned to a machine can change. Unlike proper protocols for distributing IP addresses, the capabilities exchange has no mechanism for handling that. 2. There is no guarentee that a particular IP address of a machine is accessable from a peer (address scoping, firewalling, NAT...). I don't see any reason for Diameter to reinvent the wheel in distributing IP addresses. Just leave the field as advisory for logging / debugging purposes (ditto all the other underspecified fields in the capabilities exchange, for that matter). Cheers, Ralph. > If my solution to > transport failure is to send you three addresses assuming that you'll > try them sequentially and you don't understand that, my scheme fails and > since you only have one registered address for me, this could cause a > much longer outage than if my network admins just did their job and > registered all the available addresses in the DNS. > > >> > > > > I don't have a specific error in mind. My intent was to point out > > that while there may be interesting things you can do with > > Host-IP-Address (like the example you gave), anything that requires a > > mutual understanding between the client and server aren't going to > > work unless the understanding exists. In you example, using > > Host-IP-Address to tell the peer about other available addresses to > > be used for load balancing and/or failover won't work across > > implementations unless it's documented somewhere. > > > > The original poster pointed out that they were seeing real IOT issues > > because different implementors interpreted the spec differently in > > regards to Host-IP-Address. Assuming that these differences were due > > to reasonable interpretations of the spec, rather than simple > > misunderstandings, that's a pretty big indicator that there's a > > problem. > > I would be inclined to write a short draft clarifying that, in the case > of TCP, exactly one instance of the Host-IP-Address MUST be included in > the CER/CEA messages. > > ... > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From suckfish@ihug.co.nz Mon Sep 24 12:42:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7225421F88BC for ; Mon, 24 Sep 2012 12:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIr0lIg6d5bK for ; Mon, 24 Sep 2012 12:42:43 -0700 (PDT) Received: from mailfilter38.ihug.co.nz (mailfilter38.ihug.co.nz [203.109.136.38]) by ietfa.amsl.com (Postfix) with ESMTP id B18A721F88BB for ; Mon, 24 Sep 2012 12:42:42 -0700 (PDT) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=45dRqhjvKqYp3f10dkdxNAe77GPZjwJfN/Ub0yShK6Q= c=1 sm=2 a=MJAIyVhDqfoA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=nCJgjMEQqSRoQ03NlusA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 X-IronPort-AV: E=Sophos;i="4.80,477,1344168000"; d="scan'208";a="11491036" Received: from 203-173-201-7.nzwide.ihug.co.nz (HELO i.geek.nz) ([203.173.201.7]) by cust.filter8.content.vf.net.nz with SMTP; 25 Sep 2012 07:42:41 +1200 Date: Tue, 25 Sep 2012 07:42:40 +1200 From: Ralph Loader To: jouni korhonen Message-Id: <20120925074240.4f1c4c01a7d9bef98e565086@ihug.co.nz> In-Reply-To: <6D280149-BF41-4741-9188-3CC981433D61@gmail.com> References: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> <6D280149-BF41-4741-9188-3CC981433D61@gmail.com> X-Mailer: Sylpheed 3.2.0beta9 (GTK+ 2.24.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 19:42:43 -0000 > > Yes for the first part and no for the second part.. you are not supposed to send > addresses that you cannot be connected at. But in general, a Diameter implementation can't reasonably be expected to know which of its IP addresses will be usable by a particular peer. Best just to treat the field as informational. Ralph. > > > > - Jouni > > > > > > Ankur Garg > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dieter.jacobsohn@telekom.de Mon Sep 24 22:59:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F69721F8932 for ; Mon, 24 Sep 2012 22:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPoOLSgvx7fx for ; Mon, 24 Sep 2012 22:59:52 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C021F8630 for ; Mon, 24 Sep 2012 22:59:51 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 25 Sep 2012 07:59:49 +0200 Received: from HE113456.emea1.cds.t-internal.com ([169.254.3.121]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 25 Sep 2012 07:59:49 +0200 From: To: Date: Tue, 25 Sep 2012 07:59:48 +0200 Thread-Topic: [Dime] definition of edge agent in draft-ietf-dime-overload-reqs-00 Thread-Index: Ac2aVk+/K52me1nNS0C5bvGOnSHwOwAjDIrg Message-ID: <1836CE1BA4F81F46921CA0334F7E4274583111687C@HE113456.emea1.cds.t-internal.com> References: <1836CE1BA4F81F46921CA0334F7E427458311165E1@HE113456.emea1.cds.t-internal.com> <699773C8-C09C-43A1-A874-8B04762B11E1@estacado.net> In-Reply-To: <699773C8-C09C-43A1-A874-8B04762B11E1@estacado.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_1836CE1BA4F81F46921CA0334F7E4274583111687CHE113456emea1_" MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] definition of edge agent in draft-ietf-dime-overload-reqs-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 05:59:53 -0000 --_000_1836CE1BA4F81F46921CA0334F7E4274583111687CHE113456emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Eric that is fine for me, my intention was only to avoid confusion where the Ed= ge Agent is really used as an Edge toward the operators network. BR Dieter Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de www.telekom.com Erleben, was verbindet. Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE 123475223 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. ________________________________ Von: Eric McMurry [mailto:emcmurry@estacado.net] Gesendet: Montag, 24. September 2012 15:13 An: Jacobsohn, Dieter Cc: dime@ietf.org Betreff: Re: [Dime] definition of edge agent in draft-ietf-dime-overload-re= qs-00 thanks for the comment Dieter. I agree, the severs shown in the operator networks in figure 7 would be edg= e agents. I think from the perspective of an overload control mechanism, t= here wouldn't be anything special about an edge agent though. Perhaps it w= ould be best to remove the mention of edge agents from this diagram to avoi= d confusion. What do you think? Eric On Sep 24, 2012, at 2:45 , dieter.jacobsohn@telekom.de wrote: Hello All by reading the draft-ietf-dime-overload-reqs-00 I found some problems with = the definition of the Edge Agent. At first I could not find any definition what an Edge Agent is. Furthermore if I use a definition having in my mind that an Edge Agent is t= he entry point into an operators network I have some problems with Figure 7= . If the "Interconnect" means a Diameter aware network than could be an Edg= e Agent there too but more important from my point of view would be Edge Ag= ents within Network Operator 1 and Network Operator 2. Best Regards Dieter Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de www.telekom.com Erleben, was verbindet. Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Sch= ick Handelsregister: Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft: Bonn Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_1836CE1BA4F81F46921CA0334F7E4274583111687CHE113456emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Eric
that is fine for me, my intention was only to=20 avoid  confusion where the Edge Agent  is really used as an Edge= =20 toward the operators network.
 
BR=20 Dieter

Deutsche=20 Telekom AG
Group Technology
Dieter Jacobsohn

Landgrabenweg 151,= 53227=20 Bonn
+49 228 936-18445 (Tel.)
= +49 391 5801 46624 (Fax)

+49 171 2088 710=20 (Mobil)
E-Mail: dieter.jacobsohn@telekom.de
www.telekom.com   

Erleben, was= =20 verbindet. <= FONT=20 color=3D#979797 size=3D1 face=3DArial>

Deutsche Tel= ekom=20 AG
Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender)=20
Vorstand: R= en=E9 Obermann=20 (Vorsitzender),
Dr. Manfred Balz, Reinhard Clemens, Niek Jan van=20 Damme,
Timotheus H=F6ttges, Claudia Nemat,  Prof. Dr. Marion=20 Schick

Handelsregister: Amtsgericht Bonn HRB 6794
<= SPAN=20 lang=3Dde>Sitz der Gesellschaft= =20 Bonn

USt-IdNr. DE 123475223

Gro=DFe V= er=E4nderungen=20 fangen klein an =96 Ressourcen schonen und nicht jede E-= Mail=20 drucken.

 


Von: Eric McMurry [mailto:emcmurry@esta= cado.net]=20
Gesendet: Montag, 24. September 2012 15:13
An: Jacobso= hn,=20 Dieter
Cc: dime@ietf.org
Betreff: Re: [Dime] definition= of=20 edge agent in draft-ietf-dime-overload-reqs-00

thanks for the comment Dieter.

I agree, the severs shown in the operator networks in figure 7 would b= e=20 edge agents.  I think from the perspective of an overload control=20 mechanism, there wouldn't be anything special about an edge agent though.=20  Perhaps it would be best to remove the mention of edge agents from th= is=20 diagram to avoid confusion.  What do you think?

Eric


On Sep 24, 2012, at 2:45 , dieter.jacobsohn@telekom.de= =20 wrote:

=
Hello All
by reading the draft-ietf-dime-overload-reqs-00 I found some problem= s=20 with the definition of the Edge Agent.
 
At first I could not find any definition what an Edge Agent is.
Furthermore if I use a definition having in my mind that an Edge Age= nt is=20 the entry point into an operators network I have some problems with Figur= e 7.=20 If the "Interconnect" means a Diameter aware network than could be an Edg= e=20 Agent there too but more important from my point of view would be Edge Ag= ents=20 within Network Operator 1 and Network Operator 2.
 
Best Regards
Dieter
 
 
Deutsche Telekom AG
Group Technology
Dieter Jacobsohn
Landgrabenweg 151, 53227 Bonn<= /DIV>
+49 228 936-18445 (Tel.)
+49 391 5801 46624 (Fax)
+49 171 2088 710 (Mobil)
E-Mail: dieter.jacobsohn@telekom.de
www.telekom.com   
 
Erleben, was verbindet. Deutsche Tele= kom=20 AG
Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender)
Vorstand: R= en=E9=20 Obermann (Vorsitzender),
Reinhard Clemens, Niek Jan van Damme,
Timo= theus=20 H=F6ttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion=20 Schick
Handelsregister: Amtsgericht Bonn HRB 6794
Sitz der Gesellsc= haft:=20 Bonn
Gro=DFe Ver=E4nderungen fangen klein an =96 Ressourcen schonen un= d nicht=20 jede E-Mail drucken.
 
 
____________________= ___________________________
DiME=20 mailing list
DiME@ietf.org
https://www.ietf.org/= mailman/listinfo/dime

--_000_1836CE1BA4F81F46921CA0334F7E4274583111687CHE113456emea1_-- From jouni.nospam@gmail.com Tue Sep 25 00:18:36 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007F021F84F2 for ; Tue, 25 Sep 2012 00:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuHVr8CxI-mG for ; Tue, 25 Sep 2012 00:18:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4236321F84E7 for ; Tue, 25 Sep 2012 00:18:35 -0700 (PDT) Received: by bkty12 with SMTP id y12so3281071bkt.31 for ; Tue, 25 Sep 2012 00:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6ZM9dSDT0xrbuDaMA65GXEGKnmNhpp8ZU1xDsQwppic=; b=fTehARaBWSd/FWnp28GROQ93c8serKQwnnT9b9GriGRKHXGqBpl0eWs0CrV+7lU2Dk sVepeXVFkGmkWQZFn8rcdjaO5Nigbe/XNeB+41gP7hGLa8Aw9DxXWrB0VyjHioTQnaKd HbuZd1kf/L9jvbec4HAo29cjx3Yr7gyrYhWzJ1t0UspbwMb50IOyBOwtLVFmOOYlx+zV l83S0B+l9ltUI+9wH8mLsXC0lfpXUvMQwY8RYkFmTaW6J5D1UMslFOVItXF9D3J7/15u 2n8tvYH+WD+8iPTQhl957e+5Ht1WaJ7uda7MH4C2sq6xSjlLOMY+bbh0Mc8Qa+1/hoNx 5lGA== Received: by 10.204.9.9 with SMTP id j9mr728741bkj.12.1348557514115; Tue, 25 Sep 2012 00:18:34 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id t27sm8273379bkv.10.2012.09.25.00.18.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 00:18:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120925074240.4f1c4c01a7d9bef98e565086@ihug.co.nz> Date: Tue, 25 Sep 2012 10:18:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <43547D50-1191-4572-935F-AC935A417935@gmail.com> References: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> <6D280149-BF41-4741-9188-3CC981433D61@gmail.com> <20120925074240.4f1c4c01a7d9bef98e565086@ihug.co.nz> To: Ralph Loader X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 07:18:36 -0000 On Sep 24, 2012, at 10:42 PM, Ralph Loader wrote: >>=20 >> Yes for the first part and no for the second part.. you are not = supposed to send >> addresses that you cannot be connected at. >=20 > But in general, a Diameter implementation can't reasonably be expected = to know which of its IP addresses will be usable by a particular peer. A Diameter node is supposed to know which addresses it can bind and did bind to. The addresses it might put into host-ip-address do not come out of blue. > Best just to treat the field as informational. Don't fully agree. In case of TCP I could. In case of SCTP I don't. - Jouni >=20 > Ralph. >=20 >=20 >>=20 >>=20 >>=20 >> - Jouni >>=20 >>=20 >>>=20 >>> Ankur Garg >>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Sep 25 00:32:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B202421F88F2 for ; Tue, 25 Sep 2012 00:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAQ3ljMVSG9X for ; Tue, 25 Sep 2012 00:32:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC94C21F88F8 for ; Tue, 25 Sep 2012 00:32:55 -0700 (PDT) Received: by bkty12 with SMTP id y12so3288118bkt.31 for ; Tue, 25 Sep 2012 00:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/J6S1XFb+/OGdYfT+lJh8JnnoV2f5K7hfCQdg+xooQ0=; b=uAmMBRNPmNKkC5V673zrYdkyHADSIWqwOnZJwT7ZIBfTz/3LQyrCwtX58Nsgo7cxdl b6SmkM61/SfP7avjrExsptzE4Rz5Xw8DfjnsTLxJ/v6P/KuiotZA9gbLUfvTBEu2FO3k 9k3lsG9j7mMvbQz6gipSMGnokNPNItQyKCxMiwfszW2QifaNGr6/yTTYUVv37j3qfU+2 xM6tCqGHJGxW18gWyhXw8VMzXQQ0e1V76iJEqGjWS78W/CnGetffYNasAP4jINMWzvUx wgN6HOJVisreRkXdqp5xUtZBrZKMqUT1n3RcIlaexYpG5wSC+8jmi5Z+8Y5Qo/+NdUVS MQCA== Received: by 10.204.152.211 with SMTP id h19mr5582503bkw.45.1348558374966; Tue, 25 Sep 2012 00:32:54 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id n5sm11636308bkv.14.2012.09.25.00.32.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 00:32:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120925073150.46e47860ae2f9db88035def0@ihug.co.nz> Date: Tue, 25 Sep 2012 10:32:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8425338C-2556-49B4-AB72-CA8D275D6C18@gmail.com> References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> <505C0F10.3020106@gmail.com> <20120925073150.46e47860ae2f9db88035def0@ihug.co.nz> To: Ralph Loader X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 07:32:59 -0000 Hi, Just few questions for my education and some comments inline. On Sep 24, 2012, at 10:31 PM, Ralph Loader wrote: >> The draft says: >>=20 >> 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. >>=20 >> Suppose that I send, instead of one address, three (assuming the use = of=20 >> TCP). Which one do you use? What if the list doesn't contain the=20 >> address from which the CEr/CEA command was sent? >=20 > There are other problems with using the AVP to obtain IP addresses: >=20 > 1. The set of IP addresses assigned to a machine can change. Unlike = proper protocols for distributing IP addresses, the capabilities = exchange has no mechanism for handling that. RFC6737. >=20 > 2. There is no guarentee that a particular IP address of a machine is = accessable from a peer (address scoping, firewalling, NAT...). How would the situation be any different if "proper protocols" were = used? >=20 > I don't see any reason for Diameter to reinvent the wheel in = distributing IP addresses. There is a clear use case for SCTP. - Jouni >=20 > Just leave the field as advisory for logging / debugging purposes = (ditto all the other underspecified fields in the capabilities exchange, = for that matter). >=20 > Cheers, > Ralph. >=20 >=20 >> If my solution to=20 >> transport failure is to send you three addresses assuming that you'll=20= >> try them sequentially and you don't understand that, my scheme fails = and=20 >> since you only have one registered address for me, this could cause a=20= >> much longer outage than if my network admins just did their job and=20= >> registered all the available addresses in the DNS. >>=20 >>>>=20 >>>=20 >>> I don't have a specific error in mind. My intent was to point out >>> that while there may be interesting things you can do with >>> Host-IP-Address (like the example you gave), anything that requires = a >>> mutual understanding between the client and server aren't going to >>> work unless the understanding exists. In you example, using >>> Host-IP-Address to tell the peer about other available addresses to >>> be used for load balancing and/or failover won't work across >>> implementations unless it's documented somewhere. >>>=20 >>> The original poster pointed out that they were seeing real IOT = issues >>> because different implementors interpreted the spec differently in >>> regards to Host-IP-Address. Assuming that these differences were due >>> to reasonable interpretations of the spec, rather than simple >>> misunderstandings, that's a pretty big indicator that there's a >>> problem. >>=20 >> I would be inclined to write a short draft clarifying that, in the = case=20 >> of TCP, exactly one instance of the Host-IP-Address MUST be included = in=20 >> the CER/CEA messages. >>=20 >> ... >>=20 >> _______________________________________________ >> 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 suckfish@ihug.co.nz Tue Sep 25 02:19:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01B921F8826 for ; Tue, 25 Sep 2012 02:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leBXR2iVVa7O for ; Tue, 25 Sep 2012 02:19:15 -0700 (PDT) Received: from pub.filter5.content.vf.net.nz (mailfilter35.ihug.co.nz [203.109.136.35]) by ietfa.amsl.com (Postfix) with ESMTP id 04B3521F84DC for ; Tue, 25 Sep 2012 02:19:14 -0700 (PDT) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=Z8no4Y9okuFY479hGFrQhWSBilmW7fpVhngnWmwe0qw= c=1 sm=2 a=MJAIyVhDqfoA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=FYHoseP-mZkhr3sez0wA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=fVhcpMOr0sDhJRog:21 a=Cq7OBac_EUJR42A7:21 X-IronPort-AV: E=Sophos;i="4.80,481,1344168000"; d="scan'208";a="10189169" Received: from 203-173-201-7.nzwide.ihug.co.nz (HELO i.geek.nz) ([203.173.201.7]) by cust.filter5.content.vf.net.nz with SMTP; 25 Sep 2012 21:19:13 +1200 Date: Tue, 25 Sep 2012 21:19:11 +1200 From: Ralph Loader To: jouni korhonen Message-Id: <20120925211911.f92ee04a4b637954cd1bcd33@ihug.co.nz> In-Reply-To: <43547D50-1191-4572-935F-AC935A417935@gmail.com> References: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> <6D280149-BF41-4741-9188-3CC981433D61@gmail.com> <20120925074240.4f1c4c01a7d9bef98e565086@ihug.co.nz> <43547D50-1191-4572-935F-AC935A417935@gmail.com> X-Mailer: Sylpheed 3.2.0beta9 (GTK+ 2.24.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 09:19:15 -0000 > >> Yes for the first part and no for the second part.. you are not supposed to send > >> addresses that you cannot be connected at. > > > > But in general, a Diameter implementation can't reasonably be expected to know which of its IP addresses will be usable by a particular peer. > > A Diameter node is supposed to know which addresses it can bind and > did bind to. The addresses it might put into host-ip-address do > not come out of blue. That is irrelevant. The problem is that just because the Diameter node has bound to an address, does not imply that it's possible for a specific peer to try and connect to. E.g., node A, node B are both behind different firewalls, node A binds to 192.168.1.1, on node B's network, 192.168.1.1 is assigned to a completely different machine. Do you have a specific suggestion for the algorithm a node should use in selecting which of the nodes addresses are put in the Host-IP-Address field? > > > Best just to treat the field as informational. > > Don't fully agree. In case of TCP I could. In case of SCTP I don't. For SCTP Host-IP-Address is utterly redundant. SCTP already supports multi-homing and telling peers of additional addresses (although in practice, I've seen that go hilariously wrong). Ralph. > > - Jouni > > > > > > Ralph. > > > > > >> > >> > >> > >> - Jouni > >> > >> > >>> > >>> Ankur Garg > >>> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > From jouni.nospam@gmail.com Tue Sep 25 03:25:22 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44E121F888A for ; Tue, 25 Sep 2012 03:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOGMfgtUvQiX for ; Tue, 25 Sep 2012 03:25:21 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFE421F887C for ; Tue, 25 Sep 2012 03:25:21 -0700 (PDT) Received: by eekd4 with SMTP id d4so874678eek.31 for ; Tue, 25 Sep 2012 03:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=06oWsanQ/4Cl9yH9PonyLxQuj6nNHtP3iF6ZBt8gNwA=; b=bniUxNJR/lXPrH5Plu49TjFugxZPPPwU1B9l4pfQHPF06+93e2ZtRnMjmbWQ054PhP Rf5/OD6JYR7gAr6vlHdcCTHawJIf0pE2L0SgYCFY1C0ySTtY+RyO2MUSENw18kSN//Pc 2eV+ExKnqoKq6iRkvhyY+LYGFF1tqW80mu/s0ur861gW5dzqWAfnq/TUStYMfOZLIyQU vC0kWhbDeH93CeIfON7FlIv6ThZCi3NUzMb65OhnGolaGNxyN95thlJygDTaFIi8pPQV d+PunFy8Zarj3cdLew0MAfJ1QH3BBVy/32MAKEUKdIXEMEQ6qAzQGO3pDNurqNgD4fuI f7wQ== Received: by 10.14.224.73 with SMTP id w49mr18570757eep.37.1348568720797; Tue, 25 Sep 2012 03:25:20 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id n5sm12186124bkv.14.2012.09.25.03.25.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 03:25:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120925211911.f92ee04a4b637954cd1bcd33@ihug.co.nz> Date: Tue, 25 Sep 2012 13:25:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2ADCD858-A792-467E-AD92-CE99A9087444@gmail.com> References: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> <6D280149-BF41-4741-9188-3CC981433D61@gmail.com> <20120925074240.4f1c4c01a7d9bef98e565086@ihug.co.nz> <43547D50-1191-4572-935F-AC935A417935@gmail.com> <20120925211911.f92ee04a4b637954cd1bcd33@ihug.co.nz> To: Ralph Loader X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 10:25:22 -0000 On Sep 25, 2012, at 12:19 PM, Ralph Loader wrote: >=20 >>>> Yes for the first part and no for the second part.. you are not = supposed to send >>>> addresses that you cannot be connected at. >>>=20 >>> But in general, a Diameter implementation can't reasonably be = expected to know which of its IP addresses will be usable by a = particular peer. >>=20 >> A Diameter node is supposed to know which addresses it can bind and >> did bind to. The addresses it might put into host-ip-address do >> not come out of blue. >=20 > That is irrelevant. The problem is that just because the Diameter = node has bound to an address, does not imply that it's possible for a = specific peer to try and connect to. =20 >=20 > E.g., node A, node B are both behind different firewalls, node A binds = to 192.168.1.1, on node B's network, 192.168.1.1 is assigned to a = completely different machine. Right, private addresses + NAT -> you know you will hit your head to = wall. It is not worth putting any energy to solve NATted environment related problems. > Do you have a specific suggestion for the algorithm a node should use = in selecting which of the nodes addresses are put in the Host-IP-Address = field? Not any specific algorithm than the normals: o At startup the node scans for the interfaces and addresses in those it can bind to. o the selection of interfaces can be controlled by many means like config file, and the selection of the "main" IP address can also come from a config file etc. Now there is an obvious question what happens if some addresses on some interfaces are just not reachable e.g. from outside. I would argue that every permutation of a deployment can be _made_ to break with some effort regardless of the protocols you got. >>> Best just to treat the field as informational. >>=20 >> Don't fully agree. In case of TCP I could. In case of SCTP I don't. >=20 > For SCTP Host-IP-Address is utterly redundant. SCTP already supports = multi-homing and telling peers of additional addresses (although in = practice, I've seen that go hilariously wrong). - Jouni >=20 > Ralph. >=20 >=20 >>=20 >> - Jouni >>=20 >>=20 >>>=20 >>> Ralph. >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>>=20 >>>>> Ankur Garg >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>=20 From glenzorn@gmail.com Tue Sep 25 18:03:11 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A42721F8472; Tue, 25 Sep 2012 18:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ub7qmI-aPwl; Tue, 25 Sep 2012 18:03:10 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 762AE21F8425; Tue, 25 Sep 2012 18:03:10 -0700 (PDT) Received: by danh15 with SMTP id h15so10769dan.31 for ; Tue, 25 Sep 2012 18:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nvhAs3Pg10fWPAU8MbM+lMbjkE+aYkedy9fhadOGw5o=; b=ILHvijeq3KI53TF8G71Sw7YzY/92UURIkmYWE4/oxwmNVHIm1mPbpMgA+QGa4gs/Kr 64YdAhi3ZmNVA8dnQb5XAjfw+4A9msTRYV49su7Wps6Y/dgGS18u71+iu/9qjNzfL/P9 QHMH/boIEGUUBjxufrlX2VONOzOnu3GPsygOTahXz5O4vYpCE8+cgRuUP4Y8kM9Wrhyy 3PkhQTpo6X1eRasu/eRJuCBys0SV5vCKbIRclwMuBwuojk2phazqmttzMGw7VLBTlxT2 hN1iaYpak31E8d9k68KhY7b/i7euWXG4twneJgZbzAJaDCOJNdoEVl3KBp/L9uzTfwFT zZPQ== Received: by 10.68.189.164 with SMTP id gj4mr50287085pbc.48.1348621390179; Tue, 25 Sep 2012 18:03:10 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-227-192.revip2.asianet.co.th. [124.120.227.192]) by mx.google.com with ESMTPS id gf3sm1104098pbc.74.2012.09.25.18.03.06 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 18:03:09 -0700 (PDT) Message-ID: <50625449.7010305@gmail.com> Date: Wed, 26 Sep 2012 08:03:05 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Elwyn Davies References: <5060D8AB.8010807@dial.pipex.com> In-Reply-To: <5060D8AB.8010807@dial.pipex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org" , draft-ietf-dime-erp , General Area Review Team , dime mailing list , draft-ietf-dime-erp.all@tools.ietf.org Subject: Re: [Dime] Gen-art LC review of draft-ietf-dime-erp-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 01:03:11 -0000 On 09/25/2012 05:03 AM, Elwyn Davies wrote: > Gen-art LC review of draft-ietf-dime-erp-12 I am the assigned Gen-ART > reviewer for this draft. For background on Gen-ART, please see the > FAQ at > > . > > Please resolve these comments along with any other Last Call > comments you may receive. > > Document: draft-ietf-dime-erp-12.txt Reviewer: Elwyn Davies Review > Date: 24 September 2012 IETF LC End Date: 24 September 2012 IESG > Telechat date: (if known) - > > Summary: Almost ready for the IESG. There are some minor wording > issues to sort out in s3, some advice on advertising domain names in > s5 and possibly some extra words needed in the security > considerations. In addition there a few minor nits. > > Major issues: None. > > Minor issues: s3: Both paragraphs use the phrase '...document assumes > the existence of at most one...'. Does this really mean 'exactly > one'? Oddly enough, it means just what it says. > If not, what happens if there is exactly zero servers for either > type? Both protocols will fail gracefully. > What would the consequences of there being more than one > logical server? If the message is directed to a logical server not in possession of the rRK or rDSRK (depending upon where the server is located), ERP will fail inappropriately. > Is this tied into the statement in s4: > The ER server is located either in the home domain (same as EAP > server) or in the visited domain (same as authenticator, when it > differs from the home domain). I don't think so. > This would seem to imply that the zero case means that it may not be > essential to have an ER server in a domain. It's not. > > S3, para 1: >> If multiple ER servers are deployed in the domain, we assume that >> they can be used interchangeably. > Are we talking physical servers here? Yes. > If not please refer to the > previous comment. > > s5, para 1: How would the authenticator advertise the domain name in > this context? That is outside the scope of this draft. > > s13: Looking at the various security considerations that are > imported, I wondered if some extra words were needed in respect of a > couple of the cases: - s8.4 of RFC 4072: (does distributing the > bootstrapping master key make things any worse here?) - I don't think so. > s8 of RFC > 6696 (does the DIME usage preserve the limited key scope?; is the > domino effect equally well avoided?) Yes and yes. > > Nits/editorial comments: > > s1: 'and re-use the Diameter EAP commands (DER/DEA).' : DER and DEA > ought to be expanded here. Or it might be less verbose to point at s2 > where they are currently expanded, thus: 'and re-use the Diameter EAP > commands listed in Section 2.' These are both defined in RFC 4072. > > s2, para 2: Need to expand acronyms rRK and rDSRK. rRK is defined in RFC 6696. > > s4, para 7: Should explicitly say that the ERP/DEA message is sent to > the authenticator. It's not: the authenticator is an EAP protocol entity. The message is sent to the Diameter peer, like all Diameter answer messages. > > s8.3.3: s/RGC 6696/RFC 6696/ > > Fixed, thanks. From glenzorn@gmail.com Wed Sep 26 03:46:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D367F21F87FF for ; Wed, 26 Sep 2012 03:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olniYXS9JMqx for ; Wed, 26 Sep 2012 03:46:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 605F021F87C8 for ; Wed, 26 Sep 2012 03:46:40 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so1716023pbb.31 for ; Wed, 26 Sep 2012 03:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=A7odtgnqtbtdxhJHsh8Uppfvzin7iBpSSRm1oB29BFk=; b=lB6PS8Cxf9T45Zxu7webTQHFuvb20IOZPSyb9d2FR0VUnbtnAtJAZFhMEGiyX3R2vk ZsjzHPShiWZr76vx68wAfiSkOlCt0S1hjeooKX0N3GUEPKmDiDRtW3mxOyt5cIh4OqPs kQMOPi/hD+auD/BiZtzN2TaurIlOf8Pq3Jvum2Ii2DUA95HD+VhTBipgHHmU7cfVn8zF 2SLh9afbQ/dhu5lNXYC1vMqnnOwYV+6yIUy1VUKQscUkmYUmsxoFs2WqGnZT+y6Uqjuw WNiicae37PqnnT6GHJZc/ekP110KvaLeafWgdLUD7MgiEK3on5gcGEGH6bQE+Qa+BFJw IXVw== Received: by 10.66.81.201 with SMTP id c9mr36203pay.80.1348656400152; Wed, 26 Sep 2012 03:46:40 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-218-82.revip2.asianet.co.th. [124.120.218.82]) by mx.google.com with ESMTPS id nz6sm1880825pbb.50.2012.09.26.03.46.37 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 03:46:39 -0700 (PDT) Message-ID: <5062DD0C.2080300@gmail.com> Date: Wed, 26 Sep 2012 17:46:36 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: draft-ietf-dime-rfc3588bis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime mailing list Subject: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 10:46:40 -0000 Section 4.5 of RFC 3588 says: The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. For the originator of a Diameter message, "Encr" (Encryption) means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient and integrity / confidentiality protection is offered for this AVP OR the originator has locally trusted configuration that indicates that end-to-end security is not needed. Similarly, for the originator of a Diameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. The corresponding section of 3588bis says: The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, and possible flag values. Considerable information (and normative guidance) seems to have been lost here: in particular, the statements that "the message MUST NOT be sent unless... the originator has locally trusted configuration that indicates that end-to-end security is not needed" would seem to be valid even in the absence of an E2E security solution. From lionel.morand@orange.com Wed Sep 26 11:26:44 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8334921F8585 for ; Wed, 26 Sep 2012 11:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqZC6BGBSmMf for ; Wed, 26 Sep 2012 11:26:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFD521F8582 for ; Wed, 26 Sep 2012 11:26:43 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2F88E18C2A2; Wed, 26 Sep 2012 20:26:42 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 14F424C0C4; Wed, 26 Sep 2012 20:26:42 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 20:26:41 +0200 From: To: Glen Zorn , draft-ietf-dime-rfc3588bis Thread-Topic: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: AQHNm9Q4eohZSPW+X0ufI8s6t2bgaZec8Crw Date: Wed, 26 Sep 2012 18:26:41 +0000 Message-ID: <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5062DD0C.2080300@gmail.com> In-Reply-To: <5062DD0C.2080300@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.26.150316 Cc: dime mailing list Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 18:26:44 -0000 Is it somehow covered in http://tools.ietf.org/html/draft-ietf-dime-rfc3588= bis-34#section-13.3? Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The Diameter messages containing such AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages SHOULD NOT be sent via intermediate nodes that would expose the sensitive data at those nodes except in cases where an intermediary is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Do you think that it is needed to add somewhere that "the originator has lo= cally trusted configuration that indicates that end-to-end security is not = needed"? Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de G= len Zorn Envoy=E9=A0: mercredi 26 septembre 2012 12:47 =C0=A0: draft-ietf-dime-rfc3588bis Cc=A0: dime mailing list Objet=A0: [Dime] unexpected consequence of deprecating E2E security in RFC = 3588 bis Section 4.5 of RFC 3588 says: The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. For the originator of a Diameter message, "Encr" (Encryption) means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient and integrity / confidentiality protection is offered for this AVP OR the originator has locally trusted configuration that indicates that end-to-end security is not needed. Similarly, for the originator of a Diameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. The corresponding section of 3588bis says: The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, and possible flag values. Considerable information (and normative guidance) seems to have been=20 lost here: in particular, the statements that "the message MUST NOT be=20 sent unless... the originator has locally trusted configuration that=20 indicates that end-to-end security is not needed" would seem to be valid=20 even in the absence of an E2E security solution. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From glenzorn@gmail.com Wed Sep 26 20:58:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52D021F85A3 for ; Wed, 26 Sep 2012 20:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfjtZxrHQ1Wt for ; Wed, 26 Sep 2012 20:58:00 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9921F859E for ; Wed, 26 Sep 2012 20:58:00 -0700 (PDT) Received: by padfb11 with SMTP id fb11so991109pad.31 for ; Wed, 26 Sep 2012 20:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PA4NSvztjpbxUHzdeDPbcjlpBEyeXqrb7B4myurke9E=; b=d4OF+oGgmBSPETgrJAyB5ixboTsKULprjhc/gntQRuSWqxnceL385JuN8H5ewMl8Si 8XPQH3lSs2X/wxDrn83Jcf3UKRDrSSgUQggJ6/f5oEdRywUOO2hlg6FJjDGULwFE/8XW oM+VFcYTnBlND6s3AHnhHQUvlu7WUlldvDY24yI12/lA5LEuLEMQ/ZHf38gp1vAgKxlj XwKaDcDMw2RBt3jtJtGHrRvpXnw9ff2naHlytIkg66aoXstcGe+wzrZAIWUM5j6GaQST pqpsauXkg4bAW7KR5WhKBdsaHiULEHzKzdjGcrMfm0PUQMeWCKoguDhJIEgMRWA3alcW jgOQ== Received: by 10.66.83.234 with SMTP id t10mr6236838pay.39.1348718279742; Wed, 26 Sep 2012 20:57:59 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-218-82.revip2.asianet.co.th. [124.120.218.82]) by mx.google.com with ESMTPS id nv2sm1982490pbc.44.2012.09.26.20.57.56 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 20:57:58 -0700 (PDT) Message-ID: <5063CEC3.9080305@gmail.com> Date: Thu, 27 Sep 2012 10:57:55 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: lionel.morand@orange.com References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-dime-rfc3588bis , dime mailing list , turners , Stephen Farrell Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 03:58:00 -0000 On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote: Copying the Security ADs. > Is it somehow covered in > http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? > > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and > cryptographic keys. The Diameter messages containing such AVPs MUST > only be sent protected via mutually authenticated TLS or IPsec. In > addition, those messages SHOULD NOT be sent via intermediate nodes > that would expose the sensitive data at those nodes except in cases > where an intermediary is known to be operated as part of the same > administrative domain as the endpoints so that an ability to > successfully compromise the intermediary would imply a high > probability of being able to compromise the endpoints as well. > > Do you think that it is needed to add somewhere that "the originator > has locally trusted configuration that indicates that end-to-end > security is not needed"? I think that something should be done since as it stands the language is weaker in bis than in RFC 3588; the protocol is actually less secure :-(. I would suggest changing Section 13.3 (quoted above) to say some thing like this: Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The Diameter messages containing such AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed (for example, where an intermediary is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well). Note, however, that no end-to-end security mechanism is specified in this document. However, I don't really want to delay publication any more than I already have ;-), so if that change would trigger a whole new IESG review (or worse, another IETF LC) I would rather handle it in an erratum later. > > > Lionel > > > -----Message d'origine----- De : dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoy : > mercredi 26 septembre 2012 12:47 : draft-ietf-dime-rfc3588bis Cc : > dime mailing list Objet : [Dime] unexpected consequence of > deprecating E2E security in RFC 3588 bis > > Section 4.5 of RFC 3588 says: The following table describes the > Diameter AVPs defined in the base protocol, their AVP Code values, > types, possible flag values and whether the AVP MAY be encrypted. > For the originator of a Diameter message, "Encr" (Encryption) means > that if a message containing that AVP is to be sent via a Diameter > agent (proxy, redirect or relay) then the message MUST NOT be sent > unless there is end-to-end security between the originator and the > recipient and integrity / confidentiality protection is offered for > this AVP OR the originator has locally trusted configuration that > indicates that end-to-end security is not needed. Similarly, for the > originator of a Diameter message, a "P" in the "MAY" column means > that if a message containing that AVP is to be sent via a Diameter > agent (proxy, redirect or relay) then the message MUST NOT be sent > unless there is end-to-end security between the originator and the > recipient or the originator has locally trusted configuration that > indicates that end-to-end security is not needed. > > The corresponding section of 3588bis says: The following table > describes the Diameter AVPs defined in the base protocol, their AVP > Code values, types, and possible flag values. > > Considerable information (and normative guidance) seems to have been > lost here: in particular, the statements that "the message MUST NOT > be sent unless... the originator has locally trusted configuration > that indicates that end-to-end security is not needed" would seem to > be valid even in the absence of an E2E security solution. > _______________________________________________ DiME mailing list > DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler a l'expediteur > et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. If you have > received this email in error, please notify the sender and delete > this message and its attachments. As emails may be altered, France > Telecom - Orange is not liable for messages that have been modified, > changed or falsified. Thank you. > From dieter.jacobsohn@telekom.de Thu Sep 27 03:01:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECACF21F86BA for ; Thu, 27 Sep 2012 03:01:40 -0700 (PDT) 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_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVSirpW5YRUV for ; Thu, 27 Sep 2012 03:01:39 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17821F86A2 for ; Thu, 27 Sep 2012 03:01:38 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Sep 2012 12:01:36 +0200 Received: from HE113456.emea1.cds.t-internal.com ([169.254.3.121]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 27 Sep 2012 12:01:36 +0200 From: To: , , Date: Thu, 27 Sep 2012 12:01:35 +0200 Thread-Topic: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: Ac2cZEt6h1knIDyXTG+On6ITbSQbqAAMbOXg Message-ID: <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> In-Reply-To: <5063CEC3.9080305@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, Stefan.Schroeder06@telekom.de, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 10:01:41 -0000 =20 Hello Glen After discussing it also with some security people I think that the existin= g text is more accurate and should stay. The existing text refers to "intermediary is known to be operated as part o= f the same administrative domain as the endpoints", which is fine. We don't= have end-to-end security in 3588bis, true. But 13.3 offers exactly this pa= rty1-to-party2 security as almost equivalent to e2e security.=20 The new proposed text would allow other alternatives beyond that, based on = "locally trusted configuration". But what does that mean in practice? I thi= nk such a statement would allow just anything and move away from any tangib= le technical security. Best Regards Dieter Jacobsohn Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de www.telekom.com =20 Erleben, was verbindet. =20 Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE 123475223 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.=20 -----Urspr=FCngliche Nachricht----- Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im Auftrag von Gl= en Zorn Gesendet: Donnerstag, 27. September 2012 05:58 An: lionel.morand@orange.com Cc: draft-ietf-dime-rfc3588bis; dime mailing list; turners; Stephen Farrell Betreff: Re: [Dime] unexpected consequence of deprecating E2E security in R= FC 3588 bis On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote: Copying the Security ADs. > Is it somehow covered in > http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? > > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and > cryptographic keys. The Diameter messages containing such AVPs MUST > o= nly be sent protected via mutually authenticated TLS or IPsec. In > additi= on, those messages SHOULD NOT be sent via intermediate nodes > that would = expose the sensitive data at those nodes except in cases > where an interm= ediary is known to be operated as part of the same > administrative domain= as the endpoints so that an ability to > successfully compromise the inte= rmediary would imply a high > probability of being able to compromise the = endpoints as well. > > Do you think that it is needed to add somewhere that "the originator > = has locally trusted configuration that indicates that end-to-end > securit= y is not needed"? I think that something should be done since as it stands the language is we= aker in bis than in RFC 3588; the protocol is actually less secure :-(. I = would suggest changing Section 13.3 (quoted above) to say some thing like t= his: Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The Diameter messages containing such AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the origina= tor has locally trusted configuration that indicates that end-to-end security is not ne= eded (for example, where an intermediary is known to be operated as part of = the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well).=20 Note, however, that no end-to-end security mechanism is specified in this document. However, I don't really want to delay publication any more than I already h= ave ;-), so if that change would trigger a whole new IESG review (or worse,= another IETF LC) I would rather handle it in an erratum later. > > > Lionel > > > -----Message d'origine----- De : dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoy=E9 : > mercredi 26 septembre 2012 12:47 =C0 : draft-ietf-dime-rfc3588bis Cc : > dime mailing list Objet : [Dime] unexpected consequence of > deprecating E2E security in RFC 3588 bis > > Section 4.5 of RFC 3588 says: The following table describes the > Diameter AVPs defined in the base protocol, their AVP Code values, > types, possible flag values and whether the AVP MAY be encrypted. > For the originator of a Diameter message, "Encr" (Encryption) means > that if a message containing that AVP is to be sent via a Diameter > agent (proxy, redirect or relay) then the message MUST NOT be sent > unless there is end-to-end security between the originator and the > recipient and integrity / confidentiality protection is offered for > this AVP OR the originator has locally trusted configuration that > indicates that end-to-end security is not needed. Similarly, for the > originator of a Diameter message, a "P" in the "MAY" column means > that if a message containing that AVP is to be sent via a Diameter > agent (proxy, redirect or relay) then the message MUST NOT be sent > unless there is end-to-end security between the originator and the > recipient or the originator has locally trusted configuration that > indicates that end-to-end security is not needed. > > The corresponding section of 3588bis says: The following table > describes the Diameter AVPs defined in the base protocol, their AVP > Code values, types, and possible flag values. > > Considerable information (and normative guidance) seems to have been > lost here: in particular, the statements that "the message MUST NOT > be sent unless... the originator has locally trusted configuration > that indicates that end-to-end security is not needed" would seem to > be valid even in the absence of an E2E security solution. > _______________________________________________ DiME mailing list > DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime > >=20 ___________________________________________________________________________= ______________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations=20 confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler a l'expediteur > et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. If you have > received this email in error, please notify the sender and delete > this message and its attachments. As emails may be altered, France > Telecom - Orange is not liable for messages that have been modified, > changed or falsified. Thank you. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Thu Sep 27 04:04:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A7A21F846A for ; Thu, 27 Sep 2012 04:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5j8SZbeBQPL for ; Thu, 27 Sep 2012 04:04:03 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAD821F844F for ; Thu, 27 Sep 2012 04:04:03 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so3466688pbb.31 for ; Thu, 27 Sep 2012 04:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=W0Htu/7sdvy5tJIQhu/mjyEO34GbwOu7hdBLlBr3/us=; b=G7gsuUyvtl6dpsSo32LHy6MrW75mUmzemNu1Rw5yIwiNU+PY/sCfKt3zxT7AZ9tMAe AQu1eeFqV3qnR/4DnZiDcDBN28g8pGz+r5FztX1U8uacKb8ik0cvR1im/h0Bnhff+BSB q+GRUOQPO0jGm4/vfNZCRm+I0lcnkxRAbShAKRoEpEWGdvfSLGhQ8bqFJ0u1+z+p3T4G KJZhibnVCXuMyOZOEtKpRROrtmVq2LTRjUS0bmr43gQV2pIEgLyCJTGjfJtA7IntZNda jcPOUlXnD4Au+SaaXvlPrBirP07iH4eMeSddkITbcqJqrLXeMJvstCW8uU8MZD55oF/S 7WFQ== Received: by 10.68.129.38 with SMTP id nt6mr10590911pbb.76.1348743842952; Thu, 27 Sep 2012 04:04:02 -0700 (PDT) Received: from [192.168.0.102] (ppp-110-169-207-21.revip5.asianet.co.th. [110.169.207.21]) by mx.google.com with ESMTPS id bs6sm3552264pab.30.2012.09.27.04.03.59 (version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 04:04:02 -0700 (PDT) Message-ID: <5064329D.40203@gmail.com> Date: Thu, 27 Sep 2012 18:03:57 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: dieter.jacobsohn@telekom.de References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> In-Reply-To: <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, Stefan.Schroeder06@telekom.de, dime@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 11:04:04 -0000 On 09/27/2012 05:01 PM, dieter.jacobsohn@telekom.de wrote: > > Hello Glen After discussing it also with some security people I think > that the existing text is more accurate and should stay. The existing > text refers to "intermediary is known to be operated as part of the > same administrative domain as the endpoints", which is fine. The current text assumes that exactly the same security measures are applied to the endpoints and any intermediates. I think that this assumption is basically groundless. > We don't have end-to-end security in 3588bis, true. But 13.3 offers > exactly this party1-to-party2 security as almost equivalent to e2e > security. AFAICT, it offers the assertion that "Our network is secure." and basically nothing else. > > The new proposed text would allow other alternatives beyond that, > based on "locally trusted configuration". But what does that mean in > practice? I think such a statement would allow just anything and move > away from any tangible technical security. Unless bare assertions constitute technical security, it doesn't move away from anything. Be that as it may, the current text says "In addition, those messages SHOULD NOT be sent via intermediate nodes that would expose the sensitive data at those nodes". As I understand it, "SHOULD NOT" means "don't do it unless you have a good reason to", but the definition of "good reason" is pretty much up in the air. Is the simple assertion of security a "good reason"? Sounds like it. By contrast, RFC 3588 says that messages containing sensitive AVPs MUST NOT be sent through untrusted intermediaries; that is the part I want to see remain. Admittedly, it's a small thing, but it's something; I'm sure that people are going to do whatever they like anyway, but at least they might stop and think a bit more when they see a MUST. "Blindly trust every host in this domain because I say so" could still be the policy, but it would need to be configured as such (which I suspect is actually the issue here). > > Best Regards Dieter Jacobsohn > > > Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg > 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 > 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner > (Vorsitzender) Vorstand: Ren Obermann (Vorsitzender), Dr. Manfred > Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus Httges, > Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: Amtsgericht > Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE 123475223 > > Groe Vernderungen fangen klein an - Ressourcen schonen und nicht > jede E-Mail drucken. > > > -----Ursprngliche Nachricht----- Von: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] Im Auftrag von Glen Zorn Gesendet: > Donnerstag, 27. September 2012 05:58 An: lionel.morand@orange.com Cc: > draft-ietf-dime-rfc3588bis; dime mailing list; turners; Stephen > Farrell Betreff: Re: [Dime] unexpected consequence of deprecating E2E > security in RFC 3588 bis > > On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote: > > Copying the Security ADs. > >> Is it somehow covered in >> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? > >> > >> >> > Diameter AVPs often contain security-sensitive data; for example, >> user passwords and location data, network addresses and >> cryptographic keys. The Diameter messages containing such AVPs MUST >> > only be sent protected via mutually authenticated TLS or IPsec. >> In > addition, those messages SHOULD NOT be sent via intermediate >> nodes > that would expose the sensitive data at those nodes except >> in cases > where an intermediary is known to be operated as part >> of the same > administrative domain as the endpoints so that an >> ability to > successfully compromise the intermediary would imply >> a high > probability of being able to compromise the endpoints as >> well. >> >> Do you think that it is needed to add somewhere that "the >> originator > has locally trusted configuration that indicates that >> end-to-end > security is not needed"? > > I think that something should be done since as it stands the language > is weaker in bis than in RFC 3588; the protocol is actually less > secure :-(. I would suggest changing Section 13.3 (quoted above) to > say some thing like this: > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and > cryptographic keys. The Diameter messages containing such AVPs MUST > only be sent protected via mutually authenticated TLS or IPsec. In > addition, those messages MUST NOT be sent via intermediate nodes > unless there is end-to-end security between the originator and > recipient or the originator has locally trusted configuration that > indicates that end-to-end security is not needed (for example, where > an intermediary is known to be operated as part of the same > administrative domain as the endpoints so that an ability to > successfully compromise the intermediary would imply a high > probability of being able to compromise the endpoints as well). Note, > however, that no end-to-end security mechanism is specified in this > document. > > However, I don't really want to delay publication any more than I > already have ;-), so if that change would trigger a whole new IESG > review (or worse, another IETF LC) I would rather handle it in an > erratum later. > >> >> >> Lionel >> >> >> -----Message d'origine----- De : dime-bounces@ietf.org >> [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoy : >> mercredi 26 septembre 2012 12:47 : draft-ietf-dime-rfc3588bis Cc >> : dime mailing list Objet : [Dime] unexpected consequence of >> deprecating E2E security in RFC 3588 bis >> >> Section 4.5 of RFC 3588 says: The following table describes the >> Diameter AVPs defined in the base protocol, their AVP Code values, >> types, possible flag values and whether the AVP MAY be encrypted. >> For the originator of a Diameter message, "Encr" (Encryption) >> means that if a message containing that AVP is to be sent via a >> Diameter agent (proxy, redirect or relay) then the message MUST NOT >> be sent unless there is end-to-end security between the originator >> and the recipient and integrity / confidentiality protection is >> offered for this AVP OR the originator has locally trusted >> configuration that indicates that end-to-end security is not >> needed. Similarly, for the originator of a Diameter message, a "P" >> in the "MAY" column means that if a message containing that AVP is >> to be sent via a Diameter agent (proxy, redirect or relay) then the >> message MUST NOT be sent unless there is end-to-end security >> between the originator and the recipient or the originator has >> locally trusted configuration that indicates that end-to-end >> security is not needed. >> >> The corresponding section of 3588bis says: The following table >> describes the Diameter AVPs defined in the base protocol, their >> AVP Code values, types, and possible flag values. >> >> Considerable information (and normative guidance) seems to have >> been lost here: in particular, the statements that "the message >> MUST NOT be sent unless... the originator has locally trusted >> configuration that indicates that end-to-end security is not >> needed" would seem to be valid even in the absence of an E2E >> security solution. _______________________________________________ >> DiME mailing list DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > _________________________________________________________________________________________________________________________ > > > >> >> > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous >> avez recu ce message par erreur, veuillez le signaler a >> l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, France >> Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should >> not be distributed, used or copied without authorisation. If you >> have received this email in error, please notify the sender and >> delete this message and its attachments. As emails may be altered, >> France Telecom - Orange is not liable for messages that have been >> modified, changed or falsified. Thank you. >> > > > _______________________________________________ DiME mailing list > DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Sat Sep 29 03:08:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80B21F8471 for ; Sat, 29 Sep 2012 03:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmK-slohi4br for ; Sat, 29 Sep 2012 03:08:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4D121F846C for ; Sat, 29 Sep 2012 03:08:18 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 85DB526433F; Sat, 29 Sep 2012 12:08:17 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 61EEC23804B; Sat, 29 Sep 2012 12:08:17 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sat, 29 Sep 2012 12:08:16 +0200 From: To: Glen Zorn , "dieter.jacobsohn@telekom.de" Thread-Topic: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: AQHNnJ/PmFF7ou/QQUu4tdR7kdgk0pehGbiA Date: Sat, 29 Sep 2012 10:08:15 +0000 Message-ID: <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> In-Reply-To: <5064329D.40203@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.29.65416 Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 10:08:21 -0000 Hi Glen, I'm OK with the "MUST NOT... unless" approach that is stronger than "SHOULD= NOT... unless". The last part could be slightly modified as follow: Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The Diameter messages containing such AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the origina= tor has locally trusted configuration that indicates that end-to-end security is not ne= eded. For example, end-to-end security may not be required in the case=20 where an intermediary node is known to be operated as part of the same = administrative=20 domain as the endpoints so that an ability to successfully compromise t= he intermediary=20 would imply a high probability of being able to compromise the endpoint= s as well.=20 Note that no end-to-end security mechanism is specified in this documen= t. The "may not be required" indicates that it is a design option and the defa= ult rule is "E2E security is required for those AVPs". Regards, Lionel -----Message d'origine----- De=A0: Glen Zorn [mailto:glenzorn@gmail.com]=20 Envoy=E9=A0: jeudi 27 septembre 2012 13:04 =C0=A0: dieter.jacobsohn@telekom.de Cc=A0: glenzorn@gmail.com; MORAND Lionel RD-CORE; dime@ietf.org; draft-ietf= -dime-rfc3588bis@tools.ietf.org; turners@ieca.com; stephen.farrell@cs.tcd.i= e; Stefan.Schroeder06@telekom.de Objet=A0: Re: AW: [Dime] unexpected consequence of deprecating E2E security= in RFC 3588 bis On 09/27/2012 05:01 PM, dieter.jacobsohn@telekom.de wrote: > > Hello Glen After discussing it also with some security people I think > that the existing text is more accurate and should stay. The existing > text refers to "intermediary is known to be operated as part of the > same administrative domain as the endpoints", which is fine. The current text assumes that exactly the same security measures are=20 applied to the endpoints and any intermediates. I think that this=20 assumption is basically groundless. > We don't have end-to-end security in 3588bis, true. But 13.3 offers > exactly this party1-to-party2 security as almost equivalent to e2e > security. AFAICT, it offers the assertion that "Our network is secure." and=20 basically nothing else. > > The new proposed text would allow other alternatives beyond that, > based on "locally trusted configuration". But what does that mean in > practice? I think such a statement would allow just anything and move > away from any tangible technical security. Unless bare assertions constitute technical security, it doesn't move=20 away from anything. Be that as it may, the current text says "In=20 addition, those messages SHOULD NOT be sent via intermediate nodes that=20 would expose the sensitive data at those nodes". As I understand it,=20 "SHOULD NOT" means "don't do it unless you have a good reason to", but=20 the definition of "good reason" is pretty much up in the air. Is the=20 simple assertion of security a "good reason"? Sounds like it. By=20 contrast, RFC 3588 says that messages containing sensitive AVPs MUST NOT=20 be sent through untrusted intermediaries; that is the part I want to see=20 remain. Admittedly, it's a small thing, but it's something; I'm sure=20 that people are going to do whatever they like anyway, but at least they=20 might stop and think a bit more when they see a MUST. "Blindly trust=20 every host in this domain because I say so" could still be the policy,=20 but it would need to be configured as such (which I suspect is actually=20 the issue here). > > Best Regards Dieter Jacobsohn > > > Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg > 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 46624 (Fax) +49 > 171 2088 710 (Mobil) E-Mail: dieter.jacobsohn@telekom.de > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner > (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Manfred > Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, > Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: Amtsgericht > Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE 123475223 > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht > jede E-Mail drucken. > > > -----Urspr=FCngliche Nachricht----- Von: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] Im Auftrag von Glen Zorn Gesendet: > Donnerstag, 27. September 2012 05:58 An: lionel.morand@orange.com Cc: > draft-ietf-dime-rfc3588bis; dime mailing list; turners; Stephen > Farrell Betreff: Re: [Dime] unexpected consequence of deprecating E2E > security in RFC 3588 bis > > On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote: > > Copying the Security ADs. > >> Is it somehow covered in >> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? > >> > >> >> > Diameter AVPs often contain security-sensitive data; for example, >> user passwords and location data, network addresses and >> cryptographic keys. The Diameter messages containing such AVPs MUST >> > only be sent protected via mutually authenticated TLS or IPsec. >> In > addition, those messages SHOULD NOT be sent via intermediate >> nodes > that would expose the sensitive data at those nodes except >> in cases > where an intermediary is known to be operated as part >> of the same > administrative domain as the endpoints so that an >> ability to > successfully compromise the intermediary would imply >> a high > probability of being able to compromise the endpoints as >> well. >> >> Do you think that it is needed to add somewhere that "the >> originator > has locally trusted configuration that indicates that >> end-to-end > security is not needed"? > > I think that something should be done since as it stands the language > is weaker in bis than in RFC 3588; the protocol is actually less > secure :-(. I would suggest changing Section 13.3 (quoted above) to > say some thing like this: > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and > cryptographic keys. The Diameter messages containing such AVPs MUST > only be sent protected via mutually authenticated TLS or IPsec. In > addition, those messages MUST NOT be sent via intermediate nodes > unless there is end-to-end security between the originator and > recipient or the originator has locally trusted configuration that > indicates that end-to-end security is not needed (for example, where > an intermediary is known to be operated as part of the same > administrative domain as the endpoints so that an ability to > successfully compromise the intermediary would imply a high > probability of being able to compromise the endpoints as well). Note, > however, that no end-to-end security mechanism is specified in this > document. > > However, I don't really want to delay publication any more than I > already have ;-), so if that change would trigger a whole new IESG > review (or worse, another IETF LC) I would rather handle it in an > erratum later. > >> >> >> Lionel >> >> >> -----Message d'origine----- De : dime-bounces@ietf.org >> [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoy=E9 : >> mercredi 26 septembre 2012 12:47 =C0 : draft-ietf-dime-rfc3588bis Cc >> : dime mailing list Objet : [Dime] unexpected consequence of >> deprecating E2E security in RFC 3588 bis >> >> Section 4.5 of RFC 3588 says: The following table describes the >> Diameter AVPs defined in the base protocol, their AVP Code values, >> types, possible flag values and whether the AVP MAY be encrypted. >> For the originator of a Diameter message, "Encr" (Encryption) >> means that if a message containing that AVP is to be sent via a >> Diameter agent (proxy, redirect or relay) then the message MUST NOT >> be sent unless there is end-to-end security between the originator >> and the recipient and integrity / confidentiality protection is >> offered for this AVP OR the originator has locally trusted >> configuration that indicates that end-to-end security is not >> needed. Similarly, for the originator of a Diameter message, a "P" >> in the "MAY" column means that if a message containing that AVP is >> to be sent via a Diameter agent (proxy, redirect or relay) then the >> message MUST NOT be sent unless there is end-to-end security >> between the originator and the recipient or the originator has >> locally trusted configuration that indicates that end-to-end >> security is not needed. >> >> The corresponding section of 3588bis says: The following table >> describes the Diameter AVPs defined in the base protocol, their >> AVP Code values, types, and possible flag values. >> >> Considerable information (and normative guidance) seems to have >> been lost here: in particular, the statements that "the message >> MUST NOT be sent unless... the originator has locally trusted >> configuration that indicates that end-to-end security is not >> needed" would seem to be valid even in the absence of an E2E >> security solution. _______________________________________________ >> DiME mailing list DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> >=20 ___________________________________________________________________________= ______________________________________________ > > > >> >> > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous >> avez recu ce message par erreur, veuillez le signaler a >> l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, France >> Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should >> not be distributed, used or copied without authorisation. If you >> have received this email in error, please notify the sender and >> delete this message and its attachments. As emails may be altered, >> France Telecom - Orange is not liable for messages that have been >> modified, changed or falsified. Thank you. >> > > > _______________________________________________ DiME mailing list > DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From glenzorn@gmail.com Sat Sep 29 03:20:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16021F853D for ; Sat, 29 Sep 2012 03:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLwmvMfvASPl for ; Sat, 29 Sep 2012 03:19:58 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A348D21F8522 for ; Sat, 29 Sep 2012 03:19:58 -0700 (PDT) Received: by danh15 with SMTP id h15so933773dan.31 for ; Sat, 29 Sep 2012 03:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l3F3OPKBgdwUXmuJJAlTBN/jNcQSbyZyss2QYD1KnlE=; b=tuZNW2gBa98n5464pENTnc9yOxAGVXG7GopEEiQAalyBYTZ7ujqRVySucVATi1+MzB yVZyV/0zrSfMSw9BtslPOtpDhIs2kW2Bf/O4lTUe99vXn1whq3yYqrJSgCMl25WlT52+ uOp1laT5WIEfUCaTvXgGt85ew7LxmO4gKqEdhaqybAWOp4AmhMUufgvYOoqB38z/FDJA j/H8/7WAyGZRVbi4oerY5crsyFfSEIf1dFDEyy8yzYOXCbz6pwLhoM0HfcI9ZQGq7W4W AIub47bbL9udpD3e5NNN7RZgOJfrF8O5ICb6GfmiXJ7yyLy/2F5LRghWuEkJovH9iNRb CJEg== Received: by 10.68.195.226 with SMTP id ih2mr27640347pbc.9.1348913997466; Sat, 29 Sep 2012 03:19:57 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-121-208-251.revip2.asianet.co.th. [124.121.208.251]) by mx.google.com with ESMTPS id ka4sm7034331pbc.61.2012.09.29.03.19.53 (version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 03:19:56 -0700 (PDT) Message-ID: <5066CB47.1070807@gmail.com> Date: Sat, 29 Sep 2012 17:19:51 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: lionel.morand@orange.com References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 10:20:00 -0000 On 09/29/2012 05:08 PM, lionel.morand@orange.com wrote: > Hi Glen, > > I'm OK with the "MUST NOT... unless" approach that is stronger than > "SHOULD NOT... unless". The last part could be slightly modified as > follow: > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and > cryptographic keys. The Diameter messages containing such AVPs MUST > only be sent protected via mutually authenticated TLS or IPsec. In > addition, those messages MUST NOT be sent via intermediate nodes > unless there is end-to-end security between the originator and > recipient or the originator has locally trusted configuration that > indicates that end-to-end security is not needed. For example, > end-to-end security may not be required in the case where an > intermediary node is known to be operated as part of the same > administrative domain as the endpoints so that an ability to > successfully compromise the intermediary would imply a high > probability of being able to compromise the endpoints as well. Note > that no end-to-end security mechanism is specified in this document. > > The "may not be required" indicates that it is a design option and > the default rule is "E2E security is required for those AVPs". This is fine. I noticed that another important piece of data was lost in the shuffle, as well: in RFC 3588, the AVPs considered to contain security-sensitive data were marked as such in the AVP tables, but in the revision they're not. This makes the MUST NOT above pretty close to useless. I think that we probably need to list those AVPs in this section, as well. > > Regards, > > Lionel > > -----Message d'origine----- De : Glen Zorn > [mailto:glenzorn@gmail.com] Envoy : jeudi 27 septembre 2012 13:04 > : dieter.jacobsohn@telekom.de Cc : glenzorn@gmail.com; MORAND Lionel > RD-CORE; dime@ietf.org; draft-ietf-dime-rfc3588bis@tools.ietf.org; > turners@ieca.com; stephen.farrell@cs.tcd.ie; > Stefan.Schroeder06@telekom.de Objet : Re: AW: [Dime] unexpected > consequence of deprecating E2E security in RFC 3588 bis > > On 09/27/2012 05:01 PM, dieter.jacobsohn@telekom.de wrote: >> >> Hello Glen After discussing it also with some security people I >> think that the existing text is more accurate and should stay. The >> existing text refers to "intermediary is known to be operated as >> part of the same administrative domain as the endpoints", which is >> fine. > > The current text assumes that exactly the same security measures are > applied to the endpoints and any intermediates. I think that this > assumption is basically groundless. > >> We don't have end-to-end security in 3588bis, true. But 13.3 >> offers exactly this party1-to-party2 security as almost equivalent >> to e2e security. > > AFAICT, it offers the assertion that "Our network is secure." and > basically nothing else. > >> >> The new proposed text would allow other alternatives beyond that, >> based on "locally trusted configuration". But what does that mean >> in practice? I think such a statement would allow just anything and >> move away from any tangible technical security. > > Unless bare assertions constitute technical security, it doesn't move > away from anything. Be that as it may, the current text says "In > addition, those messages SHOULD NOT be sent via intermediate nodes > that would expose the sensitive data at those nodes". As I > understand it, "SHOULD NOT" means "don't do it unless you have a good > reason to", but the definition of "good reason" is pretty much up in > the air. Is the simple assertion of security a "good reason"? > Sounds like it. By contrast, RFC 3588 says that messages containing > sensitive AVPs MUST NOT be sent through untrusted intermediaries; > that is the part I want to see remain. Admittedly, it's a small > thing, but it's something; I'm sure that people are going to do > whatever they like anyway, but at least they might stop and think a > bit more when they see a MUST. "Blindly trust every host in this > domain because I say so" could still be the policy, but it would need > to be configured as such (which I suspect is actually the issue > here). > >> >> Best Regards Dieter Jacobsohn >> >> >> Deutsche Telekom AG Group Technology Dieter Jacobsohn >> Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 >> 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: >> dieter.jacobsohn@telekom.de www.telekom.com >> >> Erleben, was verbindet. >> >> Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner >> (Vorsitzender) Vorstand: Ren Obermann (Vorsitzender), Dr. Manfred >> Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus Httges, >> Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: >> Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE >> 123475223 >> >> Groe Vernderungen fangen klein an - Ressourcen schonen und nicht >> jede E-Mail drucken. >> >> >> -----Ursprngliche Nachricht----- Von: dime-bounces@ietf.org >> [mailto:dime-bounces@ietf.org] Im Auftrag von Glen Zorn Gesendet: >> Donnerstag, 27. September 2012 05:58 An: lionel.morand@orange.com >> Cc: draft-ietf-dime-rfc3588bis; dime mailing list; turners; >> Stephen Farrell Betreff: Re: [Dime] unexpected consequence of >> deprecating E2E security in RFC 3588 bis >> >> On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote: >> >> Copying the Security ADs. >> >>> Is it somehow covered in >>> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? > >>> > >>> >> >>> >>> >> Diameter AVPs often contain security-sensitive data; for example, >>> user passwords and location data, network addresses and >>> cryptographic keys. The Diameter messages containing such AVPs >>> MUST >>>> only be sent protected via mutually authenticated TLS or >>>> IPsec. >>> In > addition, those messages SHOULD NOT be sent via >>> intermediate nodes > that would expose the sensitive data at >>> those nodes except in cases > where an intermediary is known to >>> be operated as part of the same > administrative domain as the >>> endpoints so that an ability to > successfully compromise the >>> intermediary would imply a high > probability of being able to >>> compromise the endpoints as well. >>> >>> Do you think that it is needed to add somewhere that "the >>> originator > has locally trusted configuration that indicates >>> that end-to-end > security is not needed"? >> >> I think that something should be done since as it stands the >> language is weaker in bis than in RFC 3588; the protocol is >> actually less secure :-(. I would suggest changing Section 13.3 >> (quoted above) to say some thing like this: >> >> Diameter AVPs often contain security-sensitive data; for example, >> user passwords and location data, network addresses and >> cryptographic keys. The Diameter messages containing such AVPs >> MUST only be sent protected via mutually authenticated TLS or >> IPsec. In addition, those messages MUST NOT be sent via >> intermediate nodes unless there is end-to-end security between the >> originator and recipient or the originator has locally trusted >> configuration that indicates that end-to-end security is not needed >> (for example, where an intermediary is known to be operated as part >> of the same administrative domain as the endpoints so that an >> ability to successfully compromise the intermediary would imply a >> high probability of being able to compromise the endpoints as >> well). Note, however, that no end-to-end security mechanism is >> specified in this document. >> >> However, I don't really want to delay publication any more than I >> already have ;-), so if that change would trigger a whole new IESG >> review (or worse, another IETF LC) I would rather handle it in an >> erratum later. >> >>> >>> >>> Lionel >>> >>> >>> -----Message d'origine----- De : dime-bounces@ietf.org >>> [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoy : >>> mercredi 26 septembre 2012 12:47 : draft-ietf-dime-rfc3588bis >>> Cc : dime mailing list Objet : [Dime] unexpected consequence of >>> deprecating E2E security in RFC 3588 bis >>> >>> Section 4.5 of RFC 3588 says: The following table describes the >>> Diameter AVPs defined in the base protocol, their AVP Code >>> values, types, possible flag values and whether the AVP MAY be >>> encrypted. For the originator of a Diameter message, "Encr" >>> (Encryption) means that if a message containing that AVP is to be >>> sent via a Diameter agent (proxy, redirect or relay) then the >>> message MUST NOT be sent unless there is end-to-end security >>> between the originator and the recipient and integrity / >>> confidentiality protection is offered for this AVP OR the >>> originator has locally trusted configuration that indicates that >>> end-to-end security is not needed. Similarly, for the originator >>> of a Diameter message, a "P" in the "MAY" column means that if a >>> message containing that AVP is to be sent via a Diameter agent >>> (proxy, redirect or relay) then the message MUST NOT be sent >>> unless there is end-to-end security between the originator and >>> the recipient or the originator has locally trusted configuration >>> that indicates that end-to-end security is not needed. >>> >>> The corresponding section of 3588bis says: The following table >>> describes the Diameter AVPs defined in the base protocol, their >>> AVP Code values, types, and possible flag values. >>> >>> Considerable information (and normative guidance) seems to have >>> been lost here: in particular, the statements that "the message >>> MUST NOT be sent unless... the originator has locally trusted >>> configuration that indicates that end-to-end security is not >>> needed" would seem to be valid even in the absence of an E2E >>> security solution. >>> _______________________________________________ DiME mailing list >>> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime >>> >>> >> > _________________________________________________________________________________________________________________________ > > > >> >> >>> >>> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si >>> vous avez recu ce message par erreur, veuillez le signaler a >>> l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, France >>> Telecom - Orange decline toute responsabilite si ce message a >>> ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should >>> not be distributed, used or copied without authorisation. If you >>> have received this email in error, please notify the sender and >>> delete this message and its attachments. As emails may be >>> altered, France Telecom - Orange is not liable for messages that >>> have been modified, changed or falsified. Thank you. >>> >> >> >> _______________________________________________ DiME mailing list >> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime > > > > _________________________________________________________________________________________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler a l'expediteur > et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. If you have > received this email in error, please notify the sender and delete > this message and its attachments. As emails may be altered, France > Telecom - Orange is not liable for messages that have been modified, > changed or falsified. Thank you. > From lionel.morand@orange.com Sat Sep 29 03:39:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FAE21F855D for ; Sat, 29 Sep 2012 03:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d6XwIZCcETR for ; Sat, 29 Sep 2012 03:39:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C738521F855A for ; Sat, 29 Sep 2012 03:39:06 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id EB03B2642DF; Sat, 29 Sep 2012 12:39:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C64B04C069; Sat, 29 Sep 2012 12:39:04 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sat, 29 Sep 2012 12:39:04 +0200 From: To: Glen Zorn Thread-Topic: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: AQHNnJ/PdJugYOnjTU2ziQeyw0U7bJehGbiA///jbYCAACQFIA== Date: Sat, 29 Sep 2012 10:39:03 +0000 Message-ID: <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> In-Reply-To: <5066CB47.1070807@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 10:39:10 -0000 It is actually needed if we don't want to lose info. These AVPs should be listed in a table in these sections with an indication= that is a list of AVPs that can be considered as security-sensitive, in or= der to not start a discussion on which AVP is really sensitive and which no= t. Anyway, designers will have to decide what they want to do and this list= is mainly for information. Lionel -----Message d'origine----- De=A0: Glen Zorn [mailto:glenzorn@gmail.com]=20 Envoy=E9=A0: samedi 29 septembre 2012 12:20 =C0=A0: MORAND Lionel RD-CORE Cc=A0: Glen Zorn; dieter.jacobsohn@telekom.de; dime@ietf.org; draft-ietf-di= me-rfc3588bis@tools.ietf.org; turners@ieca.com; stephen.farrell@cs.tcd.ie; = Stefan.Schroeder06@telekom.de Objet=A0: Re: AW: [Dime] unexpected consequence of deprecating E2E security= in RFC 3588 bis On 09/29/2012 05:08 PM, lionel.morand@orange.com wrote: > Hi Glen, > > I'm OK with the "MUST NOT... unless" approach that is stronger than > "SHOULD NOT... unless". The last part could be slightly modified as > follow: > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and > cryptographic keys. The Diameter messages containing such AVPs MUST > only be sent protected via mutually authenticated TLS or IPsec. In > addition, those messages MUST NOT be sent via intermediate nodes > unless there is end-to-end security between the originator and > recipient or the originator has locally trusted configuration that > indicates that end-to-end security is not needed. For example, > end-to-end security may not be required in the case where an > intermediary node is known to be operated as part of the same > administrative domain as the endpoints so that an ability to > successfully compromise the intermediary would imply a high > probability of being able to compromise the endpoints as well. Note > that no end-to-end security mechanism is specified in this document. > > The "may not be required" indicates that it is a design option and > the default rule is "E2E security is required for those AVPs". This is fine. I noticed that another important piece of data was lost=20 in the shuffle, as well: in RFC 3588, the AVPs considered to contain=20 security-sensitive data were marked as such in the AVP tables, but in=20 the revision they're not. This makes the MUST NOT above pretty close to=20 useless. I think that we probably need to list those AVPs in this=20 section, as well. > > Regards, > > Lionel > > -----Message d'origine----- De : Glen Zorn > [mailto:glenzorn@gmail.com] Envoy=E9 : jeudi 27 septembre 2012 13:04 =C0 > : dieter.jacobsohn@telekom.de Cc : glenzorn@gmail.com; MORAND Lionel > RD-CORE; dime@ietf.org; draft-ietf-dime-rfc3588bis@tools.ietf.org; > turners@ieca.com; stephen.farrell@cs.tcd.ie; > Stefan.Schroeder06@telekom.de Objet : Re: AW: [Dime] unexpected > consequence of deprecating E2E security in RFC 3588 bis > > On 09/27/2012 05:01 PM, dieter.jacobsohn@telekom.de wrote: >> >> Hello Glen After discussing it also with some security people I >> think that the existing text is more accurate and should stay. The >> existing text refers to "intermediary is known to be operated as >> part of the same administrative domain as the endpoints", which is >> fine. > > The current text assumes that exactly the same security measures are > applied to the endpoints and any intermediates. I think that this > assumption is basically groundless. > >> We don't have end-to-end security in 3588bis, true. But 13.3 >> offers exactly this party1-to-party2 security as almost equivalent >> to e2e security. > > AFAICT, it offers the assertion that "Our network is secure." and > basically nothing else. > >> >> The new proposed text would allow other alternatives beyond that, >> based on "locally trusted configuration". But what does that mean >> in practice? I think such a statement would allow just anything and >> move away from any tangible technical security. > > Unless bare assertions constitute technical security, it doesn't move > away from anything. Be that as it may, the current text says "In > addition, those messages SHOULD NOT be sent via intermediate nodes > that would expose the sensitive data at those nodes". As I > understand it, "SHOULD NOT" means "don't do it unless you have a good > reason to", but the definition of "good reason" is pretty much up in > the air. Is the simple assertion of security a "good reason"? > Sounds like it. By contrast, RFC 3588 says that messages containing > sensitive AVPs MUST NOT be sent through untrusted intermediaries; > that is the part I want to see remain. Admittedly, it's a small > thing, but it's something; I'm sure that people are going to do > whatever they like anyway, but at least they might stop and think a > bit more when they see a MUST. "Blindly trust every host in this > domain because I say so" could still be the policy, but it would need > to be configured as such (which I suspect is actually the issue > here). > >> >> Best Regards Dieter Jacobsohn >> >> >> Deutsche Telekom AG Group Technology Dieter Jacobsohn >> Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801 >> 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail: >> dieter.jacobsohn@telekom.de www.telekom.com >> >> Erleben, was verbindet. >> >> Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner >> (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Manfred >> Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus H=F6ttges, >> Claudia Nemat, Prof. Dr. Marion Schick Handelsregister: >> Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE >> 123475223 >> >> Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht >> jede E-Mail drucken. >> >> >> -----Urspr=FCngliche Nachricht----- Von: dime-bounces@ietf.org >> [mailto:dime-bounces@ietf.org] Im Auftrag von Glen Zorn Gesendet: >> Donnerstag, 27. September 2012 05:58 An: lionel.morand@orange.com >> Cc: draft-ietf-dime-rfc3588bis; dime mailing list; turners; >> Stephen Farrell Betreff: Re: [Dime] unexpected consequence of >> deprecating E2E security in RFC 3588 bis >> >> On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote: >> >> Copying the Security ADs. >> >>> Is it somehow covered in >>> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? > >>> > >>> >> >>> >>> >> Diameter AVPs often contain security-sensitive data; for example, >>> user passwords and location data, network addresses and >>> cryptographic keys. The Diameter messages containing such AVPs >>> MUST >>>> only be sent protected via mutually authenticated TLS or >>>> IPsec. >>> In > addition, those messages SHOULD NOT be sent via >>> intermediate nodes > that would expose the sensitive data at >>> those nodes except in cases > where an intermediary is known to >>> be operated as part of the same > administrative domain as the >>> endpoints so that an ability to > successfully compromise the >>> intermediary would imply a high > probability of being able to >>> compromise the endpoints as well. >>> >>> Do you think that it is needed to add somewhere that "the >>> originator > has locally trusted configuration that indicates >>> that end-to-end > security is not needed"? >> >> I think that something should be done since as it stands the >> language is weaker in bis than in RFC 3588; the protocol is >> actually less secure :-(. I would suggest changing Section 13.3 >> (quoted above) to say some thing like this: >> >> Diameter AVPs often contain security-sensitive data; for example, >> user passwords and location data, network addresses and >> cryptographic keys. The Diameter messages containing such AVPs >> MUST only be sent protected via mutually authenticated TLS or >> IPsec. In addition, those messages MUST NOT be sent via >> intermediate nodes unless there is end-to-end security between the >> originator and recipient or the originator has locally trusted >> configuration that indicates that end-to-end security is not needed >> (for example, where an intermediary is known to be operated as part >> of the same administrative domain as the endpoints so that an >> ability to successfully compromise the intermediary would imply a >> high probability of being able to compromise the endpoints as >> well). Note, however, that no end-to-end security mechanism is >> specified in this document. >> >> However, I don't really want to delay publication any more than I >> already have ;-), so if that change would trigger a whole new IESG >> review (or worse, another IETF LC) I would rather handle it in an >> erratum later. >> >>> >>> >>> Lionel >>> >>> >>> -----Message d'origine----- De : dime-bounces@ietf.org >>> [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoy=E9 : >>> mercredi 26 septembre 2012 12:47 =C0 : draft-ietf-dime-rfc3588bis >>> Cc : dime mailing list Objet : [Dime] unexpected consequence of >>> deprecating E2E security in RFC 3588 bis >>> >>> Section 4.5 of RFC 3588 says: The following table describes the >>> Diameter AVPs defined in the base protocol, their AVP Code >>> values, types, possible flag values and whether the AVP MAY be >>> encrypted. For the originator of a Diameter message, "Encr" >>> (Encryption) means that if a message containing that AVP is to be >>> sent via a Diameter agent (proxy, redirect or relay) then the >>> message MUST NOT be sent unless there is end-to-end security >>> between the originator and the recipient and integrity / >>> confidentiality protection is offered for this AVP OR the >>> originator has locally trusted configuration that indicates that >>> end-to-end security is not needed. Similarly, for the originator >>> of a Diameter message, a "P" in the "MAY" column means that if a >>> message containing that AVP is to be sent via a Diameter agent >>> (proxy, redirect or relay) then the message MUST NOT be sent >>> unless there is end-to-end security between the originator and >>> the recipient or the originator has locally trusted configuration >>> that indicates that end-to-end security is not needed. >>> >>> The corresponding section of 3588bis says: The following table >>> describes the Diameter AVPs defined in the base protocol, their >>> AVP Code values, types, and possible flag values. >>> >>> Considerable information (and normative guidance) seems to have >>> been lost here: in particular, the statements that "the message >>> MUST NOT be sent unless... the originator has locally trusted >>> configuration that indicates that end-to-end security is not >>> needed" would seem to be valid even in the absence of an E2E >>> security solution. >>> _______________________________________________ DiME mailing list >>> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime >>> >>> >> >=20 ___________________________________________________________________________= ______________________________________________ > > > >> >> >>> >>> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si >>> vous avez recu ce message par erreur, veuillez le signaler a >>> l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, France >>> Telecom - Orange decline toute responsabilite si ce message a >>> ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should >>> not be distributed, used or copied without authorisation. If you >>> have received this email in error, please notify the sender and >>> delete this message and its attachments. As emails may be >>> altered, France Telecom - Orange is not liable for messages that >>> have been modified, changed or falsified. Thank you. >>> >> >> >> _______________________________________________ DiME mailing list >> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime > > > >=20 ___________________________________________________________________________= ______________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations=20 confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler a l'expediteur > et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. If you have > received this email in error, please notify the sender and delete > this message and its attachments. As emails may be altered, France > Telecom - Orange is not liable for messages that have been modified, > changed or falsified. Thank you. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From glenzorn@gmail.com Sat Sep 29 05:33:37 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6402A21F848B for ; Sat, 29 Sep 2012 05:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaMzjPDNYBjO for ; Sat, 29 Sep 2012 05:33:36 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3521F8467 for ; Sat, 29 Sep 2012 05:33:36 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so6243010pbb.31 for ; Sat, 29 Sep 2012 05:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aQXoY77d+M2TTSoOvPtxUQQ7+CHiXt9cC2B9Fttk5YA=; b=iIKX9yFMH8xBNIkEYTrgegjh5FgTDpssSexhX3dsbnAfeCPLbgPLn+ZBXQcFyKhGBX CtBNZqR0INzr/awbtps7oxS/UBIlWh08ZH6NOMB1A5DAI/yyDWYxyKSa3Cwnlkt6K09x /Q2LqwsiI1v23w9LN/H3YWm2CFGy7zEWXTi0SFYGewq+tRmVacouK69ew9A5/QV3cKK8 vE/wJaZ3bED8zDeOmRsohVKboIM3wp02CxWnoEpK84UrEutGCsQvXclJP1T5BaGX/WA8 y3Mo4TGUqApK30PzSlUngupSv23bM9o9XOHb8tOCvn4McmZfJBhGcGDjkJl2nWBk5ucB X1rg== Received: by 10.68.209.136 with SMTP id mm8mr27527454pbc.146.1348922015465; Sat, 29 Sep 2012 05:33:35 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-121-208-251.revip2.asianet.co.th. [124.121.208.251]) by mx.google.com with ESMTPS id my10sm6976184pbc.11.2012.09.29.05.33.31 (version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 05:33:34 -0700 (PDT) Message-ID: <5066EA99.3020801@gmail.com> Date: Sat, 29 Sep 2012 19:33:29 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: lionel.morand@orange.com References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 12:33:37 -0000 On 09/29/2012 05:39 PM, lionel.morand@orange.com wrote: > It is actually needed if we don't want to lose info. These AVPs > should be listed in a table in these sections with an indication that > is a list of AVPs that can be considered as security-sensitive, in > order to not start a discussion on which AVP is really sensitive and > which not. Anyway, designers will have to decide what they want to do > and this list is mainly for information. > OK, this is what I've got now: 13.3. AVP Considerations Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The following AVPs defined in this document are considered to be security-sensitive: o Acct-Interim-Interval o Accounting-Realtime-Required o Acct-Multi-Session-Id o Accounting-Record-Number o Accounting-Record-Type o Accounting-Session-Id o Accounting-Sub-Session-Id o Class o Session-Id o Session-Binding o Session-Server-Failover o User-Name Diameter messages containing these AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. For example, end-to-end security may not be required in the case where an intermediary node is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Note that no end-to-end security mechanism is specified in this document. From lionel.morand@orange.com Sun Sep 30 04:15:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E111621F84DD for ; Sun, 30 Sep 2012 04:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCwVGwOVduxJ for ; Sun, 30 Sep 2012 04:15:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17921F84D8 for ; Sun, 30 Sep 2012 04:15:13 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9C51522C313; Sun, 30 Sep 2012 13:15:12 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7543E4C027; Sun, 30 Sep 2012 13:15:12 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sun, 30 Sep 2012 13:15:11 +0200 From: To: Glen Zorn Thread-Topic: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Thread-Index: AQHNnvzbNXtq6DSorEKrYoYEPqx3gQ== Date: Sun, 30 Sep 2012 11:15:11 +0000 Message-ID: <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> In-Reply-To: <5066EA99.3020801@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.30.80322 Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" , "stephen.farrell@cs.tcd.ie" Subject: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 11:15:15 -0000 Hi Glen, After the list of avps, we should say: "Diameter messages containing these AVPs and any other AVP considered as se= curity-sensitive MUST only be sent..." Regards, Lionel -----Message d'origine----- De : Glen Zorn Envoy=E9 : 29/09/2012, 14:33 =C0 : MORAND Lionel RD-CORE CC : Glen Zorn; dieter.jacobsohn@telekom.de; dime@ietf.org; draft-ietf-dime= -rfc3588bis@tools.ietf.org; turners@ieca.com; stephen.farrell@cs.tcd.ie; St= efan.Schroeder06@telekom.de Objet : Re: AW: [Dime] unexpected consequence of deprecating E2E security i= n RFC 3588 bis On 09/29/2012 05:39 PM, lionel.morand@orange.com wrote: > It is actually needed if we don't want to lose info. These AVPs > should be listed in a table in these sections with an indication that > is a list of AVPs that can be considered as security-sensitive, in > order to not start a discussion on which AVP is really sensitive and > which not. Anyway, designers will have to decide what they want to do > and this list is mainly for information. > OK, this is what I've got now: 13.3. AVP Considerations Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The following AVPs defined in this document are considered to be security-sensitive: o Acct-Interim-Interval o Accounting-Realtime-Required o Acct-Multi-Session-Id o Accounting-Record-Number o Accounting-Record-Type o Accounting-Session-Id o Accounting-Sub-Session-Id o Class o Session-Id o Session-Binding o Session-Server-Failover o User-Name Diameter messages containing these AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. For example, end-to-end security may not be required in the case where an intermediary node is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Note that no end-to-end security mechanism is specified in this document. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stephen.farrell@cs.tcd.ie Sun Sep 30 06:48:17 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F1621F84A6 for ; Sun, 30 Sep 2012 06:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx25zuP5UVjk for ; Sun, 30 Sep 2012 06:48:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A159621F847F for ; Sun, 30 Sep 2012 06:48:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 141311714A7; Sun, 30 Sep 2012 14:48:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349012895; bh=kE3L99iBfP4RbP HneYYXzan4mmkALBnNmBdLuvBghOM=; b=oO/juYs/r7oUyZYsZ9p2VPW5gQkKF8 aTc/s6BPeXCE3hC3IzZwyRPf7g7bN0BHZ5LNRpcnAypu+Dh7alcxPr3fToLM71ri z3ckc4pfA6fwFnPmX3Bwimdx+pn99/V/NhGV8lQgJDJIiM+4iqWZWtruSqu+IqfU zl6D9OJTH6flz+Mxgtm4Pm0LlxA999JAoRwMt/KdqZKlpOD1yeFYjjL9uMEwPxME 0s6KLwzOH1ugzy5gYbOogfha13qNha4Djvk7J+33rkVmXC81j2k096HLsGNG56uZ ohZNMFULetkAkB7UBUkUMjjFYnLmfaaLEer5SfxeBBwPeZSAco7LqX2Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1Hnvc5VZXeHz; Sun, 30 Sep 2012 14:48:15 +0100 (IST) Received: from [10.87.48.7] (unknown [86.41.14.47]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0D6241714A6; Sun, 30 Sep 2012 14:48:09 +0100 (IST) Message-ID: <50684D98.8010400@cs.tcd.ie> Date: Sun, 30 Sep 2012 14:48:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: lionel.morand@orange.com References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> In-Reply-To: <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" Subject: Re: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 13:48:17 -0000 Just checking I've got this right. The plan now is to say you MUST NOT send "e2e-sensitive" AVPs without e2e security and to have a list of currently known e2e-sensitive AVPs in 3588bis. If so, that seems like a good thing to me. Maybe consider an IANA registry listing the e2e-sensitive AVPs that could be updated via expert review for when the current list gets outdated? Could be done later if needed though, so just a suggestion. S. On 09/30/2012 12:15 PM, lionel.morand@orange.com wrote: > Hi Glen, > > After the list of avps, we should say: > > "Diameter messages containing these AVPs and any other AVP considered as security-sensitive MUST only be sent..." > > Regards, > > Lionel > -----Message d'origine----- > De : Glen Zorn > Envoy : 29/09/2012, 14:33 > : MORAND Lionel RD-CORE > CC : Glen Zorn; dieter.jacobsohn@telekom.de; dime@ietf.org; draft-ietf-dime-rfc3588bis@tools.ietf.org; turners@ieca.com; stephen.farrell@cs.tcd.ie; Stefan.Schroeder06@telekom.de > Objet : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis > > On 09/29/2012 05:39 PM, lionel.morand@orange.com wrote: > >> It is actually needed if we don't want to lose info. These AVPs > > should be listed in a table in these sections with an indication that > > is a list of AVPs that can be considered as security-sensitive, in > > order to not start a discussion on which AVP is really sensitive and > > which not. Anyway, designers will have to decide what they want to do > > and this list is mainly for information. > > > OK, this is what I've got now: > > 13.3. AVP Considerations > > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and cryptographic > keys. The following AVPs defined in this document are considered to > be security-sensitive: > > o Acct-Interim-Interval > > o Accounting-Realtime-Required > > o Acct-Multi-Session-Id > > o Accounting-Record-Number > > o Accounting-Record-Type > > o Accounting-Session-Id > > o Accounting-Sub-Session-Id > > o Class > > o Session-Id > > o Session-Binding > > o Session-Server-Failover > > o User-Name > > Diameter messages containing these AVPs MUST only be sent protected > via mutually authenticated TLS or IPsec. In addition, those messages > MUST NOT be sent via intermediate nodes unless there is end-to-end > security between the originator and recipient or the originator has > locally trusted configuration that indicates that end-to-end security > is not needed. For example, end-to-end security may not be required > in the case where an intermediary node is known to be operated as > part of the same administrative domain as the endpoints so that an > ability to successfully compromise the intermediary would imply a > high probability of being able to compromise the endpoints as well. > Note that no end-to-end security mechanism is specified in this > document. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From glenzorn@gmail.com Sun Sep 30 20:32:34 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8A021F8514 for ; Sun, 30 Sep 2012 20:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIQhnufNBMaD for ; Sun, 30 Sep 2012 20:32:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6255021F84F1 for ; Sun, 30 Sep 2012 20:32:34 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so7303342pbb.31 for ; Sun, 30 Sep 2012 20:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8yq6JHOcsgbt8elKu61wlhj/YIhHbDd9Mpy5aP0DHx0=; b=cHKeOzykiBzPjKE8UjCKv4flS8+mt4QMXQNZVCgZhAKKmQp7ykFvY4do/bF9WAptMD NSpvCVjCwo241x5lo2V8V+VrLUxO1baB/unpnaTYMX3VQECXRB/tRllbbpmozElAAhhe dtIwQuJw9WUZX+sj0LQgQqI1VS0yI+6TiHNRQnRxVyGkXVl5RKSYW6KLmcNOUeUC960J iaBysFXibGogDP3EUp3WA0+jnGJ2Sl6v1UYBPothCdF8DNPpb0pRcyaxYnB+CTJ7N63x nCz42aP1LHcjzC8z8HuYznO42UjxQk/vjkJp+DhPwGu4eUGnSCa60f6d0niTfEyTD60o wMEQ== Received: by 10.68.218.101 with SMTP id pf5mr37832102pbc.60.1349062354132; Sun, 30 Sep 2012 20:32:34 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-131-31.revip2.asianet.co.th. [124.120.131.31]) by mx.google.com with ESMTPS id s10sm9653899paz.11.2012.09.30.20.32.30 (version=SSLv3 cipher=OTHER); Sun, 30 Sep 2012 20:32:33 -0700 (PDT) Message-ID: <50690ECD.5090002@gmail.com> Date: Mon, 01 Oct 2012 10:32:29 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: lionel.morand@orange.com References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> In-Reply-To: <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 03:32:35 -0000 On 09/30/2012 06:15 PM, lionel.morand@orange.com wrote: > Hi Glen, > > After the list of avps, we should say: > > "Diameter messages containing these AVPs and any other AVP considered > as security-sensitive MUST only be sent..." OK. ... From glenzorn@gmail.com Sun Sep 30 20:34:35 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED32221F8467 for ; Sun, 30 Sep 2012 20:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1Qa1jvN4Sy1 for ; Sun, 30 Sep 2012 20:34:35 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1A721F8458 for ; Sun, 30 Sep 2012 20:34:35 -0700 (PDT) Received: by padfb11 with SMTP id fb11so3880613pad.31 for ; Sun, 30 Sep 2012 20:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rpVI+y4Pd3WDRLvC2U34VVWInSpMAAHBFQCWfGyxlvY=; b=HNOnF/7q6VRiRfUu2nuas8shN/q8UiuCrLh6Y4BEpEfiXHrEwfdwW2ugPlUegdLhA1 8ZN8bE/c6raoWQZLugxpl/yEtfk7gCaRjpvWHZ5EacGwe3vNXmp39JMlvWOqssCu+TZs sKvM93qtv7lxuEMd0aIrV2iCqHuWZQKgPaD6IuJBOkYvQ2xl2FeIVO2c6+j0BQ9Ph2BY K+z/be1fYlQ2IJONaxtAktQ9sasFtIxoErEaETfVXIsKEP3NcQqI+ocJIjVYpOfXW2GR 3blTK97U5+CDwHIJg0QWPcNuXxbsIfBe6lrVD9mO1y00YegptYFleuDwYwZ0ImwFBnxK bjTw== Received: by 10.68.242.9 with SMTP id wm9mr37657028pbc.62.1349062475269; Sun, 30 Sep 2012 20:34:35 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-131-31.revip2.asianet.co.th. [124.120.131.31]) by mx.google.com with ESMTPS id nz6sm9562939pbb.50.2012.09.30.20.34.32 (version=SSLv3 cipher=OTHER); Sun, 30 Sep 2012 20:34:34 -0700 (PDT) Message-ID: <50690F46.7020304@gmail.com> Date: Mon, 01 Oct 2012 10:34:30 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> <50684D98.8010400@cs.tcd.ie> In-Reply-To: <50684D98.8010400@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" , "Stefan.Schroeder06@telekom.de" , "dime@ietf.org" , "turners@ieca.com" Subject: Re: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 03:34:36 -0000 On 09/30/2012 08:48 PM, Stephen Farrell wrote: > > Just checking I've got this right. The plan now is to say you MUST > NOT send "e2e-sensitive" AVPs without e2e security Or explicit policy that says it's OK. > and to have a list > of currently known e2e-sensitive AVPs in 3588bis. Yup. > If so, that seems > like a good thing to me. OK, cool. > > Maybe consider an IANA registry listing the e2e-sensitive AVPs that > could be updated via expert review for when the current list gets > outdated? Could be done later if needed though, so just a > suggestion. I think later is better. ...