From nobody Thu May 3 16:10:32 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3C12DA42; Thu, 3 May 2018 16:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: dime@ietf.org, ietf@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152538902971.11660.12472378818274345823@ietfa.amsl.com> Date: Thu, 03 May 2018 16:10:29 -0700 Archived-At: Subject: [Dime] Genart last call review of draft-ietf-dime-rfc4006bis-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 23:10:30 -0000 Reviewer: Linda Dunbar Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dime-rfc4006bis-07 Reviewer: Linda Dunbar Review Date: 2018-05-03 IETF LC End Date: 2018-04-12 IESG Telechat date: 2018-05-24 Summary: The document is well written for the part describing how end-users/CC-client request services from Credit Control server. Is it mandatory to use the Section 4 provided mechanism for Rating Input to the Credit Control? Can the Credit Control get credit rating from offline process (manual, offline, etc)? Major issues: None Minor issues: Is Section 4 mechanism mandatory? Nits/editorial comments: Regards, Linda Dunbar From nobody Sun May 6 01:52:13 2018 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 EA96E126BFD for ; Sun, 6 May 2018 01:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBjabZ6XaqeE for ; Sun, 6 May 2018 01:52:09 -0700 (PDT) Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C679D124205 for ; Sun, 6 May 2018 01:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1525596728; bh=SY+cy1GKG5wTHsnl41QJ28QLMgLP6t0YljEbekO2/U0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=q6U/RnG6SMrwhpYm/YJf7Z0ZnNYs9vYJmuun43oX+wDjs0WQ0hHUv9BWTci/EWo29pWSbbLXF15WO2N/h4DsA/2oLhoIIw/Y3hqYlSkMnORhl0RvjjTcEvy0jOlwmStQaMvUlkOrxMr9eX+ro2zJvp6DI/0pia+iUNI0D7gwVXNtBgA9bM/AsaoQMU3oK92z71lBtqMJWPW9hFxLFEidfxWqJ/ophfvAziw3OQNq2aiWBpQMvYohXT8dy4iJoPtdL218vLI3qzuUNEW6cWmeNK1ZmtRSngpkxnNWUKezyh/70AA1fZAMOsmID3sXtVrnDqyTx6iwoMGl64dIlReaYQ== X-YMail-OSG: vhncX3EVM1nIZ4wXWi2t1M_ndH1DYKA2jc7Vh35h.chD0Oc7jeiPAHTMD3uaytH bVBuKYQrC5KL9u9s_hc22hEQkYF70S8kLVhfnTcEySbHBEmqnzSAz94AHGSZ1a.aEcw2UFb5FxEb mFi0qtvaTsbAxeXhzY3uzvRA24y8CFxRDVY.QLMSVbaynWwCNGCYncfRTXWf_j2wljgdGFE.Ok94 GJj_qSHdo_FYZG.OrwsoceNgjgJYaAvLljGPtI3mbWVdGMVYHWX28cWIwsz2JV7NkwmS3klbfl_Y 3oUWoUr0cTolSAyqnB.pGorOjc_GDfFj2q.XUVLDl55i7LYTOrJc7j2WtyRdxrr7nF.8OjO3x_62 2zmvDA_.OfgHdjc.Lc9WcT1eNjJSoTk6CptkiFnGmB574W78ejdFnUpUhPgDMZdCQmTWf6pamQWe sa8W3SElBHcEmshFpwLsDgXEfw8G78r94pAoKUi6FPMj5DSu7FYtsQJ4Tv256DDjLoiGPxDgeFC4 oBk5C2N3Vg9_hM57KAnNncCUjeY.I0WBmGITc35ve0RXuNYXUTY4ip_p65CUpQJwlneBrEOCSwqs sw5FH6AeI1ct_0Pim_vekrdQ2VbvqMGYPGrzAHcLaOHmSa016xQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sun, 6 May 2018 08:52:08 +0000 Date: Sun, 6 May 2018 08:42:04 +0000 (UTC) From: Yuval Lifshitz To: gen-art@ietf.org, Linda Dunbar Cc: dime@ietf.org, ietf@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org Message-ID: <1008915678.319348.1525596124850@mail.yahoo.com> In-Reply-To: <152538902971.11660.12472378818274345823@ietfa.amsl.com> References: <152538902971.11660.12472378818274345823@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_319347_1494035299.1525596124848" X-Mailer: WebService/1.1.11848 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Genart last call review of draft-ietf-dime-rfc4006bis-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 06 May 2018 08:52:11 -0000 ------=_Part_319347_1494035299.1525596124848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Section 4 does not use normative language that dictates the *only* source for rating would be the CC-client. As the act of rating is done on the CC-server it may take into account other factors (for e.g. may fetch the subscriber's tier from an external system and use it together with service ID coming from the CC-Client to do the rating). However, if the rating input comes entirely from a different source (e.g. consumption of offline UDRs) then we cannot say that the above spec is implemented, as the concepts of online-charging is pivotal to the protocol between the CC-Client and CC-Server. Yuval ------=_Part_319347_1494035299.1525596124848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Section 4 does not use normative language that dictates the *only* source for rating would be the CC-client. As the act of rating is done on the CC-server it may take into account other factors (for e.g. may fetch the subscriber's tier from an external system and use it together with service ID coming from the CC-Client to do the rating). However, if the rating input comes entirely from a different source (e.g. consumption of offline UDRs) then we cannot say that the above spec is implemented, as the concepts of online-charging is pivotal to the protocol between the CC-Client and CC-Server.

Yuval
------=_Part_319347_1494035299.1525596124848-- From nobody Tue May 15 22:31:26 2018 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 B2FD2128954; Tue, 15 May 2018 22:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFLBSl5zjPg5; Tue, 15 May 2018 22:31:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9741A124234; Tue, 15 May 2018 22:31:19 -0700 (PDT) Received: from [10.0.1.94] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4G5VIeS098513 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 May 2018 00:31:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.94] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_A0F71940-3FF5-45D2-B465-5E038B0A45A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <8FB01050-7B63-4A1B-B50A-974D0FA448C4@nostrum.com> Date: Wed, 16 May 2018 00:31:17 -0500 Cc: dime@ietf.org To: draft-ietf-dime-doic-rate-control.all@ietf.org X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [Dime] draft-ietf-dime-doic-rate-control-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 16 May 2018 05:31:25 -0000 --Apple-Mail=_A0F71940-3FF5-45D2-B465-5E038B0A45A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-dime-doic-rate-control-08. Thank you for doing the work on this. I think the document is on the = right track, but needs a little work before it will be ready for IETF = last call. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94 Substantive Comments: General: The document seems inconsistent about whether rate limits are only = reported during overload conditions, or in advance of overload = conditions. I=E2=80=99d like to see the need to allocate the rate limit across all = potential sources of traffic given some more emphasis. (Maybe a = sub-section of its own?) =C2=A71: - =E2=80=9C While this can effectively decrease the load handled by the server, it does not directly address cases where the rate of arrival of service requests increases quickly." I think it fails to address cases where the load changes rapidly in = either direction, right? At least, the following text seems to say that. =C2=A73: Does the need for future report types to consider the rate = algorithm have IANA implications? =C2=A75.1: The first paragraph indicates state should be kept for every = reacting node to which it sends an OLR. But the 5th paragraph can be = interpreted to say it sends an OLR to every reacting node with which it = has negotiated use of the rate algorithm. (see general comment). =C2=A75.4: The first paragraph seems to suggest the reacting node keeps = OCS for every server that has indicated support for the rate algorithm, = not just nodes that have sent OLRs. Is that the intent? =C2=A75.6, first paragraph: The MAY seems week here. I know and agree = that we don=E2=80=99t want to force a particular application. But = don=E2=80=99t we need to say that if an implementation uses a different = algorithm, it MUST have the same behavior as the algorithm in section 7? =C2=A77.2, third and 4th paragraphs: I don=E2=80=99t understand what = this is trying to say. Please elaborate. -6th paragraph: =E2=80=9C may receive requests at a rate below its = target maximum Diameter request rate while others above that target = rate. But the resulting request rate presented to the overloaded = reporting node will converge towards the target Diameter request = rate.=E2=80=9D Why do we expect traffic to converge to the rate limit? It seems like = that won't happen if some reporting nodes are not sending at full = capacity, unless work can be shifted from the high-rate sources to the = slow-rate ones. =C2=A77.3.1: paragraph starting with =E2=80=9C In situations where = reacting nodes are configured with some knowledge=E2=80=9D that requires knowledge of other traffic sources, not just knowledge of = the reporting node. The example code says to transmit a message if (Xp <=3D TAU). But the = text said the limit was =E2=80=9CT+TAU). =C2=A79: I think the security considerations need more thought. What are = the security considerations specific to the rate algorithm? If there = aren=E2=80=99t any, then please describe the rational behind that. But I = suspect there are, for example, can this be used for a DoS? Can it be = used to help _mitigate_ a DoS? Could one reacting node cause others to = be traffic starved? Editorial Comments: General: IDNits returns several issues. Some of those may be errors on = its part, but I=E2=80=99m pretty sure some of them are real. Please = resolve these. Requirements: There are instances of lower case =E2=80=9Cmust=E2=80=9D = and =E2=80=9Cshould=E2=80=9D. Please use the new boilerplate from RFC = 8174. =C2=A71 - =E2=80=9Cprotect the stability=E2=80=9D seems awkward. Maybe =E2=80=9Cen= sure the stability=E2=80=9D? - Also s/ =E2=80=9Csubjected with=E2=80=9D / =E2=80=9Csubjected to=E2=80=9D= . - Please cite the definitions for =E2=80=9Creporting node=E2=80=9D and = =E2=80=9Creacting node=E2=80=9D. I know they are defined later, but = these are somewhat non-intuitive concepts and people will likely stumble = over the terms when they are used before they are defined. - Please expand DOIC and SOC on first mention in the body. (Even if they = were expanded in the abstract.) =C2=A72: - Definitions of =E2=80=9CDiameter Node=E2=80=9D and =E2=80=9CDiameter = Endpoint=E2=80=9D: Please use proper citations rather than just = referring to the RFC in text. For example: =E2=80=9CDiameter Node: A = Diameter client, server, or agent. [RFC6733]=E2=80=9D =C2=A74, - first paragraph: =E2=80=94 =E2=80=9CThis extension defines=E2=80=9D: I think this should = say =E2=80=9CThis document defines=E2=80=A6=E2=80=9D =E2=80=94 Please consider active voice for the last sentence. - 2nd paragraph: The first sentence seems awkward. Consider something to = the effect of =E2=80=9CSince all nodes that support DOIC are required to = support the loss algorithm=E2=80=A6=E2=80=9D - 3rd paragraph: This paragraph seems to belong as part of the previous = paragraph. - 4th paragraph: =E2=80=9C AVP in the sent to the DOIC reacting = nodes=E2=80=9D: Missing word(s)? -5th paragraph: =E2=80=9CA reporting node MAY select=E2=80=A6=E2=80=9D : = Is that a new permission, or a statement of fact? =C2=A75.1, third paragraph: The text is not clear whether this means OCS = should be maintained per supported application, etc, or that it should = maintain state when the rate algorithm on a per supported application, = etc, basis. - 4th paragraph: s/overoload/overload =C2=A75.3: 2nd paragraph: This seems like a redundant restatement of the = first paragraph. - third paragraph: The first sentence is convoluted; can it be broken = into simpler sentences? =C2=A76.1.1, definition of " OLR_RATE_ALGORITHM=E2=80=9D: Two periods at = end of sentence. =C2=A77.1, 2nd paragraph: =E2=80=9C signal one another support for = rate-based overload control=E2=80=9D: This seems awkward; are there missing words? =C2=A77.2, last two paragraphs: The MUSTs do not seem necessary. 2119 = keywords should be used when there is some sort of choice or room for = error. You don=E2=80=99t need them to define the basic operation of the = protocol. =C2=A77.3.1: I found the text hard to follow. It would help to declare = all the identifiers and initialization up front, and to present things = in more of a stepwise fashion. - T is effectively a time interval, right? It would help to say that, = especially later when you subtract a different time interval from it. - paragraph 9: Should =E2=80=9Cadmit=E2=80=9D be =E2=80=9Cemit=E2=80=9D? - the example code has several mentions of SIP requests. =C2=A77.3.2: =E2=80=9C Request candidates for reduction, requests not = subject to reduction (except under extenuating circumstances when there = aren=E2=80=99t any messages in the first category that can be = reduced).=E2=80=9D: That seems like an awkward way to say that the = second category is the set of requests that is only subject to reduction = if there are no messages left in the first category. - =E2=80=9C This can be generalized to n priorities using n thresholds = for n>2 in the obvious way.=E2=80=9D: I suggest you refrain from calling = it =E2=80=9Cobvious". =C2=A77.3.3: Paragraph starting with =E2=80=9C Then (only) if the = arrival is admitted, increase the bucket by an amount=E2=80=A6=E2=80=9D: = I think you increase the bucket _count_, right? --Apple-Mail=_A0F71940-3FF5-45D2-B465-5E038B0A45A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlr7wiUACgkQgFZKbJXz 1A1q+g/+J5VnfdiaF4bB3b6nu5JGFjlH+xlwjWsSb7d/4qnRzjCPjpol2/wLOwrP f7ItizRanrvsXzIg+TxfIQOn5Bx3w6jD6PJ7hv1DWzXriKI68rRc0gYAX3+CT4Bs e/PWligvdir9G/8JcK7KjkYTWuX9hF7aNGM9EsCPx4jPrUyopeYaDaWWrHKsYCJi S+YEH1CuRbcOJm1nXLkWRPdqjJYyQNXOAwqaFpgwCgYZS3Jgz0lBD5cvtTGL7SxH 5ZAmaBJwwpgq8zbhj+BdcAGph+rtRQ2fEtq5EyVIDSWyPHSlepu0YovJuKDhwNSP GdrEinHVtxfqlmDcYcKEwdgIN2YLFgfQAD5mGGywGzkIDGcGMw4zvanFzVF1qwqj xedGvjJ+LzQp+dRlH6wdo4JwStdR5SLnFsuJuLBhw1pqv963qNoPWPrXHpcgBfCa lkTeRsmx8tyEIf9ANt7536ngtNDk8vmnId3Nz/6oPETq0XjcJOea1MMgtyx5vL9c U2WOva5FrMU3VkBQWyv0sjvEo565R6Vsi/fg7F1W7hgB+3f8BGCVRjdE1N0sq+8q FyNFouROvWmNZMMUlMsr4F4k584wGbGhXJypcl0So5xWcklxxvmcBq2bs+2bNaCE V2s2iVbUyROkU2I+yutpRy3T/kTzXehCLa1XJUsuh16BEgrAJNg= =vpku -----END PGP SIGNATURE----- --Apple-Mail=_A0F71940-3FF5-45D2-B465-5E038B0A45A7-- From nobody Fri May 18 19:19:09 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06512E895; Fri, 18 May 2018 19:19:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152669634805.27815.9377022900163946531@ietfa.amsl.com> Date: Fri, 18 May 2018 19:19:08 -0700 Archived-At: Subject: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 02:19:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF. Title : Diameter Credit-Control Application Authors : Lyle Bertz David Dolson Yuval Lifshitz Filename : draft-ietf-dime-rfc4006bis-08.txt Pages : 125 Date : 2018-05-18 Abstract: This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC4006, and it must be supported by all new Diameter Credit-Control Application implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-dime-rfc4006bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-rfc4006bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 21 15:41:42 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ECD127201; Mon, 21 May 2018 15:41:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2018 15:41:41 -0700 Archived-At: Subject: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 22:41:42 -0000 Adam Roach has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and other participants who helped with this revision of the credit-control application. Thanks in particular for the addition of an extensive privacy considerations section. I will note that I only reviewed the diffs between this document and RFC 4006. I have a handful of comments. --------------------------------------------------------------------------- General nit: This document uses the term "service specific" as a compound adjective in several places. As a compound adjective, this should be hyphenated (i.e., "service-specific"). --------------------------------------------------------------------------- §1.1: This document uses lowercase forms of RFC-2119-defined terms. Please update this section to use the boilerplate from RFC 8174. --------------------------------------------------------------------------- §5.1.2: > If independent credit-control of multiple services is used, the > Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- > Indication AVP SHOULD be present either in the Multiple-Services- > Credit-Control AVP(s) or at command level as single AVPs. The phrasing here is ambiguous -- it's not clear whether the requirement is: (Validity-Time and Final-Unit-Indication) or QoS-Final-Unit-Indication ... or ... Validity-Time and (Final-Unit-Indication or QoS-Final-Unit-Indication) I suspect it's the latter, in which case I suggest: If independent credit-control of multiple services is used, the Validity-Time AVP, and either the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP, SHOULD be present either in the Multiple-Services- Credit-Control AVP(s) or at command level as single AVPs. --------------------------------------------------------------------------- §5.2.1: The alignment of the "Diameter AAA Server" title on Figure 3 has changed from RFC 4006 in a way that looks worse. --------------------------------------------------------------------------- §5.6.2: > The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication or the QoS-Final- > Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- > Unit AVP. This has the same confusion as above regarding the application of logical combinations. The second half of the statement is of the form "A or B and C but not D," which is pretty ambiguous. It's also a little unclear whether the client receives a Credit-Control-Answer (with A or B and C but not D), or just a Credit-Control-Answer of any description, full stop. --------------------------------------------------------------------------- §8.19 > Note: The values reported in a Used-Service-Unit AVP does not > necessarily have a relation to the grant provided in a Granted- > Service-Unit AVP, e.g., the value in this AVP may exceed the value in > the grant. Nit: "...values reported in a Used-Service-Unit AVP do not..." ^^ (or "...value... does not...") --------------------------------------------------------------------------- §8.54: > The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. > The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is > formatted as described in [RFC3580]. Nit: remove "is" after "address". --------------------------------------------------------------------------- §8.65: > The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type > Address and defines the IPv4 or IPv6 address of the redirect server > with which the end user is to be connected when the account cannot > cover the service cost. This appears to be underspecified, unless I've missed some specification elsewhere regarding what the client is supposed to do with this IP address. While the other redirection methods (HTTP, SIP) have relatively clear means of contact (they indicate a protocol), the indication of only an IP address with neither protocol nor port doesn't seem to provide enough information for a client to act on. Please either flesh this out in this section, or point to another document that indicates how this IP address is to be used. --------------------------------------------------------------------------- §12: When new documents obsolete an RFC that originally registered values with IANA, I'm used to seeing that document also update the IANA registry so that the corresponding entries now point to the new document. You may consider text that instructs IANA to update the existing RFC-4006-registered values so that they point to this document instead of RFC 4006. --------------------------------------------------------------------------- Appendix B: As a general comment for all of the examples: I'm surprised that none of the examples have been updated to reflect the newly defined capabilities in this document. For example, all the examples in this appendix use Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, to show maximally flexible and compatible examples, I would expect that the examples would include both AVPs. This applies to all of the "Extension" AVPs as well. --------------------------------------------------------------------------- Appendix B.2: > control server. Therefore, in this example, it is assumed that the > SIP Proxy adds a Record-Route header in the initial SIP INVITE "...a Record-Route header field..." (A SIP header is everything before the first blank line; individual lines within a SIP header are called "header fields") From nobody Tue May 22 04:07:41 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 624A8126CD8; Tue, 22 May 2018 04:07:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 04:07:39 -0700 Archived-At: Subject: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 11:07:39 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 5.6.2 = I'm having a little trouble understanding the expected behavior described in Section 5.6.2 so wanted to see if I'm just confused or if there is something to be clarified. The text says: "In addition to the Redirect-Server AVP or Redirect-Server-Extension AVP, the credit-control server MAY include one or more Restriction- Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Restriction-Filter-Rule AVPs, Filter- Rule AVPs or Filter-Id AVPs. If enforcement actions other than allowing the packets (e.g., QoS), are indicated in the Filter-Rule AVPs or Filter-Id AVPs, they SHOULD be performed as well. In addition, if possible, to redirecting the user to the destination specified in the Redirect-Server AVP or Redirect-Server-Extension AVP." It seems like if the server sends a Redirect-Server AVP or Redirect-Server-Extension AVP without any of the other AVPs, then all the traffic is supposed to be redirected. But if a Restriction-Filter-Rule AVP, Filter-Rule AVP, or Filter-Id AVP is also included, then the non-matching traffic MUST be dropped, in which case how does the user get redirected? Is the last sentence (which is a sentence fragment, actually) supposed to address this somehow? And in the case of enforcement actions involving QoS, the text seems to say that packets matching the filter MUST be dropped AND have the QoS rules applied to them, so I don't understand how that works. = Section 15.1 = RFC 6733 lists a bunch of sensitive AVPs and then says this about them: "Diameter messages containing these or any other AVPs considered to be security-sensitive 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." It seems like the list of AVPs in Section 15.1 should have these same requirements applied to them explicitly. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 1 = (1) I know it's a term of art, but the term "next generation wireless networks" seems a bit out of place in two ways: (1) "wireless" seems more generic than what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considered "next generation" still? (2) "Diameter base protocol" should cite RFC 6733. = Section 5.1 = Assuming G-S-U stands for granted service unit, the acronym should be given upon first use here. = Section 8.52 = (1) Why do you need to specify the ability to send either the IMEISV or the IMEI? (2) "If the type of the equipment is one of the enumerated types of User-Equipment-Info-Type AVP, then the credit- control client SHOULD send the information in the User-Equipment-Info AVP, in addition to or instead of the User-Equipment-Info-Extension AVP." Why is this normative recommendation in support of backwards compatibility different from the one given for the Subscription-Id-Extension AVP in Sec. 8.58? = Section 15.1 = "Redirect-Server-Address AVP: the service-provider may embed personal information on the subscriber in the URL/I (e.g. to create a personalized message)." This seems like a bad idea that, if it's going to be mentioned, should be recommended against. From nobody Tue May 22 04:08:51 2018 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 AF47012EAE2; Tue, 22 May 2018 04:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=riNI3BTH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IZyYIbAT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlczbgY04ph1; Tue, 22 May 2018 04:08:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E95C126D73; Tue, 22 May 2018 04:08:48 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C266A21847; Tue, 22 May 2018 07:08:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 22 May 2018 07:08:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=pTo/xhj66m4bQVIVibpGDGsUzLvSW+0w3ksJS3xAZs0=; b=riNI3BTH 7OgmpK0Ny/ifuLRfWY/+uJRhn8q77+DAPiw5mhalV1nivzWbyYPj3Luv2WOCgYhb h9i7TPM+D6oucH7Wr4MJvg1ftXQEIIM/OHJ07E8G22AuiX6b7mPKR+bSlgXM/sux 2oZc6PWY1yZqfQOSSIaf7WOBPhHFpaF9q70BZkOJSh5k8r284Y34iEIp8uXGAWnW UoWy3C6BQJMAaxOHquNWW3nTI+0NiTYEZn+sPsT2Up+qs8i7yo3zDRMnFzPzQc09 HhAnb+MP96/hxu3tUKpUa4uAVLSIvgTxQh/6vW24z9hEjkJx6i+XSyLyb0A5rGpZ FQtmvb7JxWJY3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pTo/xhj66m4bQVIVibpGDGsUzLvSW +0w3ksJS3xAZs0=; b=IZyYIbAT+Os0a/c1yNJhKYmOXykH0amYPW3aobCCQEplt nO4whqhoVx43xCXkAj0dSZSGfcd7e2uVYC8xhIpKm2NfGxnK63fAb/yvzR6vRUar dn9orznw26ZQwe/juhnBLl/ufz35+A4/dVcnuGGJDArn26KLY1Fwly5E6CFlK4q/ cRgXzUuykFSLN5P7vsVsVJlVDRbestmlukBgUHB7xKv2M1Sm1jfO8jWK9ry94v90 vUh0WkDIvHZcdnkoFjkaYtHwkz/Z6Swut6TTptYK0m0m/iT2vEyAJmS6wusZOYeE wKSCBJcESBsVtcTLc342WY6RGSDitNbj6yAJ8vh7w== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from rtp-vpn2-1620.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F958E463E; Tue, 22 May 2018 07:08:47 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_01AAE2FC-4C12-4CB0-91C1-21FDE7479879" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <1008915678.319348.1525596124850@mail.yahoo.com> Date: Tue, 22 May 2018 07:08:46 -0400 Cc: IETF Gen-ART , Linda Dunbar , dime@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org Message-Id: References: <152538902971.11660.12472378818274345823@ietfa.amsl.com> <1008915678.319348.1525596124850@mail.yahoo.com> To: Yuval Lifshitz X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Dime] [Gen-art] Genart last call review of draft-ietf-dime-rfc4006bis-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 22 May 2018 11:08:51 -0000 --Apple-Mail=_01AAE2FC-4C12-4CB0-91C1-21FDE7479879 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Linda, thanks for your review. Yuval, thanks for your response. I have = entered a DISCUSS ballot to clarify a few things based on my own review. Alissa > On May 6, 2018, at 4:42 AM, Yuval Lifshitz wrote: >=20 > Section 4 does not use normative language that dictates the *only* = source for rating would be the CC-client. As the act of rating is done = on the CC-server it may take into account other factors (for e.g. may = fetch the subscriber's tier from an external system and use it together = with service ID coming from the CC-Client to do the rating). However, if = the rating input comes entirely from a different source (e.g. = consumption of offline UDRs) then we cannot say that the above spec is = implemented, as the concepts of online-charging is pivotal to the = protocol between the CC-Client and CC-Server. >=20 > Yuval > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_01AAE2FC-4C12-4CB0-91C1-21FDE7479879 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Linda, thanks for your review. Yuval, thanks = for your response. I have entered a DISCUSS ballot to clarify a few = things based on my own review.

Alissa

On = May 6, 2018, at 4:42 AM, Yuval Lifshitz <yuvalif@yahoo.com> = wrote:

Section 4 does not use normative language = that dictates the *only* source for rating would be the CC-client. As = the act of rating is done on the CC-server it may take into account = other factors (for e.g. may fetch the subscriber's tier from an external = system and use it together with service ID coming from the CC-Client to = do the rating). However, if the rating input comes entirely from a = different source (e.g. consumption of offline UDRs) then we cannot say = that the above spec is implemented, as the concepts of online-charging = is pivotal to the protocol between the CC-Client and = CC-Server.

Yuval
=20
___________________________= ____________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_01AAE2FC-4C12-4CB0-91C1-21FDE7479879-- From nobody Tue May 22 06:48:30 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE4127078; Tue, 22 May 2018 06:48:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 06:48:22 -0700 Archived-At: Subject: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 13:48:23 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Alissa's Discuss point about sensitive AVPs. I appear to have a different understanding of Section 5.6.2, though, with a different potential issue (but again, it's possible that I'm confused to how things work): With the redirection schemes covered in Section 5.6.2, it sounds like the user can be redirected (at the application protocol level, e.g., HTTP or SIP) to a top-up server to purchase more credits. I don't see a way described how user agents can distinguish between a Diameter-induced redirect and an attacker-induced redirect to a (potentially phishing) site that accepts payment information. To be clear, the scenario here is that a user is using a credit-controlled application session to talk to "arbitrary application servers", including potentially attacker-controllled HTTP/SIP/etc. servers; the attacker could introduce a redirect to a phishing page that asks for payment information, and the user would be led to believe that this was the normal flow for "my prepaid balance has been used up", and give their payment information to the phishing site. I think that either user agents need to give some indication that this DIAMETER-level redirect is different than an application-protocol-level redirect (e.g., http) or the Security Considerations need to mention the risk of acclimating users to arbitrary websites redirecting to sites asking for payment credentials, which may or may not be legitimate sites. Separately, in Section 8.68 (for QoS-Final-Unit-Indication): If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server-Extension AVP MUST be present. This MUST seems in conflict with the text in 8.64 (actually, is section 8.64 even internally inconsistent, too?) about "Redirect-Server AVP, in addition to or instead of the Redirect-Server-Extension AVP", in particular, the "instead of" portion. (The ABNF-based formal language spec in 8.68 does match up with the above MUST, though.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some additional significant but not necessarily DISCUSS-worthy comments, followed by more editorial- and nit-level things. In Section 1.3, "Advertising Application Support" uses the same Auth-Application-ID value as for RFC 4006; what are the interop consequences of this? Alissa already noted that the text about how to split (sub-)AVPs between the foo and foo-Extension AVPs is inconsistent among them -- e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD send [in the old one]", but Subscription-Id-Extension has separate text about "[i]f full backward compatibility with [RFC4006] is required" and slightly different behavior described. We should try to catch all instances of this sort of backwards compatibility and make them consistent. The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) might benefit from additional text about the expected contents. A lot of the time when we use a UTF8 container for names (whether domain names or other kinds), we specify what normalization form and canonicalization are performed, whether domain names are A-labels or U-labels, etc., as there's a lot of potential flexibility not all of which is good. In this case, since the communication is only between trusted actors, perhaps the additional restrictions are not needed, but I am curious if the topic was raised in the WG. Thank you for adding the Privacy Considerations and list of Privacy-Sensitive AVPs! Section 14 [...] The Diameter credit- control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS/TCP, DTLS/SCTP or IPsec is sufficient. I did not see any concrete guidance on what would suffice in other environments (with multiple hops between peers). Is this the realm of the mythical "end-to-end security mechanism" for Diameter that is much-desired? (The last paragraph does have guidance on what might *not* suffice, which is not exactly the same thing.) Even without any modification to the messages, an adversary can eavesdrop on transactions that contain privacy-sensitive information about the user. This ("an adversary can") makes it sounds as if there is no confidentiality protection anywhere in the system, but that's what TLS/DTLS/IPSec are supposed to provide. So maybe "an adversary that can eavesdrop on transactions can obtain privacy-sensitive information [...]" is better. (Editorial- and nit-level stuff follows.) Section 4 A flexible credit-control application specific failure handling is defined in which the home service provider can model the credit- control client behavior according to its own credit risk management policy. This sentence is hard to parse -- in "credit-control application specific" what does "specific" bind to? What is being modelled? Is anything being controlled (as opposed to modelled)? Section 4.1.1 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). [...] Why BER and not DER? The unnecessary flexibility in BER vs. DER has been known to tickle parser bugs and create security vulnerabilities. Section 4.1.2 [...] To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference. The specification of another cooperative standardization body (e.g., 3GPP, OMA, or 3GPP2) SHOULD be used. The RECOMMENDED and SHOULD seem slightly in conflict. Section 5.1.1 As noted elsewhere, 60 seconds per minute does not always hold; it seems that this text could be reworded to just talk about a "constant rate" or "constant level per fixed time period" or similar. Section 5.1.2 [...] timer (Section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are received, the state machine moves to OPEN state, and Tx is stopped. Transmission, or the Tx timer (is stopped)? Using a different title for Section 5.2.2 might make the parallel between it and Section 5.2.1 more clear. That is, perhaps something like "First Interrogation Included with Authorization Messages". Section 5.7 [...] It is RECOMMENDED that the client complement the credit- control failure procedures with backup accounting flow toward an accounting server. [...] Nit: it looks like there's a missing article here, maybe "a backup accounting flow" is better. The AAA transport profile [RFC3539] defines the application layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) defined in [RFC3539]. Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? Section 6.2 Should there be text indicating how the client indicates what service the balance check is being requested for? Section 8.54 Maybe give a section reference in RFC 3580 for how the formatting is done? Section 12 [...] Initially, such Expert discussions take place on the AAA WG mailing list. That list appears to be dead, suggesting that this text should be updated. (I also agree with Adam's comments about updating the IANA Considerations.) Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3? From nobody Tue May 22 16:22:55 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E4112751F; Tue, 22 May 2018 16:22:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org, joelja@bogus.com X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152703136733.27125.3038384457064090712.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 16:22:47 -0700 Archived-At: Subject: [Dime] Warren Kumari's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 23:22:47 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for Joel for his OpsDir review - I looked at the diffs between 4006 and this, and am balloting based on that. Helpful link for other ADs: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dime-rfc4006bis-08.txt&url2=https://tools.ietf.org/rfc/rfc4006.txt From nobody Tue May 22 19:21:53 2018 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 D59DB12D969; Tue, 22 May 2018 19:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bkYhfutC0bv; Tue, 22 May 2018 19:21:41 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAB9129C6D; Tue, 22 May 2018 19:21:41 -0700 (PDT) Received: from SN4PR0501CA0104.namprd05.prod.outlook.com (2603:10b6:803:42::21) by CY4PR05MB2983.namprd05.prod.outlook.com (2603:10b6:903:10::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.8; Wed, 23 May 2018 02:21:33 +0000 Received: from BN3NAM01FT030.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::200) by SN4PR0501CA0104.outlook.office365.com (2603:10b6:803:42::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.820.5 via Frontend Transport; Wed, 23 May 2018 02:21:32 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN3NAM01FT030.mail.protection.outlook.com (10.152.66.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.776.10 via Frontend Transport; Wed, 23 May 2018 02:21:32 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w4N2AdEK040531; Tue, 22 May 2018 21:21:32 -0500 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by plsapdm1.corp.sprint.com with ESMTP id 2j2hjxvx8y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 May 2018 21:21:32 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 22 May 2018 21:21:31 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1365.000; Tue, 22 May 2018 21:21:31 -0500 From: "Bertz, Lyle T [CTO]" To: Alissa Cooper , The IESG CC: "dime@ietf.org" , "dime-chairs@ietf.org" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) Thread-Index: AQHT8b0gV92dBty11EiaZD5n7O1P+6Q8gdpA Date: Wed, 23 May 2018 02:21:30 +0000 Message-ID: <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> References: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> In-Reply-To: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.36; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(39860400002)(396003)(2980300002)(438002)(13464003)(189003)(199004)(966005)(46406003)(50466002)(72206003)(7696005)(229853002)(2900100001)(102836004)(14454004)(106466001)(47776003)(356003)(108616005)(24736004)(76176011)(4326008)(81166006)(81156014)(8676002)(8746002)(8936002)(53546011)(6306002)(2906002)(486006)(336012)(54906003)(446003)(575784001)(86362001)(3846002)(23726003)(5250100002)(6116002)(476003)(126002)(97756001)(5660300001)(186003)(11346002)(110136005)(5890100001)(45080400002)(7736002)(305945005)(59450400001)(6246003)(478600001)(68736007)(53936002)(106002)(426003)(26005)(316002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2983; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT030; 1:AJPbOh3rSxKtPoZdCDoJItwdOVHgf3Uu8tVSjfhbeyw3oxSctRhfnJE2qFR1CdJtwjgIjIu6WVxYFyvf3I4Z+ft+m/FcWo2pGrWIbujp11QArrgwOVoIT/wDc6xcwONq X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:CY4PR05MB2983; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 3:NFLUe/aioB8rWyNbJCMmvuzQV3FQuHwgjS5facRFPE9kvCytE3KnfarMPAVyjvlm8WFf7YfGTs0oqz4cZGzDn1d6k0T5p57GfH4/CgBODqnZEJASZBXVI7GD4RUHyEnlarNnEdvPO55lZxeBs4rYx41+Vm6Du3KTD8Cjw5zuYgwzBfqPYCcFgJK/Cb8qZL9miHQeyBaPkBKVqywwtg3+uT5KvnqfJ9Q1V6xk8WTcds/fkwTuCI1xyywPummXemNl94kQHzMQU2IuQXB3/Y6jn5UWHrTYUmrAlRHlJiAC441/i1jsqcUlgLvfqWxf20tpkeyeuOMdvQswGeUsV8O6oJySTHADgDVk4c0GrdJ/Kq8=; 25:FCYmb6DrM6/3IsN+XXqdl6Lcil257KT/r94dpiZbiMcY2hoeCBAqBlzH5JjwERO4yIssjDHmtbvjXWs4YCfrWyjoh4sTHGPA4wZLPUU3gCMRc5/RNvtspqfDQXR1L0gnSiQK0v32QTNORYtxl/3tZWvD0I/nMpz4SJv0wDansIA7cFAu4bpPDewyr9SMeR8ZhV1HCZ9Z8zKumPohbiiegUBU011tyCZwYThAiFnjL220Zjn6jm9ur//bFEU3pOcBOPF7y7wZhulhrkQTNZFkKvJ/yP1Ap/TkB5QxEQXyNS8QlmzYU5ZYgqnG1yP1OxqTPsomANdr+01HNoxdDCrRQQ== X-MS-TrafficTypeDiagnostic: CY4PR05MB2983: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 31:2W/4hhQVRvYj5CXCv+03gn7oVQw2YaNHhqE0jiAT+Ak2NhIv9E/O9IqsKxmbSOiuqjUvhdCttML154U4dHIPV5ZSBvwobpZHYcYNuSMWZMWq4E6vEGug+XjUH+/0LLPwqVpNYHM4bQCy2MkG5VOMRWMPMcDJ8AKWe0H7eajP1bxPUGdvynIPUY4Ykrw7IViIz7ghvzgPMSKul40FHuC1IMbEiTheG7X22iap2GseW5Q=; 20:ORlcz0QLA5VZNlnfXvxxUsQQweohxZPvzh1JGM5jfff++RayO2D+iNV+JwEiB/PG+BzP7B/UewGdUCVLWE3rXgzRLLWrTxbsqz69s3EG1aqigkZNNNUS7Ff6PSgXIVtrMMMWG45Ur7dlKDSYmwh4I33jkz8Q1S5PrBAuYR2VQ8V7n1pLnt4FGUX4nlTmN4q6mYxThqqk4wMHiQaW3w1g0M4cS2+NtdfNw6+lA7NQHCI6hwLXuCVClsCdH4sesShVqNPud8gVzrFHA4TliIrMOaV8HgVMTKUtUH+S6onloFK7je3WU/QMVBPng61GaPdMkHhr8avDrP+opTcOq8UdwGN26FsCrmCFRcKbAlv0JfJobu5zLgnxqqtQyLTKAVOAGFWhZIiXc9hVAeDHC02PeiIPHXjp7GMLkZ/htiiKeb2OfDmORHkCfx+p3I77B9JmWXEp0LXIgADVyHIPzg54ntudX00pKHbINxSv7dK77QwoEvs3V6sVFHWmUUva1UDB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(189930954265078)(788757137089)(219752817060721); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93004095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY4PR05MB2983; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB2983; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 4:oWtwXeBvtz2SEUB5b4wp8t3OAK4HKafcueYcac0KCUdxgFJTAdm+WvTL85Fi9ku9crhGcrDpQolaa8H+TbEpIQ23+zaU/FhRKn86z7Wva2D93aSzqHNWEbGqXv8a7to7IsA05sQBHu7ng75Yd+0ktMIlxa29bM9579KaDDWeii6o1XE0pKbniuoQWiLEUY2XkKZpsahTBadw8JCHKaPxuosk8D01WcU8nUEFRjXOgSVF+K17la1A14XK/FjEseNMnQRBGAlC/hvK5R4ZEDqNTG+scxOS1wmfBJipwH3q41U49/enb2Drm4QGtA6fyXrdwsescF4RH+KzG9k1BiRYe3UEJd37PhunbJhtPEeouzZwuoUDTNNlYZkKsBnNeJHrJmq68Dj67KZD/E+03G0FVH58+qOwAH66DTNN0LA4JZBp0nF4EZrd/4xJxfwxoNVa X-Forefront-PRVS: 06818431B9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB2983; 23:5wcxeqQXby5iXIOOzjQS1/drJg0JqgI5N2uY/rJS5?= =?us-ascii?Q?Rl2lBCo1ejo/PAQm5ND7tAoJhSqB3oJGtC+ceANISDbcOyH1gnFomEx9CTS+?= =?us-ascii?Q?akUTcx6fq/tste2/JO88/GOAQ9++i1lnTUrSiKFQL799DfF5OwukUE61cDwE?= =?us-ascii?Q?tQ68NwO+kahJFiTGGRajll2cYkALKpUEDjHoS/+NGZYa99J0a9NjFypUUSs/?= =?us-ascii?Q?BslTinZMcaZ9F/QYOQaBkJmFO5O5TGx4HlYaiKseyxP/u5ANAusrs5e7dg+r?= =?us-ascii?Q?7pkJLzZggPwT9Pqq3PXYFwRuMI/DXLvJ6OsQAsWWQlWUOlUeZJSg7fBUaoq1?= =?us-ascii?Q?TK/94KJyuvYx3pW8QW4tIDV4AogLkujHrioHSlCCnZegKmsxv7XgZ73qxlIZ?= =?us-ascii?Q?ajHR63iNlHxO7ZMaI9k9XsV19UdojAA3++K1bCZ2qiXaAa9a89sOaY60Dc+p?= =?us-ascii?Q?hZAxyI7aebif8qNdDeJ3vfRNKAkoisLnrJdQ9bGLud3De2fPZrKHJIywH1LU?= =?us-ascii?Q?KwrxMVMYqqOFm+IFdmzWtp8f0eZ78yHxJvZHo1MnWkjtAyJPU45TwRBpHSFW?= =?us-ascii?Q?K3twPo9Hp76ra/j/VB2oiJA+vRDqUhi5q/24xLQSL/mnQOTArrjsbEUIzk85?= =?us-ascii?Q?FqbxciH+3FCAIWXGTbLcH17sO55VfLPV/yVEew0O7W7F8RsNpuH4k0Ge9HnV?= =?us-ascii?Q?fP7lzgXv9UIr6Whl5PkvHCwPVYVrrf0A1na43GoOuIir0uE4XV3OuZWMIwhU?= =?us-ascii?Q?9tM1AuW4/0DTCw1Cm2/Xfi3uusJPVONGdcPnTEd40dHOw4EP1vB6dC3TlieH?= =?us-ascii?Q?79A5bP1GAWXLSeOCuelDDgBcUUWc5bLODRADQjNqkoJ00M091WLDbqpwwjjc?= =?us-ascii?Q?BwZgeKTFPljs1IB5CwSwIT3i0RwQMTTIAm6SVzuPqP3/N/RvLxXLIjzIM184?= =?us-ascii?Q?10USXPG5+sMxDKOPjZ7h2ddZEvtpT31FfAgMV/ro1iflw8u/EDSsCLpEtyRu?= =?us-ascii?Q?gm++iRJj77vOuMDApxzV1SrunwK0o1kRZXN2cr0p/2pkt+pe571imfipvGQE?= =?us-ascii?Q?sv5MqEPDEICiaHAYc+RbmyA03SNT9tLPntjFGRb8MbrwheL5HNhC7x2iB5JL?= =?us-ascii?Q?Z87JYdhFk+gJTRzkEF/QxuIGxpmSL8xJwW8gbnJWSxi0MpcuOaFscPAfQt/i?= =?us-ascii?Q?2Zkcbx16oWbnoL5afb2LB8r9DidiBY+KdzYFzcw1bn66yZJhSRLpRFzSBHHy?= =?us-ascii?Q?SVKSfnKveZ56/uZlcZPlSX2ubS363h8gQHO09AkSE9e+n9BXYH5IXY1wwWTf?= =?us-ascii?Q?vez8t81UuMOoEYQsE5jOwnymeImP7z7DzUqJgx2rcqXmsgEqz/R2eTd/s4R3?= =?us-ascii?Q?6ugu7jhjN4XLKrN836YxVVwAsteZ9rbVkLqSt/dL20zU84ePTYTEr2X0Em+6?= =?us-ascii?Q?WXZp+a5DRIp+Kl6BEW4GbvGve4e/z8=3D?= X-Microsoft-Antispam-Message-Info: KxQZ0x14/xkUnvteQG24pIYVcm9ZvMwrMpwvwCOTrXd9k1NWwqa2j/MmQisuKAPu4nXfzXenCI9U4sbWoQsKiT+iNMc9dNIlTuL8CWxeh5qU61TRHrcGyGo1e8fZmkAc/65W/77V2/LPE6bvDEQwhO97M2ScprfhfFKIjgrd6AXO/2d5CRUbxdoz1ogjeNCu X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 6:ZYaPRUdthntZQa7CLff5KvgZVicWM1BRrmBEqH2CN8SOaPQNBskx8ilWDlO8g+ZQpAuBlFMQAyUCJp455SfZ8+B51FtenDdLDBEsu8jkRmJP3hWdK6P3b7zCF58jWfxPCLaFwSu1janUY/Krt4wevCZ8VJIW86wPKwOZb7bnd8l3D18DNW36DdctZ51N5oX7RRH6PTWsF0d6wvOpCuFAZGV4fWxOXsEt0Bx7eidjHVgODZHCK0hDu8Wv1T/tNG7MLD61sWfXPa+nnOeWs+t7e48kzyjPkKXpMVU9OAkwFi8IPT9IqZzh9uH95buTOyvGrtJHmxbW9JQr6V8KfroudDcLiioEaxc8sp/cmyb1PcWyLSBrV4NBJX5ul5kNko6qSMPJcD6vRpuJdQeehreyNAVETblvewM7bWKgLt14AYLG5+xLrkpxP7EleYeN5xhhEhOd+Wr7QqF6uRQdRtfRpw==; 5:6VovsSTOUNEBTzWNqH9nF/XFTy8N9AzXtPe9DsN16YeHiw3B5LfftuF55AjYw1GvSrKBho4YlftsOUWlb0H9WJyPjUCsbfqJFt9yqIhVJ+3QMhxfT4dGFbnTyvvAMjuIbQNaPnD5c99tEMqY7Bjl4KEYTIx5NQECYxVs6NnoqBo=; 24:+mKBt+K+cT9gj01491w3rhqAE3VZfDUo6u38C+PsPR45L4G7LaWNXZNUJ87s1t4k+cYWUCZEorV7HNXYzZWwVkG19cdhLW53/BHA0S3h+WI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 7:WyzdvNedNslyzSlzAX4HXVBGNoeTWCvhyN+eEoTIDhhubKqrxf6JvjFrV0b4s/91brksdPMt67cXTcZxUM0O6vXu4nBbAmi7wX2M3urH9dAiZV928f8QesvaCo8dvubiVQR1pG7Kq5FX6Ux3reN0uY658qmqK7ssFp7Zi+Tqq5vCYi1t7pKTGSqzW+tCOVw7ir9JFsZ4OPjPg+qSg+cZqjG4YI7qveg0H9+oOMTYld77cot5HW/8HdV14Mxj6jIA X-MS-Office365-Filtering-Correlation-Id: 07f593cd-24f1-44ad-0901-08d5c053e69f X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2018 02:21:32.5075 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 07f593cd-24f1-44ad-0901-08d5c053e69f X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2983 Archived-At: Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 02:21:45 -0000 Comments inline. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Tuesday, May 22, 2018 6:08 AM To: The IESG Cc: dime@ietf.org; dime-chairs@ietf.org; draft-ietf-dime-rfc4006bis@ietf.or= g Subject: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (= with DISCUSS and COMMENT) CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you recognize the sender and know the c= ontent is safe. Alissa Cooper has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: Discuss When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=3D02%7= C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0= acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=3DTSuSzLz5Ey2= TL45eg2TDQf%2BVQXBei6cxbVz5tU%2FtlRo%3D&reserved=3D0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatrac= ker.ietf.org%2Fdoc%2Fdraft-ietf-dime-rfc4006bis%2F&data=3D02%7C01%7Clyle.t.= bertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55= f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=3DrOjsjxdmG7IcUDzAuDhvkB9c= COopAv70yPHCckL%2B9SA%3D&reserved=3D0 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =3D Section 5.6.2 =3D I'm having a little trouble understanding the expected behavior described i= n Section 5.6.2 so wanted to see if I'm just confused or if there is someth= ing to be clarified. The text says: "In addition to the Redirect-Server AVP or Redirect-Server-Extension AVP, the credit-control server MAY include one or more Restriction- Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Restriction-Filter-Rule AVPs, Filter- Rule AVPs or Filter-Id AVPs. If enforcement actions other than allowing the packets (e.g., QoS), are indicated in the Filter-Rule AVPs or Filter-Id AVPs, they SHOULD be performed as well. In addition, if possible, to redirecting the user to the destination specified in the Redirect-Server AVP or Redirect-Server-Extension AVP." It seems like if the server sends a Redirect-Server AVP or Redirect-Server-= Extension AVP without any of the other AVPs, then all the traffic is suppos= ed to be redirected. But if a Restriction-Filter-Rule AVP, Filter-Rule AVP,= or Filter-Id AVP is also included, then the non-matching traffic MUST be d= ropped, in which case how does the user get redirected? Is the last sentenc= e (which is a sentence fragment, actually) supposed to address this somehow= ? And in the case of enforcement actions involving QoS, the text seems to s= ay that packets matching the filter MUST be dropped AND have the QoS rules = applied to them, so I don't understand how that works. > The statement "In such a case, the access device MUST drop all the packet= s not matching the IP filters specified in the Restriction-Filter-Rule AVPs= " and is redundant with the definition of Restriction-Filter-Rule. Filter-= Rule and the rule referred to by Filter-Id also contain the appropriate tra= ffic filter and actions. I would propose a simplification, replace all text= from "In such a case ..." with "In such a case, the access device MUST treat all packets according to the = Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules referred to b= y the Filter-Id AVP. This is in addition to, if possible, redirecting the = user to the destination specified in the Redirect-Server AVP or Redirect-Se= rver-Extension AVP." =3D Section 15.1 RFC 6733 lists a bunch of sensitive AVPs and then says this about them: "Diameter messages containing these or any other AVPs considered to be security-sensitive 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." It seems like the list of AVPs in Section 15.1 should have these same requi= rements applied to them explicitly. > 6733 is clear about what applies when declared as security sensitive but = the addition of the following may help. "As sensitive AVPs the Diameter message requirements specified in Section 1= 3.3 of RFC 6733 apply." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =3D Section 1 =3D (1) I know it's a term of art, but the term "next generation wireless netwo= rks" seems a bit out of place in two ways: (1) "wireless" seems more generic tha= n what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considere= d "next generation" still? > Fair point. We tend to use "wireless" though as opposed to "cellular". = Dropping 'next generation' makes sense. (2) "Diameter base protocol" should cite RFC 6733. > If the DISCUSS can be resolved and we have a next revision (I assume we w= ill) we can update this =3D Section 5.1 =3D Assuming G-S-U stands for granted service unit, the acronym should be given= upon first use here. > Can update in next revision along with the DISCUSS items =3D Section 8.52 =3D (1) Why do you need to specify the ability to send either the IMEISV or the= IMEI? > They are distinct structures and the latest generation of networks are s= tarting to use IMEISV (with no support for just the IMEI). However, the IM= EI value is identical. (2) "If the type of the equipment is one of the enumerated types of User-Equipment-Info-Type AVP, then the credit- control client SHOULD send the information in the User-Equipment-Info AVP, in addition to or instead of the User-Equipment-Info-Extension AVP." Why is this normative recommendation in support of backwards compatibility = different from the one given for the Subscription-Id-Extension AVP in Sec. = 8.58? > It was found that backwards compatibility issues were more prevalent with= User-Equipment-Info around the IMEISV and some implementations can deal wi= th IMEISV and IMEI. The language above is aggressive in recommending the "i= n addition to" in order to maximize compatibility. 8.58 is cleaner in term= s of its recommendation and production issues have not been seen on this AV= P so it seemed appropriate to limit the AVP values to one or the other and = not both as it is for User-Equipment-Info and User-Equipment-Info-Extension= . =3D Section 15.1 =3D "Redirect-Server-Address AVP: the service-provider may embed personal information on the subscriber in the URL/I (e.g. to create a personalized message)." This seems like a bad idea that, if it's going to be mentioned, should be r= ecommended against. > Makes sense. I would recommend add the sentence "However, this is not re= commended." _______________________________________________ DiME mailing list DiME@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40sprint.com= %7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%= 7C0%7C636625840688755751&sdata=3Dq3LE6zquhvAVJ%2B6rJzlqfep80r3JZrX5wgoASHwi= i%2BQ%3D&reserved=3D0 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Tue May 22 20:01:58 2018 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 D2E7A1200C1; Tue, 22 May 2018 20:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvuRRYRzES-V; Tue, 22 May 2018 20:01:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410651200FC; Tue, 22 May 2018 20:01:53 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4N31j8D079192 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 22 May 2018 22:01:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <48C95314-5F5D-4CFC-963B-36017BB364A1@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D8E64A43-73D0-4D29-8278-E6396205C918"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 22 May 2018 22:01:44 -0500 In-Reply-To: <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> Cc: Alissa Cooper , The IESG , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-rfc4006bis@ietf.org" To: "Bertz, Lyle T [CTO]" References: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 03:01:57 -0000 --Apple-Mail=_D8E64A43-73D0-4D29-8278-E6396205C918 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m having some trouble telling your comments from Alissa=E2=80=99= s. Somehow the quoting is reversed from normal convention, so it looks = like Alissa is quoting you. But I will try to figure it out :-) > On May 22, 2018, at 9:21 PM, Bertz, Lyle T [CTO] = wrote: >=20 > Comments inline. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Tuesday, May 22, 2018 6:08 AM > To: The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org; = draft-ietf-dime-rfc4006bis@ietf.org > Subject: [Dime] Alissa Cooper's Discuss on = draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) >=20 > CAUTION: This email originated from outside of the organization. Do = not click links or open attachments unless you recognize the sender and = know the content is safe. >=20 >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=3D02%7C01%7Clyle.t.b= ertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55= f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=3DTSuSzLz5Ey2TL45eg2TDQf%= 2BVQXBei6cxbVz5tU%2FtlRo%3D&reserved=3D0 > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-dime-rfc4006bis%2F&data=3D02%7C01%7Clyle.= t.bertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5= b55f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=3DrOjsjxdmG7IcUDzAuDhv= kB9cCOopAv70yPHCckL%2B9SA%3D&reserved=3D0 >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =3D Section 5.6.2 =3D >=20 > I'm having a little trouble understanding the expected behavior = described in Section 5.6.2 so wanted to see if I'm just confused or if = there is something to be clarified. The text says: >=20 > "In addition to the Redirect-Server AVP or Redirect-Server-Extension > AVP, the credit-control server MAY include one or more Restriction- > Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more > Filter-Id AVPs in the Credit-Control-Answer message to enable the > user to access other services (for example, zero-rated services). = In > such a case, the access device MUST drop all the packets not = matching > the IP filters specified in the Restriction-Filter-Rule AVPs, = Filter- > Rule AVPs or Filter-Id AVPs. If enforcement actions other than > allowing the packets (e.g., QoS), are indicated in the Filter-Rule > AVPs or Filter-Id AVPs, they SHOULD be performed as well. In > addition, if possible, to redirecting the user to the destination > specified in the Redirect-Server AVP or Redirect-Server-Extension > AVP." >=20 > It seems like if the server sends a Redirect-Server AVP or = Redirect-Server-Extension AVP without any of the other AVPs, then all = the traffic is supposed to be redirected. But if a = Restriction-Filter-Rule AVP, Filter-Rule AVP, or Filter-Id AVP is also = included, then the non-matching traffic MUST be dropped, in which case = how does the user get redirected? Is the last sentence (which is a = sentence fragment, actually) supposed to address this somehow? And in = the case of enforcement actions involving QoS, the text seems to say = that packets matching the filter MUST be dropped AND have the QoS rules = applied to them, so I don't understand how that works. >=20 >> The statement "In such a case, the access device MUST drop all the = packets not matching the IP filters specified in the = Restriction-Filter-Rule AVPs" and is redundant with the definition of = Restriction-Filter-Rule. Filter-Rule and the rule referred to by = Filter-Id also contain the appropriate traffic filter and actions. I = would propose a simplification, replace all text from "In such a case = ..." with >=20 > "In such a case, the access device MUST treat all packets according to = the Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules = referred to by the Filter-Id AVP. This is in addition to, if possible, = redirecting the user to the destination specified in the Redirect-Server = AVP or Redirect-Server-Extension AVP.=E2=80=9D I think Alissa=E2=80=99s point is to ask how redirection and filtering = interact when both are active. Does _remaining_ traffic gets redirected = after applying the filter? Note that some forms of redirection (e.g. = HTTP) may not work very well if only some traffic makes it. I also have to wonder if some of this behavior is really governed by = local policy at the NAS? >=20 > =3D Section 15.1 >=20 > RFC 6733 lists a bunch of sensitive AVPs and then says this about = them: >=20 > "Diameter messages containing these or any other AVPs considered to be > security-sensitive 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." >=20 > It seems like the list of AVPs in Section 15.1 should have these same = requirements applied to them explicitly. >=20 >> 6733 is clear about what applies when declared as security sensitive = but the addition of the following may help. >=20 > "As sensitive AVPs the Diameter message requirements specified in = Section 13.3 of RFC 6733 apply.=E2=80=9D I was going to say something similar; 6733 is the base protocol. This = draft inherits the normative rules by way of using Diameter. But it = doesn=E2=80=99t hurt to reinforce them more strongly descriptive = language. How about something to the effect of =E2=80=9D The = privacy-sensitive AVPs listed in this section must be sent across = non-trusted networks or Diameter agents without end-to-end = authentication and confidentiality protection, as described in [RFC6733] = section 13.3" >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 1 =3D >=20 > (1) I know it's a term of art, but the term "next generation wireless = networks" > seems a bit out of place in two ways: (1) "wireless" seems more = generic than what is implied (i.e., "cellular," I assume), and (2) is = Rel-13 considered "next generation" still? >=20 >> Fair point. We tend to use "wireless" though as opposed to = "cellular". Dropping 'next generation' makes sense. How about =E2=80=9Cmobile networks=E2=80=9D? >=20 > (2) "Diameter base protocol" should cite RFC 6733. >=20 >> If the DISCUSS can be resolved and we have a next revision (I assume = we will) we can update this Please assume there will be another revision :-) >=20 > =3D Section 5.1 =3D >=20 > Assuming G-S-U stands for granted service unit, the acronym should be = given upon first use here. >=20 >> Can update in next revision along with the DISCUSS items >=20 > =3D Section 8.52 =3D >=20 > (1) Why do you need to specify the ability to send either the IMEISV = or the IMEI? >=20 >> They are distinct structures and the latest generation of networks = are starting to use IMEISV (with no support for just the IMEI). = However, the IMEI value is identical. >=20 > (2) > "If the type of the equipment is one of the > enumerated types of User-Equipment-Info-Type AVP, then the credit- > control client SHOULD send the information in the = User-Equipment-Info > AVP, in addition to or instead of the User-Equipment-Info-Extension > AVP." >=20 > Why is this normative recommendation in support of backwards = compatibility different from the one given for the = Subscription-Id-Extension AVP in Sec. 8.58? >=20 >> It was found that backwards compatibility issues were more prevalent = with User-Equipment-Info around the IMEISV and some implementations can = deal with IMEISV and IMEI. The language above is aggressive in = recommending the "in addition to" in order to maximize compatibility. = 8.58 is cleaner in terms of its recommendation and production issues = have not been seen on this AVP so it seemed appropriate to limit the AVP = values to one or the other and not both as it is for User-Equipment-Info = and User-Equipment-Info-Extension. Assuming Alissa is okay with the explanations for both points, please = add some explanatory text to the section. >=20 > =3D Section 15.1 =3D >=20 > "Redirect-Server-Address AVP: the service-provider may embed > personal information on the subscriber in the URL/I (e.g. to > create a personalized message)." >=20 > This seems like a bad idea that, if it's going to be mentioned, should = be recommended against. >=20 >> Makes sense. I would recommend add the sentence "However, this is = not recommended.=E2=80=9D It=E2=80=99s also commonly done, isn=E2=80=99t it? I think the point is = to mention that the AVP is sensitive because people might do this, not = to offer permission. There=E2=80=99s already text recommending against = directly using personal information. Would it help to change =E2=80=9Cmay=E2= =80=9D to =E2=80=9Cmight=E2=80=9D? to avoid any semblance of = =E2=80=9Cpermission=E2=80=9D? Some of the other AVPs likely carried in the same message are going to = have personally identifiable information one way or another (i.e. = Subscription-ID). > _______________________________________________ > DiME mailing list > DiME@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40sprint.c= om%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7= C0%7C0%7C636625840688755751&sdata=3Dq3LE6zquhvAVJ%2B6rJzlqfep80r3JZrX5wgoA= SHwii%2BQ%3D&reserved=3D0 >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_D8E64A43-73D0-4D29-8278-E6396205C918 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsE2ZgACgkQgFZKbJXz 1A1FBA//R0hqfe54XQrnfxkNXo1OzzQ+MBrNCzmYoSLKz3fE/LKkRsL6/IQOORFT zeWdoLJvUSfue2zWtrI6po0XkKt0SUPzOd5erGJJ1thpkt2cMUjjMSBUYDb3HQ0w OXUwA2zCCDCqR1a0SHR4C4PjgsUwrPeJN/fwP0i5H/EeE0LEcTiY5KW/nQvv4GrC BtOKRgusgyhmujUk5TVEOD+guh4soKRA9R1OxyzEyMpTvj5bR5QWZTVIZ53vUqeQ xVAVMZRBVZpkGldd3h5foN9Tq61t4c+mKSqeLOjtI4bnHo/c1O7Y/uAYsOIFXcOc KMMvEGUie5SylHmZ+bDE6hPoHraoI1Lg+gHKkalQIehLHXOPNdHSU8P+9JY5wlDP gt2WUhHA+0KXaRoQEL2cFp8tRWzLwv8sNGM32KaZoZg18G9BYRrGlqPfPZCoSLhk OMm4vv9m1Kr2odvkGCsW1qKEdVvQRZCsGB6ioB7eUtZ++yR/Z8mbpx7JcSQOh0WE JN6DFYaCkm8gNv81wyI8soXlw2GPfDnMOGLcZHGmoCOYrDMPaP2wV2+VM/IDZVIf wrvx1K2PzvUCH+ON9hjH07k66wVAo1DdGD0qjFK0IuWagTBJsykgqypTfj+eQ44P 9bdgI5/iM/qHhfYrdmQnuWkKBmBFhzIk4uFJXnH+GCAxteClHiE= =4OQj -----END PGP SIGNATURE----- --Apple-Mail=_D8E64A43-73D0-4D29-8278-E6396205C918-- From nobody Tue May 22 20:32:45 2018 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 05FCE12DA02; Tue, 22 May 2018 20:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUbMd4Fc9mG4; Tue, 22 May 2018 20:32:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40EF120713; Tue, 22 May 2018 20:32:35 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4N3WYbP084056 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 22 May 2018 22:32:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9BC0923D-A3F8-4FC6-9B00-2BE862A0243D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 22 May 2018 22:32:32 -0500 In-Reply-To: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> Cc: The IESG , dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org To: Benjamin Kaduk References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 03:32:38 -0000 --Apple-Mail=_9BC0923D-A3F8-4FC6-9B00-2BE862A0243D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benjamin, I=E2=80=99ve cherry-picked a few points, inline: Thanks! Ben. > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Alissa's Discuss point about sensitive AVPs. >=20 > I appear to have a different understanding of Section 5.6.2, though, > with a different potential issue (but again, it's possible that I'm > confused to how things work): >=20 > With the redirection schemes covered in Section 5.6.2, it sounds > like the user can be redirected (at the application protocol level, > e.g., HTTP or SIP) to a top-up server to purchase more credits. I > don't see a way described how user agents can distinguish between a > Diameter-induced redirect and an attacker-induced redirect to a > (potentially phishing) site that accepts payment information. To be > clear, the scenario here is that a user is using a credit-controlled > application session to talk to "arbitrary application servers", > including potentially attacker-controllled HTTP/SIP/etc. servers; > the attacker could introduce a redirect to a phishing page that asks > for payment information, and the user would be led to believe that > this was the normal flow for "my prepaid balance has been used up", > and give their payment information to the phishing site. I think > that either user agents need to give some indication that this > DIAMETER-level redirect is different than an > application-protocol-level redirect (e.g., http) or the Security > Considerations need to mention the risk of acclimating users to > arbitrary websites redirecting to sites asking for payment > credentials, which may or may not be legitimate sites. >=20 I think it=E2=80=99s reasonable to mention the concern in the security = considerations. But I don=E2=80=99t see how a redirection based on this = specification is any different than any other time an HTTP browser or = SIP UA connects to a resource based on an arbitrary URL. But to put some more context around this, the Diameter client is = typically a Network Access Server (NAS) that the end user is using for = network access. The user is already at the mercy of that NAS, and that = NAS is at the mercy of the credit-control application server. The = user=E2=80=99s trust in that NAS seems to have the same issues whether = or not this Diameter application is used. > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): >=20 > If the Final-Unit-Action AVP is set to REDIRECT at least the > Redirect-Server-Extension AVP MUST be present. >=20 > This MUST seems in conflict with the text in 8.64 (actually, is > section 8.64 even internally inconsistent, too?) about > "Redirect-Server AVP, in addition to or instead of the > Redirect-Server-Extension AVP", in particular, the "instead of" > portion. (The ABNF-based formal language spec in 8.68 does match up > with the above MUST, though.) Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64 to = just =E2=80=9Cin addition to=E2=80=9D help? Authors: Please comment if that works, given the backwards-compatibility = concern. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Some additional significant but not necessarily DISCUSS-worthy > comments, followed by more editorial- and nit-level things. >=20 > In Section 1.3, "Advertising Application Support" uses the same > Auth-Application-ID value as for RFC 4006; what are the interop > consequences of this? >=20 > Alissa already noted that the text about how to split (sub-)AVPs > between the foo and foo-Extension AVPs is inconsistent among them -- > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > send [in the old one]", but Subscription-Id-Extension has separate > text about "[i]f full backward compatibility with [RFC4006] is > required" and slightly different behavior described. We should try > to catch all instances of this sort of backwards compatibility and > make them consistent. I agree. >=20 > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > might benefit from additional text about the expected contents. A > lot of the time when we use a UTF8 container for names (whether > domain names or other kinds), we specify what normalization form and > canonicalization are performed, whether domain names are A-labels or > U-labels, etc., as there's a lot of potential flexibility not all of > which is good. In this case, since the communication is only > between trusted actors, perhaps the additional restrictions are not > needed, but I am curious if the topic was raised in the WG. On reflection, shouldn=E2=80=99t that be based on whatever rules already = exist for the URL scheme? And if some scheme doesn=E2=80=99t have well = defined behavior for non-ascii labels, is that the concern of this = application? >=20 > Thank you for adding the Privacy Considerations and list of > Privacy-Sensitive AVPs! >=20 > Section 14 >=20 > [...] The Diameter credit- > control application is often used within one domain, and there may = be > a single hop between the peers. In these environments, the use of > TLS/TCP, DTLS/SCTP or IPsec is sufficient. >=20 > I did not see any concrete guidance on what would suffice in other > environments (with multiple hops between peers). Is this the realm > of the mythical "end-to-end security mechanism" for Diameter that is > much-desired? (The last paragraph does have guidance on what might > *not* suffice, which is not exactly the same thing.) >=20 Sort of, but in real world deployments the =E2=80=9Coften used within = one domain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D,= which should be clarified) effectively overrides everything else. That = is far from ideal, but it=E2=80=99s the reality. So it basically comes = down to keep everything in the trust domain, or if you cross a = non-trusted network then use TLS or IPSec. There=E2=80=99s no solution to safely traverse a non-trusted Diameter = agent. The mythical e2e mechanism could conceivably give us that. = (someday, along with world peace and a post-scarcity economy). > Even without any modification to the messages, an adversary can > eavesdrop on transactions that contain privacy-sensitive information > about the user. >=20 > This ("an adversary can") makes it sounds as if there is no > confidentiality protection anywhere in the system, but that's what > TLS/DTLS/IPSec are supposed to provide. So maybe "an adversary that > can eavesdrop on transactions can obtain privacy-sensitive > information [...]" is better. >=20 Good point, I agree your suggestion is better. > (Editorial- and nit-level stuff follows.) >=20 > Section 4 >=20 > A flexible credit-control application specific failure handling is > defined in which the home service provider can model the credit- > control client behavior according to its own credit risk management > policy. >=20 > This sentence is hard to parse -- in "credit-control application > specific" what does "specific" bind to? What is being modelled? Is > anything being controlled (as opposed to modelled)? >=20 > Section 4.1.1 >=20 > 2. The Service-Parameter-Info AVP MAY be used as a container to = pass > legacy rating information in its original encoded form (e.g., ASN.1 > BER). [...] >=20 > Why BER and not DER? The unnecessary flexibility in BER vs. DER has > been known to tickle parser bugs and create security > vulnerabilities. >=20 > Section 4.1.2 >=20 > [...] To > facilitate interoperability, it is RECOMMENDED that the rating input > and the values of the Service-Context-Id be coordinated via an > informational RFC or other permanent and readily available = reference. > The specification of another cooperative standardization body (e.g., > 3GPP, OMA, or 3GPP2) SHOULD be used. >=20 > The RECOMMENDED and SHOULD seem slightly in conflict. >=20 > Section 5.1.1 >=20 > As noted elsewhere, 60 seconds per minute does not always hold; it > seems that this text could be reworded to just talk about a > "constant rate" or "constant level per fixed time period" or > similar. >=20 > Section 5.1.2 >=20 > [...] > timer (Section 13) every time a CCR message with the value > UPDATE_REQUEST is sent while they are in PendingU state. When > answers to all pending messages are received, the state machine = moves > to OPEN state, and Tx is stopped. >=20 > Transmission, or the Tx timer (is stopped)? >=20 > Using a different title for Section 5.2.2 might make the parallel > between it and Section 5.2.1 more clear. That is, perhaps something > like "First Interrogation Included with Authorization Messages". >=20 > Section 5.7 >=20 > [...] It is RECOMMENDED that the client complement the credit- > control failure procedures with backup accounting flow toward an > accounting server. [...] >=20 > Nit: it looks like there's a missing article here, maybe "a backup > accounting flow" is better. >=20 > The AAA transport profile [RFC3539] defines the application layer > watchdog algorithm that enables failover from a peer that has failed > and is controlled by a watchdog timer (Tw) defined in [RFC3539]. >=20 > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? >=20 > Section 6.2 >=20 > Should there be text indicating how the client indicates what > service the balance check is being requested for? >=20 > Section 8.54 >=20 > Maybe give a section reference in RFC 3580 for how the formatting is > done? >=20 > Section 12 >=20 > [...] Initially, such Expert discussions take place on the AAA > WG mailing list. >=20 > That list appears to be dead, suggesting that this text should be > updated. (I also agree with Adam's comments about updating the IANA = Considerations.) >=20 > Why is the disclaimer in Section B.4 (and other examples) not needed = in Section B.3? >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_9BC0923D-A3F8-4FC6-9B00-2BE862A0243D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsE4NAACgkQgFZKbJXz 1A3x5RAAg2YEMeeUakvpUV6DpaU/Fx29sDjmprgjC7NlQaaJeWyz3KDOB9sKJwK3 2WswBEMR/tq2UgxqAonuKHzrFj+NAnj5Gifw5tdfOdvbfrpC6V1L9nF9ZSXmOnSe OZiF+zT9wEULvu6juVH22rPaWsFQGKS1Ah+pt8YxKICe0bvIWdO5JsqNhGgFZXpI NxIIpaJp7HKGFS6ZgNtg7NBN0emgUXyK1fZFvEnqK5kWzl632XZpLWC39bWOFbpq 53KnzHOG54PRKjxwZ/WITI0THUSsHwPYOooeQgBxsbwEuWkpK69aDVCnFjadxD30 mp99BwwNgDgOzCpoK3n/yMshEGhrXHo4G4iFBxsCf08Lrggex7Ttb6kfwiQ+V0Lx /hWVtAKqFZF1YrbWpHwXq6zq7Fq9Z1+tzkyAwBaLijPaQKAjqZMAwOciO5BxCa0I nz+UFR6CKnp+Pg/HBKUVGjYkVWXbcTJiI/I9hEMlq7dIPkPNY9OfRv29wfEM3zdv xv2ZXqL8X1VuytZVG3Q6Pq0Wq9MP/C7MWxP/J94DMqCi9CtYUC/i+EZSzpwVvJTX MYtRfOwl8AuCnObbVf0Zh3V+gujkdpw8FrWbwVCB6Vpq2/WO0t8S9VafyLvCb4CO nrsMbX+Gw2fs70PrHZ1Y6I6S/aw0MqWvTLcPV7jUo/+Ksn9AMbE= =KwVc -----END PGP SIGNATURE----- --Apple-Mail=_9BC0923D-A3F8-4FC6-9B00-2BE862A0243D-- From nobody Wed May 23 01:32:07 2018 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 ECFBE126BF0 for ; Wed, 23 May 2018 01:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJhglwOy7v0X for ; Wed, 23 May 2018 01:31:57 -0700 (PDT) Received: from sonic309-20.consmr.mail.ne1.yahoo.com (sonic309-20.consmr.mail.ne1.yahoo.com [66.163.184.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCA912DA07 for ; Wed, 23 May 2018 01:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527064316; bh=gUH7239eT3dWfvXyk4RShY/GcwWM+6CMoDVXRRy6Aso=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=r/C7Sb6j6oE933xIj5kZs8Ec93q6Rr9X8CkBOjWAzo5Qr+cKXLIpH/5VP/bfddqUg8Oao5E5qNTjquSWq/BCE6cCN7Ek63Ti0sloR+zi2+c5qCH+W8Qi0GZu+cNZZzqSOgEmoWuiVqro3ckQNZRwSQKC30ofwrPwhbIBB1mqzYOQojPHHHQX4Ylj2S9sxVOKW/in3TNA5ZOR11oI6mBLUgULrQIdJpAvAXq43Y2eZqxxeItartrk940zhV1Po3si/TZZjneK0PvFYLE3+EsMQlmEJU3D2BueScee5oUtI57R0K+L33oQTxdHSVNuaXb6vbYtLEg/lpJT9vLdLHwdGw== X-YMail-OSG: j6E7M9kVM1nF3Z1Ue2qfzwpL7uJaBwI3s_tqREG1k9FgAZ0WK0uNbSZX346kJvn zUm0xiAQATJ4GvJYsODIQ8COxgSxQftm9n3L6NbkDXbVBjiTcokleSp6PzgwQtbswLHL9Uehx893 bM3_0UzgjnK1GL6_Qu02bx3SCS5bXERXgXjmaVIkYIURDhvuBtHAYzsYDDGzlrm.n93sukm9mcgQ Wk9EbTBa8E5j4BagR1v1HrFWbw0QaxVGG5MCOI9ddu4TorfsMKUbVvvcG2O9Pj21Ag0o_t8By9kt 7fyosmIyvJukb2beooKNkD_CPpkgL90wkPcP4W1I7XJm_9VSLt3VDeBTW5HbMlodVTtIqmiS32gJ DVS2jiTZQTBSeb7cLgEqGyhfUvtoGjYXNLhZOH_SHlImktKPfyKSglwxMjcvXlhYse5VlnVJMCUV BfiLpc58UmhG7DXb1vqCLCUvcaXe2hHyky9VicibGD4mXemCl_3fEJZySsjUQttaWZP9BY2GhPW_ IYABZOXTzRyvzRXUP6EbN42xekUgL1H7b3CGZinsAbk33GSi_isSDksO7J6rJzkjsoNlb6lLtdKU j6ZUF2068yTajt7Dh9cjox2zDNA8B57r2lLXLWMgFsFPu1In_L6ArpzNWVl3apmCVNR1lu4AQTkq QgOsrMIE0OJp3YohmvtEfdlsqRe5xaDdZtdzp4Lo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Wed, 23 May 2018 08:31:56 +0000 Date: Wed, 23 May 2018 08:31:51 +0000 (UTC) From: Yuval Lifshitz To: Benjamin Kaduk , Ben Campbell Cc: dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <380581659.4450262.1527064311638@mail.yahoo.com> In-Reply-To: <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4450261_1723727983.1527064311623" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 08:32:00 -0000 ------=_Part_4450261_1723727983.1527064311623 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Ben and Benjamin! Comments inline On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell wrote: =20 =20 Hi Benjamin, I=E2=80=99ve cherry-picked a few points, inline: Thanks! Ben. > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Alissa's Discuss point about sensitive AVPs. >=20 > I appear to have a different understanding of Section 5.6.2, though, > with a different potential issue (but again, it's possible that I'm > confused to how things work): >=20 > With the redirection schemes covered in Section 5.6.2, it sounds > like the user can be redirected (at the application protocol level, > e.g., HTTP or SIP) to a top-up server to purchase more credits.=C2=A0 I > don't see a way described how user agents can distinguish between a > Diameter-induced redirect and an attacker-induced redirect to a > (potentially phishing) site that accepts payment information.=C2=A0 To be > clear, the scenario here is that a user is using a credit-controlled > application session to talk to "arbitrary application servers", > including potentially attacker-controllled HTTP/SIP/etc. servers; > the attacker could introduce a redirect to a phishing page that asks > for payment information, and the user would be led to believe that > this was the normal flow for "my prepaid balance has been used up", > and give their payment information to the phishing site. I think > that either user agents need to give some indication that this > DIAMETER-level redirect is different than an > application-protocol-level redirect (e.g., http) or the Security > Considerations need to mention the risk of acclimating users to > arbitrary websites redirecting to sites asking for payment > credentials, which may or may not be legitimate sites. >=20 I think it=E2=80=99s reasonable to mention the concern in the security cons= iderations. But I don=E2=80=99t see how a redirection based on this specifi= cation is any different than any other time an HTTP browser or SIP UA conne= cts to a resource based on an arbitrary URL. But to put some more context around this, the Diameter client is typically = a Network Access Server (NAS) that the end user is using for network access= . The user is already at the mercy of that NAS, and that NAS is at the merc= y of the credit-control application server. The user=E2=80=99s trust in tha= t NAS seems to have the same issues whether or not this Diameter applicatio= n is used. [yuval] agree with Ben, if someone bad took control over the NAS, they can = do much worse > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): >=20 >=C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the >=C2=A0 Redirect-Server-Extension AVP MUST be present. >=20 > This MUST seems in conflict with the text in 8.64 (actually, is > section 8.64 even internally inconsistent, too?) about > "Redirect-Server AVP, in addition to or instead of the > Redirect-Server-Extension AVP", in particular, the "instead of" > portion.=C2=A0 (The ABNF-based formal language spec in 8.68 does match up > with the above MUST, though.) Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64 to ju= st =E2=80=9Cin addition to=E2=80=9D help? Authors: Please comment if that works, given the backwards-compatibility co= ncern. [yuval] the cumbersome text is because of backward compatibility issue. Wou= ld appriciate suggestion for better phrasing. The idea is the following:* W= e have an existing AVP that can carry some information* We need more inform= ation, but we cannot modify the existing one, so we added a new AVP (which,= unlike the old one, is future proof)* If you have a peer that does not sup= port the new spec, but only need the old info, you can use the old AVP. wha= t makes the spec backward compatible to the old one* If you have need to se= nd the new info, you have to use the new AVP, but in this case an older pee= r does not make sense >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Some additional significant but not necessarily DISCUSS-worthy > comments, followed by more editorial- and nit-level things. >=20 > In Section 1.3, "Advertising Application Support" uses the same > Auth-Application-ID value as for RFC 4006; what are the interop > consequences of this? >=C2=A0[yuval] this was done to make interops easier - this is why we kept = this RFC backward compatible with RFC4006 > Alissa already noted that the text about how to split (sub-)AVPs > between the foo and foo-Extension AVPs is inconsistent among them -- > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > send [in the old one]", but Subscription-Id-Extension has separate > text about "[i]f full backward compatibility with [RFC4006] is > required" and slightly different behavior described.=C2=A0 We should try > to catch all instances of this sort of backwards compatibility and > make them consistent. I agree. [yuval] will look to unify the text >=20 > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > might benefit from additional text about the expected contents.=C2=A0 A > lot of the time when we use a UTF8 container for names (whether > domain names or other kinds), we specify what normalization form and > canonicalization are performed, whether domain names are A-labels or > U-labels, etc., as there's a lot of potential flexibility not all of > which is good.=C2=A0 In this case, since the communication is only > between trusted actors, perhaps the additional restrictions are not > needed, but I am curious if the topic was raised in the WG. On reflection, shouldn=E2=80=99t that be based on whatever rules already ex= ist for the URL scheme? And if some scheme doesn=E2=80=99t have well define= d behavior for non-ascii labels, is that the concern of this application? >=20 > Thank you for adding the Privacy Considerations and list of > Privacy-Sensitive AVPs! >=20 > Section 14 >=20 >=C2=A0 [...] The Diameter credit- >=C2=A0 control application is often used within one domain, and there may = be >=C2=A0 a single hop between the peers.=C2=A0 In these environments, the us= e of >=C2=A0 TLS/TCP, DTLS/SCTP or IPsec is sufficient. >=20 > I did not see any concrete guidance on what would suffice in other > environments (with multiple hops between peers).=C2=A0 Is this the realm > of the mythical "end-to-end security mechanism" for Diameter that is > much-desired?=C2=A0 (The last paragraph does have guidance on what might > *not* suffice, which is not exactly the same thing.) >=20 Sort of, but in real world deployments the =E2=80=9Coften used within one d= omain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D, which= should be clarified) effectively overrides everything else. That is far fr= om ideal, but it=E2=80=99s the reality. So it basically comes down to keep = everything in the trust domain, or if you cross a non-trusted network then = use TLS or IPSec. There=E2=80=99s no solution to safely traverse a non-trusted Diameter agent= . The mythical e2e mechanism could conceivably give us that.=C2=A0 (someday= , along with world peace and a post-scarcity economy). [yuval] as Ben and Lyle wrote, if your messages need to go through agents t= hat belong to a 3rd party, you have risks. In this case, AVP level encrypti= on (which is not standardized=C2=A0yet...) is the only option for to ensure= privacy. So, the only thing we can do here is to highlight the risks.=C2= =A0 >=C2=A0 Even without any modification to the messages, an adversary can >=C2=A0 eavesdrop on transactions that contain privacy-sensitive informatio= n >=C2=A0 about the user. >=20 > This ("an adversary can") makes it sounds as if there is no > confidentiality protection anywhere in the system, but that's what > TLS/DTLS/IPSec are supposed to provide.=C2=A0 So maybe "an adversary that > can eavesdrop on transactions can obtain privacy-sensitive > information [...]" is better. >=20 Good point, I agree your suggestion is better.[yuval] ok > (Editorial- and nit-level stuff follows.) >=20 > Section 4 >=20 >=C2=A0 A flexible credit-control application specific failure handling is >=C2=A0 defined in which the home service provider can model the credit- >=C2=A0 control client behavior according to its own credit risk management >=C2=A0 policy. >=20 > This sentence is hard to parse -- in "credit-control application > specific" what does "specific" bind to?=C2=A0 What is being modelled?=C2= =A0 Is > anything being controlled (as opposed to modelled)? [yuval] ok. so how about: "Flexible failure handling, specific to the credit-control, is defined in t= he application.This allows the the service provider to control the credit-c= ontrol client behavior according to its ownrisk management policy" >=20 > Section 4.1.1 >=20 >=C2=A0 2.=C2=A0 The Service-Parameter-Info AVP MAY be used as a container = to pass >=C2=A0 legacy rating information in its original encoded form (e.g., ASN.1 >=C2=A0 BER).=C2=A0 [...] >=20 > Why BER and not DER?=C2=A0 The unnecessary flexibility in BER vs. DER has > been known to tickle parser bugs and create security > vulnerabilities. >=C2=A0 [yuval] this is just an example of legacy stuff you have no control over > Section 4.1.2 >=20 >=C2=A0 [...] To >=C2=A0 facilitate interoperability, it is RECOMMENDED that the rating inpu= t >=C2=A0 and the values of the Service-Context-Id be coordinated via an >=C2=A0 informational RFC or other permanent and readily available referenc= e. >=C2=A0 The specification of another cooperative standardization body (e.g.= , >=C2=A0 3GPP, OMA, or 3GPP2) SHOULD be used. >=20 > The RECOMMENDED and SHOULD seem slightly in conflict. >=C2=A0 [yuval] yes, seems a bit awkward. How about: "To=C2=A0facilitate interoperability, it is RECOMMENDED that the rating inp= ut and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference, preferably, of another cooperative standardization body (e.g., =C2=A03GPP, OMA, or 3GPP2)." > Section 5.1.1 >=20 > As noted elsewhere, 60 seconds per minute does not always hold; it > seems that this text could be reworded to just talk about a > "constant rate" or "constant level per fixed time period" or > similar. >=C2=A0 [yuval] "constant rate" could mean sub-second resolution as well. The grant= s are in seconds, so, IMO, this phrasing is more accurate > Section 5.1.2 >=20 >=C2=A0 [...] >=C2=A0 timer (Section 13) every time a CCR message with the value >=C2=A0 UPDATE_REQUEST is sent while they are in PendingU state.=C2=A0 When >=C2=A0 answers to all pending messages are received, the state machine mov= es >=C2=A0 to OPEN state, and Tx is stopped. >=20 > Transmission, or the Tx timer (is stopped)? >=C2=A0 [yuval] well, "Tx" is overloaded :-( but we never use it in the sense of "t= ransmission" in the RFC > Using a different title for Section 5.2.2 might make the parallel > between it and Section 5.2.1 more clear.=C2=A0 That is, perhaps something > like "First Interrogation Included with Authorization Messages". >=C2=A0 [yuval] make sense > Section 5.7 >=20 >=C2=A0 [...] It is RECOMMENDED that the client complement the credit- >=C2=A0 control failure procedures with backup accounting flow toward an >=C2=A0 accounting server. [...] >=20 > Nit: it looks like there's a missing article here, maybe "a backup > accounting flow" is better. >=C2=A0 [yuval] the rest of the paragraph describe such "backup accounting flow". S= ee what comes after "For example" >=C2=A0 The AAA transport profile [RFC3539] defines the application layer >=C2=A0 watchdog algorithm that enables failover from a peer that has faile= d >=C2=A0 and is controlled by a watchdog timer (Tw) defined in [RFC3539]. >=20 > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? >=C2=A0 [yuval] would imagine there are other algorithms out there... should fix > Section 6.2 >=20 > Should there be text indicating how the client indicates what > service the balance check is being requested for? >=C2=A0 [yuval] didn't find any reference to service information for "EVET_REQUEST"= type messages (direct debit, refund, balance check and price enquiry). See= ms like that in the IEC section of 3GPP TS 32.299, they added their own mec= hanism for "direct debit", and "refund", and leave "balance check" and "pri= ce enquiry" as references to RFC4006. Unless I've missed something, this se= ems like a missing part of the spec. > Section 8.54 >=20 > Maybe give a section reference in RFC 3580 for how the formatting is > done? >=C2=A0 [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 in = our RFC > Section 12 >=20 >=C2=A0 [...] Initially, such Expert discussions take place on the AAA >=C2=A0 WG mailing list. >=20 > That list appears to be dead, suggesting that this text should be > updated.=C2=A0 (I also agree with Adam's comments about updating the IANA= Considerations.) >=C2=A0 [yuval] i don't know the process here - not sure how to change it. > Why is the disclaimer in Section B.4 (and other examples) not needed in S= ection B.3? [yuval] should be added there as well >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > DiME Info Page |=20 |=20 | |=20 DiME Info Page | | | _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_4450261_1723727983.1527064311623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Ben and Benjamin! Comments inline

=20
=20
On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben= Campbell <ben@nostrum.com> wrote:
Hi Benjamin,

I=E2=80=99ve cherry-picke= d a few points, inline:

= Thanks!

Ben.<= br clear=3D"none">
&g= t; On May 22, 2018, at 8:48 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
> Benjamin Kaduk has entered the following = ballot position for
> draft-ietf-dime-rfc4006bis-08: Discuss
>
> When responding, plea= se keep the subject line intact and reply to all
> email addresses included in = the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)=
> <= /span>
>
> Ple= ase refer to https://www.ietf.org/iesg/state= ment/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT position= s.
>=
> =
> T= he document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-rf= c4006bis/
>
>
>
> -----= -----------------------------------------------------------------
> DISCUSS:
> ----= ------------------------------------------------------------------
>
> I support A= lissa's Discuss point about sensitive AVPs.
>
= > I appear to have a different under= standing of Section 5.6.2, though,
> with a different potential issue (but agai= n, it's possible that I'm
> confused to how things work):
>
> With the redirection sch= emes covered in Section 5.6.2, it sounds
> like the user can be redirected (at = the application protocol level,
> e.g., HTTP or SIP) to a top-up server to purc= hase more credits.  I
> don't see a way described how user agents can di= stinguish between a
> Diameter-induced redirect and an attacker-induced redirec= t to a
= > (potentially phishing) site that accepts payment information.  To= be
>= ; clear, the scenario here is that a user is using a credit-controlled
> applic= ation session to talk to "arbitrary application servers",
> including potential= ly attacker-controllled HTTP/SIP/etc. servers;
> the attacker could introduce a= redirect to a phishing page that asks
<= span style=3D"font-size: 13px;">> for payment information, and the user = would be led to believe that
> this was the normal flow for "my prepaid balance= has been used up",
> and give their payment information to the phishing site. = I think
> that either user agents need to give some indication that this=
> DIAMETER= -level redirect is different than an
> application-protocol-level redirect (e.g= ., http) or the Security
> Considerations need to mention the risk of acclimati= ng users to
> arbitrary websites redirecting to sites asking for payment=
> credenti= als, which may or may not be legitimate sites.
>

I think it=E2=80= =99s reasonable to mention the concern in the security considerations. But = I don=E2=80=99t see how a redirection based on this specification is any di= fferent than any other time an HTTP browser or SIP UA connects to a resourc= e based on an arbitrary URL.

But to put some more context aroun= d this, the Diameter client is typically a Network Access Server (NAS) that= the end user is using for network access. The user is already at the mercy= of that NAS, and that NAS is at the mercy of the credit-control applicatio= n server. The user=E2=80=99s trust in that NAS seems to have the same issue= s whether or not this Diameter application is used.

[= yuval] agree with Ben, if someone bad took control over the NAS, they can d= o much worse

> Separately, in Section 8.68 (for QoS-Final-Unit-Indication):
>
> = ; If the Final-Unit-Action AVP is set to REDIRECT at least the
>  Redire= ct-Server-Extension AVP MUST be present.
>
= > This MUST seems in conflict with the = text in 8.64 (actually, is
> section 8.64 even internally inconsistent, too?)= about
= > "Redirect-Server AVP, in addition to or instead of the> Redirect-Server-E= xtension AVP", in particular, the "instead of"
> portion.  (The ABNF-based= formal language spec in 8.68 does match up
> with the above MUST, though.)

Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8= .64 to just =E2=80=9Cin addition to=E2=80=9D help?

Authors: P= lease comment if that works, given the backwards-compatibility concern.

[yuval] the cumbersome text is because of backw= ard compatibility issue. Would appriciate suggestion for better phrasing. T= he idea is the following:
* We have an existing AVP that can carry s= ome information
* We need more information, but we cannot modify the= existing one, so we added a new AVP (which, unlike the old one, is future = proof)
* If you have a peer that does not support the new spec, but = only need the old info, you can use the old AVP. what makes the spec backwa= rd compatible to the old one
* If you have need to send the new info= , you have to use the new AVP, but in this case an older peer does not make= sense
>= ;
>=
> = ----------------------------------------------------------------------
> COMMEN= T:
>= ----------------------------------------------------------------------
>
> Some a= dditional significant but not necessarily DISCUSS-worthy
> comments, followed b= y more editorial- and nit-level things.
= >
<= span style=3D"font-size: 13px;">> In Section 1.3, "Advertising Applicati= on Support" uses the same
> Auth-Application-ID value as for RFC 4006; what are= the interop
> consequences of this?
> 
[yuval] this was done to make interops= easier - this is why we kept this RFC backward compatible with RFC4006=
> Alissa already noted that the text about how= to split (sub-)AVPs
> between the foo and foo-Extension AVPs is inconsistent a= mong them --
> e.g., Redirect-Server-Extension and User-Equipment-Info say "S= HOULD
&= gt; send [in the old one]", but Subscription-Id-Extension has separate
> text a= bout "[i]f full backward compatibility with [RFC4006] is
> required" and slight= ly different behavior described.  We should try
> to catch all instances o= f this sort of backwards compatibility and
= > make them consistent.

= I agree.
[yuval] will look to unify the text
<= br clear=3D"none">>
> The us= e of UTF8String for URLs and URIs (e.g., Redirect-Address-URL)
> might benefit = from additional text about the expected contents.  A
> lot of the time whe= n we use a UTF8 container for names (whether
> domain names or other kinds), we= specify what normalization form and
> canonicalization are performed, whether = domain names are A-labels or
> U-labels, etc., as there's a lot of potential fl= exibility not all of
> which is good.  In this case, since the communicati= on is only
> between trusted actors, perhaps the additional restrictions are no= t
> = needed, but I am curious if the topic was raised in the WG.
On = reflection, shouldn=E2=80=99t that be based on whatever rules already exist= for the URL scheme? And if some scheme doesn=E2=80=99t have well defined b= ehavior for non-ascii labels, is that the concern of this application?

>
> Thank you for adding the Privacy Considerations and list of
> Priv= acy-Sensitive AVPs!
>
> Section 14
>
>  [...] The Diameter credit-<= br clear=3D"none">>  control a= pplication is often used within one domain, and there may be<= br clear=3D"none">>  a single = hop between the peers.  In these environments, the use of
>  TLS/TCP= , DTLS/SCTP or IPsec is sufficient.
>
> I did not see any concrete guidance on wha= t would suffice in other
> environments (with multiple hops between peers).&nbs= p; Is this the realm
> of the mythical "end-to-end security mechanism" for Diam= eter that is
> much-desired?  (The last paragraph does have guidance on = what might
> *not* suffice, which is not exactly the same thing.)=
> <= br clear=3D"none">
So= rt of, but in real world deployments the =E2=80=9Coften used within one dom= ain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D, which s= hould be clarified) effectively overrides everything else. That is far from= ideal, but it=E2=80=99s the reality. So it basically comes down to keep ev= erything in the trust domain, or if you cross a non-trusted network then us= e TLS or IPSec.

There=E2=80=99s no solution to safely traverse = a non-trusted Diameter agent. The mythical e2e mechanism could conceivably = give us that.  (someday, along with world peace and a post-scarcity ec= onomy).

[yuval] as Ben and Lyle wrote, if your messages nee= d to go through agents that belong to a 3rd party, you have risks. In this = case, AVP level encryption (which is not standardized yet...) is the o= nly option for to ensure privacy. So, the only thing we can do here is to h= ighlight the risks. 

>  Even without any modification to the= messages, an adversary can
>  eavesdrop on transactions that contain pr= ivacy-sensitive information
>  about the user.
>
> This ("an adversary can") ma= kes it sounds as if there is no
> confidentiality protection anywhere in the sy= stem, but that's what
> TLS/DTLS/IPSec are supposed to provide.  So maybe = "an adversary that
> can eavesdrop on transactions can obtain privacy-sensitive=
> i= nformation [...]" is better.
>

Good point, I agree your suggestion= is better.
[yuval] ok

> (Editorial- and nit-level stuff follows.)
> > Section 4
>
&g= t;  A flexible credit-control application specific failure handling i= s
>  defined in which the home service provider = can model the credit-
>  control client behavior= according to its own credit risk management
>  = policy.
>
> This sentence is har= d to parse -- in "credit-control application
> specifi= c" what does "specific" bind to?  What is being modelled?  Is
> anything being controlled (as opposed to modelled)?

[yuval] ok. so how about:=
"Flexible failure handling, specific to the credit-control, is defined i= n the application.
This allows the the service provider to control= the credit-control client behavior according to its own<= /div>
risk mana= gement policy"

>
> Section 4.1.1
>
>  2.  The Service-Paramete= r-Info AVP MAY be used as a container to pass
>  = legacy rating information in its original encoded form (e.g., ASN.1
>  BER).  [...]
>
> Why BER and not DER?  The unnecessary flexibility in BE= R vs. DER has
> been known to tickle parser bugs and c= reate security
> vulnerabilities.
&g= t; 

[yuval] this is just an = example of legacy stuff you have no control over

> Section 4= .1.2
>
>  [...] To
>  facilitate interoperability, it is RECOMMENDED that = the rating input
>  and the values of the Servic= e-Context-Id be coordinated via an
>  informatio= nal RFC or other permanent and readily available reference.
>  The specification of another cooperative standardization bod= y (e.g.,
>  3GPP, OMA, or 3GPP2) SHOULD be used.=
>
> The RECOMMENDED and SHOULD = seem slightly in conflict.
> 

[yuval] yes, seems a bit awkward. How about:=
"To facilitate interoperability, it is RECOMMENDED that = the rating input
and the values of the Service= -Context-Id be coordinated via an
informationa= l RFC or other permanent and readily available reference,
preferably, of another cooperative standardization body (e.g.,<= br clear=3D"none" style=3D""> 3GPP, OMA, or 3GPP2)."
<= div class=3D"ydpb0f3ec32yqt4643171513" id=3D"ydpb0f3ec32yqtfd89974" style= =3D"color: rgb(38, 40, 42); font-family: "Helvetica Neue", Helvet= ica, Arial, sans-serif; font-size: 13px;">
> Section 5= .1.1
>
> As noted elsewhere, 60 = seconds per minute does not always hold; it
> seems th= at this text could be reworded to just talk about a
> = "constant rate" or "constant level per fixed time period" or
> similar.
> 

= [yuval] "constant rate" could mean sub-second resolution as w= ell. The grants are in seconds, so, IMO, this phrasing is more accurate

> Section 5.1.2
>
>=   [...]
>  timer (Section 13) every time a= CCR message with the value
>  UPDATE_REQUEST is= sent while they are in PendingU state.  When
>&n= bsp; answers to all pending messages are received, the state machine moves=
>  to OPEN state, and Tx is stopped.
>
> Transmission, or the Tx timer (is st= opped)?
> 

[yuval] well, "Tx" is overloaded :-( but we never use it in the sens= e of "transmission" in the RFC

> Using a different title for= Section 5.2.2 might make the parallel
> between it an= d Section 5.2.1 more clear.  That is, perhaps something
> like "First Interrogation Included with Authorization Messages".> 
<= br>
[yuva= l] make sense

> Section 5.7
>
>  [...] It is RECOMMENDED that the client complement th= e credit-
>  control failure procedures with bac= kup accounting flow toward an
>  accounting serv= er. [...]
>
> Nit: it looks like= there's a missing article here, maybe "a backup
> acc= ounting flow" is better.
> 

[yuval] the rest of the paragraph describe such "backu= p accounting flow". See what comes after "For example"

>  = The AAA transport profile [RFC3539] defines the application layer
>  watchdog algorithm that enables failover from a peer = that has failed
>  and is controlled by a watchd= og timer (Tw) defined in [RFC3539].
>
> Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm?
> 
<= br>
[yuva= l] would imagine there are other algorithms out there... should fix<= /i>

> Section 6.2
>
> Should= there be text indicating how the client indicates what
&= gt; service the balance check is being requested for?
>= ; 

[yuval] didn't find any = reference to service information for "EVET_REQUEST" type messages (direct d= ebit, refund, balance check and price enquiry). Seems like that in the IEC = section of 3GPP TS 32.299, they added their own mechanism for "direct debit= ", and "refund", and leave "balance check" and "price e= nquiry" as references to RFC4006. Unless I've missed something, this seems = like a missing part of the spec.

> Section= 8.54
>
> Maybe give a section r= eference in RFC 3580 for how the formatting is
> done?=
> 

[yu= val] see section 3.21 in RFC3580, this is also true for section 8.50 in our= RFC
<= br clear=3D"none">> Section 12
>
>  [...] Initially, such Expert discussions take place on the AAA=
>  WG mailing list.
>
> That list appears to be dead, suggesting that this text= should be
> updated.  (I also agree with Adam's = comments about updating the IANA Considerations.)
>&nb= sp;

[yuval] i don't know the proc= ess here - not sure how to change it.

> Why is the disclaime= r in Section B.4 (and other examples) not needed in Section B.3?

[yuval] should be added there as well
>
>
> ____________________= ___________________________
> DiME mailing list
> DiME@ietf.org
> DiME Info Page
<= br clear=3D"none">



______________________= _________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------=_Part_4450261_1723727983.1527064311623-- From nobody Wed May 23 02:13:45 2018 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 0682A126B6E for ; Wed, 23 May 2018 02:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDLq7dmhvMQP for ; Wed, 23 May 2018 02:13:41 -0700 (PDT) Received: from sonic314-22.consmr.mail.ne1.yahoo.com (sonic314-22.consmr.mail.ne1.yahoo.com [66.163.189.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0797A124BAC for ; Wed, 23 May 2018 02:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527066819; bh=n6mlWN9Fuz5fz8+EEdj5+ilhluvb11mH0wsCUSbacas=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=oi0qqkb6sLdJRES6D4Q+CiNQCns+5oH7md60k3olmWcLncomf8b0u/lywQLtAAlM2jGY6kpy2/BIaRNvuD5oRvFDmRqePYVTqsKdZ4ghf2j3+lG4v2VAejjUspyYXf7VxIqVtjnghoxbwvda3+9ypsZfZLyVKxe/B13PPa++ft85rPTlmyC2hcQyOKfdQMeiwnqeZ+UXFUGrK2i2D+14c7iYAIteIH3w++TLeaM75WHTm2wa4/3HJcJVTxa8nyp4gxGbBKBd51YxZNahO4D6LqOEE9zaweiAm1a0pFZrz0f7PMM/4X69qYUpIII3ZQfGn4QaR4IubpLNo8+eWyjmDQ== X-YMail-OSG: fzf9rg4VM1kaqv3xXPLxrKua3ZK7fd2iCMiTDeF4Me05wKVjkXzmAoiIgifQya3 YStd1.GDQx815xdGSAEuedh2xaVgwjyrdeSST4s4YenS7g1hdg.UAn54p_hkW9SCWd6euNNvTYOZ ibEm0txHYMhqD5e_Cw_YQT2BZuCIZYfEgLJmiqt5wG2dqQnQmw5ISYOx5pt30IVBUr5sGo4g0Srr mFy0cvZhZdc6MUILavZAvIOQlbtOExBqzjrO2O1OxBNdVjaqyKXkMDqJClK870NxQSSF3GwaZrkc s0CoUCbFTLh8DFtYuQJ1BUepvYHj3g19Em3UrBmxx1bZ07hVSnnvQQ9SPUJ3ZhDwTlySDCfI.F1a iemqFNvJg5cG5flPNlqUxGwhyQVt2pnDr9mKXjbEmauTIruXIg6SgKL4hr.sHarnO9vak8gne8XK Amcy_LaDYH6CP0CmWhbBNT1pug4FShzinMvvcpvcaT3tbiy7JFQikZOHUiQ4EWoZ.YFM1qTvHX4f 6GHDRhE0i3XL47LgHZLp7UaOLRSvqZC4yBdeaCqOaRLTIey_7qw07jUhSL8A4QFlUoSqzmCxkwX4 BE2iKgiUnqHUMzOe7Qxv61VgIJdUAsPceUIutTruaoAHqbszVYdkKqw2RuYAR3sFIboPSihajMq. qBr1DEqV_ZsnW9cyKjplfK6rmmgAVw7YlfZzgLKc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Wed, 23 May 2018 09:13:39 +0000 Date: Wed, 23 May 2018 09:13:37 +0000 (UTC) From: Yuval Lifshitz To: The IESG , Adam Roach Cc: dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <1651457572.4445831.1527066817455@mail.yahoo.com> In-Reply-To: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> References: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4445830_1015538383.1527066817446" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 09:13:43 -0000 ------=_Part_4445830_1015538383.1527066817446 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adam, thanks for the review. Comments inline On Tuesday, May 22, 2018, 1:41:50 a.m. GMT+3, Adam Roach wrote: =20 =20 Adam Roach has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and other participants who helped with this revision = of the credit-control application. Thanks in particular for the addition of an extensive privacy considerations section. I will note that I only reviewed the diffs between this document and RFC 40= 06. I have a handful of comments. --------------------------------------------------------------------------- General nit: This document uses the term "service specific" as a compound adjective in several places. As a compound adjective, this should be hyphenated (i.e., "service-specific"). [yuval] will fix --------------------------------------------------------------------------- =C2=A71.1: This document uses lowercase forms of RFC-2119-defined terms. Please update= this section to use the boilerplate from RFC 8174. [yuval] we use them in lowercase, without their normative meaning. Is this = an issue? For example: "a commercial agreement must exist between the=C2=A0visited do= main and the home domain" is just informational --------------------------------------------------------------------------- =C2=A75.1.2: >=C2=A0 If independent credit-control of multiple services is used, the >=C2=A0 Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- >=C2=A0 Indication AVP SHOULD be present either in the Multiple-Services- >=C2=A0 Credit-Control AVP(s) or at command level as single AVPs. The phrasing here is ambiguous -- it's not clear whether the requirement is= : =C2=A0 (Validity-Time and Final-Unit-Indication) or QoS-Final-Unit-Indicati= on ... or ... =C2=A0 Validity-Time and (Final-Unit-Indication or QoS-Final-Unit-Indicatio= n) I suspect it's the latter, in which case I suggest: =C2=A0 If independent credit-control of multiple services is used, the =C2=A0 Validity-Time AVP, and either the Final-Unit-Indication AVP or =C2=A0 the QoS-Final-Unit-Indication AVP, SHOULD be present either in the =C2=A0 Multiple-Services- Credit-Control AVP(s) or at command level as sing= le =C2=A0 AVPs. [yuval] yes. will fix --------------------------------------------------------------------------- =C2=A75.2.1: The alignment of the "Diameter AAA Server" title on Figure 3 has changed fr= om RFC 4006 in a way that looks worse. --------------------------------------------------------------------------- [yuval] will fix =C2=A75.6.2: >=C2=A0 The credit-control >=C2=A0 client receives a Credit-Control-Answer or service specific >=C2=A0 authorization answer with the Final-Unit-Indication or the QoS-Fina= l- >=C2=A0 Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- >=C2=A0 Unit AVP. This has the same confusion as above regarding the application of logical combinations. The second half of the statement is of the form "A or B and C but not D," which is pretty ambiguous. It's also a little unclear whether t= he client receives a Credit-Control-Answer (with A or B and C but not D), or j= ust a Credit-Control-Answer of any description, full stop. [yuval] how about this: "When the credit-control=C2=A0client receives (either at session or service= specific level) a=C2=A0Final-Unit-Indication AVP or QoS-Final-Unit-Indicat= ion AVP, together with Validity-Time AVP,but without Granted-Service-Unit A= VP, it immediately starts the graceful service termination=C2=A0 =C2=A0with= out sending any message to the server." --------------------------------------------------------------------------- =C2=A78.19 >=C2=A0 Note: The values reported in a Used-Service-Unit AVP does not >=C2=A0 necessarily have a relation to the grant provided in a Granted- >=C2=A0 Service-Unit AVP, e.g., the value in this AVP may exceed the value = in >=C2=A0 the grant. Nit: "...values reported in a Used-Service-Unit AVP do not..." =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^ (or "...value... does not...") [yuval] will fix --------------------------------------------------------------------------- =C2=A78.54: >=C2=A0 The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. >=C2=A0 The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is >=C2=A0 formatted as described in [RFC3580]. Nit: remove "is" after "address". [yuval] will fix --------------------------------------------------------------------------- =C2=A78.65: >=C2=A0 The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type >=C2=A0 Address and defines the IPv4 or IPv6 address of the redirect server >=C2=A0 with which the end user is to be connected when the account cannot >=C2=A0 cover the service cost. This appears to be underspecified, unless I've missed some specification elsewhere regarding what the client is supposed to do with this IP address. While the other redirection methods (HTTP, SIP) have relatively clear means= of contact (they indicate a protocol), the indication of only an IP address wi= th neither protocol nor port doesn't seem to provide enough information for a client to act on.=C2=A0 Please either flesh this out in this section, or po= int to another document that indicates how this IP address is to be used. [yuval] I think this is left unspecifid on purpose. There are many ways to = redirect IP addresses (e.g. different tunneling mechanism), don't think we = want to list them here?[yuval] --------------------------------------------------------------------------- =C2=A712: When new documents obsolete an RFC that originally registered values with I= ANA, I'm used to seeing that document also update the IANA registry so that the corresponding entries now point to the new document. You may consider text = that instructs IANA to update the existing RFC-4006-registered values so that th= ey point to this document instead of RFC 4006. [yuval] don't know what the process here. but does it need to go into the R= FC? --------------------------------------------------------------------------- Appendix B: As a general comment for all of the examples: I'm surprised that none of th= e examples have been updated to reflect the newly defined capabilities in thi= s document. For example, all the examples in this appendix use Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, t= o show maximally flexible and compatible examples, I would expect that the examples would include both AVPs. This applies to all of the "Extension" AVPs as well. [yuval] the examples are more around the flow and less about the actual con= tent. With respect to flow, there is no difference between the old and new AVPs -= and we wanted to minimize unnecessary changes. Only flow that was modified= was reflected in a new diagram at the end of section 5.6 ("zero GSU") --------------------------------------------------------------------------- Appendix B.2: >=C2=A0 control server.=C2=A0 Therefore, in this example, it is assumed tha= t the >=C2=A0 SIP Proxy adds a Record-Route header in the initial SIP INVITE "...a Record-Route header field..." (A SIP header is everything before the first blank line; individual lines w= ithin a SIP header are called "header fields") [yuval] ok. will fix _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_4445830_1015538383.1527066817446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adam, thanks for the review. Comments = inline

=20
=20
On Tuesday, May 22, 2018, 1:41:50 a.m. GMT+3, Adam = Roach <adam@nostrum.com> wrote:


Adam Roach has entered the follow= ing ballot position for
draft-ietf-dime-rfc4006bi= s-08: No Objection

Whe= n responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel fr= ee to cut this
introductory paragraph, however.)<= br>


for more in= formation about IESG DISCUSS and COMMENT positions.


The document, alon= g with other ballot positions, can be found here:



-------------------= ---------------------------------------------------
COMMENT:
-------------------------------------= ---------------------------------

Thanks to the authors and other participants who helped with th= is revision of
the credit-control application. Th= anks in particular for the addition of an
extensi= ve privacy considerations section.

I will note that I only reviewed the diffs between this docume= nt and RFC 4006.

I hav= e a handful of comments.

------------------------------------------------------------------------= ---

General nit:

This document uses the term= "service specific" as a compound adjective in
se= veral places. As a compound adjective, this should be hyphenated (i.e.,
=
"service-specific").

<= /div>
[yuval] will fix

------------------------------= ---------------------------------------------
=C2=A71.1:

This document uses lowercase forms of RFC-2119-defined terms. = Please update this
section to use the boilerplate= from RFC 8174.

= [yuval] we use them in lowercase, without their normative meaning. Is t= his an issue?
For exa= mple: "
a commercial agreement must exist between the 
<= /i>
visited domain and the ho= me domain" is just informational


------= ---------------------------------------------------------------------

=C2=A75.1.2:

>  If independent credit-con= trol of multiple services is used, the
> = Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit-
>  Indication AVP SHOULD be present either in th= e Multiple-Services-
>  Credit-Control AV= P(s) or at command level as single AVPs.

The phrasing here is ambiguous -- it's not clear whether= the requirement is:

&= nbsp; (Validity-Time and Final-Unit-Indication) or QoS-Final-Unit-Indicatio= n

... or ...
=

  Validity-Time and (Final= -Unit-Indication or QoS-Final-Unit-Indication)
I suspect it's the latter, in which case I suggest= :

  If independe= nt credit-control of multiple services is used, the
  Validity-Time AVP, and either the Final-Unit-Indication AVP or
  the QoS-Final-Unit-Indication AVP, SHOULD = be present either in the
  Multiple-Service= s- Credit-Control AVP(s) or at command level as single
  AVPs.

[yuval] yes. will fix
<= br>
-------------------------------------------------= --------------------------

=C2=A75.2.1:

The = alignment of the "Diameter AAA Server" title on Figure 3 has changed from
RFC 4006 in a way that looks worse.

------------------------------------= ---------------------------------------

[yuval] will fix

=C2=A75.6.2:

>  The credit-control
>  client receives a Credit-Control-Answer or service = specific
>  authorization answer with the= Final-Unit-Indication or the QoS-Final-
>&nbs= p; Unit-Indication AVP and Validity-Time AVPs but no Granted-Service-
>  Unit AVP.

This has the same confusion as above regarding the appl= ication of logical
combinations. The second half = of the statement is of the form "A or B and C
but= not D," which is pretty ambiguous. It's also a little unclear whether the<= br>
client receives a Credit-Control-Answer (with A o= r B and C but not D), or just
a Credit-Control-An= swer of any description, full stop.

= [yuval] how about this:
=
"
When the credit-control 
client receives (either at session or service specific l= evel) a 
Final-Unit-Indicati= on AVP or QoS-Final-
Unit-Indicat= ion AVP, together with Validity-Time AVP,
but without Granted-Service-
Unit AVP, it immediately starts the graceful service term= ination
   without sending any message= to the server."

<= /div>
-----------------------------------------------------= ----------------------

=C2=A78.19

> = Note: The values reported in a Used-Service-Unit AVP does not
>  necessarily have a relation to the grant provided = in a Granted-
>  Service-Unit AVP, e.g., = the value in this AVP may exceed the value in
>= ;  the grant.

Nit= : "...values reported in a Used-Service-Unit AVP do not..."
                  &= nbsp;                    =             ^^
(or "...value... does not...")

[yuval] will fix

-------------------= --------------------------------------------------------

=C2=A78.54:
<= br>
>  The User-Equipment-Info-MAC (AVP Code = TBD3) is of type OctetString.
>  The User= -Equipment-Info-MAC AVP contains the 48-bit MAC address is
>  formatted as described in [RFC3580].

Nit: remove "is" after "address".

[yuval] will fix<= /font>

----= -----------------------------------------------------------------------
=

=C2=A78.65:

>  The Redirect-Address-IPA= ddress AVP (AVP Code TBD14) is of type
> = Address and defines the IPv4 or IPv6 address of the redirect server
>  with which the end user is to be connected w= hen the account cannot
>  cover the servi= ce cost.

This appears = to be underspecified, unless I've missed some specification
elsewhere regarding what the client is supposed to do with this = IP address.
While the other redirection methods (= HTTP, SIP) have relatively clear means of
contact= (they indicate a protocol), the indication of only an IP address with
<= /div>
neither protocol nor port doesn't seem to provide eno= ugh information for a
client to act on.  Ple= ase either flesh this out in this section, or point to
another document that indicates how this IP address is to be used.

[yuval] I thin= k this is left unspecifid on purpose. There are many ways to redirect IP ad= dresses (e.g. different tunneling mechanism), don't think we want to list t= hem here?[yuval]
<= br>
-------------------------------------------------= --------------------------

=C2=A712:

When ne= w documents obsolete an RFC that originally registered values with IANA,
I'm used to seeing that document also update the IA= NA registry so that the
corresponding entries now= point to the new document. You may consider text that
instructs IANA to update the existing RFC-4006-registered values so t= hat they
point to this document instead of RFC 40= 06.

[yuval] = don't know what the process here. but does it need to go into the RFC?

--------= -------------------------------------------------------------------

Appendix B:

As a general comment for all of the exa= mples: I'm surprised that none of the
examples ha= ve been updated to reflect the newly defined capabilities in this
=
document. For example, all the examples in this appendix u= se
Final-Unit-Indication rather than QoS-Final-Un= it-Indication. In practice, to
show maximally fle= xible and compatible examples, I would expect that the
examples would include both AVPs. This applies to all of the "Extensi= on"
AVPs as well.

<= /div>
[yuval] the examples are more around the fl= ow and less about the actual content.
With respect to flow, there is no difference between the= old and new AVPs - and we wanted to minimize unnecessary changes. Only flo= w that was modified was reflected in a new diagram at the end of section 5.= 6 ("zero GSU")

------------------------------------------------------------------= ---------

Appendix B.2= :

>  control s= erver.  Therefore, in this example, it is assumed that the
>  SIP Proxy adds a Record-Route header in the initi= al SIP INVITE

"...a Re= cord-Route header field..."

(A SIP header is everything before the first blank line; individual l= ines within
a SIP header are called "header field= s")

[yuval] = ok. will fix

______________________________________= _________
DiME mailing list
------=_Part_4445830_1015538383.1527066817446-- From nobody Wed May 23 05:29:59 2018 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 ACEA4126FB3; Wed, 23 May 2018 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aemUFs2Ls_gU; Wed, 23 May 2018 05:29:46 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EA9126D74; Wed, 23 May 2018 05:29:46 -0700 (PDT) Received: from BN7PR05CA0019.namprd05.prod.outlook.com (2603:10b6:406:ee::32) by BLUPR05MB1955.namprd05.prod.outlook.com (2a01:111:e400:52ad::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.8; Wed, 23 May 2018 12:29:44 +0000 Received: from BY2NAM01FT032.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::209) by BN7PR05CA0019.outlook.office365.com (2603:10b6:406:ee::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.797.8 via Frontend Transport; Wed, 23 May 2018 12:29:44 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BY2NAM01FT032.mail.protection.outlook.com (10.152.69.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.776.10 via Frontend Transport; Wed, 23 May 2018 12:29:43 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w4NCJ2BM015688; Wed, 23 May 2018 08:29:43 -0400 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by preapdm3.corp.sprint.com with ESMTP id 2j2e677f4d-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 08:29:43 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M03.ad.sprint.com (2002:90e2:8016::90e2:8016) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 May 2018 08:29:42 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1365.000; Wed, 23 May 2018 07:29:42 -0500 From: "Bertz, Lyle T [CTO]" To: Ben Campbell CC: Alissa Cooper , The IESG , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) Thread-Index: AQHT8b0gV92dBty11EiaZD5n7O1P+6Q8gdpAgABzQACAAEdUQA== Date: Wed, 23 May 2018 12:29:41 +0000 Message-ID: <0e9e72c11cde4097b9d698327882be42@plswe13m04.ad.sprint.com> References: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> <48C95314-5F5D-4CFC-963B-36017BB364A1@nostrum.com> In-Reply-To: <48C95314-5F5D-4CFC-963B-36017BB364A1@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39380400002)(346002)(39860400002)(376002)(2980300002)(438002)(13464003)(189003)(199004)(102836004)(47776003)(4326008)(53546011)(7696005)(11346002)(108616005)(24736004)(76176011)(5660300001)(97736004)(436003)(446003)(2486003)(426003)(23676004)(59450400001)(476003)(126002)(486006)(336012)(8676002)(6116002)(5890100001)(3846002)(5250100002)(54906003)(45080400002)(8936002)(81166006)(81156014)(316002)(72206003)(7736002)(305945005)(966005)(14454004)(106466001)(478600001)(106002)(356003)(53936002)(229853002)(186003)(2900100001)(575784001)(86362001)(2906002)(6306002)(26005)(50466002)(68736007)(6916009)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1955; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT032; 1:2+RzcRPGTSUQTjfSPgmlkadki/BK4EH8ePrYvAbV1vb/1O/mPso/UlW+jPm2Ojly8y3vhkHYn8w8ugODpwJxztpRyLjcYscnfwsOZ95IeqiiXBxNd9UByjkkuChCfDau X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:(18430343700868); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:BLUPR05MB1955; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 3:12z4V7+u0nLfKRtK82D+de3Shzw4YVxwCKQ/KUtKgPCQaYWN6F6gK85nrRM6dNIHxzCJO3rqE9fQrWbCqekO5+yAeGGG+rgYqOD/yBbdYE/R5MTxYKsmVzOIyrcVw2Qzs+C6BPCeM7GFrXFv9L2q7imcbISaqcMbHmuRr661Y5901EbtVphyx/P9Vv566MLgsbwAmS12MHsnIEzZaHEFFpuUVY4HGkV1M3MJO0GgWF14JaxeTz5IWWFltdsnpOxM00Q3FnQ8ap2MUxdAUK4O0EB40pri0vXYqsq951YzTl+a/inJBD3050XtpzoA8qScQ1mwbau5XUW1qfEWptLwM/NlvtDOayM/4uK46NoXFqM/9oTphVSlh+aA2KwBvS4Z9Z7PEIduhTH7Q8jUfTrvlA==; 25:rGRfdjrcSTNV7vdmsHyLG8D91vpYuDEErviWlqd3XlRp3SRhmbPheVVezo+repRdckB8ihTliIOvH3FRtJzhG0i+QTumvn6GzpOEESbDreHxIOb6c/BvIDVDH4E4M47UYdVWID8fJ58jvL0+IsFXaNKCxj0m8I0q1oeQD9vd2Omp5llR/T2zN4objmPqUWYNtAcPSFTade6B3/Pi9U8hQgb8r4QVeTiJfxBedaxpFImAgvW5OAO7ptWowNKWi2KKV6nuakDhJcMtu/jrfBSYmDTAqBVikxBZYAv/VfMMH2BOI8qIuI75HNz0QXq8E+iQlEmtO3zi1QIYuPE98/LgPONfEQuGBYUl/1/8ifktn/M= X-MS-TrafficTypeDiagnostic: BLUPR05MB1955: X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 31:HoWG/pMIzPwzpXQpAoZZ13zLNbOp7XPNbfm3JQ+jty10I+sKGEdRLUhIoG4FL8L2WQeQRScLaCvpofXAFNnOUgFEJV48OW5eSrabmcRJqI3TrHSnvNBaOZdn3Es5kSHKTHux7Qp5y7A9emUDIBZ0Xph8kaB7vumcHiTpkf3yoMTEraioS00hE/+hRGl3fO8tFpk6k4Li3wpltABuj8gnHrb9dxTnRuJK1ZENEFxeBBA=; 20:StLL+SqJWSEAt9UQp/cdUmrTmVzqU4tZHVHdNZ4xrGZQquFQRMrmq0/ct/cTe0FhzCC4VoEGCu3/H0mqsLfgUnYcsRouLaFaACLi62U48bp1yb4cTKleVoJoI09EtH/OkIAf+AJiHgkPf8hS6JqIs2shjZqqMTimpFLlXuC3tDosnjQpAMZ4UA17OvdrNZLtY9nxQqdunDk57GrT9B/QIMIcBYO4T3p8ILJv2YR3YlMsQ1xbgPRGCArxzFW2wnDlJ6GJr+wEr+qcqftz9O7ZywXsRm0gfxGtgo+uWsPn7kJIygfAWTIt4B+8wSKPvCwxgxx5wmv0R5Fsr2ADOtR2OsfAgvJe+mbsIbMWQZGZ9R6noJe9XLsGziUgriUFdjJ69a4RyfRQkirO8PdIV9grXsLCfVQx/z4hLYSo44UaqDvNWg6XF8A97NxvnJVq4SZwRwtKZrlFTpJxYA6Vr+Y18zT9UVbTTIHz5No++A+RV84W9dKIMNqKMDfM2aGPjt7+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(18430343700868)(189930954265078)(35073007944872)(788757137089)(219752817060721); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BLUPR05MB1955; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1955; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 4:867YL8B1Deo62fmaiSzX3ECDNmJd+Dk4HL87UWNhNKP0L+J7Mr7LsbNULpINMqCuwK0E8V29GrNRHTD6HNMAzGLbhmfJJMCoa7coKhhrbHYkwCZ1Sv7QLA7ruO5Rhz975w/KmbKa8pHZX6OePG+dvWLy058fcVfvlRyh3+ldsBk/ERW3CVhemJnA4ZYXnP7Gh5YZQnC/e6z+dWCDYeyeE1cOlPm7W0MX12YBCQoLELnjlr5iT1r/w0UVWndFuSPYnYWEGcv02PF0SuDvEB8Ty6fyiJ5/D3MM6I9vImECOlNh8o64vi/vCCf2aUTxsEw6hkFSkDQ9haDPGK4wGH76mZJUwIdPn9vHiUQm+SiX4IVh4F5lYu3IIv9Xs5cHotdy87rUkPGantY+YT8HZJ3W/IW2nH3JcEalDaFEeU6Yl5UhsMYKI+v2cFUKMMS3/MyRfqiKjAF1G+6trX9hv2vj5Ys/q5oBT9OKR8fdZzOUfPO/ZxXxVyiiwtF93m7GB6Z/FCcj8Si7X50L9H0SV+ielA== X-Forefront-PRVS: 06818431B9 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUIxOTU1OzIzOmZrNkYrNjNnUGhIVlowbE9ueVRhM0NqSjJ6?= =?utf-8?B?NURKUHB6S0ZqQzFvQ201N2ozUnhGWGloS0UyRzVKeVFubEdyMHlrOW80eXV4?= =?utf-8?B?S01pYmZnUk9xdnlMMmNPbDRrK2ZsVWxqN3d4MWo4NmRwSm44R3BJNlF1UFdy?= =?utf-8?B?YmUvWGNnaEI4bktaMTRuYk1BMGt3a1ZtczdaemFxOWxYWEI5dFBhUDQycjd1?= =?utf-8?B?QzliSWlkOUV4cXJJcFcvVVg2Z0NwaStPRXNreEwxTGVXcGYzMkhDVm5hbXdw?= =?utf-8?B?ckM0NE93SEhzVUlFVVhUb0tDZENKYUVqWnJtZWdPMi9UN0pmaXU1eWt3OGxv?= =?utf-8?B?cmJEZExNVGQ5bTcwNmJqQjBMQ3RXY3JoVnJzZmp1SnRwZUFpUHV3cUZQclRV?= =?utf-8?B?b3h5VlhFaHFkQklBTmp2dDl1S0lVK3BpRER5cVJqY290dVJLdzJjbDV5TUo4?= =?utf-8?B?dGwzMUpVVjFTWDhFRDBaNEVuaW42U2hmRWJVMzN4Mk1Tb0tIWW5Mc2Z0QmY4?= =?utf-8?B?WVIveXlqWktWOXhhUnV4YmlvOHVEV1pHMHhIcThxR0dGVmFjWmt3blpSRnpl?= =?utf-8?B?c3dtZzhLL0hMUEdkNHlKL1B5UWEvaTYzN2pxZWFIS2N4SW14LzNoc1drQnY0?= =?utf-8?B?VFUzZzRTNkgzRGJGMmw5ZDhYdldPR05pVUJsV3p4YTNkdy93NXQwcUZRWHpH?= =?utf-8?B?Z1p5akZyWk1vU013WnhQQVZVMk9VYW1NM3RsRzhjVFFsbzlEQjljelJOMS8w?= =?utf-8?B?RU00R09mN29ONms3N0JJTTFqZlFKTitqVHFiSmxKZWQ5T0lMTWd5MzZyK3Z0?= =?utf-8?B?bjMycjIrM2RQajNRQUlJYWJWMWZTWEd1MWtBNnY4OVB1Y2JtMlN4YmFZWGdz?= =?utf-8?B?NDhFMlExOWJMY3pRdHRmZDRDRWpuUGo0ZEZ4M3QvL3JqdXcxdlBNNTBycEN3?= =?utf-8?B?ZUZKbUI3SHJPek9qMHdBN3pWT0lBME55TXI1aXRpY0lBMG54TDMyNXFEMmRo?= =?utf-8?B?SFE1QmNUNmgzdi9ITFVzUkFnUUdRRnFMQWJnc0dWWmVOSnhkeGNhSktVYzJL?= =?utf-8?B?Zzh3OEhRc2ZzQ3paZTAwcVd1RGdaNXc5dWlqaldicTI1MkJlOUFhckoyRW91?= =?utf-8?B?QkRUWGIrcGlDcmprRWlRQll4YVBVV0ZFSStkYUNYM294STN4T3U4Wnl6WmZV?= =?utf-8?B?TzVXMUJ6N3Q1cnVoM3VKejdjV2hFQ2ppTFREREhMTTBVbWZ4Q0I4d0JUTWtk?= =?utf-8?B?VmFnc201cmxjOVFiaW9pVlNFQmU5YTZKalJEdExLcDhkaFVISUlxUEE0dG1v?= =?utf-8?B?MmJ2blZtR3FZdmNpL3hIODk0Y245dU5GR2hFODl5M3JrSWo2YS9HUzBvdVF3?= =?utf-8?B?V25sdlBqdTdsekk1OERXeE5LS2lOazlnS0RxNlU4T0NXcmlJUE5FRFhoMjhn?= =?utf-8?B?MTF2UWhaZjhNd1NOVTNsWU54NndwZGVHakg2SEx6ZkhmT0kyZ2ZiVWpyOXhQ?= =?utf-8?B?eENQRlNac0tHNGtIWlFRamYyWEY2OElvZWcyZndPbWRyN28wSHpXS2E3akxB?= =?utf-8?B?cUlBY29Rd2RPbzBQUE5rb1RCUXRQRDh4MG1VMjRUVUJ2c3gzdmdJK2h3cTd0?= =?utf-8?B?TStVOUtUcC9mN0JFWWJHeXFVOW5PQ0ZMY3BOL2I2WlcvSXlnUzFtcDBKTGgw?= =?utf-8?B?RFdSL0UxTUxjanErMVp5VTRYWk5mSm11RTlFZXBkUnd1aXNYSjB4WHBaWEdw?= =?utf-8?B?VjFXUlpEL3BLd05ib0hNZFRmWURaeDRLTjlXcmpncGJoY2JPMm0wSDl5cC8w?= =?utf-8?B?TGJGVmJ6eHFZNkVFMjRlRE9iR2RybTExNzE0NEpqTWdHRmF0aGowandVWmlh?= =?utf-8?B?S3d5bUN6bmYxM3VRNjZFeWJSbmxyMzlyNVNTbURnR2Z1TnNSdVBTZEszQ2FM?= =?utf-8?B?UzJSTTdWT2VnPT0=?= X-Microsoft-Antispam-Message-Info: w1DaeQzW+6qKljBkdfAYIYFmmBGJ3JEuV0DOjU3NX9CGzBFql2IRpF30Go8godx6NBWmtGYON/rUIHbrLbmmdSV3Z/vAZ8+xFyoaDnavHlD42rnqh3UIcd1RYJjXp00LTxStzcLfsO9O98iBCEuFk8ewrMNehTDMqmtG/jVIv5zoNGZRdUAa/aEYnay1Mae9 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 6:PwwPRxIEXTTa/I2KfKMP77CUEMP94haTphrrZGYIihi5ndi1/sgKtzuDCHHpO3V0pkbQBTftUd8QoWipcL5FkNqY+Ssc4vxIwlp0IASlEL8ohSdO/SsyHtdELzr6U/1vsi3voSjhtggYWdxRg+v234tOOnOaf9OIHJpsQMcXENbrlyR25tOVrQ/T2pwGgAfYjL+lMweDtjt+noOn7o0F69d/xTaf0rLMylU8G8WosqfLAHN3kp7ArFaXLDzMDMqRsk/qv/KpPeXoYrON+DlV781H066podkSL2pC44R1ChUdGWLOLMJGWpms1We02e6HhDDKneB/1obezG0xVWiXwxPH0RtLhbs6cpXd+Jg2Vjv83rv9rs/MT9BxfmXDjkof+I4QfIB+wbjpS5pw8rFPh+RskQO5tTbyRARbqJSMxizKxr5+YeBeRY8R8SrFjMe8yKTc6KbcH1Du+quzLD/YeQ==; 5:74wVlsWpI+xADp5TyrdUFhdxU/o7bKELI7FO9YP20jjLgiSOQl9q4xDCqLcAp9LEoOvdQIX+dNf7Z+TlPDHPSbKt+w3fEh3Q/Iq8rGSv6SW5cA2UatjDB5quLHG3MJ7F7a5Pn3SgoqRWCDRFNY+DttpAjNiZYfZlM6AJLrwwWio=; 24:O1Tz8NY6em2xTURUSuso/PWuPI2saFaWH+qYTmcEtA9Nul032zcO+yOu+ofx2aTxN37GLQAXbtuMCnK6EO4Z534OO5oqRVWflkOP9YsfNGA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 7:5pcWlD/ExBam2jUyLwaYdtNo51kY6ouHn6TTgshyGK/3im9gSVIisAmSb7G7DrrwJAxNVgANdlMfZBkCF86/thBmlpzMo53AmvdmQBUR+EAclyU0Ctly4bnDvasnDEgyrxf791imkDZ8UkCHlUsHBcCKL3Fk+rJeqsPDWeZJyYncp42QOjqRJDIrh2oK+71iyd4uSRjUh9J0uvuUNXlHcbu+f8XMQjOTxbNFGwrAYGQzQ6K4BBhpNS5szqSkURVJ X-MS-Office365-Filtering-Correlation-Id: 724f27ac-8180-4243-c9db-08d5c0a8dd31 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2018 12:29:43.8359 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 724f27ac-8180-4243-c9db-08d5c0a8dd31 X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1955 Archived-At: Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 12:29:51 -0000 Q29tbWVudHMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0NCj4gU2VudDogVHVlc2RheSwg TWF5IDIyLCAyMDE4IDEwOjAyIFBNDQo+IFRvOiBCZXJ0eiwgTHlsZSBUIFtDVE9dIDxMeWxlLlQu QmVydHpAc3ByaW50LmNvbT4NCj4gQ2M6IEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3Lmlu PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBkaW1lLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IGRp bWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1yZmM0MDA2YmlzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbRGltZV0gQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kaW1l LXJmYzQwMDZiaXMtMDg6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+DQo+IEhpLA0K Pg0KPiBJ4oCZbSBoYXZpbmcgc29tZSB0cm91YmxlIHRlbGxpbmcgeW91ciBjb21tZW50cyBmcm9t IEFsaXNzYeKAmXMuIFNvbWVob3cgdGhlDQo+IHF1b3RpbmcgaXMgcmV2ZXJzZWQgZnJvbSBub3Jt YWwgY29udmVudGlvbiwgc28gaXQgbG9va3MgbGlrZSBBbGlzc2EgaXMgcXVvdGluZw0KPiB5b3Uu IEJ1dCBJIHdpbGwgdHJ5IHRvIGZpZ3VyZSBpdCBvdXQgOi0pDQo+DQo+ID4gT24gTWF5IDIyLCAy MDE4LCBhdCA5OjIxIFBNLCBCZXJ0eiwgTHlsZSBUIFtDVE9dIDxMeWxlLlQuQmVydHpAc3ByaW50 LmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBDb21tZW50cyBpbmxpbmUuDQo+ID4NCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlzc2EgQ29vcGVyDQo+ID4gU2VudDogVHVlc2Rh eSwgTWF5IDIyLCAyMDE4IDY6MDggQU0NCj4gPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+ DQo+ID4gQ2M6IGRpbWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRm LWRpbWUtDQo+IHJmYzQwMDZiaXNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbRGltZV0gQWxpc3Nh IENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDZiaXMtMDg6DQo+ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBDQVVUSU9OOiBUaGlzIGVtYWlsIG9y aWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdA0KPiBjbGlj ayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5k ZXIgYW5kIGtub3cNCj4gdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gPg0KPiA+DQo+ID4gQWxpc3Nh IENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4g PiBkcmFmdC1pZXRmLWRpbWUtcmZjNDAwNmJpcy0wODogRGlzY3Vzcw0KPiA+DQo+ID4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVhc2UgcmVmZXIgdG8NCj4gaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaQ0KPiBl dGYub3JnJTJGaWVzZyUyRnN0YXRlbWVudCUyRmRpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwmZGF0 YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6JTQwc3ByaW50LmNvbSU3Q2E2MTljMmFlMjU1YQ0KPiA0 ZTNkYjY0ZjA4ZDViZmQ0NDA2MyU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdD MCU3QzAlDQo+IDdDNjM2NjI1ODQwNjg4NzU1NzUxJnNkYXRhPVRTdVN6THo1RXkyVEw0NWVnMlRE UWYlMkJWUVhCZWk2Y3hiVno1DQo+IHRVJTJGdGxSbyUzRCZyZXNlcnZlZD0wDQo+ID4gZm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4N Cj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+DQo+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyDQo+IGFja2Vy LmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1kaW1lLQ0KPiByZmM0MDA2YmlzJTJGJmRhdGE9 MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0NhNjE5YzJhZTI1NQ0KPiBhNGUz ZGI2NGYwOGQ1YmZkNDQwNjMlN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAl N0MwDQo+ICU3QzYzNjYyNTg0MDY4ODc1NTc1MSZzZGF0YT1yT2pzanhkbUc3SWNVRHpBdURodmtC OWNDT29wQXY3MHlQSA0KPiBDY2tMJTJCOVNBJTNEJnJlc2VydmVkPTANCj4gPg0KPiA+DQo+ID4N Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4N Cj4gPiA9IFNlY3Rpb24gNS42LjIgPQ0KPiA+DQo+ID4gSSdtIGhhdmluZyBhIGxpdHRsZSB0cm91 YmxlIHVuZGVyc3RhbmRpbmcgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGRlc2NyaWJlZA0KPiBpbiBT ZWN0aW9uIDUuNi4yIHNvIHdhbnRlZCB0byBzZWUgaWYgSSdtIGp1c3QgY29uZnVzZWQgb3IgaWYg dGhlcmUgaXMgc29tZXRoaW5nDQo+IHRvIGJlIGNsYXJpZmllZC4gVGhlIHRleHQgc2F5czoNCj4g Pg0KPiA+ICJJbiBhZGRpdGlvbiB0byB0aGUgUmVkaXJlY3QtU2VydmVyIEFWUCBvciBSZWRpcmVj dC1TZXJ2ZXItRXh0ZW5zaW9uDQo+ID4gICBBVlAsIHRoZSBjcmVkaXQtY29udHJvbCBzZXJ2ZXIg TUFZIGluY2x1ZGUgb25lIG9yIG1vcmUgUmVzdHJpY3Rpb24tDQo+ID4gICBGaWx0ZXItUnVsZSBB VlBzLCBvbmUgb3IgbW9yZSBGaWx0ZXItUnVsZSBBVlBzLCBvciBvbmUgb3IgbW9yZQ0KPiA+ICAg RmlsdGVyLUlkIEFWUHMgaW4gdGhlIENyZWRpdC1Db250cm9sLUFuc3dlciBtZXNzYWdlIHRvIGVu YWJsZSB0aGUNCj4gPiAgIHVzZXIgdG8gYWNjZXNzIG90aGVyIHNlcnZpY2VzIChmb3IgZXhhbXBs ZSwgemVyby1yYXRlZCBzZXJ2aWNlcykuICBJbg0KPiA+ICAgc3VjaCBhIGNhc2UsIHRoZSBhY2Nl c3MgZGV2aWNlIE1VU1QgZHJvcCBhbGwgdGhlIHBhY2tldHMgbm90IG1hdGNoaW5nDQo+ID4gICB0 aGUgSVAgZmlsdGVycyBzcGVjaWZpZWQgaW4gdGhlIFJlc3RyaWN0aW9uLUZpbHRlci1SdWxlIEFW UHMsIEZpbHRlci0NCj4gPiAgIFJ1bGUgQVZQcyBvciBGaWx0ZXItSWQgQVZQcy4gIElmIGVuZm9y Y2VtZW50IGFjdGlvbnMgb3RoZXIgdGhhbg0KPiA+ICAgYWxsb3dpbmcgdGhlIHBhY2tldHMgKGUu Zy4sIFFvUyksIGFyZSBpbmRpY2F0ZWQgaW4gdGhlIEZpbHRlci1SdWxlDQo+ID4gICBBVlBzIG9y IEZpbHRlci1JZCBBVlBzLCB0aGV5IFNIT1VMRCBiZSBwZXJmb3JtZWQgYXMgd2VsbC4gIEluDQo+ ID4gICBhZGRpdGlvbiwgaWYgcG9zc2libGUsIHRvIHJlZGlyZWN0aW5nIHRoZSB1c2VyIHRvIHRo ZSBkZXN0aW5hdGlvbg0KPiA+ICAgc3BlY2lmaWVkIGluIHRoZSBSZWRpcmVjdC1TZXJ2ZXIgQVZQ IG9yIFJlZGlyZWN0LVNlcnZlci1FeHRlbnNpb24NCj4gPiAgIEFWUC4iDQo+ID4NCj4gPiBJdCBz ZWVtcyBsaWtlIGlmIHRoZSBzZXJ2ZXIgc2VuZHMgYSBSZWRpcmVjdC1TZXJ2ZXIgQVZQIG9yIFJl ZGlyZWN0LVNlcnZlci0NCj4gRXh0ZW5zaW9uIEFWUCB3aXRob3V0IGFueSBvZiB0aGUgb3RoZXIg QVZQcywgdGhlbiBhbGwgdGhlIHRyYWZmaWMgaXMgc3VwcG9zZWQNCj4gdG8gYmUgcmVkaXJlY3Rl ZC4gQnV0IGlmIGEgUmVzdHJpY3Rpb24tRmlsdGVyLVJ1bGUgQVZQLCBGaWx0ZXItUnVsZSBBVlAs IG9yDQo+IEZpbHRlci1JZCBBVlAgaXMgYWxzbyBpbmNsdWRlZCwgdGhlbiB0aGUgbm9uLW1hdGNo aW5nIHRyYWZmaWMgTVVTVCBiZQ0KPiBkcm9wcGVkLCBpbiB3aGljaCBjYXNlIGhvdyBkb2VzIHRo ZSB1c2VyIGdldCByZWRpcmVjdGVkPyBJcyB0aGUgbGFzdA0KPiBzZW50ZW5jZSAod2hpY2ggaXMg YSBzZW50ZW5jZSBmcmFnbWVudCwgYWN0dWFsbHkpIHN1cHBvc2VkIHRvIGFkZHJlc3MgdGhpcw0K PiBzb21laG93PyBBbmQgaW4gdGhlIGNhc2Ugb2YgZW5mb3JjZW1lbnQgYWN0aW9ucyBpbnZvbHZp bmcgUW9TLCB0aGUgdGV4dA0KPiBzZWVtcyB0byBzYXkgdGhhdCBwYWNrZXRzIG1hdGNoaW5nIHRo ZSBmaWx0ZXIgTVVTVCBiZSBkcm9wcGVkIEFORCBoYXZlDQo+IHRoZSBRb1MgcnVsZXMgYXBwbGll ZCB0byB0aGVtLCBzbyBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoYXQgd29ya3MuDQo+ID4NCj4g Pj4gVGhlIHN0YXRlbWVudCAiSW4gc3VjaCBhIGNhc2UsIHRoZSBhY2Nlc3MgZGV2aWNlIE1VU1Qg ZHJvcCBhbGwgdGhlDQo+IHBhY2tldHMgbm90IG1hdGNoaW5nIHRoZSBJUCBmaWx0ZXJzIHNwZWNp ZmllZCBpbiB0aGUgUmVzdHJpY3Rpb24tRmlsdGVyLVJ1bGUNCj4gQVZQcyIgYW5kIGlzIHJlZHVu ZGFudCB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIFJlc3RyaWN0aW9uLUZpbHRlci1SdWxlLiAgRmls dGVyLQ0KPiBSdWxlIGFuZCB0aGUgcnVsZSByZWZlcnJlZCB0byBieSBGaWx0ZXItSWQgYWxzbyBj b250YWluIHRoZSBhcHByb3ByaWF0ZSB0cmFmZmljDQo+IGZpbHRlciBhbmQgYWN0aW9ucy4gSSB3 b3VsZCBwcm9wb3NlIGEgc2ltcGxpZmljYXRpb24sIHJlcGxhY2UgYWxsIHRleHQgZnJvbSAiSW4N Cj4gc3VjaCBhIGNhc2UgLi4uIiB3aXRoDQo+ID4NCj4gPiAiSW4gc3VjaCBhIGNhc2UsIHRoZSBh Y2Nlc3MgZGV2aWNlIE1VU1QgdHJlYXQgYWxsIHBhY2tldHMgYWNjb3JkaW5nIHRvIHRoZQ0KPiBS ZXN0cmljdGlvbi1GaWx0ZXItUnVsZSBBVlBzLCBGaWx0ZXItUnVsZXMgQVZQcyBhbmQgdGhlIHJ1 bGVzIHJlZmVycmVkIHRvIGJ5DQo+IHRoZSBGaWx0ZXItSWQgQVZQLiAgVGhpcyBpcyBpbiBhZGRp dGlvbiB0bywgaWYgcG9zc2libGUsIHJlZGlyZWN0aW5nIHRoZSB1c2VyIHRvIHRoZQ0KPiBkZXN0 aW5hdGlvbiBzcGVjaWZpZWQgaW4gdGhlIFJlZGlyZWN0LVNlcnZlciBBVlAgb3IgUmVkaXJlY3Qt U2VydmVyLQ0KPiBFeHRlbnNpb24gQVZQLuKAnQ0KPg0KPiBJIHRoaW5rIEFsaXNzYeKAmXMgcG9p bnQgaXMgdG8gYXNrIGhvdyByZWRpcmVjdGlvbiBhbmQgZmlsdGVyaW5nIGludGVyYWN0IHdoZW4g Ym90aA0KPiBhcmUgYWN0aXZlLiBEb2VzIF9yZW1haW5pbmdfIHRyYWZmaWMgZ2V0cyByZWRpcmVj dGVkIGFmdGVyIGFwcGx5aW5nIHRoZSBmaWx0ZXI/DQo+IE5vdGUgdGhhdCBzb21lIGZvcm1zIG9m IHJlZGlyZWN0aW9uIChlLmcuIEhUVFApIG1heSBub3Qgd29yayB2ZXJ5IHdlbGwgaWYNCj4gb25s eSBzb21lIHRyYWZmaWMgbWFrZXMgaXQuDQo+DQo+IEkgYWxzbyBoYXZlIHRvIHdvbmRlciBpZiBz b21lIG9mIHRoaXMgYmVoYXZpb3IgaXMgcmVhbGx5IGdvdmVybmVkIGJ5IGxvY2FsDQo+IHBvbGlj eSBhdCB0aGUgTkFTPw0KPg0KDQpUaGUgcnVsZXMgYXJlIGFsd2F5cyBlbmZvcmNlZCBwcmlvciB0 byByZWRpcmVjdGlvbiBvbiB0aGUgTkFTLg0KDQpUbyB5b3VyIHBvaW50LCB0aGUgcG9saWN5ICpj b3VsZCogZ292ZXJuIGxvY2FsIGJlaGF2aW9yIG9mIHJlZGlyZWN0IGluIHRoZSBydWxlIGJ1dCBp biBnZW5lcmFsIHRoaXMgaXMgcG9vciBwcmFjdGljZSwgZS5nLiB3aGF0IGlmIHR3byBydWxlcyB3 aXRoIHRoZSBzYW1lIHByZWNlZGVuY2UgcmVkaXJlY3QgdG8gZGlmZmVyZW50IGxvY2F0aW9ucyBm b3Igb3ZlcmxhcHBpbmcgdHJhZmZpYyBhbmQgYSBSZWRpcmVjdC1TZXJ2ZXItRXh0ZW5zaW9uIEFW UCBpcyBwcmVzZW50PyAgVGhpcyB3b3VsZCBkZWZpbml0ZWx5IGJlIHBvb3IgZGVzaWduIG9uIHRo ZWlyIHBhcnQuICBVc2VycyBvZiB0aGUgUmVkaXJlY3QtU2VydmVyIGFuZCBSZWRpcmVjdC1TZXJ2 ZXItRXh0ZW5zaW9uIEFWUCBhbGlnbiB0aGUgcnVsZXMgd2l0aCB0aGUgcmVkaXJlY3QgdXNlIGNh c2UuDQoNCj4gPg0KPiA+ID0gU2VjdGlvbiAxNS4xDQo+ID4NCj4gPiBSRkMgNjczMyBsaXN0cyBh IGJ1bmNoIG9mIHNlbnNpdGl2ZSBBVlBzIGFuZCB0aGVuIHNheXMgdGhpcyBhYm91dCB0aGVtOg0K PiA+DQo+ID4gIkRpYW1ldGVyIG1lc3NhZ2VzIGNvbnRhaW5pbmcgdGhlc2Ugb3IgYW55IG90aGVy IEFWUHMgY29uc2lkZXJlZCB0byBiZQ0KPiA+ICAgc2VjdXJpdHktc2Vuc2l0aXZlIE1VU1Qgb25s eSBiZSBzZW50IHByb3RlY3RlZCB2aWEgbXV0dWFsbHkNCj4gPiAgIGF1dGhlbnRpY2F0ZWQgVExT IG9yIElQc2VjLiAgSW4gYWRkaXRpb24sIHRob3NlIG1lc3NhZ2VzIE1VU1QgTk9UIGJlDQo+ID4g ICBzZW50IHZpYSBpbnRlcm1lZGlhdGUgbm9kZXMgdW5sZXNzIHRoZXJlIGlzIGVuZC10by1lbmQg c2VjdXJpdHkNCj4gPiAgIGJldHdlZW4gdGhlIG9yaWdpbmF0b3IgYW5kIHJlY2lwaWVudCBvciB0 aGUgb3JpZ2luYXRvciBoYXMgbG9jYWxseQ0KPiA+ICAgdHJ1c3RlZCBjb25maWd1cmF0aW9uIHRo YXQgaW5kaWNhdGVzIHRoYXQgZW5kLXRvLWVuZCBzZWN1cml0eSBpcyBub3QNCj4gPiAgIG5lZWRl ZC4iDQo+ID4NCj4gPiBJdCBzZWVtcyBsaWtlIHRoZSBsaXN0IG9mIEFWUHMgaW4gU2VjdGlvbiAx NS4xIHNob3VsZCBoYXZlIHRoZXNlIHNhbWUNCj4gcmVxdWlyZW1lbnRzIGFwcGxpZWQgdG8gdGhl bSBleHBsaWNpdGx5Lg0KPiA+DQo+ID4+IDY3MzMgaXMgY2xlYXIgYWJvdXQgd2hhdCBhcHBsaWVz IHdoZW4gZGVjbGFyZWQgYXMgc2VjdXJpdHkgc2Vuc2l0aXZlIGJ1dA0KPiB0aGUgYWRkaXRpb24g b2YgdGhlIGZvbGxvd2luZyBtYXkgaGVscC4NCj4gPg0KPiA+ICJBcyBzZW5zaXRpdmUgQVZQcyB0 aGUgRGlhbWV0ZXIgbWVzc2FnZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkIGluDQo+IFNlY3Rpb24g MTMuMyBvZiBSRkMgNjczMyBhcHBseS7igJ0NCj4NCj4gSSB3YXMgZ29pbmcgdG8gc2F5IHNvbWV0 aGluZyBzaW1pbGFyOyA2NzMzIGlzIHRoZSBiYXNlIHByb3RvY29sLiBUaGlzIGRyYWZ0DQo+IGlu aGVyaXRzIHRoZSBub3JtYXRpdmUgcnVsZXMgYnkgd2F5IG9mIHVzaW5nIERpYW1ldGVyLiBCdXQg aXQgZG9lc27igJl0IGh1cnQgdG8NCj4gcmVpbmZvcmNlIHRoZW0gbW9yZSBzdHJvbmdseSBkZXNj cmlwdGl2ZSBsYW5ndWFnZS4gSG93IGFib3V0IHNvbWV0aGluZyB0bw0KPiB0aGUgZWZmZWN0IG9m IOKAnSBUaGUgcHJpdmFjeS1zZW5zaXRpdmUgQVZQcyBsaXN0ZWQgaW4gdGhpcyBzZWN0aW9uIG11 c3QgYmUgc2VudA0KPiBhY3Jvc3Mgbm9uLXRydXN0ZWQgbmV0d29ya3Mgb3IgRGlhbWV0ZXIgYWdl bnRzIHdpdGhvdXQgZW5kLXRvLWVuZA0KPiBhdXRoZW50aWNhdGlvbiBhbmQgY29uZmlkZW50aWFs aXR5IHByb3RlY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBbUkZDNjczM10NCj4gc2VjdGlvbiAxMy4z Ig0KPg0KDQpQZXJmZWN0ISBXZSB3aWxsIGZpeC4NCg0KPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IENPTU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gPSBTZWN0aW9uIDEg PQ0KPiA+DQo+ID4gKDEpIEkga25vdyBpdCdzIGEgdGVybSBvZiBhcnQsIGJ1dCB0aGUgdGVybSAi bmV4dCBnZW5lcmF0aW9uIHdpcmVsZXNzDQo+IG5ldHdvcmtzIg0KPiA+IHNlZW1zIGEgYml0IG91 dCBvZiBwbGFjZSBpbiB0d28gd2F5czogKDEpICJ3aXJlbGVzcyIgc2VlbXMgbW9yZSBnZW5lcmlj DQo+IHRoYW4gd2hhdCBpcyBpbXBsaWVkIChpLmUuLCAiY2VsbHVsYXIsIiBJIGFzc3VtZSksIGFu ZCAoMikgaXMgUmVsLTEzIGNvbnNpZGVyZWQNCj4gIm5leHQgZ2VuZXJhdGlvbiIgc3RpbGw/DQo+ ID4NCj4gPj4gRmFpciBwb2ludC4gICBXZSB0ZW5kIHRvIHVzZSAid2lyZWxlc3MiIHRob3VnaCBh cyBvcHBvc2VkIHRvICJjZWxsdWxhciIuDQo+IERyb3BwaW5nICduZXh0IGdlbmVyYXRpb24nIG1h a2VzIHNlbnNlLg0KPg0KPiBIb3cgYWJvdXQg4oCcbW9iaWxlIG5ldHdvcmtz4oCdPw0KDQpXZSBh cmUgZmluZSB3aXRoIHRoYXQuDQoNCj4NCj4gPg0KPiA+ICgyKSAiRGlhbWV0ZXIgYmFzZSBwcm90 b2NvbCIgc2hvdWxkIGNpdGUgUkZDIDY3MzMuDQo+ID4NCj4gPj4gSWYgdGhlIERJU0NVU1MgY2Fu IGJlIHJlc29sdmVkIGFuZCB3ZSBoYXZlIGEgbmV4dCByZXZpc2lvbiAoSSBhc3N1bWUgd2UNCj4g d2lsbCkgd2UgY2FuIHVwZGF0ZSB0aGlzDQo+DQo+IFBsZWFzZSBhc3N1bWUgdGhlcmUgd2lsbCBi ZSBhbm90aGVyIHJldmlzaW9uICA6LSkNCg0KOkQNCg0KPg0KPiA+DQo+ID4gPSBTZWN0aW9uIDUu MSA9DQo+ID4NCj4gPiBBc3N1bWluZyBHLVMtVSBzdGFuZHMgZm9yIGdyYW50ZWQgc2VydmljZSB1 bml0LCB0aGUgYWNyb255bSBzaG91bGQgYmUNCj4gZ2l2ZW4gdXBvbiBmaXJzdCB1c2UgaGVyZS4N Cj4gPg0KPiA+PiBDYW4gdXBkYXRlIGluIG5leHQgcmV2aXNpb24gYWxvbmcgd2l0aCB0aGUgRElT Q1VTUyBpdGVtcw0KPiA+DQo+ID4gPSBTZWN0aW9uIDguNTIgPQ0KPiA+DQo+ID4gKDEpIFdoeSBk byB5b3UgbmVlZCB0byBzcGVjaWZ5IHRoZSBhYmlsaXR5IHRvIHNlbmQgZWl0aGVyIHRoZSBJTUVJ U1Ygb3IgdGhlDQo+IElNRUk/DQo+ID4NCj4gPj4gVGhleSBhcmUgZGlzdGluY3Qgc3RydWN0dXJl cyBhbmQgdGhlIGxhdGVzdCBnZW5lcmF0aW9uIG9mIG5ldHdvcmtzIGFyZQ0KPiBzdGFydGluZyB0 byB1c2UgSU1FSVNWICh3aXRoIG5vIHN1cHBvcnQgZm9yIGp1c3QgdGhlIElNRUkpLiAgSG93ZXZl ciwgdGhlDQo+IElNRUkgdmFsdWUgaXMgaWRlbnRpY2FsLg0KPiA+DQo+ID4gKDIpDQo+ID4gIklm IHRoZSB0eXBlIG9mIHRoZSBlcXVpcG1lbnQgaXMgb25lIG9mIHRoZQ0KPiA+ICAgZW51bWVyYXRl ZCB0eXBlcyBvZiBVc2VyLUVxdWlwbWVudC1JbmZvLVR5cGUgQVZQLCB0aGVuIHRoZSBjcmVkaXQt DQo+ID4gICBjb250cm9sIGNsaWVudCBTSE9VTEQgc2VuZCB0aGUgaW5mb3JtYXRpb24gaW4gdGhl IFVzZXItRXF1aXBtZW50LUluZm8NCj4gPiAgIEFWUCwgaW4gYWRkaXRpb24gdG8gb3IgaW5zdGVh ZCBvZiB0aGUgVXNlci1FcXVpcG1lbnQtSW5mby1FeHRlbnNpb24NCj4gPiAgIEFWUC4iDQo+ID4N Cj4gPiBXaHkgaXMgdGhpcyBub3JtYXRpdmUgcmVjb21tZW5kYXRpb24gaW4gc3VwcG9ydCBvZiBi YWNrd2FyZHMNCj4gY29tcGF0aWJpbGl0eSBkaWZmZXJlbnQgZnJvbSB0aGUgb25lIGdpdmVuIGZv ciB0aGUgU3Vic2NyaXB0aW9uLUlkLUV4dGVuc2lvbg0KPiBBVlAgaW4gU2VjLiA4LjU4Pw0KPiA+ DQo+ID4+IEl0IHdhcyBmb3VuZCB0aGF0IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGlzc3VlcyB3 ZXJlIG1vcmUgcHJldmFsZW50DQo+IHdpdGggVXNlci1FcXVpcG1lbnQtSW5mbyBhcm91bmQgdGhl IElNRUlTViBhbmQgc29tZSBpbXBsZW1lbnRhdGlvbnMNCj4gY2FuIGRlYWwgd2l0aCBJTUVJU1Yg YW5kIElNRUkuIFRoZSBsYW5ndWFnZSBhYm92ZSBpcyBhZ2dyZXNzaXZlIGluDQo+IHJlY29tbWVu ZGluZyB0aGUgImluIGFkZGl0aW9uIHRvIiBpbiBvcmRlciB0byBtYXhpbWl6ZSBjb21wYXRpYmls aXR5LiAgOC41OCBpcw0KPiBjbGVhbmVyIGluIHRlcm1zIG9mIGl0cyByZWNvbW1lbmRhdGlvbiBh bmQgcHJvZHVjdGlvbiBpc3N1ZXMgaGF2ZSBub3QgYmVlbg0KPiBzZWVuIG9uIHRoaXMgQVZQIHNv IGl0IHNlZW1lZCBhcHByb3ByaWF0ZSB0byBsaW1pdCB0aGUgQVZQIHZhbHVlcyB0byBvbmUgb3IN Cj4gdGhlIG90aGVyIGFuZCBub3QgYm90aCBhcyBpdCBpcyBmb3IgVXNlci1FcXVpcG1lbnQtSW5m byBhbmQgVXNlci1FcXVpcG1lbnQtDQo+IEluZm8tRXh0ZW5zaW9uLg0KPg0KPiBBc3N1bWluZyBB bGlzc2EgaXMgb2theSB3aXRoIHRoZSBleHBsYW5hdGlvbnMgZm9yIGJvdGggcG9pbnRzLCBwbGVh c2UgYWRkDQo+IHNvbWUgZXhwbGFuYXRvcnkgdGV4dCB0byB0aGUgc2VjdGlvbi4NCj4NCg0KWWVz DQoNCj4gPg0KPiA+ID0gU2VjdGlvbiAxNS4xID0NCj4gPg0KPiA+ICJSZWRpcmVjdC1TZXJ2ZXIt QWRkcmVzcyBBVlA6IHRoZSBzZXJ2aWNlLXByb3ZpZGVyIG1heSBlbWJlZA0KPiA+ICAgICAgICBw ZXJzb25hbCBpbmZvcm1hdGlvbiBvbiB0aGUgc3Vic2NyaWJlciBpbiB0aGUgVVJML0kgKGUuZy4g dG8NCj4gPiAgICAgICAgY3JlYXRlIGEgcGVyc29uYWxpemVkIG1lc3NhZ2UpLiINCj4gPg0KPiA+ IFRoaXMgc2VlbXMgbGlrZSBhIGJhZCBpZGVhIHRoYXQsIGlmIGl0J3MgZ29pbmcgdG8gYmUgbWVu dGlvbmVkLCBzaG91bGQgYmUNCj4gcmVjb21tZW5kZWQgYWdhaW5zdC4NCj4gPg0KPiA+PiBNYWtl cyBzZW5zZS4gIEkgd291bGQgcmVjb21tZW5kIGFkZCB0aGUgc2VudGVuY2UgIkhvd2V2ZXIsIHRo aXMgaXMNCj4gbm90IHJlY29tbWVuZGVkLuKAnQ0KPg0KPiBJdOKAmXMgYWxzbyBjb21tb25seSBk b25lLCBpc27igJl0IGl0PyBJIHRoaW5rIHRoZSBwb2ludCBpcyB0byBtZW50aW9uIHRoYXQgdGhl IEFWUA0KPiBpcyBzZW5zaXRpdmUgYmVjYXVzZSBwZW9wbGUgbWlnaHQgZG8gdGhpcywgbm90IHRv IG9mZmVyIHBlcm1pc3Npb24uIFRoZXJl4oCZcw0KPiBhbHJlYWR5IHRleHQgcmVjb21tZW5kaW5n IGFnYWluc3QgZGlyZWN0bHkgdXNpbmcgcGVyc29uYWwgaW5mb3JtYXRpb24uDQo+IFdvdWxkIGl0 IGhlbHAgdG8gY2hhbmdlIOKAnG1heeKAnSB0byDigJxtaWdodOKAnT8gdG8gYXZvaWQgYW55IHNl bWJsYW5jZSBvZg0KPiDigJxwZXJtaXNzaW9u4oCdPw0KPg0KPiBTb21lIG9mIHRoZSBvdGhlciBB VlBzIGxpa2VseSBjYXJyaWVkIGluIHRoZSBzYW1lIG1lc3NhZ2UgYXJlIGdvaW5nIHRvIGhhdmUN Cj4gcGVyc29uYWxseSBpZGVudGlmaWFibGUgaW5mb3JtYXRpb24gb25lIHdheSBvciBhbm90aGVy IChpLmUuIFN1YnNjcmlwdGlvbi1JRCkuDQo+DQoNCklmICJtaWdodCIgd29ya3MgZm9yIGV2ZXJ5 b25lIHdlJ2xsIG1ha2UgdGhlIGNoYW5nZS4NCg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1F QGlldGYub3JnDQo+ID4NCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaQ0KPiBldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGZGltZSZkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzDQo+IHByaW50LmNv bSU3Q2E2MTljMmFlMjU1YTRlM2RiNjRmMDhkNWJmZDQ0MDYzJTdDNGY4YmMwYWNiZDc4NGJmNWI1 NQ0KPiBmMWIzMTMwMWQ5YWRmJTdDMCU3QzAlN0M2MzY2MjU4NDA2ODg3NTU3NTEmc2RhdGE9cTNM RTZ6cXVodkFWSiUNCj4gMkI2ckp6bHFmZXA4MHIzSlpyWDV3Z29BU0h3aWklMkJRJTNEJnJlc2Vy dmVkPTANCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4g PiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24g aW50ZW5kZWQgZm9yIHRoZQ0KPiBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNl IGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdA0KPiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGll cyBvZiB0aGUNCj4gbWVzc2FnZS4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNv bnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3Qg dGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Wed May 23 06:58:39 2018 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 5116E12706D; Wed, 23 May 2018 06:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyONNzUlVoyr; Wed, 23 May 2018 06:58:34 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380F5126D85; Wed, 23 May 2018 06:58:33 -0700 (PDT) X-AuditID: 12074424-e67ff70000000267-fc-5b057386c307 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 07.DC.00615.683750B5; Wed, 23 May 2018 09:58:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w4NDwSjC027896; Wed, 23 May 2018 09:58:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4NDwM0o015315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 May 2018 09:58:25 -0400 Date: Wed, 23 May 2018 08:58:23 -0500 From: Benjamin Kaduk To: Yuval Lifshitz Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <20180523135822.GA32807@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <380581659.4450262.1527064311638@mail.yahoo.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrNtezBptcOmAqMX8ztPsFmsPplnM 7V3BZrFk4gRWixl/JjJbHP/2kN2BzWPJkp9MHrN2PmHxmDXrMFMAcxSXTUpqTmZZapG+XQJX xoI7Z9kKGiYyVuzqPcHcwPilpIuRk0NCwERi3cRrLF2MXBxCAouZJHZu+coOkhAS2Mgo0bCI GSJxlUli0ZblrCAJFgFViVe/ZzGD2GwCKhIN3ZfBbBEBNYnHjTfYQBqYBfoZJa6fPQ+WEBbI lvg0YQIbiM0LtO7/zytQU7cxStzqfs8MkRCUODnzCQuIzSygLvFn3iWgOAeQLS2x/B8HRFhe onnrbLByTgFbiUNb3oEdJCqgLLG37xD7BEbBWUgmzUIyaRbCpFlIJi1gZFnFKJuSW6Wbm5iZ U5yarFucnJiXl1qka66Xm1mil5pSuokRFAvsLio7GLt7vA8xCnAwKvHwamSwRguxJpYVV+Ye YpTkYFIS5Y08wxItxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ3NAaonDclsbIqtSgfJiXNwaIk zpu7iDFaSCA9sSQ1OzW1ILUIJivDwaEkwStWBNQoWJSanlqRlplTgpBm4uAEGc4DNNwKpIa3 uCAxtzgzHSJ/ilGXo+P9lB5mIZa8/LxUKXHeOJAiAZCijNI8uDmgFCaRvb/mFaM40FvCvE4g VTzA9Ac36RXQEiagJReXM4MsKUlESEk1MHKwreh2vNtv1Bmv/T1yw6UCweLlCt1cnxdencgs OlOy8NPLZaf8dYynXptVsGXhiosBa4sK/t4vLVWTEFt98m99wn+5rUsKw0J1qyNmdHOw3J7h cPVKVZJcU1TMul2/yi4YnOcvcDp+h3dR3fVDl/Y5TvbY2/S+x8Xy9f4+nY41/non2abO5Vdi Kc5INNRiLipOBADJutAqPAMAAA== Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 13:58:38 -0000 [re-sending since my client crashed during the first attempt and I don't see the message in the archives. I attempted to reconstruct my message from a scrollback buffer, but there may be some artifacts with missing or duplicated text] On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > Thanks Ben and Benjamin! Comments inline > On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell wrote: > > Hi Benjamin, > > I’ve cherry-picked a few points, inline: > > Thanks! > > Ben. > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > I appear to have a different understanding of Section 5.6.2, though, > > with a different potential issue (but again, it's possible that I'm > > confused to how things work): > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > like the user can be redirected (at the application protocol level, > > e.g., HTTP or SIP) to a top-up server to purchase more credits.  I > > don't see a way described how user agents can distinguish between a > > Diameter-induced redirect and an attacker-induced redirect to a > > (potentially phishing) site that accepts payment information.  To be > > clear, the scenario here is that a user is using a credit-controlled > > application session to talk to "arbitrary application servers", > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > the attacker could introduce a redirect to a phishing page that asks > > for payment information, and the user would be led to believe that > > this was the normal flow for "my prepaid balance has been used up", > > and give their payment information to the phishing site. I think > > that either user agents need to give some indication that this > > DIAMETER-level redirect is different than an > > application-protocol-level redirect (e.g., http) or the Security > > Considerations need to mention the risk of acclimating users to > > arbitrary websites redirecting to sites asking for payment > > credentials, which may or may not be legitimate sites. > > > > I think it’s reasonable to mention the concern in the security considerations. But I don’t see how a redirection based on this specification is any different than any other time an HTTP browser or SIP UA connects to a resource based on an arbitrary URL. In some sense, it's not. My claim is more that users are being conditioned to expect payment prompts to appear at "arbitrary times" than a specific flaw in this workflow. > But to put some more context around this, the Diameter client is typically a Network Access Server (NAS) that the end user is using for network access. The user is already at the mercy of that NAS, and that NAS is at the mercy of the credit-control application server. The user’s trust in that NAS seems to have the same issues whether or not this Diameter application is used. > > [yuval] agree with Ben, if someone bad took control over the NAS, they can do much worse I agree that the NAS could send traffic to "wherever", but my objection could perhaps be categorized as more "social" than "technical". Maybe I should attempt to give an example (and you can point out if I misunderstand things). I believe that a "normal usage" of this technology could be for a user with a prepaid data plan to be using a web browser, and, e.g., connect successfully to https://example.com. Suppose that this request used up their last remaining credits, and they click on a link from that page. Instead of going to the actual target of that link, they are redirected to the data plan owner's top-up page, which displays a message "your balance is zero; please enter credit card information to purchase more data", the user pays, and can potentially even be redirected back to the actual target of the link they clicked on (though that's not key to my example). Let's consider what would happen in an "attack scenario", where the same user has plenty of data quota remaining, and goes to https://honest-achmed.com. They click on a link from that page, which instead of going to an "actual site" that would be expected from the context surrounding the link, actually goes to http://[IP address controlled by attacker]/topup.html, which is designed to look as similar as possible to the actual data plan owner's top-up page. The user may then enter their payment information, and get redirected to a site with actual content, believing that they have obtained more data quota from their provider, when in reality they have given their credit card information to a phisher. I don't see what mechanism is in place to allow the user to be able to distinguish between the "normal usage" scenario and the "attack scenario". I also understand that this sort of technology is already deployed and is seen as useful by both users and data providers, so it seems unrealistic to expect to be able to get rid of this usage entirely. I do think that it is unreasonable for us to enable this behavior without documenting the risks to the user, though. > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > >  If the Final-Unit-Action AVP is set to REDIRECT at least the > >  Redirect-Server-Extension AVP MUST be present. > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > section 8.64 even internally inconsistent, too?) about > > "Redirect-Server AVP, in addition to or instead of the > > Redirect-Server-Extension AVP", in particular, the "instead of" > > portion.  (The ABNF-based formal language spec in 8.68 does match up > > with the above MUST, though.) > > Would changing “in addition to or instead of” in 8.64 to just “in addition to” help? > > Authors: Please comment if that works, given the backwards-compatibility concern. > [yuval] the cumbersome text is because of backward compatibility issue. Would appriciate suggestion for better phrasing. The idea is the following:* We have an existing AVP that can carry some information* We need more information, but we cannot modify the existing one, so we added a new AVP (which, unlike the old one, is future proof)* If you have a peer that does not support the new spec, but only need the old info, you can use the old AVP. what makes the spec backward compatible to the old one* If you have need to send the new info, you have to use the new AVP, but in this case an older peer does not make sense To Ben, I believe that just "in addition to" resolves the internal inconsistency. However, it sounds like that may not be the best solution from a deployment perspective, and perhaps the formal definition in Section 8.68 (and the body text) should be relaxed to allow either the -Extension or non-Extension form. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some additional significant but not necessarily DISCUSS-worthy > > comments, followed by more editorial- and nit-level things. > > > > In Section 1.3, "Advertising Application Support" uses the same > > Auth-Application-ID value as for RFC 4006; what are the interop > > consequences of this? > > [yuval] this was done to make interops easier - this is why we kept this RFC backward compatible with RFC4006 > > Alissa already noted that the text about how to split (sub-)AVPs > > between the foo and foo-Extension AVPs is inconsistent among them -- > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > send [in the old one]", but Subscription-Id-Extension has separate > > text about "[i]f full backward compatibility with [RFC4006] is > > required" and slightly different behavior described.  We should try > > to catch all instances of this sort of backwards compatibility and > > make them consistent. > > I agree. > [yuval] will look to unify the text I see that there was some discussion on Alissa's ballot thread that there may indeed be special considerations for one AVP. If so, that's fine, but the reasoning should probably be included in the document to explain the apparent disparity. > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > > might benefit from additional text about the expected contents.  A > > lot of the time when we use a UTF8 container for names (whether > > domain names or other kinds), we specify what normalization form and > > canonicalization are performed, whether domain names are A-labels or > > U-labels, etc., as there's a lot of potential flexibility not all of > > which is good.  In this case, since the communication is only > > between trusted actors, perhaps the additional restrictions are not > > needed, but I am curious if the topic was raised in the WG. > > On reflection, shouldn’t that be based on whatever rules already exist for the URL scheme? And if some scheme doesn’t have well defined behavior for non-ascii labels, is that the concern of this application? It is probably a matter for the URL scheme, yes. So at most we could note here that "individual URL schemes may restrict the contents of the UTF8String", but as I imply in my original comment, it's far from clear to me that we actually need to say anything in this specific case. > > > > Thank you for adding the Privacy Considerations and list of > > Privacy-Sensitive AVPs! > > > > Section 14 > > > >  [...] The Diameter credit- > >  control application is often used within one domain, and there may be > >  a single hop between the peers.  In these environments, the use of > >  TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > I did not see any concrete guidance on what would suffice in other > > environments (with multiple hops between peers).  Is this the realm > > of the mythical "end-to-end security mechanism" for Diameter that is > > much-desired?  (The last paragraph does have guidance on what might > > *not* suffice, which is not exactly the same thing.) > > > > Sort of, but in real world deployments the “often used within one domain” (assuming domain means “trust domain”, which should be clarified) effectively overrides everything else. That is far from ideal, but it’s the reality. So it basically comes down to keep everything in the trust domain, or if you cross a non-trusted network then use TLS or IPSec. > > There’s no solution to safely traverse a non-trusted Diameter agent. The mythical e2e mechanism could conceivably give us that.  (someday, along with world peace and a post-scarcity economy). > > [yuval] as Ben and Lyle wrote, if your messages need to go through agents that belong to a 3rd party, you have risks. In this case, AVP level encryption (which is not standardized yet...) is the only option for to ensure privacy. So, the only thing we can do here is to highlight the risks.  Do we want to say something about "at present, there is not a general reliable security solution for other environments"? (To be clear, I do not insiste that we do so.) > >  Even without any modification to the messages, an adversary can > >  eavesdrop on transactions that contain privacy-sensitive information > >  about the user. > > > > This ("an adversary can") makes it sounds as if there is no > > confidentiality protection anywhere in the system, but that's what > > TLS/DTLS/IPSec are supposed to provide.  So maybe "an adversary that > > can eavesdrop on transactions can obtain privacy-sensitive > > information [...]" is better. > > > > Good point, I agree your suggestion is better.[yuval] ok > > > (Editorial- and nit-level stuff follows.) > > > > Section 4 > > > >  A flexible credit-control application specific failure handling is > >  defined in which the home service provider can model the credit- > >  control client behavior according to its own credit risk management > >  policy. > > > > This sentence is hard to parse -- in "credit-control application > > specific" what does "specific" bind to?  What is being modelled?  Is > > anything being controlled (as opposed to modelled)? > [yuval] ok. so how about: > "Flexible failure handling, specific to the credit-control, is defined in the application.This allows the the service provider to control the credit-control client behavior according to its ownrisk management policy" That's much better; thanks! > > Section 4.1.1 > > > >  2.  The Service-Parameter-Info AVP MAY be used as a container to pass > >  legacy rating information in its original encoded form (e.g., ASN.1 > >  BER).  [...] > > > > Why BER and not DER?  The unnecessary flexibility in BER vs. DER has > > been known to tickle parser bugs and create security > > vulnerabilities. > >  > [yuval] this is just an example of legacy stuff you have no control over > > > Section 4.1.2 > > > >  [...] To > >  facilitate interoperability, it is RECOMMENDED that the rating input > >  and the values of the Service-Context-Id be coordinated via an > >  informational RFC or other permanent and readily available reference. > >  The specification of another cooperative standardization body (e.g., > >  3GPP, OMA, or 3GPP2) SHOULD be used. > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > >  > [yuval] yes, seems a bit awkward. How about: > "To facilitate interoperability, it is RECOMMENDED that the rating input > and the values of the Service-Context-Id be coordinated via an > informational RFC or other permanent and readily available reference, > preferably, of another cooperative standardization body (e.g., >  3GPP, OMA, or 3GPP2)." Sounds good. > > Section 5.1.1 > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > seems that this text could be reworded to just talk about a > > "constant rate" or "constant level per fixed time period" or > > similar. > >  > [yuval] "constant rate" could mean sub-second resolution as well. The grants are in seconds, so, IMO, this phrasing is more accurate It seems that it's only more accurate if leap seconds are ignored. (I suppose you could explicitly disclaim "(ignoring leap seconds)" or similar.) > > Section 5.1.2 > > > >  [...] > >  timer (Section 13) every time a CCR message with the value > >  UPDATE_REQUEST is sent while they are in PendingU state.  When > >  answers to all pending messages are received, the state machine moves > >  to OPEN state, and Tx is stopped. > > > > Transmission, or the Tx timer (is stopped)? > >  > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense of "transmission" in the RFC (I think that "Tx timer" was fairly consistently used throughout the rest of the document; it may make sense to be fully consistent about it.) > > Using a different title for Section 5.2.2 might make the parallel > > between it and Section 5.2.1 more clear.  That is, perhaps something > > like "First Interrogation Included with Authorization Messages". > >  > [yuval] make sense > > > Section 5.7 > > > >  [...] It is RECOMMENDED that the client complement the credit- > >  control failure procedures with backup accounting flow toward an > >  accounting server. [...] > > > > Nit: it looks like there's a missing article here, maybe "a backup > > accounting flow" is better. > >  > [yuval] the rest of the paragraph describe such "backup accounting flow". See what comes after "For example" I just meant that it sounds like you need to add the word "a" in order for the grammar to make sense. (But perhaps "the" is the right word; I wasn't sure.) > >  The AAA transport profile [RFC3539] defines the application layer > >  watchdog algorithm that enables failover from a peer that has failed > >  and is controlled by a watchdog timer (Tw) defined in [RFC3539]. > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > >  > [yuval] would imagine there are other algorithms out there... should fix > > > Section 6.2 > > > > Should there be text indicating how the client indicates what > > service the balance check is being requested for? > >  > [yuval] didn't find any reference to service information for "EVET_REQUEST" type messages (direct debit, refund, balance check and price enquiry). Seems like that in the IEC section of 3GPP TS 32.299, they added their own mechanism for "direct debit", and "refund", and leave "balance check" and "price enquiry" as references to RFC4006. Unless I've missed something, this seems like a missing part of the spec. > > > Section 8.54 > > > > Maybe give a section reference in RFC 3580 for how the formatting is > > done? > >  > [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 in our RFC > > > Section 12 > > > >  [...] Initially, such Expert discussions take place on the AAA > >  WG mailing list. > > > > That list appears to be dead, suggesting that this text should be > > updated.  (I also agree with Adam's comments about updating the IANA Considerations.) > >  > [yuval] i don't know the process here - not sure how to change it. With respect to the "expert discussions take place" text, I think it could just be removed. Discussion of the detailed updates to the IANA actions should probably happen in Adam's ballot thread. > > Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3? > [yuval] should be added there as well Great, thanks. -Benjamin From nobody Wed May 23 07:37:49 2018 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 D07AA12E046; Wed, 23 May 2018 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stzmtQ-tqlrU; Wed, 23 May 2018 07:37:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DAC12E03C; Wed, 23 May 2018 07:37:45 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4NEbcNO095181 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 May 2018 09:37:39 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Yuval Lifshitz , The IESG Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org References: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> <1651457572.4445831.1527066817455@mail.yahoo.com> From: Adam Roach Message-ID: <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com> Date: Wed, 23 May 2018 09:37:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1651457572.4445831.1527066817455@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------092FB7C4EC9086C320810147" Content-Language: en-US Archived-At: Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 14:37:48 -0000 This is a multi-part message in MIME format. --------------092FB7C4EC9086C320810147 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/23/18 4:13 AM, Yuval Lifshitz wrote: > > §1.1: > > This document uses lowercase forms of RFC-2119-defined terms. Please > update this > section to use the boilerplate from RFC 8174. > > /[yuval] we use them in lowercase, without their normative meaning. Is > this an issue?/ > /For example: "// > a commercial agreement must exist between the > // > visited domain and the home domain" is just informational > / It's not the language use that's an issue. RFC 2119 has been updated, and since you use the lowercase terms, the update is relevant to your document. The fix is to simply replace your existing text with: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described inBCP 14 [RFC2119 ] [RFC8174 ] when, and only when, they appear in all capitals, as shown here. > > §5.6.2: > > >  The credit-control > >  client receives a Credit-Control-Answer or service specific > >  authorization answer with the Final-Unit-Indication or the QoS-Final- > >  Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- > >  Unit AVP. > > This has the same confusion as above regarding the application of logical > combinations. The second half of the statement is of the form "A or B > and C > but not D," which is pretty ambiguous. It's also a little unclear > whether the > client receives a Credit-Control-Answer (with A or B and C but not D), > or just > a Credit-Control-Answer of any description, full stop. > > /[yuval] how about this:/ > /" > When the credit-control / > client receives (either at session or service specific level) a > // > Final-Unit-Indication AVP or QoS-Final- > // > Unit-Indication AVP, together with Validity-Time AVP, > / > / > but without Granted-Service- > // > Unit AVP, it immediately starts the graceful service termination > / >    without sending any message to the server." > / Sounds good to me. Thanks. > --------------------------------------------------------------------------- > > §8.65: > > >  The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type > >  Address and defines the IPv4 or IPv6 address of the redirect server > >  with which the end user is to be connected when the account cannot > >  cover the service cost. > > This appears to be underspecified, unless I've missed some specification > elsewhere regarding what the client is supposed to do with this IP > address. > While the other redirection methods (HTTP, SIP) have relatively clear > means of > contact (they indicate a protocol), the indication of only an IP > address with > neither protocol nor port doesn't seem to provide enough information for a > client to act on.  Please either flesh this out in this section, or > point to > another document that indicates how this IP address is to be used. > > /[yuval] I think this is left unspecifid on purpose. There are many > ways to redirect IP addresses (e.g. different tunneling mechanism), > don't think we want to list them here?[yuval]/ If it's an open-ended set of behaviors (or a set of behaviors that is unrealistic to list), then I would expect the document to at least let implementors know that they're not going to find any further guidance in this document or other RFCs. Perhaps add something like: "The interpretation of Redirect-Address-IPAddress by the Diameter Credit-control Client is a matter of local policy." > > --------------------------------------------------------------------------- > > §12: > > When new documents obsolete an RFC that originally registered values > with IANA, > I'm used to seeing that document also update the IANA registry so that the > corresponding entries now point to the new document. You may consider > text that > instructs IANA to update the existing RFC-4006-registered values so > that they > point to this document instead of RFC 4006. > > /[yuval] don't know what the process here. but does it need to go into > the RFC?/ Typically, that's how we give instructions to IANA pertaining to document updates, yes. See https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-11 for an example. > > --------------------------------------------------------------------------- > > Appendix B: > > As a general comment for all of the examples: I'm surprised that none > of the > examples have been updated to reflect the newly defined capabilities > in this > document. For example, all the examples in this appendix use > Final-Unit-Indication rather than QoS-Final-Unit-Indication. In > practice, to > show maximally flexible and compatible examples, I would expect that the > examples would include both AVPs. This applies to all of the "Extension" > AVPs as well. > > /[yuval] the examples are more around the flow and less about the > actual content./ > /With respect to flow, there is no difference between the old and new > AVPs - and we wanted to minimize unnecessary changes. Only flow that > was modified was reflected in a new diagram at the end of section 5.6 > ("zero GSU")/ While I don't agree with the rationale here, this is an editorial comment about a non-normative part of the document, so it's ultimately your decision. /a --------------092FB7C4EC9086C320810147 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/23/18 4:13 AM, Yuval Lifshitz wrote:

§1.1:

This document uses lowercase forms of RFC-2119-defined terms. Please update this
section to use the boilerplate from RFC 8174.

[yuval] we use them in lowercase, without their normative meaning. Is this an issue?
For example: "
a commercial agreement must exist between the 
visited domain and the home domain" is just informational

It's not the language use that's an issue. RFC 2119 has been updated, and since you use the lowercase terms, the update is relevant to your document. The fix is to simply replace your existing text with:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.


§5.6.2:

>  The credit-control
>  client receives a Credit-Control-Answer or service specific
>  authorization answer with the Final-Unit-Indication or the QoS-Final-
>  Unit-Indication AVP and Validity-Time AVPs but no Granted-Service-
>  Unit AVP.

This has the same confusion as above regarding the application of logical
combinations. The second half of the statement is of the form "A or B and C
but not D," which is pretty ambiguous. It's also a little unclear whether the
client receives a Credit-Control-Answer (with A or B and C but not D), or just
a Credit-Control-Answer of any description, full stop.

[yuval] how about this:
"
When the credit-control 
client receives (either at session or service specific level) a 
Final-Unit-Indication AVP or QoS-Final-
Unit-Indication AVP, together with Validity-Time AVP,
but without Granted-Service-
Unit AVP, it immediately starts the graceful service termination
   without sending any message to the server."

Sounds good to me. Thanks.

---------------------------------------------------------------------------

§8.65:

>  The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type
>  Address and defines the IPv4 or IPv6 address of the redirect server
>  with which the end user is to be connected when the account cannot
>  cover the service cost.

This appears to be underspecified, unless I've missed some specification
elsewhere regarding what the client is supposed to do with this IP address.
While the other redirection methods (HTTP, SIP) have relatively clear means of
contact (they indicate a protocol), the indication of only an IP address with
neither protocol nor port doesn't seem to provide enough information for a
client to act on.  Please either flesh this out in this section, or point to
another document that indicates how this IP address is to be used.

[yuval] I think this is left unspecifid on purpose. There are many ways to redirect IP addresses (e.g. different tunneling mechanism), don't think we want to list them here?[yuval]

If it's an open-ended set of behaviors (or a set of behaviors that is unrealistic to list), then I would expect the document to at least let implementors know that they're not going to find any further guidance in this document or other RFCs. Perhaps add something like: "The interpretation of Redirect-Address-IPAddress by the Diameter Credit-control Client is a matter of local policy."


---------------------------------------------------------------------------

§12:

When new documents obsolete an RFC that originally registered values with IANA,
I'm used to seeing that document also update the IANA registry so that the
corresponding entries now point to the new document. You may consider text that
instructs IANA to update the existing RFC-4006-registered values so that they
point to this document instead of RFC 4006.

[yuval] don't know what the process here. but does it need to go into the RFC?

Typically, that's how we give instructions to IANA pertaining to document updates, yes. See https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-11 for an example.


---------------------------------------------------------------------------

Appendix B:

As a general comment for all of the examples: I'm surprised that none of the
examples have been updated to reflect the newly defined capabilities in this
document. For example, all the examples in this appendix use
Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, to
show maximally flexible and compatible examples, I would expect that the
examples would include both AVPs. This applies to all of the "Extension"
AVPs as well.

[yuval] the examples are more around the flow and less about the actual content.
With respect to flow, there is no difference between the old and new AVPs - and we wanted to minimize unnecessary changes. Only flow that was modified was reflected in a new diagram at the end of section 5.6 ("zero GSU")

While I don't agree with the rationale here, this is an editorial comment about a non-normative part of the document, so it's ultimately your decision.

/a
--------------092FB7C4EC9086C320810147-- From nobody Wed May 23 08:07:57 2018 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 659731270A3; Wed, 23 May 2018 08:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=iJMgCdW5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hcSvz4DX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2v9zkWU9Gew; Wed, 23 May 2018 08:07:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501D71270A0; Wed, 23 May 2018 08:07:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BFF7021DC8; Wed, 23 May 2018 11:07:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 23 May 2018 11:07:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=Vdx91kNpiCdV8Nwl8S1F3R7A+0vh+ jfZvcqQMM5wwuM=; b=iJMgCdW5M4cVDDqUA2Mx9zpcuJuuPwOa2ye6cJhcOmzkc 4V2p1+dRbidQ236nn6dtQ9dTkDxEQRRYlmg7+i4JJOMFhm7vaRSXH9B62xlt+6LL dTGDK7IP5cTx4/QQaMfXAffevJurUfN/S/YaZKLYrrifOJY4Mq2H8LUjY6mVwzzT PdeAK03poPDc8+K0yVUj2oUaEJg/fnFuMzucmhunKp4h4nCMmIztgpv+xbPY3mPP pQEkwVJYE4HSj+kLcR9MrcVs9V4SRGUiNHXRKMtOdFQ70s+C/0qTB7gRE3HStFvn /H0i5MsW+VF7Ce0EpA8q3StENZW4888GpSYGwYAeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Vdx91k NpiCdV8Nwl8S1F3R7A+0vh+jfZvcqQMM5wwuM=; b=hcSvz4DXcmnXzpsmfmBS6d QgzcbG/cbiaF9KPfqlePbSpumMt96NYFrvzzCHUriJRRJQ6f8DuF4WfFpL8uHSXl c9Vtlt7XKr37I4FkeT0p9cliW/Umj9W5aTQ9Bm2lNdhjiR4DNs1amHjGnAxsAYzF 4DB7OJjX6qWZX2ExM6FDwFFF2stjtAT2DWsjHg8aVxJo3fiZGHHnRFBgYj8FFw1w 3RB06gsSELkxh8ShvyxygKhtODG+awGKJBYe2nW/Kl5ClmIH3NS+6/zfZy/JlKKz y3SapjIsjU7YgwJoemwE9xbXTw6x/KSEMVG3SM4ziLHnGVuHAgSyjtqQjuMLYu8g == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from rtp-vpn4-514.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 2FEF4E4F0B; Wed, 23 May 2018 11:07:51 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <0e9e72c11cde4097b9d698327882be42@plswe13m04.ad.sprint.com> Date: Wed, 23 May 2018 11:07:50 -0400 Cc: Ben Campbell , IESG , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-rfc4006bis@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> <48C95314-5F5D-4CFC-963B-36017BB364A1@nostrum.com> <0e9e72c11cde4097b9d698327882be42@plswe13m04.ad.sprint.com> To: "Bertz, Lyle T [CTO]" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 15:07:55 -0000 > On May 23, 2018, at 8:29 AM, Bertz, Lyle T [CTO] = wrote: >=20 > Comments inline. >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, May 22, 2018 10:02 PM >> To: Bertz, Lyle T [CTO] >> Cc: Alissa Cooper ; The IESG ; = dime- >> chairs@ietf.org; dime@ietf.org; draft-ietf-dime-rfc4006bis@ietf.org >> Subject: Re: [Dime] Alissa Cooper's Discuss on = draft-ietf-dime-rfc4006bis-08: >> (with DISCUSS and COMMENT) >>=20 >> Hi, >>=20 >> I=E2=80=99m having some trouble telling your comments from = Alissa=E2=80=99s. Somehow the >> quoting is reversed from normal convention, so it looks like Alissa = is quoting >> you. But I will try to figure it out :-) >>=20 >>> On May 22, 2018, at 9:21 PM, Bertz, Lyle T [CTO] = >> wrote: >>>=20 >>> Comments inline. >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Alissa Cooper >>> Sent: Tuesday, May 22, 2018 6:08 AM >>> To: The IESG >>> Cc: dime@ietf.org; dime-chairs@ietf.org; draft-ietf-dime- >> rfc4006bis@ietf.org >>> Subject: [Dime] Alissa Cooper's Discuss on = draft-ietf-dime-rfc4006bis-08: >> (with DISCUSS and COMMENT) >>>=20 >>> CAUTION: This email originated from outside of the organization. Do = not >> click links or open attachments unless you recognize the sender and = know >> the content is safe. >>>=20 >>>=20 >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-dime-rfc4006bis-08: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>>=20 >>>=20 >>> Please refer to >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i >> etf.org%2Fiesg%2Fstatement%2Fdiscuss- >> criteria.html&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255a= >> 4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0% >> 7C636625840688755751&sdata=3DTSuSzLz5Ey2TL45eg2TDQf%2BVQXBei6cxbVz5 >> tU%2FtlRo%3D&reserved=3D0 >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>>=20 >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr >> acker.ietf.org%2Fdoc%2Fdraft-ietf-dime- >> rfc4006bis%2F&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255 >> a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0 >> %7C636625840688755751&sdata=3DrOjsjxdmG7IcUDzAuDhvkB9cCOopAv70yPH >> CckL%2B9SA%3D&reserved=3D0 >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> =3D Section 5.6.2 =3D >>>=20 >>> I'm having a little trouble understanding the expected behavior = described >> in Section 5.6.2 so wanted to see if I'm just confused or if there is = something >> to be clarified. The text says: >>>=20 >>> "In addition to the Redirect-Server AVP or Redirect-Server-Extension >>> AVP, the credit-control server MAY include one or more Restriction- >>> Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more >>> Filter-Id AVPs in the Credit-Control-Answer message to enable the >>> user to access other services (for example, zero-rated services). = In >>> such a case, the access device MUST drop all the packets not = matching >>> the IP filters specified in the Restriction-Filter-Rule AVPs, = Filter- >>> Rule AVPs or Filter-Id AVPs. If enforcement actions other than >>> allowing the packets (e.g., QoS), are indicated in the Filter-Rule >>> AVPs or Filter-Id AVPs, they SHOULD be performed as well. In >>> addition, if possible, to redirecting the user to the destination >>> specified in the Redirect-Server AVP or Redirect-Server-Extension >>> AVP." >>>=20 >>> It seems like if the server sends a Redirect-Server AVP or = Redirect-Server- >> Extension AVP without any of the other AVPs, then all the traffic is = supposed >> to be redirected. But if a Restriction-Filter-Rule AVP, Filter-Rule = AVP, or >> Filter-Id AVP is also included, then the non-matching traffic MUST be >> dropped, in which case how does the user get redirected? Is the last >> sentence (which is a sentence fragment, actually) supposed to address = this >> somehow? And in the case of enforcement actions involving QoS, the = text >> seems to say that packets matching the filter MUST be dropped AND = have >> the QoS rules applied to them, so I don't understand how that works. >>>=20 >>>> The statement "In such a case, the access device MUST drop all the >> packets not matching the IP filters specified in the = Restriction-Filter-Rule >> AVPs" and is redundant with the definition of = Restriction-Filter-Rule. Filter- >> Rule and the rule referred to by Filter-Id also contain the = appropriate traffic >> filter and actions. I would propose a simplification, replace all = text from "In >> such a case ..." with >>>=20 >>> "In such a case, the access device MUST treat all packets according = to the >> Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules = referred to by >> the Filter-Id AVP. This is in addition to, if possible, redirecting = the user to the >> destination specified in the Redirect-Server AVP or Redirect-Server- >> Extension AVP.=E2=80=9D >>=20 >> I think Alissa=E2=80=99s point is to ask how redirection and = filtering interact when both >> are active. Does _remaining_ traffic gets redirected after applying = the filter? Yes, this is what I think is not clear in the original or in the = suggested replacement text. >> Note that some forms of redirection (e.g. HTTP) may not work very = well if >> only some traffic makes it. >>=20 >> I also have to wonder if some of this behavior is really governed by = local >> policy at the NAS? >>=20 >=20 > The rules are always enforced prior to redirection on the NAS. >=20 > To your point, the policy *could* govern local behavior of redirect in = the rule but in general this is poor practice, e.g. what if two rules = with the same precedence redirect to different locations for overlapping = traffic and a Redirect-Server-Extension AVP is present? This would = definitely be poor design on their part. Users of the Redirect-Server = and Redirect-Server-Extension AVP align the rules with the redirect use = case. >=20 >>>=20 >>> =3D Section 15.1 >>>=20 >>> RFC 6733 lists a bunch of sensitive AVPs and then says this about = them: >>>=20 >>> "Diameter messages containing these or any other AVPs considered to = be >>> security-sensitive 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." >>>=20 >>> It seems like the list of AVPs in Section 15.1 should have these = same >> requirements applied to them explicitly. >>>=20 >>>> 6733 is clear about what applies when declared as security = sensitive but >> the addition of the following may help. >>>=20 >>> "As sensitive AVPs the Diameter message requirements specified in >> Section 13.3 of RFC 6733 apply.=E2=80=9D >>=20 >> I was going to say something similar; 6733 is the base protocol. This = draft >> inherits the normative rules by way of using Diameter. But it = doesn=E2=80=99t hurt to >> reinforce them more strongly descriptive language. How about = something to >> the effect of =E2=80=9D The privacy-sensitive AVPs listed in this = section must be sent >> across non-trusted networks or Diameter agents without end-to-end >> authentication and confidentiality protection, as described in = [RFC6733] >> section 13.3" >>=20 >=20 > Perfect! We will fix. Assuming you meant s/must/MUST NOT/ this seems fine. >=20 >>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> =3D Section 1 =3D >>>=20 >>> (1) I know it's a term of art, but the term "next generation = wireless >> networks" >>> seems a bit out of place in two ways: (1) "wireless" seems more = generic >> than what is implied (i.e., "cellular," I assume), and (2) is Rel-13 = considered >> "next generation" still? >>>=20 >>>> Fair point. We tend to use "wireless" though as opposed to = "cellular". >> Dropping 'next generation' makes sense. >>=20 >> How about =E2=80=9Cmobile networks=E2=80=9D? >=20 > We are fine with that. WFM >=20 >>=20 >>>=20 >>> (2) "Diameter base protocol" should cite RFC 6733. >>>=20 >>>> If the DISCUSS can be resolved and we have a next revision (I = assume we >> will) we can update this >>=20 >> Please assume there will be another revision :-) >=20 > :D >=20 >>=20 >>>=20 >>> =3D Section 5.1 =3D >>>=20 >>> Assuming G-S-U stands for granted service unit, the acronym should = be >> given upon first use here. >>>=20 >>>> Can update in next revision along with the DISCUSS items >>>=20 >>> =3D Section 8.52 =3D >>>=20 >>> (1) Why do you need to specify the ability to send either the IMEISV = or the >> IMEI? >>>=20 >>>> They are distinct structures and the latest generation of networks = are >> starting to use IMEISV (with no support for just the IMEI). However, = the >> IMEI value is identical. >>>=20 >>> (2) >>> "If the type of the equipment is one of the >>> enumerated types of User-Equipment-Info-Type AVP, then the credit- >>> control client SHOULD send the information in the = User-Equipment-Info >>> AVP, in addition to or instead of the User-Equipment-Info-Extension >>> AVP." >>>=20 >>> Why is this normative recommendation in support of backwards >> compatibility different from the one given for the = Subscription-Id-Extension >> AVP in Sec. 8.58? >>>=20 >>>> It was found that backwards compatibility issues were more = prevalent >> with User-Equipment-Info around the IMEISV and some implementations >> can deal with IMEISV and IMEI. The language above is aggressive in >> recommending the "in addition to" in order to maximize compatibility. = 8.58 is >> cleaner in terms of its recommendation and production issues have not = been >> seen on this AVP so it seemed appropriate to limit the AVP values to = one or >> the other and not both as it is for User-Equipment-Info and = User-Equipment- >> Info-Extension. >>=20 >> Assuming Alissa is okay with the explanations for both points, please = add >> some explanatory text to the section. >>=20 >=20 > Yes WFM >=20 >>>=20 >>> =3D Section 15.1 =3D >>>=20 >>> "Redirect-Server-Address AVP: the service-provider may embed >>> personal information on the subscriber in the URL/I (e.g. to >>> create a personalized message)." >>>=20 >>> This seems like a bad idea that, if it's going to be mentioned, = should be >> recommended against. >>>=20 >>>> Makes sense. I would recommend add the sentence "However, this is >> not recommended.=E2=80=9D >>=20 >> It=E2=80=99s also commonly done, isn=E2=80=99t it? I think the point = is to mention that the AVP >> is sensitive because people might do this, not to offer permission. = There=E2=80=99s >> already text recommending against directly using personal = information. >> Would it help to change =E2=80=9Cmay=E2=80=9D to =E2=80=9Cmight=E2=80=9D= ? to avoid any semblance of >> =E2=80=9Cpermission=E2=80=9D? >>=20 >> Some of the other AVPs likely carried in the same message are going = to have >> personally identifiable information one way or another (i.e. = Subscription-ID). >>=20 What I was thinking was more that this potentially makes the URLs = guessable in such a way that attackers accessing them could obtain = personal information about any subscriber whose name they know. Is that = not a concern? Thanks, Alissa >=20 > If "might" works for everyone we'll make the change. >=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>>=20 >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i >> etf.org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40s >> print.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55 >> f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=3Dq3LE6zquhvAVJ% >> 2B6rJzlqfep80r3JZrX5wgoASHwii%2BQ%3D&reserved=3D0 >>>=20 >>> ________________________________ >>>=20 >>> This e-mail may contain Sprint proprietary information intended for = the >> sole use of the recipient(s). Any use by others is prohibited. If you = are not >> the intended recipient, please contact the sender and delete all = copies of the >> message. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. From nobody Wed May 23 08:43:52 2018 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 3D7E712E055; Wed, 23 May 2018 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljMgwkvBnmNC; Wed, 23 May 2018 08:43:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E3A12711E; Wed, 23 May 2018 08:43:49 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4NFhfYc006316 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 May 2018 10:43:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F5AA3A48-762C-4B24-86FF-CF46673D621A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 23 May 2018 10:43:20 -0500 In-Reply-To: Cc: "Bertz, Lyle T [CTO]" , IESG , "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-rfc4006bis@ietf.org" To: Alissa Cooper References: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> <48C95314-5F5D-4CFC-963B-36017BB364A1@nostrum.com> <0e9e72c11cde4097b9d698327882be42@plswe13m04.ad.sprint.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 15:43:51 -0000 --Apple-Mail=_F5AA3A48-762C-4B24-86FF-CF46673D621A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 23, 2018, at 10:07 AM, Alissa Cooper wrote: >=20 >>>>=20 >>>> =3D Section 15.1 =3D >>>>=20 >>>> "Redirect-Server-Address AVP: the service-provider may embed >>>> personal information on the subscriber in the URL/I (e.g. to >>>> create a personalized message)." >>>>=20 >>>> This seems like a bad idea that, if it's going to be mentioned, = should be >>> recommended against. >>>>=20 >>>>> Makes sense. I would recommend add the sentence "However, this is >>> not recommended.=E2=80=9D >>>=20 >>> It=E2=80=99s also commonly done, isn=E2=80=99t it? I think the point = is to mention that the AVP >>> is sensitive because people might do this, not to offer permission. = There=E2=80=99s >>> already text recommending against directly using personal = information. >>> Would it help to change =E2=80=9Cmay=E2=80=9D to =E2=80=9Cmight=E2=80=9D= ? to avoid any semblance of >>> =E2=80=9Cpermission=E2=80=9D? >>>=20 >>> Some of the other AVPs likely carried in the same message are going = to have >>> personally identifiable information one way or another (i.e. = Subscription-ID). >>>=20 >=20 > What I was thinking was more that this potentially makes the URLs = guessable in such a way that attackers accessing them could obtain = personal information about any subscriber whose name they know. Is that = not a concern? >=20 That=E2=80=99s a very good point. Would it help to add some guidance to = make these hard to guess along with the existing text about not adding = user identifying information? Ben. --Apple-Mail=_F5AA3A48-762C-4B24-86FF-CF46673D621A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsFjBgACgkQgFZKbJXz 1A0jDg//RBr3xsqrinPqiYJQLRPNJ+6ydaWJt4gmSat+BaZY4qqhfWeRTtG+aF3m sv+XFyg4hskdv+dchg0hcfT8SWpNZcyoDPYwzqTf8GiGURgjytI/laElCpbexFMv CdBhRIJIHod4bsQhUR8+wsvbffmFIv5MEA/fqsqsRz+PV7n7/9iHaqalsi0ZMoK+ zIfrguv05qOno+0PmtcJhksWXUqANLRNDl/qiAcBxuL4oRg+c6C6OTHE1UcwJ7wo QkNYrVpijm35jp2dpY/89Q6V7Wf3H+gHNYmbVWZFlm66XHnGZsTJsGReg+DlHhO+ G4bwg9CNy9nHB+511Isfdxo+Fu/JdK/N5oXt4CYgm2CPBc1dx8L+yaedAGM+xFp5 famMBzhcW7ISmlxRcVT0c8n9yxdpCsn/bzo4+ezaJL/0XXsSCzYUvqsBvVOACNNj eznDQtY8N8sLQaWecK9F2mnkJ8d6xDjlNg+BxBHh3ePYKwqPTvvn/vRM6s6JieR0 e3c0tQKKEJb6CC05+efj8kMSierSUhEcGLWOh9xlyz8RSuGH21wmGi6FNm++OlFe irNhgX3ryYWaxsDGPUwri+QEQqILp/L+uhwXBqtoAalLPsMF3587fFWJbQIzpZvC 7cN+SBgllIR/f4jv1oeYRh6nIpozrtF99ruhjcpwF8VMHHaWHfM= =xrmo -----END PGP SIGNATURE----- --Apple-Mail=_F5AA3A48-762C-4B24-86FF-CF46673D621A-- From nobody Wed May 23 08:46:54 2018 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 A3EAE12E3AE; Wed, 23 May 2018 08:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htL3WwC-s0Cz; Wed, 23 May 2018 08:46:45 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC61D12711E; Wed, 23 May 2018 08:46:43 -0700 (PDT) X-AuditID: 12074423-37bff70000006ce2-d9-5b058ce0576f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 08.89.27874.1EC850B5; Wed, 23 May 2018 11:46:41 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w4NFkco4013419; Wed, 23 May 2018 11:46:39 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4NFkXoH021941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 May 2018 11:46:36 -0400 Date: Wed, 23 May 2018 10:46:33 -0500 From: Benjamin Kaduk To: Ben Campbell Cc: Alissa Cooper , "Bertz, Lyle T [CTO]" , "dime-chairs@ietf.org" , "dime@ietf.org" , IESG , "draft-ietf-dime-rfc4006bis@ietf.org" Message-ID: <20180523154633.GB32807@kduck.kaduk.org> References: <152698725939.7754.12532481695345574563.idtracker@ietfa.amsl.com> <50deaa6d510944beafa49868eea7a6b1@plswe13m04.ad.sprint.com> <48C95314-5F5D-4CFC-963B-36017BB364A1@nostrum.com> <0e9e72c11cde4097b9d698327882be42@plswe13m04.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixCmqrPuwhzXa4OF5Q4vpZ/4yWszvPM1u sfZgmsXc3hVsFksmTmC1mPFnIrPFx/VnWRzYPb48ecnksWTJTyaPWTufsHi0XdrNHMASxWWT kpqTWZZapG+XwJVxaPV5loIHPBV9X1sYGxjbuboYOTgkBEwk9uyr7mLk4hASWMwkse34LmYI ZyOjxJy759ghnKtMEgv27APKcHKwCKhKPH/0iA3EZhNQkWjovgwWFxFQknjevJUFpIFZYC2T xK9Hf1lAEsICWRKrVkwCs3mB1k34uJAVYupzJontK6dAJQQlTs58AmYzC6hL/Jl3iRnkPmYB aYnl/zggwvISzVtngy3jFLCXuNHynR3EFhVQltjbd4h9AqPgLCSTZiGZNAth0iwkkxYwsqxi lE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIig52F+UdjC/7vA8xCnAwKvHwamSw RguxJpYVV+YeYpTkYFIS5S2rBwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4f3YCJTjTUmsrEot yodJSXOwKInz5ixijBYSSE8sSc1OTS1ILYLJynBwKEnw6gKTgJBgUWp6akVaZk4JQpqJgxNk OA/QcF6QGt7igsTc4sx0iPwpRkUpcd533UAJAZBERmkeXC8oeUlk7695xSgO9IowbyZIOw8w 8cF1vwIazAQ0+OJyZpDBJYkIKakGxqmlHqrX7hhPOS2Yeb9/XfI8jY++v71OTHi68N+nhz8S Dq2Wkbm22GOFwrYNuy9vts/4/vXXPxVGi31yU7auFec++dxVPmBr2QXfY6k5Xy3XKu6LXPTq Q/z8Kdqr5x1OZNaX/tD59eDrfQ3HFK7Y7lcoi+B5se+dyffn9pbcmSbLfVKXL3G3v8ysxFKc kWioxVxUnAgAdXol9DkDAAA= Archived-At: Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 15:46:47 -0000 On Wed, May 23, 2018 at 10:43:20AM -0500, Ben Campbell wrote: > > > > On May 23, 2018, at 10:07 AM, Alissa Cooper wrote: > > > >>>> > >>>> = Section 15.1 = > >>>> > >>>> "Redirect-Server-Address AVP: the service-provider may embed > >>>> personal information on the subscriber in the URL/I (e.g. to > >>>> create a personalized message)." > >>>> > >>>> This seems like a bad idea that, if it's going to be mentioned, should be > >>> recommended against. > >>>> > >>>>> Makes sense. I would recommend add the sentence "However, this is > >>> not recommended.” > >>> > >>> It’s also commonly done, isn’t it? I think the point is to mention that the AVP > >>> is sensitive because people might do this, not to offer permission. There’s > >>> already text recommending against directly using personal information. > >>> Would it help to change “may” to “might”? to avoid any semblance of > >>> “permission”? > >>> > >>> Some of the other AVPs likely carried in the same message are going to have > >>> personally identifiable information one way or another (i.e. Subscription-ID). > >>> > > > > What I was thinking was more that this potentially makes the URLs guessable in such a way that attackers accessing them could obtain personal information about any subscriber whose name they know. Is that not a concern? > > > > That’s a very good point. Would it help to add some guidance to make these hard to guess along with the existing text about not adding user identifying information? That seems worth doing. Thanks, Benjamin From nobody Wed May 23 13:55:35 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20862127010; Wed, 23 May 2018 13:55:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2018 13:55:26 -0700 Archived-At: Subject: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:55:27 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 8.38. RFC5952 contains significant changes in text representation from RFC3513 and I am concerned that there might be RFC4006 compliant implementations that will no longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper case hex digits, with leading zeroes in 16 bit fields etc. Has the working group considered this break in compatibility already in its discussions? If it has, this text should still be finessed a bit because RFC5952 recommendations (even at the MUST level) are a SHOULD for senders with the receivers being required to handle all possible legal formats as per RFC4291. So at least the sender rules and receiver rules need to be written differently. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 8.65 Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 Address while you can directly use address family 1 to encode it directly as an IPv4 address? This allows for two different encodings for the same address. From nobody Wed May 23 19:03:43 2018 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 18A91129C53; Wed, 23 May 2018 19:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmrW6RjDd9L0; Wed, 23 May 2018 19:03:33 -0700 (PDT) Received: from smtp2.execulink.net (smtp2.execulink.net [69.63.44.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3C51200F1; Wed, 23 May 2018 19:03:33 -0700 (PDT) Received: from node-13336.pppoe.execulink.com ([216.75.190.33] helo=[192.168.58.129]) by smtp2.execulink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1fLfbI-0000Te-29; Wed, 23 May 2018 22:03:32 -0400 To: Suresh Krishnan , The IESG Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, dime@ietf.org References: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> From: Dave Dolson Message-ID: <968ed1c2-5709-b3a6-3735-e4df59c4ae22@golden.net> Date: Wed, 23 May 2018 22:03:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <152710892612.27153.4934518520563046738.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 02:03:35 -0000 Suresh, Please see inline. On 2018-05-23 04:55 PM, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: Discuss > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 8.38. > > RFC5952 contains significant changes in text representation from RFC3513 and I > am concerned that there might be RFC4006 compliant implementations that will no > longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper > case hex digits, with leading zeroes in 16 bit fields etc. Has the working > group considered this break in compatibility already in its discussions? > > If it has, this text should still be finessed a bit because RFC5952 > recommendations (even at the MUST level) are a SHOULD for senders with the > receivers being required to handle all possible legal formats as per RFC4291. > So at least the sender rules and receiver rules need to be written differently. If I recall correctly, we did give this some thought. RFC 5952 was presumably done for a reason, due to flaws in previous descriptions of address format. Hence it is prudent to use the new requirements. Implementations are free to be liberal in what they receive, for backwards compatibility with RFC 4006. So I think it's fair to say this standard requires use of RFC 5952 syntax. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 8.65 > > Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 > Address while you can directly use address family 1 to encode it directly as an > IPv4 address? This allows for two different encodings for the same address. Because IPv4-mapped IPv6 is a good idea. It allows coders to ignore IPv4 and just develop for IPv6. If we hadn't mentioned it explicitly, I think some people would have assumed it to be supported and others not. So we had the choice of allowing it or prohibiting it. We chose to allow. -Dave From nobody Wed May 23 20:41:10 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A10612D946; Wed, 23 May 2018 20:41:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: dime-chairs@ietf.org, dime@ietf.org, Jouni Korhonen , jouni.nospam@gmail.com, draft-ietf-dime-rfc4006bis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2018 20:41:08 -0700 Archived-At: Subject: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 03:41:08 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. > deduction of credit from the end user account when service is > completed and refunding of reserved credit that is not used. > > Diameter Credit-control Server A Diameter credit-control server acts > as a prepaid server, performing real-time rating and credit- > control. It is located in the home domain and is accessed by a definition of "home domain" would be useful S 2. > credit-control application. > > When an end user requests services such as SIP or messaging, the > request is typically forwarded to a service element (e.g., SIP Proxy) > in the user's home domain. In some cases it might be possible that > the service element in the visited domain can offer services to the also define visited domain, or at least point to a reference. S 3.1. > [ CC-Correlation-Id ] > [ User-Equipment-Info ] > [ User-Equipment-Info-Extension ] > *[ Proxy-Info ] > *[ Route-Record ] > *[ AVP ] Please expand AVP on first use. S 4. > control client requests credit authorization from the credit-control > server prior to allowing any service to be delivered to the end user. > > In the first model, the credit-control server rates the request, > reserves a suitable amount of money from the user's account, and > returns the corresponding amount of credit resources. Note that Sorry, reserves the balance or the amount reserved? S 14. > > Even without any modification to the messages, an adversary can > eavesdrop on transactions that contain privacy-sensitive information > about the user. Also, by monitoring the credit-control messages one > can collect information about the credit-control server's billing > models and business relationships. I'm having trouble reading these two paragraphs. Are they about what happens if TLS isn't used? From nobody Wed May 23 22:36:36 2018 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 AB1E3126FDC for ; Wed, 23 May 2018 22:36:29 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkT9_5m5d6Wz for ; Wed, 23 May 2018 22:36:28 -0700 (PDT) Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E274D1241FC for ; Wed, 23 May 2018 22:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527140186; bh=3+4nELbWUi8NC3HYmXLPkpu+OFc9kg4Lr1DmvuGrjAI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kRwbPQT1PvKnUCBGJWoeoBA2ieJ9DZlSsKK843OdjKfrXTQM1AOgXuU0GKdigdmmddXLM98b2v+471ImZjtrA5afMHc2vDQbXe1fCn5Zs8LPCFU7/BoX1VIGkRGwdfa6D1se/VWTzzCNre/Hcg+pAogVmZ+6Qg5lHzJtPD9iBQ6tF26BH5ADOkA616DyhBRueK7BjV0kHEcMa9uJAscTUl74qd3A+i70C1ggH21FdzEQJ/vSGzigrnicZD+op/Z1+NaOcOj0MBj6DgofL2hToBykTvBWdCNRpFdmMc0Xmv/colZRGNBXmnFsXbUvvqAamVeHIMJEUEQ39ecUKaKFWw== X-YMail-OSG: 5Dx.X2QVM1lK3t7bplcTZJZcTjh3mkR2QmRkYHZj1YVRM4ztAPQxbWXXExgDXOU dGTOii_dFQSp7.t5eSPEwYP1.mkOLxdRIG0bh8MOiw4mOE5HCrg1g43FnJl42FzpyiX3mXWEa02s p5tJuL_ITbQQecUt3Wt1k3Mj3L4MibkwAutke0FSCzbEs2i8BOoJjLmj7MwxSPD0wqh3VRCOhIZQ .fWGgoxDFLGP6Fhlj6eMyc7PsfjGjOKCBuFQBgLmlMhoPTffQgkrT.2V5B2a1FFNU..st3Zwd.kC G66ppnJ2UCTowBUAzk907fbLvGHDrJ3ZQGqAQYWLwiAUBYooQGtb0FKjmU2xIBqJ.cG9jpK.e1Q_ 5ahk607k6aLrmebg4Fkwx9N.K_F5jZyyqaV9wAlhUNC1TctcCTxNeuinW9afxMKq6kAi6m2EFcjv lBPXvzVboBJBJbYHw2ISktGGJwH4OyoZ6eI6To26QgRWfykuwfmAfIA.CSYke9RCQnZlDUm4cxFL ao3ZpCYmfLiI33.nv0560eme7j_0qu706zwvnXHJK9LJ6BFtEbdLzFyL6cCgqX.mfMwUi1RayHY8 _oH.aL2mltPA20aEpHku684dnZV5pd_iRJfKsH3jPNEo9aO2RcfnIsXG.5ceXSpW_lCo5Ws4MMWr o5w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 05:36:26 +0000 Date: Thu, 24 May 2018 05:26:23 +0000 (UTC) From: Yuval Lifshitz To: Yuval Lifshitz , The IESG , Adam Roach Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <699526940.4818562.1527139583898@mail.yahoo.com> In-Reply-To: <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com> References: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> <1651457572.4445831.1527066817455@mail.yahoo.com> <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4818561_1030357329.1527139583891" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 05:36:30 -0000 ------=_Part_4818561_1030357329.1527139583891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Will fix the first 3 issues.=C2=A0 Regarding IANA, Lionel, didn't we contact them already?Do we still need to = add that to the RFC? Yuval On Wednesday, May 23, 2018, 5:37:56 p.m. GMT+3, Adam Roach wrote: =20 =20 On 5/23/18 4:13 AM, Yuval Lifshitz wrote: =20 =20 =C2=A71.1: =20 This document uses lowercase forms of RFC-2119-defined terms. Please upda= te this section to use the boilerplate from RFC 8174. =20 [yuval] we use them in lowercase, without their normative meaning. Is thi= s an issue? For example: " a commercial agreement must exist between the=C2=A0 visit= ed domain and the home domain" is just informational =20 =20 It's not the language use that's an issue. RFC 2119 has been updated, and = since you use the lowercase terms, the update is relevant to your document.= The fix is to simply replace your existing text with: =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.=20 =20 =20 =C2=A75.6.2: =20 >=C2=A0 The credit-control >=C2=A0 client receives a Credit-Control-Answer or service specific >=C2=A0 authorization answer with the Final-Unit-Indication or the QoS-Fi= nal- >=C2=A0 Unit-Indication AVP and Validity-Time AVPs but no Granted-Service= - >=C2=A0 Unit AVP. =20 This has the same confusion as above regarding the application of logical combinations. The second half of the statement is of the form "A or B and= C but not D," which is pretty ambiguous. It's also a little unclear whether= the client receives a Credit-Control-Answer (with A or B and C but not D), or= just a Credit-Control-Answer of any description, full stop. =20 [yuval] how about this: " When the credit-control=C2=A0 client receives (either at session or ser= vice specific level) a=C2=A0 Final-Unit-Indication AVP or QoS-Final- Unit= -Indication AVP, together with Validity-Time AVP, but without Granted-Ser= vice- Unit AVP, it immediately starts the graceful service termination = =C2=A0 =C2=A0without sending any message to the server." =20 =20 Sounds good to me. Thanks. =20 =20 ----------------------------------------------------------------------= ----- =20 =C2=A78.65: =20 >=C2=A0 The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type >=C2=A0 Address and defines the IPv4 or IPv6 address of the redirect serv= er >=C2=A0 with which the end user is to be connected when the account canno= t >=C2=A0 cover the service cost. =20 This appears to be underspecified, unless I've missed some specification elsewhere regarding what the client is supposed to do with this IP addres= s. While the other redirection methods (HTTP, SIP) have relatively clear mea= ns of contact (they indicate a protocol), the indication of only an IP address = with neither protocol nor port doesn't seem to provide enough information for = a client to act on.=C2=A0 Please either flesh this out in this section, or = point to another document that indicates how this IP address is to be used. =20 [yuval] I think this is left unspecifid on purpose. There are many ways t= o redirect IP addresses (e.g. different tunneling mechanism), don't think = we want to list them here?[yuval] =20 =20 If it's an open-ended set of behaviors (or a set of behaviors that is unre= alistic to list), then I would expect the document to at least let implemen= tors know that they're not going to find any further guidance in this docum= ent or other RFCs. Perhaps add something like: "The interpretation of Redir= ect-Address-IPAddress by the Diameter Credit-control Client is a matter of = local policy." =20 =20 =20 -------------------------------------------------------------------------= -- =20 =C2=A712: =20 When new documents obsolete an RFC that originally registered values with= IANA, I'm used to seeing that document also update the IANA registry so that th= e corresponding entries now point to the new document. You may consider tex= t that instructs IANA to update the existing RFC-4006-registered values so that = they point to this document instead of RFC 4006. =20 [yuval] don't know what the process here. but does it need to go into the= RFC? =20 =20 Typically, that's how we give instructions to IANA pertaining to document = updates, yes. See https://tools.ietf.org/html/draft-ietf-tls-tls13-28#secti= on-11 for an example. =20 =20 =20 -------------------------------------------------------------------------= -- =20 Appendix B: =20 As a general comment for all of the examples: I'm surprised that none of = the examples have been updated to reflect the newly defined capabilities in t= his document. For example, all the examples in this appendix use Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice,= to show maximally flexible and compatible examples, I would expect that the examples would include both AVPs. This applies to all of the "Extension" AVPs as well. =20 [yuval] the examples are more around the flow and less about the actual c= ontent. With respect to flow, there is no difference between the old and new AVPs= - and we wanted to minimize unnecessary changes. Only flow that was modif= ied was reflected in a new diagram at the end of section 5.6 ("zero GSU") = =20 =20 While I don't agree with the rationale here, this is an editorial comment = about a non-normative part of the document, so it's ultimately your decisio= n. =20 /a _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_4818561_1030357329.1527139583891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Will fix the first 3 issues. 

Regarding IANA, Lionel, didn't we contact them already?
= Do we still need to add that to the RFC?

Yuval

=20
=20
On Wednesday, May 23, 2018, 5:37:56 p.m. GMT+3, Ada= m Roach <adam@nostrum.com> wrote:


On 5/23/18 4:13 AM, Yuval L= ifshitz wrote:

=C2=A71.1:

This document uses lowercase forms of RFC-2119-defined terms. Please update this
section to use the boilerplate from RFC 8174.

[yuval] we use them in lowercase, without their normative meaning. Is this an issue?
For example: "
a commercial agreement must exist between the 
visited domain and the home domain" is just informational

It's not the language use that's an issue. RFC 2119 has been updated, and since you use the lowercase terms, the update is relevant to your document. The fix is to simply replace your existing text with:

      The key words "MUST", "MUST N=
OT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only=
 when, they
      appear in all capitals, as shown here.


=C2=A75.6.2:

>  The credit-control
>  client receives a Credit-Control-Answer or service specific
>  authorization answer with the Final-Unit-Indication or the QoS-Final-
>  Unit-Indication AVP and Validity-= Time AVPs but no Granted-Service-
>  Unit AVP.

This has the same confusion as above regarding the application of logical
combinations. The second half of the statement is of the form "A or B and C
but not D," which is pretty ambiguous. It's also a little unclear whether the
client receives a Credit-Control-Answer (with A or B and C but not D), or just
a Credit-Control-Answer of any description, full stop.

[yuval] how about this:
"
When the credit-contr= ol 
cli= ent receives (either at session or service specific level) a 
Fin= al-Unit-Indication AVP or QoS-Final-
Uni= t-Indication AVP, together with Validity-Time AVP,
but without Granted-Service-
Uni= t AVP, it immediately starts the graceful service termination
   without sending any message to th= e server."

Sounds good to me. Thanks.

--------------------------------------------= -------------------------------

=C2=A78.65:

>  The Redirect-Address-IPAddress AV= P (AVP Code TBD14) is of type
>  Address and defines the IPv4 or I= Pv6 address of the redirect server
>  with which the end user is to be connected when the account cannot
>  cover the service cost.

This appears to be underspecified, unless I've missed some specification
elsewhere regarding what the client is supposed to do with this IP address.
While the other redirection methods (HTTP, SIP) have relatively clear means of
contact (they indicate a protocol), the indication of only an IP address with
neither protocol nor port doesn't seem to provide enough information for a
client to act on.  Please either flesh = this out in this section, or point to
another document that indicates how this IP address is to be used.

[yuval] I think this is left unspecifid on purpose. There are many ways to redirect IP addresses (e.g. different tunneling mechanism), don't think we want to list them here?[yuval]

If it's an open-ended set of behaviors (or a set of behaviors that is unrealistic to list), then I would expect the document to at least let implementors know that they're not going to find any further guidance in this document or other RFCs. Perhaps add something like: "The interpretation of Redirect-Address-IPAddress by the Diameter Credit-control Client is a matter of local policy."


--------------------------------------------= -------------------------------

=C2=A712:

When new documents obsolete an RFC that originally registered values with IANA,
I'm used to seeing that document also update the IANA registry so that the
corresponding entries now point to the new document. You may consider text that
instructs IANA to update the existing RFC-4006-registered values so that they
point to this document instead of RFC 4006.<= br clear=3D"none">

[yuval] don't know what the process here. but does it need to go into the RFC?

Typically, that's how we give instructions to IANA pertaining to document updates, yes. See https://tools.ietf.org/html/draft-ietf-tls-tls13-28= #section-11 for an example.


--------------------------------------------= -------------------------------

Appendix B:

As a general comment for all of the examples: I'm surprised that none of the
examples have been updated to reflect the newly defined capabilities in this
document. For example, all the examples in this appendix use
Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, to
show maximally flexible and compatible examples, I would expect that the
examples would include both AVPs. This applies to all of the "Extension"
AVPs as well.

[yuval] the examples are more around the flow and less about the actual content.
With respect to flow, there is no difference between the old and new AVPs - and we wanted to minimize unnecessary changes. Only flow that was modified was reflected in a new diagram at the end of section 5.6 ("zero GSU")

While I don't agree with the rationale here, this is an editorial comment about a non-normative part of the document, so it's ultimately your decision.


/a
________= _______________________________________
DiME mailing list=
DiME@ietf.org
= https://www.ietf.org/mailman/listinfo/dime
------=_Part_4818561_1030357329.1527139583891-- From nobody Wed May 23 23:30:10 2018 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 6C10412D952 for ; Wed, 23 May 2018 23:30:07 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHvrolmbGwiJ for ; Wed, 23 May 2018 23:30:03 -0700 (PDT) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E96A12D951 for ; Wed, 23 May 2018 23:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527143402; bh=dpnWwjLLN7WnHsHgfMawg7S6pjex9cLFIcefZ74EAP4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=GvCnReejYMLhKiq0ri0P9L/cqOHU6PcaLukv6dwsY2RqDKm3cp2RBJzEyNaVzYMptr1+xNkxVFCPwnP2mYxPoIEZF3vIIrVSEgsO1BkgX5ZaWHgSp3PYabS4iWV0dz51ksjWX0pcU2slWPW/uUsNAJHavRYvhR+dAPlnYzncVN0+6Cb2hCGpFOApZy1WH/w5pg/kUMtl4aOKCsArvbSsAgkZ4BOKLYVDrMYj+LS2ltYeOCv/t1zMFJSsSJxh4ErKyWJuIUAM57eQadOhD3rYOaFoQv/Mtx9IwIoGmNUKbX+Ci8e5/s/OFj9iVZqMii3Dk9zpAccTH3uRKjrYRE6jvw== X-YMail-OSG: 2g3GuQgVM1nao.d9S52Ppij.ycjYSAPqPA63GKuuoRb9k1iae67R3cbi4xlDSKb NUl9f8wmetBqqTJOeN5coGjjYLXMiIsYJT4jM7Guz24VB7f27a4cgoK_kwwUanagzTPTA_08MTbT oAuAabv9jqMXbSWvMjCCAsFIxCMW9pZlfnQ3lHcbRi5ZzNFwgKkVXAInoYim0TgQ7wm3qLOsa2Vm xdLQZUfTvzl4dSbCtqnFHpm7BXouhvEoTPeAaLq2vIEemy.ZrBHX_CV7H.gSaPSPYgJ_HjLwLOiK e3DnRGYa6SngrWtrXU0iNpaIm_CiHKzalecH13secfrad0yOFmhxYaiX.DczBfP3PsCis5WXRf.N 7bZuy0OkRZaWFX3McNsj3YBSxBI2oYADkGwceupumvry9n4ygjVdN_rDdAqpErwTG2k1xPbuR_s1 iKNOrBb4hC36Y__EtLkgd4KPBu5fTsjJJdnlMW0Co7GL2JT4sYOkEdwvLrYjYcruPjLNnGy.P.Ak vOysMRmB9ppcx6Gsco3523ixCkMCSeKqfON9oMrPoepTWX8g0I292ESURPmSS7WdVYV750ViY_Kk P0OXizt2apfNomJRZNeNH7CztzGcUi.pewnp5Hu.lGpMtCnwRmRCFD_Mxa51QK.NXr1T5MiDg91I L_BP448Hmaa8LzUYu Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 06:30:02 +0000 Date: Thu, 24 May 2018 06:17:51 +0000 (UTC) From: Yuval Lifshitz To: Benjamin Kaduk Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <1467920717.4840713.1527142671894@mail.yahoo.com> In-Reply-To: <20180523135822.GA32807@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4840712_1592862768.1527142671872" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 06:30:08 -0000 ------=_Part_4840712_1592862768.1527142671872 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inline On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk wrote: =20 =20 [re-sending since my client crashed during the first attempt and I don't see the message in the archives.=C2=A0 I attempted to reconstruct my message from a scrollback buffer, but there may be some artifacts with missing or duplicated text] On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: >=C2=A0 Thanks Ben and Benjamin! Comments inline >=C2=A0 =C2=A0 On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell= wrote: > >=C2=A0 Hi Benjamin, > > I=E2=80=99ve cherry-picked a few points, inline: > > Thanks! > > Ben. > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > I appear to have a different understanding of Section 5.6.2, though, > > with a different potential issue (but again, it's possible that I'm > > confused to how things work): > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > like the user can be redirected (at the application protocol level, > > e.g., HTTP or SIP) to a top-up server to purchase more credits.=C2=A0 I > > don't see a way described how user agents can distinguish between a > > Diameter-induced redirect and an attacker-induced redirect to a > > (potentially phishing) site that accepts payment information.=C2=A0 To = be > > clear, the scenario here is that a user is using a credit-controlled > > application session to talk to "arbitrary application servers", > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > the attacker could introduce a redirect to a phishing page that asks > > for payment information, and the user would be led to believe that > > this was the normal flow for "my prepaid balance has been used up", > > and give their payment information to the phishing site. I think > > that either user agents need to give some indication that this > > DIAMETER-level redirect is different than an > > application-protocol-level redirect (e.g., http) or the Security > > Considerations need to mention the risk of acclimating users to > > arbitrary websites redirecting to sites asking for payment > > credentials, which may or may not be legitimate sites. > > > > I think it=E2=80=99s reasonable to mention the concern in the security co= nsiderations. But I don=E2=80=99t see how a redirection based on this speci= fication is any different than any other time an HTTP browser or SIP UA con= nects to a resource based on an arbitrary URL. In some sense, it's not.=C2=A0 My claim is more that users are being conditioned to expect payment prompts to appear at "arbitrary times" than a specific flaw in this workflow. > But to put some more context around this, the Diameter client is typicall= y a Network Access Server (NAS) that the end user is using for network acce= ss. The user is already at the mercy of that NAS, and that NAS is at the me= rcy of the credit-control application server. The user=E2=80=99s trust in t= hat NAS seems to have the same issues whether or not this Diameter applicat= ion is used. > > [yuval] agree with Ben, if someone bad took control over the NAS, they ca= n do much worse I agree that the NAS could send traffic to "wherever", but my objection could perhaps be categorized as more "social" than "technical".=C2=A0 Maybe I should attempt to give an example (and you can point out if I misunderstand things). I believe that a "normal usage" of this technology could be for a user with a prepaid data plan to be using a web browser, and, e.g., connect successfully to https://example.com. Suppose that this request used up their last remaining credits, and they click on a link from that page.=C2=A0 Instead of going to the actual target of that link, they are redirected to the data plan owner's top-up page, which displays a message "your balance is zero; please enter credit card information to purchase more data", the user pays, and can potentially even be redirected back to the actual target of the link they clicked on (though that's not key to my example).=C2=A0 Let's consider what would happen in an "attack scenario", where the same user has plenty of data quota remaining, and goes to https://honest-achmed.com. They click on a link from that page, which instead of going to an "actual site" that would be expected from the context surrounding the link, actually goes to http://[IP address controlled by attacker]/topup.html, which is designed to look as similar as possible to the actual data plan owner's top-up page.=C2=A0 The user may then enter their payment information, and get redirected to a site with actual content, believing that they have obtained more data quota from their provider, when in reality they have given their credit card information to a phisher. I don't see what mechanism is in place to allow the user to be able to distinguish between the "normal usage" scenario and the "attack scenario".=C2=A0 I also understand that this sort of technology is already deployed and is seen as useful by both users and data providers, so it seems unrealistic to expect to be able to get rid of this usage entirely.=C2=A0 I do think that it is unreasonable for us to enable this behavior without documenting the risks to the user, though. [yuval] I guess that there is nothing in the spec that technically enables = phishing, however, it makes the social engineering part of it easier. How a= bout the following addition to the security sections:"It is RECOMMENDED tha= t operators put in place mechanisms that would help their subscribers ident= ify a valid redirect operation from a malicious=C2=A0one" > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > >=C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the > >=C2=A0 Redirect-Server-Extension AVP MUST be present. > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > section 8.64 even internally inconsistent, too?) about > > "Redirect-Server AVP, in addition to or instead of the > > Redirect-Server-Extension AVP", in particular, the "instead of" > > portion.=C2=A0 (The ABNF-based formal language spec in 8.68 does match = up > > with the above MUST, though.) > > Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64 to = just =E2=80=9Cin addition to=E2=80=9D help? > > Authors: Please comment if that works, given the backwards-compatibility = concern. > [yuval] the cumbersome text is because of backward compatibility issue. W= ould appriciate suggestion for better phrasing. The idea is the following:*= We have an existing AVP that can carry some information* We need more info= rmation, but we cannot modify the existing one, so we added a new AVP (whic= h, unlike the old one, is future proof)* If you have a peer that does not s= upport the new spec, but only need the old info, you can use the old AVP. w= hat makes the spec backward compatible to the old one* If you have need to = send the new info, you have to use the new AVP, but in this case an older p= eer does not make sense To Ben, I believe that just "in addition to" resolves the internal inconsistency.=C2=A0 However, it sounds like that may not be the best solution from a deployment perspective, and perhaps the formal definition in Section 8.68 (and the body text) should be relaxed to allow either the -Extension or non-Extension form. [yuval] will remove "instead of" > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some additional significant but not necessarily DISCUSS-worthy > > comments, followed by more editorial- and nit-level things. > > > > In Section 1.3, "Advertising Application Support" uses the same > > Auth-Application-ID value as for RFC 4006; what are the interop > > consequences of this? > >=C2=A0[yuval] this was done to make interops easier - this is why we kep= t this RFC backward compatible with RFC4006 > > Alissa already noted that the text about how to split (sub-)AVPs > > between the foo and foo-Extension AVPs is inconsistent among them -- > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > send [in the old one]", but Subscription-Id-Extension has separate > > text about "[i]f full backward compatibility with [RFC4006] is > > required" and slightly different behavior described.=C2=A0 We should tr= y > > to catch all instances of this sort of backwards compatibility and > > make them consistent. > > I agree. > [yuval] will look to unify the text I see that there was some discussion on Alissa's ballot thread that there may indeed be special considerations for one AVP.=C2=A0 If so, that's fine, but the reasoning should probably be included in the document to explain the apparent disparity. [yuval] ok > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > > might benefit from additional text about the expected contents.=C2=A0 A > > lot of the time when we use a UTF8 container for names (whether > > domain names or other kinds), we specify what normalization form and > > canonicalization are performed, whether domain names are A-labels or > > U-labels, etc., as there's a lot of potential flexibility not all of > > which is good.=C2=A0 In this case, since the communication is only > > between trusted actors, perhaps the additional restrictions are not > > needed, but I am curious if the topic was raised in the WG. > > On reflection, shouldn=E2=80=99t that be based on whatever rules already = exist for the URL scheme? And if some scheme doesn=E2=80=99t have well defi= ned behavior for non-ascii labels, is that the concern of this application? It is probably a matter for the URL scheme, yes.=C2=A0 So at most we could note here that "individual URL schemes may restrict the contents of the UTF8String", but as I imply in my original comment, it's far from clear to me that we actually need to say anything in this specific case. > > > > Thank you for adding the Privacy Considerations and list of > > Privacy-Sensitive AVPs! > > > > Section 14 > > > >=C2=A0 [...] The Diameter credit- > >=C2=A0 control application is often used within one domain, and there ma= y be > >=C2=A0 a single hop between the peers.=C2=A0 In these environments, the = use of > >=C2=A0 TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > I did not see any concrete guidance on what would suffice in other > > environments (with multiple hops between peers).=C2=A0 Is this the real= m > > of the mythical "end-to-end security mechanism" for Diameter that is > > much-desired?=C2=A0 (The last paragraph does have guidance on what migh= t > > *not* suffice, which is not exactly the same thing.) > > > > Sort of, but in real world deployments the =E2=80=9Coften used within one= domain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D, whi= ch should be clarified) effectively overrides everything else. That is far = from ideal, but it=E2=80=99s the reality. So it basically comes down to kee= p everything in the trust domain, or if you cross a non-trusted network the= n use TLS or IPSec. > > There=E2=80=99s no solution to safely traverse a non-trusted Diameter age= nt. The mythical e2e mechanism could conceivably give us that.=C2=A0 (somed= ay, along with world peace and a post-scarcity economy). > > [yuval] as Ben and Lyle wrote, if your messages need to go through agents= that belong to a 3rd party, you have risks. In this case, AVP level encryp= tion (which is not standardized=C2=A0yet...) is the only option for to ensu= re privacy. So, the only thing we can do here is to highlight the risks.=C2= =A0 Do we want to say something about "at present, there is not a general reliable security solution for other environments"?=C2=A0 (To be clear, I do not insiste that we do so.) [yuval] not sure if AVP level ancryption would ever happen... would keep te= xt as is > >=C2=A0 Even without any modification to the messages, an adversary can > >=C2=A0 eavesdrop on transactions that contain privacy-sensitive informat= ion > >=C2=A0 about the user. > > > > This ("an adversary can") makes it sounds as if there is no > > confidentiality protection anywhere in the system, but that's what > > TLS/DTLS/IPSec are supposed to provide.=C2=A0 So maybe "an adversary th= at > > can eavesdrop on transactions can obtain privacy-sensitive > > information [...]" is better. > > > > Good point, I agree your suggestion is better.[yuval] ok > > > (Editorial- and nit-level stuff follows.) > > > > Section 4 > > > >=C2=A0 A flexible credit-control application specific failure handling i= s > >=C2=A0 defined in which the home service provider can model the credit- > >=C2=A0 control client behavior according to its own credit risk manageme= nt > >=C2=A0 policy. > > > > This sentence is hard to parse -- in "credit-control application > > specific" what does "specific" bind to?=C2=A0 What is being modelled?= =C2=A0 Is > > anything being controlled (as opposed to modelled)? > [yuval] ok. so how about: > "Flexible failure handling, specific to the credit-control, is defined in= the application.This allows the the service provider to control the credit= -control client behavior according to its ownrisk management policy" That's much better; thanks! > > Section 4.1.1 > > > >=C2=A0 2.=C2=A0 The Service-Parameter-Info AVP MAY be used as a containe= r to pass > >=C2=A0 legacy rating information in its original encoded form (e.g., ASN= .1 > >=C2=A0 BER).=C2=A0 [...] > > > > Why BER and not DER?=C2=A0 The unnecessary flexibility in BER vs. DER h= as > > been known to tickle parser bugs and create security > > vulnerabilities. > >=C2=A0 > [yuval] this is just an example of legacy stuff you have no control over > > > Section 4.1.2 > > > >=C2=A0 [...] To > >=C2=A0 facilitate interoperability, it is RECOMMENDED that the rating in= put > >=C2=A0 and the values of the Service-Context-Id be coordinated via an > >=C2=A0 informational RFC or other permanent and readily available refere= nce. > >=C2=A0 The specification of another cooperative standardization body (e.= g., > >=C2=A0 3GPP, OMA, or 3GPP2) SHOULD be used. > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > >=C2=A0 > [yuval] yes, seems a bit awkward. How about: > "To=C2=A0facilitate interoperability, it is RECOMMENDED that the rating i= nput > and the values of the Service-Context-Id be coordinated via an > informational RFC or other permanent and readily available reference, > preferably, of another cooperative standardization body (e.g., > =C2=A03GPP, OMA, or 3GPP2)." Sounds good. > > Section 5.1.1 > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > seems that this text could be reworded to just talk about a > > "constant rate" or "constant level per fixed time period" or > > similar. > >=C2=A0 > [yuval] "constant rate" could mean sub-second resolution as well. The gra= nts are in seconds, so, IMO, this phrasing is more accurate It seems that it's only more accurate if leap seconds are ignored. (I suppose you could explicitly disclaim "(ignoring leap seconds)" or similar.) [yuval] will add > > Section 5.1.2 > > > >=C2=A0 [...] > >=C2=A0 timer (Section 13) every time a CCR message with the value > >=C2=A0 UPDATE_REQUEST is sent while they are in PendingU state.=C2=A0 Wh= en > >=C2=A0 answers to all pending messages are received, the state machine m= oves > >=C2=A0 to OPEN state, and Tx is stopped. > > > > Transmission, or the Tx timer (is stopped)? > >=C2=A0 > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense of = "transmission" in the RFC (I think that "Tx timer" was fairly consistently used throughout the rest of the document; it may make sense to be fully consistent about it.) [yuval] will fix in the doc > > Using a different title for Section 5.2.2 might make the parallel > > between it and Section 5.2.1 more clear.=C2=A0 That is, perhaps somethi= ng > > like "First Interrogation Included with Authorization Messages". > >=C2=A0 > [yuval] make sense > > > Section 5.7 > > > >=C2=A0 [...] It is RECOMMENDED that the client complement the credit- > >=C2=A0 control failure procedures with backup accounting flow toward an > >=C2=A0 accounting server. [...] > > > > Nit: it looks like there's a missing article here, maybe "a backup > > accounting flow" is better. > >=C2=A0 > [yuval] the rest of the paragraph describe such "backup accounting flow".= See what comes after "For example" I just meant that it sounds like you need to add the word "a" in order for the grammar to make sense.=C2=A0 (But perhaps "the" is the right word; I wasn't sure.) [yuval] ok > >=C2=A0 The AAA transport profile [RFC3539] defines the application layer > >=C2=A0 watchdog algorithm that enables failover from a peer that has fai= led > >=C2=A0 and is controlled by a watchdog timer (Tw) defined in [RFC3539]. > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > >=C2=A0 > [yuval] would imagine there are other algorithms out there... should fix > > > Section 6.2 > > > > Should there be text indicating how the client indicates what > > service the balance check is being requested for? > >=C2=A0 > [yuval] didn't find any reference to service information for "EVET_REQUES= T" type messages (direct debit, refund, balance check and price enquiry). S= eems like that in the IEC section of 3GPP TS 32.299, they added their own m= echanism for "direct debit", and "refund", and leave "balance check" and "p= rice enquiry" as references to RFC4006. Unless I've missed something, this = seems like a missing part of the spec. > [yuval] hmm. seems like "event requests"=C2=A0should be looked at (probably= at the light of 3GPP 32.299 IEC concept). But for sure *not* as part of th= is work. > > Section 8.54 > > > > Maybe give a section reference in RFC 3580 for how the formatting is > > done? > >=C2=A0 > [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 i= n our RFC > > > Section 12 > > > >=C2=A0 [...] Initially, such Expert discussions take place on the AAA > >=C2=A0 WG mailing list. > > > > That list appears to be dead, suggesting that this text should be > > updated.=C2=A0 (I also agree with Adam's comments about updating the IA= NA Considerations.) > >=C2=A0 > [yuval] i don't know the process here - not sure how to change it. With respect to the "expert discussions take place" text, I think it could just be removed. Discussion of the detailed updates to the IANA actions should probably happen in Adam's ballot thread. > > Why is the disclaimer in Section B.4 (and other examples) not needed in= Section B.3? > [yuval] should be added there as well Great, thanks. -Benjamin |=20 |=20 | |=20 Example Domain | | | =20 ------=_Part_4840712_1592862768.1527142671872 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline

=20
=20
On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Ben= jamin Kaduk <kaduk@mit.edu> wrote:
[re= -sending since my client crashed during the first attempt and I
don't se= e the message in the archives.  I attempted to reconstruct
my messa= ge from a scrollback buffer, but there may be some artifacts
with missin= g or duplicated text]

On Wed, May 23, 2018 at 08:31:51AM +0000, Yuva= l Lifshitz wrote:
>  Thanks Ben and Benjamin! Comments inline>    On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Cam= pbell <ben@nostrum.com> wrote:
>
>  Hi Benjamin,
&= gt;
> I=E2=80=99ve cherry-picked a few points, inline:
>
>= ; Thanks!
>
> Ben.
>
> > On May 22, 2018, at 8:4= 8 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> >
> > Be= njamin Kaduk has entered the following ballot position for
> > dra= ft-ietf-dime-rfc4006bis-08: Discuss
> >
> > When respondi= ng, please keep the subject line intact and reply to all
> > email= addresses included in the To and CC lines. (Feel free to cut this
> = > introductory paragraph, however.)
> >
> >
> &g= t; Please refer to https://www.ietf.org/iesg/= statement/discuss-criteria.html
> > for more information about= IESG DISCUSS and COMMENT positions.
> >
> >
> >= The document, along with other ballot positions, can be found here:
>= ; > https://datatracker.ietf.org/doc/dr= aft-ietf-dime-rfc4006bis/
> >
> >
> >
>= ; > --------------------------------------------------------------------= --
> > DISCUSS:
> > -------------------------------------= ---------------------------------
> >
> > I support Aliss= a's Discuss point about sensitive AVPs.
> >
> > I appear = to have a different understanding of Section 5.6.2, though,
> > wi= th a different potential issue (but again, it's possible that I'm
> &= gt; confused to how things work):
> >
> > With the redire= ction schemes covered in Section 5.6.2, it sounds
> > like the use= r can be redirected (at the application protocol level,
> > e.g., = HTTP or SIP) to a top-up server to purchase more credits.  I
> &= gt; don't see a way described how user agents can distinguish between a
= > > Diameter-induced redirect and an attacker-induced redirect to a> > (potentially phishing) site that accepts payment information.&n= bsp; To be
> > clear, the scenario here is that a user is using a = credit-controlled
> > application session to talk to "arbitrary ap= plication servers",
> > including potentially attacker-controllled= HTTP/SIP/etc. servers;
> > the attacker could introduce a redirec= t to a phishing page that asks
> > for payment information, and th= e user would be led to believe that
> > this was the normal flow f= or "my prepaid balance has been used up",
> > and give their payme= nt information to the phishing site. I think
> > that either user = agents need to give some indication that this
> > DIAMETER-level r= edirect is different than an
> > application-protocol-level redire= ct (e.g., http) or the Security
> > Considerations need to mention= the risk of acclimating users to
> > arbitrary websites redirecti= ng to sites asking for payment
> > credentials, which may or may n= ot be legitimate sites.
> >
>
> I think it=E2=80=99s r= easonable to mention the concern in the security considerations. But I don= =E2=80=99t see how a redirection based on this specification is any differe= nt than any other time an HTTP browser or SIP UA connects to a resource bas= ed on an arbitrary URL.

In some sense, it's not.  My claim is m= ore that users are being
conditioned to expect payment prompts to appear= at "arbitrary times"
than a specific flaw in this workflow.


=
> But to put s= ome more context around this, the Diameter client is typically a Network Ac= cess Server (NAS) that the end user is using for network access. The user i= s already at the mercy of that NAS, and that NAS is at the mercy of the cre= dit-control application server. The user=E2=80=99s trust in that NAS seems = to have the same issues whether or not this Diameter application is used.
>
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> [yuval] agree with Ben, if someone = bad took control over the NAS, they can do much worse

= I agree that the NAS could send traffic= to "wherever", but my
objection could perhaps be categorized as more "social" than=
"technical".  Maybe I should a= ttempt to give an example (and you can
point out if I misunderstand things).
I believe that a "normal usage" of thi= s technology could be for a
user with a prepaid data plan to be using a web browser, and, e.g.,=
connect successfully = to https://example.com. Suppose that this
request used up their last remaining credits, and they click on a
link from that page.  Ins= tead of going to the actual target of that
link, they are redirected to the data plan owner's to= p-up page,
which displ= ays a message "your balance is zero; please enter credit
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">card information to purchase more data",= the user pays, and can
they clicked on (though th= at's not key to my example).  Let's
consider what would happen in an "attack scenario", wher= e the same
user has pl= enty of data quota remaining, and goes to
https://honest-achmed.com. They click on a link from that page,
which instead of going to an "actu= al site" that would be expected
from the context surrounding the link, actually goes to
http://[IP address controlled b= y attacker]/topup.html, which is
designed to look as similar as possible to the actual data plan<= /span>
owner's top-up page.&n= bsp; The user may then enter their payment
information, and get redirected to a site with actual= content,
believing th= at they have obtained more data quota from their
provider, when in reality they have given their = credit card
informatio= n to a phisher.

I = don't see what mechanism is in place to allow the user to be able
to distinguish between the "nor= mal usage" scenario and the "attack
scenario".  I also understand that this sort of technolo= gy is
already deployed= and is seen as useful by both users and data
providers, so it seems unrealistic to expect to be= able to get rid
of th= is usage entirely.  I do think that it is unreasonable for us
to enable this behavior withou= t documenting the risks to the user,
though.

[yuval] I guess that there is nothi= ng in the spec that technically enables phishing, however, it makes the soc= ial engineering part of it easier. How about the following addition to the = security sections:
"It is RECOMMENDED that operators put in place mechanisms that = would help their subscribers identify a valid redirect operation from a mal= icious one"

&g= t; > Separately, in Section 8.68 (for QoS-Final-Unit-Indication):=
> >
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> >  If the Final-Unit-Action= AVP is set to REDIRECT at least the
> >  Redirect-Server-Extension AVP MUST be presen= t.
> >
> > This MUST seems in co= nflict with the text in 8.64 (actually, is
> > section 8.64 even internally inconsistent, = too?) about
> > = "Redirect-Server AVP, in addition to or instead of the
= > > Redirect-Server-Extension AVP", = in particular, the "instead of"
> > portion.  (The ABNF-based formal language spec in = 8.68 does match up
>= ; > with the above MUST, though.)
>
&g= t; Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64 to= just =E2=80=9Cin addition to=E2=80=9D help?
>
> Authors: Please comment if that works, given the backwards-com= patibility concern.
&g= t; [yuval] the cumbersome text is because of backward compatibility issue. = Would appriciate suggestion for better phrasing. The idea is the following:= * We have an existing AVP that can carry some information* We need more inf= ormation, but we cannot modify the existing one, so we added a new AVP (whi= ch, unlike the old one, is future proof)* If you have a peer that does not = support the new spec, but only need the old info, you can use the old AVP. = what makes the spec backward compatible to the old one* If you have need to= send the new info, you have to use the new AVP, but in this case an older = peer does not make sense

To Ben, I believe that just "in addition to" resolves the internal<= /span>
inconsistency.  H= owever, it sounds like that may not be the best
solution from a deployment perspective, and perha= ps the formal
definiti= on in Section 8.68 (and the body text) should be relaxed toallow either the -Extension or non-Ex= tension form.

[yuval] will remove "instead of"
> >
> > --------------------------------------= --------------------------------
> > COMMENT:
> > ---------------------------------------------------------= -------------
> >= ;
> > Some addit= ional significant but not necessarily DISCUSS-worthy
> > comments, followed by more editori= al- and nit-level things.
> >
> >= ; In Section 1.3, "Advertising Application Support" uses the same
> > Auth-Application-ID v= alue as for RFC 4006; what are the interop
> > consequences of this?
<= span style=3D"font-size: 13px;">> > [yuval] this was done to mak= e interops easier - this is why we kept this RFC backward compatible with R= FC4006
> > Aliss= a already noted that the text about how to split (sub-)AVPs> > between the foo and foo-Ext= ension AVPs is inconsistent among them --
> > e.g., Redirect-Server-Extension and User-Eq= uipment-Info say "SHOULD
> > send [in the old one]", but Subscription-Id-Extension has sepa= rate
> > text ab= out "[i]f full backward compatibility with [RFC4006] is
> > required" and slightly differen= t behavior described.  We should try
> > to catch all instances of this sort of back= wards compatibility and
>
> = I agree.
> [yuval] = will look to unify the text

I see that there was some discussion on Alissa's ballot thread th= at
there may indeed be= special considerations for one AVP.  If so,
that's fine, but the reasoning should probably = be included in the
doc= ument to explain the apparent disparity.

[yuval] ok<= br>
> > The use of UTF8String = for URLs and URIs (e.g., Redirect-Address-URL)
> > might benefit from additional text about= the expected contents.  A
> > lot of the time when we use a UTF8 container for names = (whether
> > dom= ain names or other kinds), we specify what normalization form and
> > canonicalization are = performed, whether domain names are A-labels or
> > U-labels, etc., as there's a lot of pot= ential flexibility not all of
> > which is good.  In this case, since the communicatio= n is only
> > be= tween trusted actors, perhaps the additional restrictions are not
> > needed, but I am curi= ous if the topic was raised in the WG.
>
= > On reflection, shouldn=E2=80=99t that be based on whatever rules alrea= dy exist for the URL scheme? And if some scheme doesn=E2=80=99t have well d= efined behavior for non-ascii labels, is that the concern of this applicati= on?

It is probably= a matter for the URL scheme, yes.  So at most we
= could note here that "individual URL schem= es may restrict the
co= ntents of the UTF8String", but as I imply in my original comment,
it's far from clear to me that = we actually need to say anything in
this specific case.

> >
> > Thank you for adding the Privacy Considerations and list of
> > Privacy-Sensi= tive AVPs!
> >
> > Section 14
> ><= br>> >  [...] The Diameter c= redit-
> > = control application is often used within one domain, and there may be
> >  a single h= op between the peers.  In these environments, the use of=
> >  TLS/TCP, DTLS/SCTP = or IPsec is sufficient.
> > = I did not see any concrete guidance on what would suffice in other
> > environments (with m= ultiple hops between peers).  Is this the realm
> > of the mythical "end-to-end securi= ty mechanism" for Diameter that is
> > much-desired?  (The last paragraph does have gu= idance on what might
&= gt; > *not* suffice, which is not exactly the same thing.)=
> >
>
> Sort of, but in real world deployments the =E2=80=9Coften u= sed within one domain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain= =E2=80=9D, which should be clarified) effectively overrides everything else= . That is far from ideal, but it=E2=80=99s the reality. So it basically com= es down to keep everything in the trust domain, or if you cross a non-trust= ed network then use TLS or IPSec.
>
> = There=E2=80=99s no solution to safely traverse a non-trusted Diameter agent= . The mythical e2e mechanism could conceivably give us that.  (someday= , along with world peace and a post-scarcity economy).
= >
> [yuval] as Ben and Lyle wrote, if your messages need t= o go through agents that belong to a 3rd party, you have risks. In this cas= e, AVP level encryption (which is not standardized yet...) is the only= option for to ensure privacy. So, the only thing we can do here is to high= light the risks. 

Do we want to say something about "at present, there is not a
general reliable security solu= tion for other environments"?  (To be
clear, I do not insiste that we do so.)=

[yuval] not sure if AVP level ancryption would ever happen...= would keep text as is

&g= t; >  Even without any modification to the messages, an adversary c= an
> >  eav= esdrop on transactions that contain privacy-sensitive information
> >  about the user.=
> >
> > This ("an adversary can= ") makes it sounds as if there is no
> > confidentiality protection anywhere in the system,= but that's what
> = > TLS/DTLS/IPSec are supposed to provide.  So maybe "an adversary t= hat
> > can eave= sdrop on transactions can obtain privacy-sensitive
> > information [...]" is better.=
> >
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">>
> Good point, I agree your suggestion is better.[yuval= ] ok
>
> > (Editorial- and nit-leve= l stuff follows.)
>= >
> > Sectio= n 4
> >
> >  A flexible cre= dit-control application specific failure handling is
> >  defined in which the home se= rvice provider can model the credit-
> >  control client behavior according to its own= credit risk management
> >
> >= ; This sentence is hard to parse -- in "credit-control application
> > specific" what does = "specific" bind to?  What is being modelled?  Is> > anything being controlled (a= s opposed to modelled)?
> "Flexible failure handling, specific to the credit-control,= is defined in the application.This allows the the service provider to cont= rol the credit-control client behavior according to its ownrisk management = policy"

That's muc= h better; thanks!

= > > Section 4.1.1
> >&= nbsp; 2.  The Service-Parameter-Info AVP MAY be used as a container to= pass
> >  = legacy rating information in its original encoded form (e.g., ASN.1<= /font>
> >  BER).  [= ...]
> ><= /font>
> > Why BER and not DER= ?  The unnecessary flexibility in BER vs. DER has
= > > been known to tickle parser bugs= and create security
&= gt; > vulnerabilities.
> > 
&g= t; [yuval] this is just an example of legacy stuff you have no control over=
>> > Section 4.1.2<= br>> >
> >  [...] To
> >  facilitate interoperability, = it is RECOMMENDED that the rating input
> >  and the values of the Service-Context-Id = be coordinated via an
= > >  informational RFC or other permanent and readily available = reference.
> >&n= bsp; The specification of another cooperative standardization body (e.g.,
> >  3GPP, O= MA, or 3GPP2) SHOULD be used.
> >
>= > The RECOMMENDED and SHOULD seem slightly in conflict.> > 
<= span style=3D"font-size: 13px;">> [yuval] yes, seems a bit awkward. How = about:
> "To f= acilitate interoperability, it is RECOMMENDED that the rating input<= /font>
> and the values of the Se= rvice-Context-Id be coordinated via an
> informational RFC or other permanent and readily avai= lable reference,
> = preferably, of another cooperative standardization body (e.g.,
>  3GPP, OMA, or 3GPP2)."<= /span>

Sounds good.

> > Section 5.1.1=
> >
> > As noted elsewhere, 60 = seconds per minute does not always hold; it
> > seems that this text could be reworded to j= ust talk about a
> = > "constant rate" or "constant level per fixed time period" or
> > similar.
> > 
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> [yuval] "constant rate" could mean = sub-second resolution as well. The grants are in seconds, so, IMO, this phr= asing is more accurate

It seems that it's only more accurate if leap seconds are ignored.
(I suppose you could expl= icitly disclaim "(ignoring leap seconds)"
or similar.)

[yuval] will = add

> > Section 5.1= .2
> >
> >  [...]
> >  timer (Section = 13) every time a CCR message with the value
> >  UPDATE_REQUEST is sent while they are= in PendingU state.  When
> >  answers to all pending messages are received, the = state machine moves
&g= t; >  to OPEN state, and Tx is stopped.
> >
> > Transmission, or the Tx timer (is stopped)?<= /font>
> > =
> [yuval] well, "Tx" is overload= ed :-( but we never use it in the sense of "transmission" in the RFC=

(I think that "Tx timer"= was fairly consistently used throughout the
rest of the document; it may make sense to be full= y consistent about
it.= )

[yuval] will fix in the doc

<= span style=3D"font-size: 13px;">> > Using a different title for Secti= on 5.2.2 might make the parallel
> > between it and Section 5.2.1 more clear.  That is= , perhaps something
&g= t; > like "First Interrogation Included with Authorization Messages".
> > 
> [yuval] make sense=
>
> > Section 5.7
> >
> >  [...] It is RECOMMENDED that the client c= omplement the credit-
= > >  control failure procedures with backup accounting flow towa= rd an
> >  = accounting server. [...]
> >
> >= Nit: it looks like there's a missing article here, maybe "a backup<= /font>
> > accounting flow" is= better.
> >&nbs= p;
> [yuval] the re= st of the paragraph describe such "backup accounting flow". See what comes = after "For example"


order for the grammar to make = sense.  (But perhaps "the" is the
right word; I wasn't sure.)

[yu= val] ok

> >  The AAA transport profile [RFC3539] defines the applicatio= n layer
> > = ; watchdog algorithm that enables failover from a peer that has failed
> >  and is con= trolled by a watchdog timer (Tw) defined in [RFC3539].
= > >
> > Nit: Is it "the" watchdog algorithm or "an"= watchdog algorithm?
&= gt; > 
> [y= uval] would imagine there are other algorithms out there... should fix
>
<= span style=3D"font-size: 13px;">> > Section 6.2
<= span style=3D"font-size: 13px;">> >
> > Should there be text indicating how the cli= ent indicates what
>= ; > service the balance check is being requested for?
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> > 
> [yuval] didn't find any reference to serv= ice information for "EVET_REQUEST" type messages (direct debit, refund, bal= ance check and price enquiry). Seems like that in the IEC section of 3GPP T= S 32.299, they added their own mechanism for "direct debit", and "refund", = and leave "balance check" and "price enquiry" as references to RFC4006. Unl= ess I've missed something, this seems like a missing part of the spec.
>

<= div style=3D"">[yuval] hmm. seems like "event requests" should b= e looked at (probably at the light of 3GPP 32.299 IEC concept). But for sur= e *not* as part of this work.

> > Section 8.54
> >
> > Maybe give a section reference in RFC 3580 for how t= he formatting is
> = > done?
> >&n= bsp;
> [yuval] see = section 3.21 in RFC3580, this is also true for section 8.50 in our RFC
>
<= span style=3D"font-size: 13px;">> > Section 12
> >
> >  [...] Initially, such Expert discussions= take place on the AAA
> >  WG mailing list.
> >
= > > That list appears to be dead, suggesting that this text should be=
> > updated.&nb= sp; (I also agree with Adam's comments about updating the IANA Consideratio= ns.)
> > 
> [yuval] i don't kn= ow the process here - not sure how to change it.

With respect to the "expert discussions take= place" text, I think it
could just be removed.

Discussion of the detailed updates to the IANA actions should
probably happen in Adam's b= allot thread.

>= > Why is the disclaimer in Section B.4 (and other examples) not needed = in Section B.3?
> [= yuval] should be added there as well

Great, thanks.


-Benjamin



------=_Part_4840712_1592862768.1527142671872-- From nobody Wed May 23 23:43:20 2018 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 5B09212D95A for ; Wed, 23 May 2018 23:43:19 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f9hkaYSrh-j for ; Wed, 23 May 2018 23:43:17 -0700 (PDT) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FE112D958 for ; Wed, 23 May 2018 23:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527144196; bh=isObVCNipWYhk5vv9bK9buOGw9WKyXpRLih3xu2/Yrg=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=PM325B/NoAH76gSiZYWwBz4bSUfssPep1O/mBZv9Tnyjk1cqlB3JEvOR2u2XLVTUg7HUVMi8CBP2ebsNcdO81k0ZKlgNFNLQ25KELqaook7m2kO54rdBupEKusWCRRz24xyHEk2WrjGwUu2/scIgkRAlkZsv9rkbg3s4Wd8JOXe1oZJTXLLyfgQkbrOIGMTei+wdO3Dn9Xu0mW/ILLatp7knkAd4sYSQh8RLSaWEpBOqGFq6FoZkDa6QpUBfwIFPCwk+ySOO/JH3GKw+brxpS4IeNlmcwQ/eTks/xvDpUZtbjWxu8d9qNCmD1wCTFKWyb6qVraPDkgD9B2Lx3BKUMQ== X-YMail-OSG: AjUAeRAVM1kG5JzUIAd6MUTpkDRFOPscYbiPx8I2a85t9jGN6PLb8H.HsKwiEc7 eCK0A5KlKr5J4dxV45c2W1ND11hxTfv9ZjqDEQ7n6uoXMDFxtv6VrER3EmSFP8cW.5KugnRmhdub O3BKmjNicZNjttwBWSmEbMixotFvl9FQQ5loE8MFJYiCY6kHcp3zgncH58X9DswdPN83eDMOrBmK 1wRlfPiEn3HByPiGiR17iq2LRdFl44IrFPVawQIgtXE2lu5X3Z8l1CDmpPW316gkx9s5TaEcd9lV L1khg9Fg3yCW0Xov7bbine3GQ3N8K0cM33yUspzYusenfFPcsFLzWyh0vxUOsRBn1F7c.Ai.bPIp y7LeT0AIpQVipa8yD8hhfmGUh2DLupgXyILAmvMK0ro0D7OodG4eMDp076tbd2TRNNHWnuIHQlu3 h9rEqxZWdI8oEVXlP_SRY2qzrihodbDLGZRiwBodq4N43QL3d3DhwjWtoG1MDIk_JQqPmGcL1tVq q0QrfJeu.TvFUNqZMBF4p9sboWXUYCFe7pYbXn6ZpB_.vnxfgYRLkJOp5TJ9w1Zhvvw6PrTCOeg4 RXtPuxWmpRrYXRfikrkv3isz.fGUio5E1SKrL9qBOKMsW_xGF6IzBJvRzQMCn2RjAPWlojXQL5ju snmqtKV0Tzh_qwlXjAU_4bxeLBrxeSwQuuOJrqTv8NpbMmgnsm2zeyy4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 06:43:16 +0000 Date: Thu, 24 May 2018 06:33:13 +0000 (UTC) From: Yuval Lifshitz To: The IESG , Eric Rescorla Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <2012436261.4832236.1527143593730@mail.yahoo.com> In-Reply-To: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4832235_1427263167.1527143593725" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 06:43:19 -0000 ------=_Part_4832235_1427263167.1527143593725 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inline On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla wrote: =20 =20 Eric Rescorla has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deduction of credit from the end user account = when service is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 completed and refunding of reserved credit tha= t is not used. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Diameter Credit-control Server=C2=A0 A Diameter credi= t-control server acts >=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a prepaid server, performing real-time rati= ng and credit- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 control.=C2=A0 It is located in the home domai= n and is accessed by a definition of "home domain" would be useful [yuval] base spec define "home realm" we should probably change to that S 2. >=C2=A0 =C2=A0 =C2=A0 credit-control application. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 When an end user requests services such as SIP or mes= saging, the >=C2=A0 =C2=A0 =C2=A0 request is typically forwarded to a service element (= e.g., SIP Proxy) >=C2=A0 =C2=A0 =C2=A0 in the user's home domain.=C2=A0 In some cases it mig= ht be possible that >=C2=A0 =C2=A0 =C2=A0 the service element in the visited domain can offer s= ervices to the also define visited domain, or at least point to a reference. [yuval] base spec defined "local realm" for that. will fix S 3.1. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CC-Correlation-Id ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extensi= on ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Proxy-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] Please expand AVP on first use. [yuval] it is in the base spec S 4. >=C2=A0 =C2=A0 =C2=A0 control client requests credit authorization from the= credit-control >=C2=A0 =C2=A0 =C2=A0 server prior to allowing any service to be delivered = to the end user. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 In the first model, the credit-control server rates t= he request, >=C2=A0 =C2=A0 =C2=A0 reserves a suitable amount of money from the user's a= ccount, and >=C2=A0 =C2=A0 =C2=A0 returns the corresponding amount of credit resources.= =C2=A0 Note that Sorry, reserves the balance or the amount reserved? [yuval] not sure what is not clear? S 14. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Even without any modification to the messages, an adv= ersary can >=C2=A0 =C2=A0 =C2=A0 eavesdrop on transactions that contain privacy-sensit= ive information >=C2=A0 =C2=A0 =C2=A0 about the user.=C2=A0 Also, by monitoring the credit-= control messages one >=C2=A0 =C2=A0 =C2=A0 can collect information about the credit-control serv= er's billing >=C2=A0 =C2=A0 =C2=A0 models and business relationships. I'm having trouble reading these two paragraphs. Are they about what happens if TLS isn't used? [yuval] will clarify. see here:=C2=A0https://github.com/lbertz02/rfc4006bis= /issues/51 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_4832235_1427263167.1527143593725 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline

=20
=20
On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:


Eric Rescorla has entered the fol= lowing ballot position for
draft-ietf-dime-rfc400= 6bis-08: No Objection

= When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel= free to cut this
introductory paragraph, however= .)


for mor= e information about IESG DISCUSS and COMMENT positions.


The document= , along with other ballot positions, can be found here:



-----------= -----------------------------------------------------------
COMMENT:
-----------------------------= -----------------------------------------

Rich version of this review at:


I only gave this a light read. Some minor comments below.

COMMENTS
S 1.2.
>        deductio= n of credit from the end user account when service is
>        completed and refunding of reserved c= redit that is not used.
> 
>      Diameter Credit-control Server = A Diameter credit-control server acts
> =       as a prepaid server, performing real-time rating and= credit-
>        control= .  It is located in the home domain and is accessed by

a definition of "home domain" would b= e useful

[yuval] base spec define "ho= me realm" we should probably change to that

S 2.
>  =     credit-control application.
>&nb= sp;
>      When an end user r= equests services such as SIP or messaging, the
&g= t;      request is typically forwarded to a service element = (e.g., SIP Proxy)
>      in the= user's home domain.  In some cases it might be possible that
>      the service element in the visit= ed domain can offer services to the

also define visited domain, or at least point to a reference.=

[yuval] base spec defined "local rea= lm" for that. will fix

S 3.1.
>       = ;                     &nb= sp;     [ CC-Correlation-Id ]
>&nbs= p;                     &n= bsp;           [ User-Equipment-Info ]
<= div dir=3D"ltr">>               =                   [ User-Equ= ipment-Info-Extension ]
>      =                      = ;       *[ Proxy-Info ]
> =                     &nbs= p;           *[ Route-Record ]
>                 =                 *[ AVP ]
=

Please expand AVP on first use.=

[yuval] it is in the base spec

S 4.
>      control client requests credit auth= orization from the credit-control
>  &nbs= p;   server prior to allowing any service to be delivered to the end u= ser.
> 
>&= nbsp;     In the first model, the credit-control server rates the= request,
>      reserves a sui= table amount of money from the user's account, and
>      returns the corresponding amount of credit resou= rces.  Note that

= Sorry, reserves the balance or the amount reserved?

[yuval] not sure what is not clear?

S 14.
>= ; 
>      Even without a= ny modification to the messages, an adversary can
>      eavesdrop on transactions that contain privacy-se= nsitive information
>      abou= t the user.  Also, by monitoring the credit-control messages one
>      can collect information about= the credit-control server's billing
>  &= nbsp;   models and business relationships.
<= br>
I'm having trouble reading these two paragraphs. = Are they about what
happens if TLS isn't used?




=

_______________________________= ________________
DiME mailing list
------=_Part_4832235_1427263167.1527143593725-- From nobody Thu May 24 05:26:47 2018 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9915812E856; Thu, 24 May 2018 05:26:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152716480462.29976.8086290676124985634.idtracker@ietfa.amsl.com> Date: Thu, 24 May 2018 05:26:44 -0700 Archived-At: Subject: [Dime] Alexey Melnikov's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 12:26:45 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I only scanned the document, so I only have one minor question/comment: In Section 8.39: Redirect-Server-Address looks underspecified to me. It says "address". Is it a well known DIAMETER term? What is the syntax of address? Is it a URI or something else? From nobody Thu May 24 05:45:29 2018 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 9F63512E8A8; Thu, 24 May 2018 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ty69muBb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b1ZDJZlq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_Ac3-7Xt7EL; Thu, 24 May 2018 05:44:58 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E9012E8F1; Thu, 24 May 2018 05:44:58 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1D7AC21C1A; Thu, 24 May 2018 08:44:58 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 24 May 2018 08:44:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=SwBikzgnztqE3KucL7JXu/yuYZrNB UAOuOI2ECB0HfI=; b=ty69muBbiEauBTqZ/NI3ZiLu9r7VKEzO5/iQYn+czPJP9 tQiszjDZRatHQtLvcXUqxEFeMuQHbXHPktIZX+vlhu6D/9DIkLlCo3Gj9uFnpfkD efhtR11n3wBC5LZNul7HbfTjSiWqwgFunTKh1J1m8loqHhuwok6J2ZNnf1DsEGxZ dwe045LaImK3DXPIaahgYb2Ng8gSJJ/MUfElwGJiHK8d5Q1QGOjT204D448YXmne nsWKAcRx0MxJjvDam5n1p4WBFBANx1XPH0aWzqvEt+VYgVcljGDTnbGulcVBQws3 hI8hR005z6BsKbiwnX4RZm/LH3ChLRzPrCkaJ3hog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SwBikz gnztqE3KucL7JXu/yuYZrNBUAOuOI2ECB0HfI=; b=b1ZDJZlq6I80zIUksu6RRJ 0hcQDZEBaznZdB99HVORGSTuZCiBOBhzR+aAL/grkRCfLs0tkXnAS3do5ziWSAqn iQlmH3OVgwNQcFJI2KwQrxGOS5PBD3qkpLCe2aFXrbVZ25MO9Qp0MlEjqY5CopNG fyug1ADieRFRzYZiNyr2JVIdR+Do29Rf0yzeLbVvsp1c1AnOWzSRvr2Xjm7Z6Qeu jYqLZmWSbZqkhKaGDFRsevKSvrdwkAOZt9rjqTuuASusQdoWMcYNlN3UrWit9l76 iSRPRsLygIy6SsYs48n+SNl+p5HD0IpYDGJoIiO+jhEPeFI3oek7evZKa514cqqA == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E3DB39E0A5; Thu, 24 May 2018 08:44:56 -0400 (EDT) Message-Id: <1527165896.143725.1383358696.52AE275A@webmail.messagingengine.com> From: Alexey Melnikov To: Yuval Lifshitz , The IESG Cc: dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15271658961437257" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 References: <152716480462.29976.8086290676124985634.idtracker@ietfa.amsl.com> <587088516.4915767.1527165417345@mail.yahoo.com> Date: Thu, 24 May 2018 13:44:56 +0100 In-Reply-To: <587088516.4915767.1527165417345@mail.yahoo.com> Archived-At: Subject: Re: [Dime] Alexey Melnikov's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 12:45:13 -0000 This is a multi-part message in MIME format. --_----------=_15271658961437257 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Yuval, On Thu, May 24, 2018, at 1:36 PM, Yuval Lifshitz wrote: > > Hi Alexey, > Different Redirect-Address-Type values would mean different formats of > Redirect-Server-Address, this is why the formatting is specified in > 8.38 and not 8.39.Ah, great. Maybe point to section 8.38 in section 8.39? E.g. something like "The address syntax is specified by Redirect-Address-Type (see Section 8.38)"? Best Regards, Alexey > > Yuval > > On Thursday, May 24, 2018, 3:26:54 p.m. GMT+3, Alexey Melnikov > wrote:> > > Alexey Melnikov has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: No Objection > > When responding, please keep the subject line intact and reply to all> email addresses included in the To and CC lines. (Feel free to > cut this> introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > ----------------------------------------------------------------------> COMMENT: > ----------------------------------------------------------------------> > I only scanned the document, so I only have one minor > question/comment:> > In Section 8.39: Redirect-Server-Address looks underspecified to > me. It says> "address". Is it a well known DIAMETER term? What is the syntax of > address? Is> it a URI or something else? > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --_----------=_15271658961437257 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Yuval,

On Thu, May 24, 2018, at 1:36 PM, Yuval Lifshitz wrote:

Hi Alexey,
Different Redirect-Address-Type values would mean different formats of Redirect-Server-Address, this is why the formatting is specified in 8.38 and not 8.39.
Ah, great.

Maybe point to section 8.38 in section 8.39? E.g. something like "The address syntax is specified by Redirect-Address-Type (see Section 8.38)"?

Best Regards,
Alexey


Yuval

On Thursday, May 24, 2018, 3:26:54 p.m. GMT+3, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:


Alexey Melnikov has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I only scanned the document, so I only have one minor question/comment:

In Section 8.39: Redirect-Server-Address looks underspecified to me. It says
"address". Is it a well known DIAMETER term? What is the syntax of address? Is
it a URI or something else?


_______________________________________________
DiME mailing list

--_----------=_15271658961437257-- From nobody Thu May 24 05:47:04 2018 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 C4E8112DA50 for ; Thu, 24 May 2018 05:47:02 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ZGOfZeXVoJ for ; Thu, 24 May 2018 05:47:01 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597B0126D45 for ; Thu, 24 May 2018 05:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527166020; bh=02rv+xQHd/x8lCajn3zbhFwcQNgWkhatkXkC+gPsXSs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=nspSrcQwYaRo7rajU7ZgLI2W9o9ASzuwz81W/aCIsSeRKupttKdE7VFZyS7qsGmhD7Tw8w/JeqPL4IvncKDmNN1VMIu5gmPea9xlueDzWE7z9bwPJYCVoimp0Jok4D377Lm1mPV+N2yb/kd4N8AgTj+NktChOjAbeWa4cs1KQddet7cBeXkMImODqCrUTH5JlTilSSZqzdzS9PhD2RVW22zC0IfZJZ9JAu/IEQ9qqHMuyNz01I/T08FsdFUe7q4ySGcgAvUZTLTmb5S/MuZrRXA8aN5XtuTxLd9O1CJxjNdAk9tFGQDcAkXD8ELmdDpyBCHKkgj8IY4Za3DNRWLobg== X-YMail-OSG: SFKM35AVM1n8Vd.UR00tp0AF_uAZ9upcUQjsytFmcyjn0DnDBJjtybJLKPo_vn3 0KT5Z6ZjJQOdbyDVpQaC_MGNgGA0EtW4ygD2XqPh0TLE4HJXABE5FCq.O4EsMCqRm6Z5HrWlG3a6 I_s4iG1bHqqpSvv5ZtxVqQ3pTltMWDeOI74dbL1TXp9OoNwxcBP3SUK4NA2DQY0be9ht0EIjdGnA HiNXoqaNgeAVeW3WSidNNGBeB2Og_ifLO9swT6Dx_k1j292IGZPE0N4HczJi1Dm_FwRdWwULL3LL 0bvRLkTe3IDPq9bSy9Wpi.LSwENlBwj4.HxcOt.9n45qkx7pbnss_Nttms.rCkiLCnKQ8t3DbF8Z DSZIqqk4bZjznLImKaf.3VFqo21aXifhqk2w0HdwqYN8C7QB__NQ4XatJurIypElQ_Vwq7dnQwh1 afPdSsuO3vBZw1cnZ6cVe4jjMQm2WzvFv80IcBt.V80i8_hiPEtB4_.IRE9flPJjnnKZ8kkb53B0 Ac5qhmQxOwCNczIre6PCrSj54nRh0ewGndbQ8EWcXLqGDtFL6vd0pprVe5chM9UAtuwvUtu_D__D _UhsmhUgEfoQCcc._0urSLmc8n1BoCOhMsLZFhTYS8RKVI_IYX_l5HdgvinXwxoGb31_Bj4oO8S0 ZWg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 12:47:00 +0000 Date: Thu, 24 May 2018 12:36:57 +0000 (UTC) From: Yuval Lifshitz To: The IESG , Alexey Melnikov Cc: dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <587088516.4915767.1527165417345@mail.yahoo.com> In-Reply-To: <152716480462.29976.8086290676124985634.idtracker@ietfa.amsl.com> References: <152716480462.29976.8086290676124985634.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4915766_802061324.1527165417342" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Alexey Melnikov's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 12:47:03 -0000 ------=_Part_4915766_802061324.1527165417342 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alexey,Different=C2=A0Redirect-Address-Type values would mean different= formats of=C2=A0Redirect-Server-Address, this is why the formatting is spe= cified in 8.38 and not 8.39. Yuval On Thursday, May 24, 2018, 3:26:54 p.m. GMT+3, Alexey Melnikov wrote: =20 =20 Alexey Melnikov has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I only scanned the document, so I only have one minor question/comment: In Section 8.39: Redirect-Server-Address looks underspecified to me. It say= s "address". Is it a well known DIAMETER term? What is the syntax of address?= Is it a URI or something else? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_4915766_802061324.1527165417342 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alexey,
Different Redirect-Address= -Type values would mean different formats of Redirect-Server-Add= ress, this is why the formatting is specified in 8.38 and not 8.39.<= /span>

Yuval=

=20
=20
On Thursday, May 24, 2018, 3:26:54 p.m. GMT+3, Alex= ey Melnikov <aamelnikov@fastmail.fm> wrote:


Alexey Melnikov has entered the f= ollowing ballot position for
draft-ietf-dime-rfc4= 006bis-08: No Objection

When responding, please keep the subject line intact and reply to all
=
email addresses included in the To and CC lines. (Fe= el free to cut this
introductory paragraph, howev= er.)


for more information ab= out IESG DISCUSS and COMMENT positions.


The document, along with other= ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/


=
------------------------------------------------= ----------------------
COMMENT:
------------------------------------------------------------------= ----

I only scanned th= e document, so I only have one minor question/comment:

In Section 8.39: Redirect-Server-Address l= ooks underspecified to me. It says
"address". Is = it a well known DIAMETER term? What is the syntax of address? Is
<= div dir=3D"ltr">it a URI or something else?

<= /div>

__________________________= _____________________
DiME mailing list
=
------=_Part_4915766_802061324.1527165417342-- From nobody Thu May 24 06:01:33 2018 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 42A2C12E878; Thu, 24 May 2018 06:01:26 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJuHA87fYTTn; Thu, 24 May 2018 06:01:21 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3FF12E858; Thu, 24 May 2018 06:01:20 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id r13-v6so540628ybm.12; Thu, 24 May 2018 06:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fu0rRe4LhF+tKttz9q/2tnxQ6eVwffW7H20+HJVqOxU=; b=iZvV9+rJuNdUz43uAnPcS2g1sD7SdCLPdYrX0Z0JuwwrDTcdexAjtSRNbMQR++CYCu cm8Eryrq1dxxmRC0clxiZ813xeFPO7odj4xsrLGQHS3HELpT9vmuV14HVCBRP2KNrWaZ Jc3ZmkJGPNqKRNeXlKT3EOwSAOw4Sy5qWXCO2F3R0eiY7IVvcph4Rx28goNFePvY6vNu V3malpil3RLE77dROnlLStLqk0p3zIFMrQ0Ly3RaGSHIFCez1bE1By10sfJzRRHKSPsU Jm6eDcu9sR/x52e5f8NzmpzmZc0GQJa7uGKnswPoyQl9j6I89gaPZ9v8s0b2GVrFKV7i hpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fu0rRe4LhF+tKttz9q/2tnxQ6eVwffW7H20+HJVqOxU=; b=ncQise2EkMKYAGZxYennESYeb0p1rMyWiwCxSHWWF56/R+o8Klpb9J9nmrr4pNoHMB Hn9mb4InE7iLo6TzAuOAoQSBrsN+Kv6VeR+uXJ3E9EzrQdxG8WyLeTDrN/3qziOumfGW 1HP+1bQW87UhVJsDlqjZ/sL3DJQY5cGlZy6FCbPcYbwid+vCYvtsHpjySBTXTDWYC0Wq P94uv/1qy3xKf2OuIudOm9xLNNLIHOk1TiCXFMsPrSexI2jOUpBI/F5XobFBIsX0GIu8 qAI6aOBGb4uVU5wGVlNEh9NlbFrVNpCWi5Qaoawc0Wt6JzTJMqq8rbzDSR/7naYPG/Ne qLTQ== X-Gm-Message-State: ALKqPwfhGWcAikRvnDtHIO3oDhKsyRgYdfnw6V15FwaD1/K0esYj4EXM c5ito+dhva6DiQsw2502ZodKEiEUiKeCpHe4TdM= X-Google-Smtp-Source: AB8JxZq48tKGQ2O2FI66d1vGrhnHegn7w9TiiggsFSKrtUhZFU1ru0Mb1XRN9gNREOpbI7gt1kmqEYYiLW9qKurWv24= X-Received: by 2002:a25:4d57:: with SMTP id a84-v6mr4109894ybb.286.1527166878075; Thu, 24 May 2018 06:01:18 -0700 (PDT) MIME-Version: 1.0 References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> In-Reply-To: <1467920717.4840713.1527142671894@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Thu, 24 May 2018 08:01:04 -0500 Message-ID: To: yuvalif=40yahoo.com@dmarc.ietf.org Cc: Benjamin Kaduk , Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, IESG , draft-ietf-dime-rfc4006bis@ietf.org Content-Type: multipart/alternative; boundary="00000000000047ce65056cf33fde" Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 13:01:27 -0000 --00000000000047ce65056cf33fde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Keeping in mind that this is Benjamin's ballot thread, so what he thinks matters more than what I think ... On Thu, May 24, 2018 at 1:20 AM Yuval Lifshitz wrote: > *inline* > > On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk < > kaduk@mit.edu> wrote: > > > [re-sending since my client crashed during the first attempt and I > don't see the message in the archives. I attempted to reconstruct > my message from a scrollback buffer, but there may be some artifacts > with missing or duplicated text] > > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > > Thanks Ben and Benjamin! Comments inline > > On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell < > ben@nostrum.com> wrote: > > > > Hi Benjamin, > > > > I=E2=80=99ve cherry-picked a few points, inline: > > > > Thanks! > > > > Ben. > > > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > > > I appear to have a different understanding of Section 5.6.2, though, > > > with a different potential issue (but again, it's possible that I'm > > > confused to how things work): > > > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > > like the user can be redirected (at the application protocol level, > > > e.g., HTTP or SIP) to a top-up server to purchase more credits. I > > > don't see a way described how user agents can distinguish between a > > > Diameter-induced redirect and an attacker-induced redirect to a > > > (potentially phishing) site that accepts payment information. To be > > > clear, the scenario here is that a user is using a credit-controlled > > > application session to talk to "arbitrary application servers", > > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > > the attacker could introduce a redirect to a phishing page that asks > > > for payment information, and the user would be led to believe that > > > this was the normal flow for "my prepaid balance has been used up", > > > and give their payment information to the phishing site. I think > > > that either user agents need to give some indication that this > > > DIAMETER-level redirect is different than an > > > application-protocol-level redirect (e.g., http) or the Security > > > Considerations need to mention the risk of acclimating users to > > > arbitrary websites redirecting to sites asking for payment > > > credentials, which may or may not be legitimate sites. > > > > > > > I think it=E2=80=99s reasonable to mention the concern in the security > considerations. But I don=E2=80=99t see how a redirection based on this > specification is any different than any other time an HTTP browser or SIP > UA connects to a resource based on an arbitrary URL. > > In some sense, it's not. My claim is more that users are being > conditioned to expect payment prompts to appear at "arbitrary times" > than a specific flaw in this workflow. > > > > But to put some more context around this, the Diameter client is > typically a Network Access Server (NAS) that the end user is using for > network access. The user is already at the mercy of that NAS, and that NA= S > is at the mercy of the credit-control application server. The user=E2=80= =99s trust > in that NAS seems to have the same issues whether or not this Diameter > application is used. > > > > [yuval] agree with Ben, if someone bad took control over the NAS, they > can do much worse > > I agree that the NAS could send traffic to "wherever", but my > objection could perhaps be categorized as more "social" than > "technical". Maybe I should attempt to give an example (and you can > point out if I misunderstand things). > > I believe that a "normal usage" of this technology could be for a > user with a prepaid data plan to be using a web browser, and, e.g., > connect successfully to https://example.com. Suppose that this > request used up their last remaining credits, and they click on a > link from that page. Instead of going to the actual target of that > link, they are redirected to the data plan owner's top-up page, > which displays a message "your balance is zero; please enter credit > card information to purchase more data", the user pays, and can > potentially even be redirected back to the actual target of the link > they clicked on (though that's not key to my example). Let's > consider what would happen in an "attack scenario", where the same > user has plenty of data quota remaining, and goes to > https://honest-achmed.com. They click on a link from that page, > which instead of going to an "actual site" that would be expected > from the context surrounding the link, actually goes to > http://[IP address controlled by attacker]/topup.html, which is > designed to look as similar as possible to the actual data plan > owner's top-up page. The user may then enter their payment > information, and get redirected to a site with actual content, > believing that they have obtained more data quota from their > provider, when in reality they have given their credit card > information to a phisher. > > I don't see what mechanism is in place to allow the user to be able > to distinguish between the "normal usage" scenario and the "attack > scenario". I also understand that this sort of technology is > already deployed and is seen as useful by both users and data > providers, so it seems unrealistic to expect to be able to get rid > of this usage entirely. I do think that it is unreasonable for us > to enable this behavior without documenting the risks to the user, > though. > > *[yuval] I guess that there is nothing in the spec that technically > enables phishing, however, it makes the social engineering part of it > easier. How about the following addition to the security sections:* > *"It is RECOMMENDED that operators put in place mechanisms that would hel= p > their subscribers identify a valid redirect operation from a malicious on= e"* > I wouldn't dream of saying this is not a good idea, but I do wonder if this is the right document to call attention to that problem. It sure sounds more generic than "topping off my access credit". Are the right people who need to be aware of that problem in order to fix it going to look to this document for guidance? If the answer is "yes", go for it, but if that advice needs to be somewhere more visible, please do the right thing. Spencer > > > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > > > > If the Final-Unit-Action AVP is set to REDIRECT at least the > > > Redirect-Server-Extension AVP MUST be present. > > > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > > section 8.64 even internally inconsistent, too?) about > > > "Redirect-Server AVP, in addition to or instead of the > > > Redirect-Server-Extension AVP", in particular, the "instead of" > > > portion. (The ABNF-based formal language spec in 8.68 does match up > > > with the above MUST, though.) > > > > Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64 t= o just =E2=80=9Cin > addition to=E2=80=9D help? > > > > Authors: Please comment if that works, given the backwards-compatibilit= y > concern. > > [yuval] the cumbersome text is because of backward compatibility issue. > Would appriciate suggestion for better phrasing. The idea is the > following:* We have an existing AVP that can carry some information* We > need more information, but we cannot modify the existing one, so we added= a > new AVP (which, unlike the old one, is future proof)* If you have a peer > that does not support the new spec, but only need the old info, you can u= se > the old AVP. what makes the spec backward compatible to the old one* If y= ou > have need to send the new info, you have to use the new AVP, but in this > case an older peer does not make sense > > To Ben, I believe that just "in addition to" resolves the internal > inconsistency. However, it sounds like that may not be the best > solution from a deployment perspective, and perhaps the formal > definition in Section 8.68 (and the body text) should be relaxed to > allow either the -Extension or non-Extension form. > > [yuval] will remove "instead of" > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Some additional significant but not necessarily DISCUSS-worthy > > > comments, followed by more editorial- and nit-level things. > > > > > > In Section 1.3, "Advertising Application Support" uses the same > > > Auth-Application-ID value as for RFC 4006; what are the interop > > > consequences of this? > > > [yuval] this was done to make interops easier - this is why we kept > this RFC backward compatible with RFC4006 > > > Alissa already noted that the text about how to split (sub-)AVPs > > > between the foo and foo-Extension AVPs is inconsistent among them -- > > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > > send [in the old one]", but Subscription-Id-Extension has separate > > > text about "[i]f full backward compatibility with [RFC4006] is > > > required" and slightly different behavior described. We should try > > > to catch all instances of this sort of backwards compatibility and > > > make them consistent. > > > > I agree. > > [yuval] will look to unify the text > > I see that there was some discussion on Alissa's ballot thread that > there may indeed be special considerations for one AVP. If so, > that's fine, but the reasoning should probably be included in the > document to explain the apparent disparity. > > [yuval] ok > > > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > > > might benefit from additional text about the expected contents. A > > > lot of the time when we use a UTF8 container for names (whether > > > domain names or other kinds), we specify what normalization form and > > > canonicalization are performed, whether domain names are A-labels or > > > U-labels, etc., as there's a lot of potential flexibility not all of > > > which is good. In this case, since the communication is only > > > between trusted actors, perhaps the additional restrictions are not > > > needed, but I am curious if the topic was raised in the WG. > > > > On reflection, shouldn=E2=80=99t that be based on whatever rules alread= y exist > for the URL scheme? And if some scheme doesn=E2=80=99t have well defined = behavior > for non-ascii labels, is that the concern of this application? > > It is probably a matter for the URL scheme, yes. So at most we > could note here that "individual URL schemes may restrict the > contents of the UTF8String", but as I imply in my original comment, > it's far from clear to me that we actually need to say anything in > this specific case. > > > > > > > Thank you for adding the Privacy Considerations and list of > > > Privacy-Sensitive AVPs! > > > > > > Section 14 > > > > > > [...] The Diameter credit- > > > control application is often used within one domain, and there may b= e > > > a single hop between the peers. In these environments, the use of > > > TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > > > I did not see any concrete guidance on what would suffice in other > > > environments (with multiple hops between peers). Is this the realm > > > of the mythical "end-to-end security mechanism" for Diameter that is > > > much-desired? (The last paragraph does have guidance on what might > > > *not* suffice, which is not exactly the same thing.) > > > > > > > Sort of, but in real world deployments the =E2=80=9Coften used within o= ne > domain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D, wh= ich should be clarified) > effectively overrides everything else.. That is far from ideal, but it=E2= =80=99s > the reality. So it basically comes down to keep everything in the trust > domain, or if you cross a non-trusted network then use TLS or IPSec. > > > > There=E2=80=99s no solution to safely traverse a non-trusted Diameter a= gent.. > The mythical e2e mechanism could conceivably give us that. (someday, alo= ng > with world peace and a post-scarcity economy). > > > > [yuval] as Ben and Lyle wrote, if your messages need to go through > agents that belong to a 3rd party, you have risks. In this case, AVP leve= l > encryption (which is not standardized yet...) is the only option for to > ensure privacy. So, the only thing we can do here is to highlight the > risks. > > Do we want to say something about "at present, there is not a > general reliable security solution for other environments"? (To be > clear, I do not insiste that we do so.) > > [yuval] not sure if AVP level ancryption would ever happen... would keep > text as is > > > > Even without any modification to the messages, an adversary can > > > eavesdrop on transactions that contain privacy-sensitive information > > > about the user. > > > > > > This ("an adversary can") makes it sounds as if there is no > > > confidentiality protection anywhere in the system, but that's what > > > TLS/DTLS/IPSec are supposed to provide. So maybe "an adversary that > > > can eavesdrop on transactions can obtain privacy-sensitive > > > information [...]" is better. > > > > > > > Good point, I agree your suggestion is better.[yuval] ok > > > > > (Editorial- and nit-level stuff follows.) > > > > > > Section 4 > > > > > > A flexible credit-control application specific failure handling is > > > defined in which the home service provider can model the credit- > > > control client behavior according to its own credit risk management > > > policy. > > > > > > This sentence is hard to parse -- in "credit-control application > > > specific" what does "specific" bind to? What is being modelled? Is > > > anything being controlled (as opposed to modelled)? > > [yuval] ok. so how about: > > "Flexible failure handling, specific to the credit-control, is defined > in the application.This allows the the service provider to control the > credit-control client behavior according to its ownrisk management policy= " > > That's much better; thanks! > > > > Section 4.1.1 > > > > > > 2. The Service-Parameter-Info AVP MAY be used as a container to pas= s > > > legacy rating information in its original encoded form (e.g., ASN.1 > > > BER). [....] > > > > > > Why BER and not DER? The unnecessary flexibility in BER vs. DER has > > > been known to tickle parser bugs and create security > > > vulnerabilities. > > > > > [yuval] this is just an example of legacy stuff you have no control ove= r > > > > > Section 4.1.2 > > > > > > [...] To > > > facilitate interoperability, it is RECOMMENDED that the rating input > > > and the values of the Service-Context-Id be coordinated via an > > > informational RFC or other permanent and readily available reference= . > > > The specification of another cooperative standardization body (e.g., > > > 3GPP, OMA, or 3GPP2) SHOULD be used. > > > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > > > > > [yuval] yes, seems a bit awkward. How about: > > "To facilitate interoperability, it is RECOMMENDED that the rating inpu= t > > and the values of the Service-Context-Id be coordinated via an > > informational RFC or other permanent and readily available reference, > > preferably, of another cooperative standardization body (e.g., > > 3GPP, OMA, or 3GPP2)." > > Sounds good. > > > > Section 5.1.1 > > > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > > seems that this text could be reworded to just talk about a > > > "constant rate" or "constant level per fixed time period" or > > > similar. > > > > > [yuval] "constant rate" could mean sub-second resolution as well. The > grants are in seconds, so, IMO, this phrasing is more accurate > > It seems that it's only more accurate if leap seconds are ignored. > (I suppose you could explicitly disclaim "(ignoring leap seconds)" > or similar.) > > [yuval] will add > > > > Section 5.1..2 > > > > > > [...] > > > timer (Section 13) every time a CCR message with the value > > > UPDATE_REQUEST is sent while they are in PendingU state. When > > > answers to all pending messages are received, the state machine move= s > > > to OPEN state, and Tx is stopped. > > > > > > Transmission, or the Tx timer (is stopped)? > > > > > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense o= f > "transmission" in the RFC > > (I think that "Tx timer" was fairly consistently used throughout the > rest of the document; it may make sense to be fully consistent about > it.) > > [yuval] will fix in the doc > > > > Using a different title for Section 5.2.2 might make the parallel > > > between it and Section 5.2.1 more clear. That is, perhaps something > > > like "First Interrogation Included with Authorization Messages". > > > > > [yuval] make sense > > > > > Section 5.7 > > > > > > [...] It is RECOMMENDED that the client complement the credit- > > > control failure procedures with backup accounting flow toward an > > > accounting server. [...] > > > > > > Nit: it looks like there's a missing article here, maybe "a backup > > > accounting flow" is better. > > > > > [yuval] the rest of the paragraph describe such "backup accounting > flow". See what comes after "For example" > > I just meant that it sounds like you need to add the word "a" in > order for the grammar to make sense. (But perhaps "the" is the > right word; I wasn't sure.) > > [yuval] ok > > > > The AAA transport profile [RFC3539] defines the application layer > > > watchdog algorithm that enables failover from a peer that has failed > > > and is controlled by a watchdog timer (Tw) defined in [RFC3539]. > > > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > > > > > [yuval] would imagine there are other algorithms out there... should fi= x > > > > > Section 6.2 > > > > > > Should there be text indicating how the client indicates what > > > service the balance check is being requested for? > > > > > [yuval] didn't find any reference to service information for > "EVET_REQUEST" type messages (direct debit, refund, balance check and pri= ce > enquiry). Seems like that in the IEC section of 3GPP TS 32.299, they adde= d > their own mechanism for "direct debit", and "refund", and leave "balance > check" and "price enquiry" as references to RFC4006. Unless I've missed > something, this seems like a missing part of the spec. > > > > [yuval] hmm. seems like "event requests" should be looked at (probably at > the light of 3GPP 32.299 IEC concept). But for sure *not* as part of this > work. > > > > Section 8.54 > > > > > > Maybe give a section reference in RFC 3580 for how the formatting is > > > done? > > > > > [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 > in our RFC > > > > > Section 12 > > > > > > [...] Initially, such Expert discussions take place on the AAA > > > WG mailing list. > > > > > > That list appears to be dead, suggesting that this text should be > > > updated. (I also agree with Adam's comments about updating the IANA > Considerations.) > > > > > [yuval] i don't know the process here - not sure how to change it. > > With respect to the "expert discussions take place" text, I think it > could just be removed. > > Discussion of the detailed updates to the IANA actions should > probably happen in Adam's ballot thread. > > > > Why is the disclaimer in Section B.4 (and other examples) not needed > in Section B.3? > > [yuval] should be added there as well > > Great, thanks. > > > -Benjamin > > Example Domain > > > > > --00000000000047ce65056cf33fde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Keeping in mind that this is Benjamin's ballot thread,= so what he thinks matters more than what I think ...

On Thu, May 24, 2018 at 1:20 AM Yuval Lifshi= tz <yuvalif=3D40yahoo.com@= dmarc.ietf.org> wrote:
=
inline

=20
=20
On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Ben= jamin Kaduk <kaduk@mi= t.edu> wrote:


[re-sending si= nce my client crashed during the first attempt and I
don't see the m= essage in the archives.=C2=A0 I attempted to reconstruct
my message from= a scrollback buffer, but there may be some artifacts
with missing or du= plicated text]

On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifsh= itz wrote:
>=C2=A0 Thanks Ben and Benjamin! Comments inline
>= =C2=A0 =C2=A0 On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell= <= ben@nostrum.com> wrote:
>
>=C2=A0 Hi Benjamin,
>> I=E2=80=99ve cherry-picked a few points, inline:
>
> Tha= nks!
>
> Ben.
>
> > On May 22, 2018, at 8:48 AM,= Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> >
> > Benjami= n Kaduk has entered the following ballot position for
> > draft-ie= tf-dime-rfc4006bis-08: Discuss
> >
> > When responding, p= lease keep the subject line intact and reply to all
> > email addr= esses included in the To and CC lines. (Feel free to cut this
> > = introductory paragraph, however.)
> >
> >
> > Pl= ease refer to https://www.ietf.org/iesg/state= ment/discuss-criteria.html
> > for more information about IESG= DISCUSS and COMMENT positions.
> >
> >
> > The = document, along with other ballot positions, can be found here:
> >= ; https://datatracker.ietf.org/doc/draft-i= etf-dime-rfc4006bis/
> >
> >
> >
> >= ; ----------------------------------------------------------------------> > DISCUSS:
> > ------------------------------------------= ----------------------------
> >
> > I support Alissa'= ;s Discuss point about sensitive AVPs.
> >
> > I appear t= o have a different understanding of Section 5.6.2, though,
> > wit= h a different potential issue (but again, it's possible that I'm> > confused to how things work):
> >
> > With the= redirection schemes covered in Section 5.6.2, it sounds
> > like = the user can be redirected (at the application protocol level,
> >= e.g., HTTP or SIP) to a top-up server to purchase more credits.=C2=A0 I> > don't see a way described how user agents can distinguish be= tween a
> > Diameter-induced redirect and an attacker-induced redi= rect to a
> > (potentially phishing) site that accepts payment inf= ormation.=C2=A0 To be
> > clear, the scenario here is that a user = is using a credit-controlled
> > application session to talk to &q= uot;arbitrary application servers",
> > including potentially= attacker-controllled HTTP/SIP/etc. servers;
> > the attacker coul= d introduce a redirect to a phishing page that asks
> > for paymen= t information, and the user would be led to believe that
> > this = was the normal flow for "my prepaid balance has been used up",> > and give their payment information to the phishing site. I think=
> > that either user agents need to give some indication that thi= s
> > DIAMETER-level redirect is different than an
> > ap= plication-protocol-level redirect (e.g., http) or the Security
> >= Considerations need to mention the risk of acclimating users to
> &g= t; arbitrary websites redirecting to sites asking for payment
> > = credentials, which may or may not be legitimate sites.
> >
>=
> I think it=E2=80=99s reasonable to mention the concern in the secu= rity considerations. But I don=E2=80=99t see how a redirection based on thi= s specification is any different than any other time an HTTP browser or SIP= UA connects to a resource based on an arbitrary URL.

In some sense,= it's not.=C2=A0 My claim is more that users are being
conditioned t= o expect payment prompts to appear at "arbitrary times"
than a= specific flaw in this workflow.


> But to put some more context around this, the Diameter c= lient is typically a Network Access Server (NAS) that the end user is using= for network access. The user is already at the mercy of that NAS, and that= NAS is at the mercy of the credit-control application server. The user=E2= =80=99s trust in that NAS seems to have the same issues whether or not this= Diameter application is used.
>
> [yuval]= agree with Ben, if someone bad took control over the NAS, they can do much= worse

I agree that = the NAS could send traffic to "wherever", but myobjection could perhaps be categorized a= s more "social" than
"technical".=C2=A0 Maybe I should attempt to give an examp= le (and you can
point ou= t if I misunderstand things).

I believe that a "normal usage" of this technology coul= d be for a
user with a p= repaid data plan to be using a web browser, and, e.g.,
= connect successfully to https://example.com. Suppose tha= t this
request used up t= heir last remaining credits, and they click on a
link from that page.=C2=A0 Instead of going to the= actual target of that
l= ink, they are redirected to the data plan owner's top-up page,
which displays a message "y= our balance is zero; please enter credit
card information to purchase more data", the user pay= s, and can
potentially e= ven be redirected back to the actual target of the link
they clicked on (though that's not key = to my example).=C2=A0 Let's
consider what would happen in an "attack scenario", where= the same
user has plent= y of data quota remaining, and goes to
https://honest-achmed.com. They click on a link from that page,
which instead of going to an "actual site" th= at would be expected
fro= m the context surrounding the link, actually goes to
http://[IP address controlled by attacker]/top= up.html, which is
design= ed to look as similar as possible to the actual data plan
= owner's top-up page.=C2=A0 The user m= ay then enter their payment
information, and get redirected to a site with actual content,=
believing that they have obtai= ned more data quota from their
provider, when in reality they have given their credit card
information to a phisher.=

I don't see what mecha= nism is in place to allow the user to be able
to distinguish between the "normal usage" = scenario and the "attack
scenario".=C2=A0 I also understand that this sort of technology = is
already deployed and = is seen as useful by both users and data
providers, so it seems unrealistic to expect to be able to= get rid
of this usage e= ntirely.=C2=A0 I do think that it is unreasonable for us
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">to enable this behavior without documentin= g the risks to the user,
though.

[yuval] I guess that there is nothing in the spec that technically= enables phishing, however, it makes the social engineering part of it easi= er. How about the following addition to the security sections:
"It is RECOMMENDED that op= erators put in place mechanisms that would help their subscribers identify = a valid redirect operation from a malicious=C2=A0one"
=

I wouldn'= ;t dream of saying this is not a good idea, but I do wonder if this is the = right document to call attention to that problem. It sure sounds more gener= ic than "topping off my access credit".=C2=A0

Are the right people who need to be aware of that problem in order to= fix it going to look to this document for guidance?

If the answer is "yes", go for it, but if that advice needs to= be somewhere more visible, please do the right thing.

=
Spencer
=C2=A0

<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> > Separately, in Section 8.68 (for= QoS-Final-Unit-Indication):
> >
> >= ;=C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the=
> >=C2=A0 Redirect-Serve= r-Extension AVP MUST be present.
> >
> = > This MUST seems in conflict with the text in 8.64 (actually, is=
> > section 8.64 even in= ternally inconsistent, too?) about
> > "Redirect-Server AVP, in addition to or instead o= f the
> > Redirect= -Server-Extension AVP", in particular, the "instead of"
> > portion.=C2=A0 (Th= e ABNF-based formal language spec in 8.68 does match up
> > with the above MUST, though.)
>
> Would changing =E2=80=9Cin addition to or= instead of=E2=80=9D in 8.64 to just =E2=80=9Cin addition to=E2=80=9D help?=
>
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> Authors: Please comment if that works= , given the backwards-compatibility concern.
> [yuval] the cumbersome text is because of backw= ard compatibility issue. Would appriciate suggestion for better phrasing. T= he idea is the following:* We have an existing AVP that can carry some info= rmation* We need more information, but we cannot modify the existing one, s= o we added a new AVP (which, unlike the old one, is future proof)* If you h= ave a peer that does not support the new spec, but only need the old info, = you can use the old AVP. what makes the spec backward compatible to the old= one* If you have need to send the new info, you have to use the new AVP, b= ut in this case an older peer does not make sense

<= span style=3D"font-size:13px">To Ben, I believe that just "in addition= to" resolves the internal
inconsistency.=C2=A0 However, it sounds like that may not be the be= st
solution from a deplo= yment perspective, and perhaps the formal
definition in Section 8.68 (and the body text) should b= e relaxed to
allow eithe= r the -Extension or non-Extension form.

[yuval] will remove "in= stead of"

> >
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> > --------------------------------= --------------------------------------
> > COMMENT:
> > -------------------------------------------------------= ---------------
> >= ;
> > Some additio= nal significant but not necessarily DISCUSS-worthy
> > comments, followed by more editorial- = and nit-level things.
&g= t; >
> > In Sec= tion 1.3, "Advertising Application Support" uses the same<= /font>
> > Auth-Application-ID v= alue as for RFC 4006; what are the interop
> > consequences of this?
> >=C2=A0[yuval] this was done to make in= terops easier - this is why we kept this RFC backward compatible with RFC40= 06
> > Alissa alre= ady noted that the text about how to split (sub-)AVPs
<= span style=3D"font-size:13px">> > between the foo and foo-Extension A= VPs is inconsistent among them --
> > e.g., Redirect-Server-Extension and User-Equipment-Info= say "SHOULD
> &= gt; send [in the old one]", but Subscription-Id-Extension has separate=
> > text about &q= uot;[i]f full backward compatibility with [RFC4006] is
= > > required" and slightly differ= ent behavior described.=C2=A0 We should try
> > to catch all instances of this sort of backwa= rds compatibility and
&g= t; > make them consistent.
>
> I agree.=
> [yuval] will look = to unify the text

I = see that there was some discussion on Alissa's ballot thread that
there may indeed be special c= onsiderations for one AVP.=C2=A0 If so,
that's fine, but the reasoning should probably be inclu= ded in the
document to e= xplain the apparent disparity.

[yuval] ok

> > The use of UTF8String for URLs and URIs (e.g.= , Redirect-Address-URL)
= > > might benefit from additional text about the expected contents.= =C2=A0 A
> > lot o= f the time when we use a UTF8 container for names (whether> > domain names or other kinds), = we specify what normalization form and
> > canonicalization are performed, whether domain nam= es are A-labels or
> = > U-labels, etc., as there's a lot of potential flexibility not all = of
> > which is go= od.=C2=A0 In this case, since the communication is only
> > between trusted actors, perhaps t= he additional restrictions are not
> > needed, but I am curious if the topic was raised in th= e WG.
>=
> On reflection, shouldn=E2=80=99t= that be based on whatever rules already exist for the URL scheme? And if s= ome scheme doesn=E2=80=99t have well defined behavior for non-ascii labels,= is that the concern of this application?

It is probably a matter for the URL scheme, yes.=C2= =A0 So at most we
could = note here that "individual URL schemes may restrict the<= br>contents of the UTF8String", but = as I imply in my original comment,
it's far from clear to me that we actually need to say anyth= ing in
this specific cas= e.

> ><= /font>
> > Thank you for adding = the Privacy Considerations and list of
> > Privacy-Sensitive AVPs!
> >
> > Section 14
> >
> &= gt;=C2=A0 [...] The Diameter credit-
> >=C2=A0 control application is often used within one d= omain, and there may be
= > >=C2=A0 a single hop between the peers.=C2=A0 In these environments= , the use of
> >= =C2=A0 TLS/TCP, DTLS/SCTP or IPsec is sufficient.
> >
> > I did not see any concrete guidance on what would suf= fice in other
> > = environments (with multiple hops between peers).=C2=A0 Is this the realm
> > of the mythical = "end-to-end security mechanism" for Diameter that is
> > much-desired?=C2=A0 (The l= ast paragraph does have guidance on what might
> > *not* suffice, which is not exactly the sa= me thing.)
> >
>
> Sort of, but in real world deployments th= e =E2=80=9Coften used within one domain=E2=80=9D (assuming domain means =E2= =80=9Ctrust domain=E2=80=9D, which should be clarified) effectively overrid= es everything else.. That is far from ideal, but it=E2=80=99s the reality. = So it basically comes down to keep everything in the trust domain, or if yo= u cross a non-trusted network then use TLS or IPSec.
>
> There=E2=80=99s no solution to safely traverse a non-trusted= Diameter agent.. The mythical e2e mechanism could conceivably give us that= .=C2=A0 (someday, along with world peace and a post-scarcity economy).
>
> [yuval] as Ben and Lyle wrote, if your mes= sages need to go through agents that belong to a 3rd party, you have risks.= In this case, AVP level encryption (which is not standardized=C2=A0yet...)= is the only option for to ensure privacy. So, the only thing we can do her= e is to highlight the risks.=C2=A0

Do we want to say something about "at present, there is= not a
general reliable = security solution for other environments"?=C2=A0 (To be<= br>clear, I do not insiste that we do so.= )

[yuval] not sure if AVP level ancryption would= ever happen... would keep text as is

> >=C2=A0 Even without any modification to the messages, a= n adversary can
> >= ;=C2=A0 eavesdrop on transactions that contain privacy-sensitive informatio= n
> >=C2=A0 about = the user.
> >
> > This ("an adv= ersary can") makes it sounds as if there is no
> > confidentiality protection anywhere i= n the system, but that's what
> > TLS/DTLS/IPSec are supposed to provide.=C2=A0 So maybe = "an adversary that
= > > can eavesdrop on transactions can obtain privacy-sensitive=
> > information [...]&qu= ot; is better.
> >=
>
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> Good point, I agree your suggestion i= s better.[yuval] ok
>=
> > (Editorial- a= nd nit-level stuff follows.)
> >
> >= ; Section 4
> >
> >=C2=A0 A flexible= credit-control application specific failure handling is
<= font color=3D"#26282a" face=3D"Helvetica Neue, Helvetica, Arial, sans-serif= ">> >=C2=A0 defined in which the home = service provider can model the credit-
> >=C2=A0 control client behavior according to its own= credit risk management
= > >=C2=A0 policy.
= > >
> > This= sentence is hard to parse -- in "credit-control application
> > specific" what doe= s "specific" bind to?=C2=A0 What is being modelled?=C2=A0 Is
> > anything being con= trolled (as opposed to modelled)?
> [yuval] ok. so how about:
> "Flexible failure handling, specific to the cred= it-control, is defined in the application.This allows the the service provi= der to control the credit-control client behavior according to its ownrisk = management policy"

That's much better; thanks!

> > Section 4.1.1
> >
> >=C2=A0 2.=C2=A0 The Service-Parameter-Info AVP MAY be used a= s a container to pass
&g= t; >=C2=A0 legacy rating information in its original encoded form (e.g.,= ASN.1
> >=C2=A0 B= ER).=C2=A0 [....]
> &= gt;
> > Why BER an= d not DER?=C2=A0 The unnecessary flexibility in BER vs. DER has
> > been known to tickle pars= er bugs and create security
> > vulnerabilities.
> >=C2=A0
> [yuval] this is just an example of legacy stuff you have no control o= ver
>> > Section 4.1.2> >
> >=C2=A0 [...] To
> >=C2=A0 facilitate interoperability, it is = RECOMMENDED that the rating input
> >=C2=A0 and the values of the Service-Context-Id be coord= inated via an
> >= =C2=A0 informational RFC or other permanent and readily available reference= .
> >=C2=A0 The sp= ecification of another cooperative standardization body (e.g.,
> >=C2=A0 3GPP, OMA, or 3GPP2)= SHOULD be used.
> &g= t;
> > The RECOMME= NDED and SHOULD seem slightly in conflict.
> >=C2=A0
> [yuval] yes, seems a bit awkward. How about:=
> "To=C2=A0facilitate interop= erability, it is RECOMMENDED that the rating input
> and the values of the Service-Context-Id be= coordinated via an
>= informational RFC or other permanent and readily available reference,
> preferably, of another = cooperative standardization body (e.g.,
> =C2=A03GPP, OMA, or 3GPP2)."
Sounds good.

> > Section 5.1.1
> >
> > As noted elsewhere, 60 seconds per minute does not = always hold; it
> >= ; seems that this text could be reworded to just talk about a=
> > "constant rate" o= r "constant level per fixed time period" or
<= span style=3D"font-size:13px">> > similar.
> >=C2=A0
> [yuval] "constant rate" could mean sub-seco= nd resolution as well. The grants are in seconds, so, IMO, this phrasing is= more accurate

It se= ems that it's only more accurate if leap seconds are ignored.
(I suppose you could explicitly d= isclaim "(ignoring leap seconds)"
or similar.)

[yuval] will ad= d

> > Section 5.1..2<= /span>
> ><= br>> >=C2=A0 [...]> >=C2=A0 timer (Section 13) every= time a CCR message with the value
> >=C2=A0 UPDATE_REQUEST is sent while they are in Pending= U state.=C2=A0 When
>= >=C2=A0 answers to all pending messages are received, the state machine= moves
> >=C2=A0 t= o OPEN state, and Tx is stopped.
> >
> = > Transmission, or the Tx timer (is stopped)?
> >=C2=A0
> [yuval] well, "Tx" is overloaded :-( but we= never use it in the sense of "transmission" in the RFC

(I think that "Tx timer&= quot; was fairly consistently used throughout the
rest of the document; it may make sense to be ful= ly consistent about
it.)=

[yuval] will fix in the doc

> > Using a different title for Section = 5.2.2 might make the parallel
> > between it and Section 5.2.1 more clear.=C2=A0 That is, per= haps something
> >= like "First Interrogation Included with Authorization Messages".=
> >=C2=A0<= /font>
> [yuval] make sense<= /font>
>
> > Section 5.7
> >
> >=C2=A0 [...] It is RECOMMENDED that the client complement= the credit-
> >= =C2=A0 control failure procedures with backup accounting flow toward an
> >=C2=A0 accounting = server. [...]
> ><= /span>
> > Nit: it looks = like there's a missing article here, maybe "a backup=
> > accounting flow" is be= tter.
> >=C2=A0
> [yuval] the rest of t= he paragraph describe such "backup accounting flow". See what com= es after "For example"

I just meant that it sounds like you need to add the word &quo= t;a" in
order for t= he grammar to make sense.=C2=A0 (But perhaps "the" is the<= /font>
right word; I wasn't sure.)=

[yuval] ok

> >=C2=A0 The AAA transport profile [RFC3539] def= ines the application layer
> >=C2=A0 watchdog algorithm that enables failover from a peer tha= t has failed
> >= =C2=A0 and is controlled by a watchdog timer (Tw) defined in [RFC3539].
> >
= > > Nit: Is it "the" watc= hdog algorithm or "an" watchdog algorithm?
> >=C2=A0
> [yuval] would imagine there are other algorithm= s out there... should fix
>
> > Section= 6.2
> >
> > Should there be text in= dicating how the client indicates what
> > service the balance check is being requested for?<= /span>
> >=C2=A0
> [yuval] didn't find any= reference to service information for "EVET_REQUEST" type message= s (direct debit, refund, balance check and price enquiry). Seems like that = in the IEC section of 3GPP TS 32.299, they added their own mechanism for &q= uot;direct debit", and "refund", and leave "balance che= ck" and "price enquiry" as references to RFC4006. Unless I&#= 39;ve missed something, this seems like a missing part of the spec.<= /font>
>

[yuval] = hmm. seems like "event requests"=C2=A0should be looked at (probab= ly at the light of 3GPP 32.299 IEC concept). But for sure *not* as part of = this work.

> >= Section 8.54
> ><= /span>
> > Maybe give a s= ection reference in RFC 3580 for how the formatting is
= > > done?
> >=C2=A0
> [yuval] see section 3.21 in RFC3580, this is also true = for section 8.50 in our RFC
>
> > Sec= tion 12
> >=
> >=C2=A0 [...] Initiall= y, such Expert discussions take place on the AAA
> >=C2=A0 WG mailing list.
= > >
> > That list appears to be dead, suggesting that= this text should be
>= ; > updated.=C2=A0 (I also agree with Adam's comments about updating= the IANA Considerations.)
> >=C2=A0
> = [yuval] i don't know the process here - not sure how to change it.

With respect to the &quo= t;expert discussions take place" text, I think it
= could just be removed.

= Discussion of the detailed updates to the= IANA actions should
pro= bably happen in Adam's ballot thread.

> > Why is the disclaimer in Section B.4 (and = other examples) not needed in Section B.3?
> [yuval] should be added there as well

Great, thanks.
=

-Benjamin
=

Example Domain



--00000000000047ce65056cf33fde-- From nobody Thu May 24 06:16:56 2018 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 7F8CB12E8DF; Thu, 24 May 2018 06:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3GgmT8vMo9q; Thu, 24 May 2018 06:16:39 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FD012EAB7; Thu, 24 May 2018 06:16:31 -0700 (PDT) X-AuditID: 12074425-d63ff70000004f1a-c8-5b06bb2e3384 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 18.21.20250.E2BB60B5; Thu, 24 May 2018 09:16:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w4ODGSd6021855; Thu, 24 May 2018 09:16:29 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4ODGLfO009942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 May 2018 09:16:24 -0400 Date: Thu, 24 May 2018 08:16:22 -0500 From: Benjamin Kaduk To: Spencer Dawkins at IETF Cc: yuvalif=40yahoo.com@dmarc.ietf.org, Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <20180524131619.GH32807@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsUixCmqrau3my3a4NF5aYv5nafZLdYeTLOY 27uCzWLJxAmsFjP+TGS2WDZlD7NF4+qfLA7sHieWXWH12DnrLrvHkiU/mTxm7XzCEsASxWWT kpqTWZZapG+XwJVxfa9AwUSnirXTehgbGK+ZdDFyckgImEiceLaZtYuRi0NIYDGTxOL1l9gh nI2MEnMWX4VyrjJJ7F9ymxGkhUVAVaLj+iVmEJtNQEWiofsymC0iYC2xpa+TDcRmFtjBKDF7 hjiILSyQLfFpwgSwOC/QuquzbrNADL3DJPG3ZSoLREJQ4uTMJywQzeoSf+aBLOAAsqUllv/j gAjLSzRvnQ22i1MgUOLPjk3sILaogLLE3r5D7BMYBWchmTQLyaRZCJNmIZm0gJFlFaNsSm6V bm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRlBssLuo7mCc89frEKMAB6MSD++FVNZoIdbE suLK3EOMkhxMSqK8Tsxs0UJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeBckAeV4UxIrq1KL8mFS 0hwsSuK8OYsYo4UE0hNLUrNTUwtSi2CyMhwcShK8mruAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG u4HU8BYXJOYWZ6ZD5E8x6nJ0vJ/SwyzEkpeflyolzpsKUiQAUpRRmgc3B5TSJLL317xiFAd6 S5jXFqSKB5gO4Sa9AlrCBLTk4nJmkCUliQgpqQbG5d7pvWway6ZvLGq/vMWYY/vTe1WnNVy0 Aw9Kn1N9yfzMkeHxXj+Jd6qnfrjePRawP+xQ/bX3XAIsM8sPTbEzdX44NUui6bFsaJNf1OyH rZwqjXZ19o+/bt+5ZpuTr+OJDdu1A69/8jrDvfz8rQqWhujDvmtuGCRsuXD4q9qByKt3+yfM 3tO8V4mlOCPRUIu5qDgRAKRBzmVEAwAA Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 13:16:50 -0000 [trimming some quoted material] On Thu, May 24, 2018 at 08:01:04AM -0500, Spencer Dawkins at IETF wrote: > Keeping in mind that this is Benjamin's ballot thread, so what he thinks > matters more than what I think ... > > On Thu, May 24, 2018 at 1:20 AM Yuval Lifshitz 40yahoo.com@dmarc.ietf.org> wrote: > > > *inline* > > > > On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk < > > kaduk@mit.edu> wrote: > > > > > > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > > > On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell < > > ben@nostrum.com> wrote: > > > > > > > > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > > > like the user can be redirected (at the application protocol level, > > > > e.g., HTTP or SIP) to a top-up server to purchase more credits. I > > > > don't see a way described how user agents can distinguish between a > > > > Diameter-induced redirect and an attacker-induced redirect to a > > > > (potentially phishing) site that accepts payment information. To be > > > > clear, the scenario here is that a user is using a credit-controlled > > > > application session to talk to "arbitrary application servers", > > > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > > > the attacker could introduce a redirect to a phishing page that asks > > > > for payment information, and the user would be led to believe that > > > > this was the normal flow for "my prepaid balance has been used up", > > > > and give their payment information to the phishing site. I think > > > > that either user agents need to give some indication that this > > > > DIAMETER-level redirect is different than an > > > > application-protocol-level redirect (e.g., http) or the Security > > > > Considerations need to mention the risk of acclimating users to > > > > arbitrary websites redirecting to sites asking for payment > > > > credentials, which may or may not be legitimate sites. > > > > > > > > > > I think it’s reasonable to mention the concern in the security > > considerations. But I don’t see how a redirection based on this > > specification is any different than any other time an HTTP browser or SIP > > UA connects to a resource based on an arbitrary URL. > > > > In some sense, it's not. My claim is more that users are being > > conditioned to expect payment prompts to appear at "arbitrary times" > > than a specific flaw in this workflow. > > > > > > > But to put some more context around this, the Diameter client is > > typically a Network Access Server (NAS) that the end user is using for > > network access. The user is already at the mercy of that NAS, and that NAS > > is at the mercy of the credit-control application server. The user’s trust > > in that NAS seems to have the same issues whether or not this Diameter > > application is used. > > > > > > [yuval] agree with Ben, if someone bad took control over the NAS, they > > can do much worse > > > > I agree that the NAS could send traffic to "wherever", but my > > objection could perhaps be categorized as more "social" than > > "technical". Maybe I should attempt to give an example (and you can > > point out if I misunderstand things). > > > > I believe that a "normal usage" of this technology could be for a > > user with a prepaid data plan to be using a web browser, and, e.g., > > connect successfully to https://example.com. Suppose that this > > request used up their last remaining credits, and they click on a > > link from that page. Instead of going to the actual target of that > > link, they are redirected to the data plan owner's top-up page, > > which displays a message "your balance is zero; please enter credit > > card information to purchase more data", the user pays, and can > > potentially even be redirected back to the actual target of the link > > they clicked on (though that's not key to my example). Let's > > consider what would happen in an "attack scenario", where the same > > user has plenty of data quota remaining, and goes to > > https://honest-achmed.com. They click on a link from that page, > > which instead of going to an "actual site" that would be expected > > from the context surrounding the link, actually goes to > > http://[IP address controlled by attacker]/topup.html, which is > > designed to look as similar as possible to the actual data plan > > owner's top-up page. The user may then enter their payment > > information, and get redirected to a site with actual content, > > believing that they have obtained more data quota from their > > provider, when in reality they have given their credit card > > information to a phisher. > > > > I don't see what mechanism is in place to allow the user to be able > > to distinguish between the "normal usage" scenario and the "attack > > scenario". I also understand that this sort of technology is > > already deployed and is seen as useful by both users and data > > providers, so it seems unrealistic to expect to be able to get rid > > of this usage entirely. I do think that it is unreasonable for us > > to enable this behavior without documenting the risks to the user, > > though. > > > > *[yuval] I guess that there is nothing in the spec that technically > > enables phishing, however, it makes the social engineering part of it > > easier. How about the following addition to the security sections:* > > *"It is RECOMMENDED that operators put in place mechanisms that would help > > their subscribers identify a valid redirect operation from a malicious one"* > > > > I wouldn't dream of saying this is not a good idea, but I do wonder if this > is the right document to call attention to that problem. It sure sounds > more generic than "topping off my access credit". I also am not saying this is not a good idea, but... > Are the right people who need to be aware of that problem in order to fix > it going to look to this document for guidance? > > If the answer is "yes", go for it, but if that advice needs to be somewhere > more visible, please do the right thing. ... it's unclear to me that this document is the right place for such guidance. That is, instead of a concrete recommendation, I had in mind just giving some extra facts that would allow the reader to consider the security implications of their deployment (this is the Security Considerations, after all), as in something like: This document includes a redirection facility whereby the service provider can redirect (in an application-specific way) the end user to an alternate location when their credits have expired. This is useful in that it allows for the user to return to normal service quickly, but also exposes additional risks and attack surface. In particular, this redirection can potentially occur at an arbitrary point in a user's session, potentially without any additional contextual confirmation available to the user that the redirection is driven by the network. Such a confirmation is important because, in many application protocols, the communication peer is also capable of inducing redirection, and when the peer is an attacker, the redirection can be to an attacker-controlled site. In particular, such sites may be "phishing" sites designed to appear similar to legitimate payment sites in an attempt to obtain users' payment information for fraudulent uses. Because of the potentially harmful consequences of arbitrary redirection by an attacker (such as to phishing sites), it can be important for users and service providers to be aware of the risk and take measures to ensure that sensitive information (such as payment information) is only used for legitmiate purposes. If an out-of-band signalling channel is available to provide contextual information that a redirection is triggered by the network as opposed to a communications peer, that can provide a highly effective mechanism for remediating this class of risk. (The above may well be too wordy and could benefit from editing, of course.) -Benjamin From nobody Thu May 24 06:18:37 2018 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 5CD5812DA4A for ; Thu, 24 May 2018 06:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdlDGEHPLHqd for ; Thu, 24 May 2018 06:18:28 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BEC126CB6 for ; Thu, 24 May 2018 06:18:05 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id 77-v6so1867995otd.4 for ; Thu, 24 May 2018 06:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c6URVO5GcvaRZvkUDYL+l4jAiJ+52wZjl5z2vZv2yOY=; b=MQeTr9waAVGloTEtWSzE2tl0tPSdmNF2w9rosRG+v8hbHS5Pav74ZMjqbMdfoCmAHS QSn+oEEO4EADDTEZZ6Pos3fy3azDmFs44PKbBB9xjGEPQNs9M7ejlmWrGIFiE2sNfYxp SnXcu8U2bhUEgDFJ2gaaDCZkO0pNK4aVBulMC2vGn/wcz0SIAdW0foCcUX43owdccBxe Ha2mprfnaQImhF5l0OQoexkz3vbaI1Zxi2P3xvcOhT3XWgXTd3ZxBy/jZiQwv2r9OlYM FzAie3WXiJbPHDJDJv8w2IKNmiM71KvWNbFeQhlIJZxC+8nHgGhhCBp+kga7B1NzJzUt +oYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c6URVO5GcvaRZvkUDYL+l4jAiJ+52wZjl5z2vZv2yOY=; b=irBVytVNvF1kFyoICSRFstDXfsHdR4S5raXubUrqkeQLZw5kpqWa1KUT2JoDLnPgpP zalT2uhjbh+G7Cio83FcOXNIj3VyXurFPDCraUyVSBwuMEZnys+HPvOQKtfp4Bk212b2 DRBJrFUtfk2yzYyGgYgXAEdcGZ04IqZ35kT8C6y+YcIyUh85Dw6qZTB3CPR0IcymbjVH ubvqvrNNMRjOXvM6aYsdI0BFf96ZZfl5/r9dk9SmwYIEW2pscMU9uMfcuceF1KC/1+ok 9iQl4pe/k7ea+ib71I3AGdvPID0+G6wBLGZ801xek9aIupRYfXmDduCQI8OiKQFezDTz rASA== X-Gm-Message-State: ALKqPwcU1ld+F2QNadmx0FfQ40AXEOqns4x3ZasLJ5p4C/+kW0SqvQFY KziNUVH5O4P4OFMaZ9fJxO4FgxqW9dP0x2AN6/vGow== X-Google-Smtp-Source: AB8JxZqwPO+pgoUbLxjK9qnIrXSIMQGvvhqQ6l1Bb2D3U9H7i4vyNcw2gZ1dZtvn1PMXZuUr2gvKRVtxfqM3lAOw6Uw= X-Received: by 2002:a9d:719a:: with SMTP id o26-v6mr4985458otj.44.1527167884931; Thu, 24 May 2018 06:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 24 May 2018 06:17:24 -0700 (PDT) In-Reply-To: <2012436261.4832236.1527143593730@mail.yahoo.com> References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> From: Eric Rescorla Date: Thu, 24 May 2018 06:17:24 -0700 Message-ID: To: Yuval Lifshitz Cc: The IESG , dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000004b4927056cf37bad" Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 13:18:31 -0000 --0000000000004b4927056cf37bad Content-Type: text/plain; charset="UTF-8" On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz wrote: > *inline* > > On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla > wrote: > > > Eric Rescorla has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3353 > > > I only gave this a light read. Some minor comments below. > > COMMENTS > S 1.2. > > deduction of credit from the end user account when service is > > completed and refunding of reserved credit that is not used. > > > > Diameter Credit-control Server A Diameter credit-control server > acts > > as a prepaid server, performing real-time rating and credit- > > control. It is located in the home domain and is accessed by > > a definition of "home domain" would be useful > > *[yuval] base spec define "home realm" we should probably change to that* > > S 2. > > credit-control application. > > > > When an end user requests services such as SIP or messaging, the > > request is typically forwarded to a service element (e.g., SIP > Proxy) > > in the user's home domain. In some cases it might be possible that > > the service element in the visited domain can offer services to the > > also define visited domain, or at least point to a reference. > > *[yuval] base spec defined "local realm" for that. will fix* > > S 3.1. > > [ CC-Correlation-Id ] > > [ User-Equipment-Info ] > > [ User-Equipment-Info-Extension ] > > *[ Proxy-Info ] > > *[ Route-Record ] > > *[ AVP ] > > Please expand AVP on first use. > > *[yuval] it is in the base spec* > I'm sure it is, but you should still expand it. > > S 4. > > control client requests credit authorization from the credit-control > > server prior to allowing any service to be delivered to the end > user. > > > > In the first model, the credit-control server rates the request, > > reserves a suitable amount of money from the user's account, and > > returns the corresponding amount of credit resources. Note that > > Sorry, reserves the balance or the amount reserved? > > *[yuval] not sure what is not clear?* > As I said above, do you return the balance or do you return the amount of credit that has been reserved. > > S 14. > > > > Even without any modification to the messages, an adversary can > > eavesdrop on transactions that contain privacy-sensitive information > > about the user. Also, by monitoring the credit-control messages one > > can collect information about the credit-control server's billing > > models and business relationships. > > I'm having trouble reading these two paragraphs. Are they about what > happens if TLS isn't used? > > *[yuval] will clarify. see here: *https://github.com/ > lbertz02/rfc4006bis/issues/51 > This doesn't seem dramatically clearer. What sort of an adversary can do that? -Ekr > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0000000000004b4927056cf37bad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz <= yuvalif@yahoo.com> wrote:
<= div>
inline

=20
=20


Eric Resc= orla has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: No Objection
When responding, please keep the subject line intac= t and reply to all
email addresses included in th= e To and CC lines. (Feel free to cut this
introdu= ctory paragraph, however.)


for more information about IESG DISCUSS and COMME= NT positions.


The document, along with other ballot positions, can be = found here:
http= s://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/
<= /div>



------------------------------------------= ----------------------------
COMMENT:
--------------------------------------------------= --------------------

Rich version of this review at:


I only= gave this a light read. Some minor comments below.

COMMENTS
S 1.2.
=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 deduction of credit= from the end user account when service is
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 completed and refunding of reserved credit tha= t is not used.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 Diameter Credit-control Server=C2=A0 A Diamet= er credit-control server acts
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 as a prepaid server, performing real-time rating and credit-=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 control.=C2=A0 = It is located in the home domain and is accessed by

a definition of "home domain" would= be useful

[yuval] base spec define "= home realm" we should probably change to that

S 2.
>=C2=A0 =C2=A0 =C2=A0 credit-control application.
=
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 When an end user requests services such as SIP or messaging, the
=
>=C2=A0 =C2=A0 =C2=A0 request is typically forwar= ded to a service element (e.g., SIP Proxy)
>= =C2=A0 =C2=A0 =C2=A0 in the user's home domain.=C2=A0 In some cases it = might be possible that
>=C2=A0 =C2=A0 =C2=A0 t= he service element in the visited domain can offer services to the

also define visited domain, or= at least point to a reference.

=
[yuval] ba= se spec defined "local realm" for that. will fix

S 3.1.
=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ C= C-Correlation-Id ]
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info ]
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extens= ion ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 *[ Proxy-Info ]
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ]
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ]

Please expand AVP on first use.
<= div dir=3D"ltr">
[yuval] it is in the base spec

I'm sure it i= s, but you should still expand it.



S 4.
>=C2=A0 =C2=A0 =C2=A0 control client requests credit autho= rization from the credit-control
>=C2=A0 =C2= =A0 =C2=A0 server prior to allowing any service to be delivered to the end = user.
>=C2=A0
>= =C2=A0 =C2=A0 =C2=A0 In the first model, the credit-control server rates th= e request,
>=C2=A0 =C2=A0 =C2=A0 reserves a su= itable amount of money from the user's account, and
>=C2=A0 =C2=A0 =C2=A0 returns the corresponding amount of credi= t resources.=C2=A0 Note that

Sorry, reserves the balance or the amount reserved?

[yuval] not sure what is not clear?

As I said above,= do you return the balance or do you return the amount of credit that has b= een reserved.



S 14.
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 Even without any m= odification to the messages, an adversary can
>= ;=C2=A0 =C2=A0 =C2=A0 eavesdrop on transactions that contain privacy-sensit= ive information
>=C2=A0 =C2=A0 =C2=A0 about th= e user.=C2=A0 Also, by monitoring the credit-control messages one
=
>=C2=A0 =C2=A0 =C2=A0 can collect information about the= credit-control server's billing
>=C2=A0 = =C2=A0 =C2=A0 models and business relationships.
=
I'm having trouble reading these two paragra= phs. Are they about what
happens if TLS isn't= used?

[yuval] will clarify. see here:=C2= =A0https://github.com/lbertz02/rfc4006= bis/issues/51

=
This doesn't seem dramatically clearer. What sort of an adve= rsary can do that?

-Ekr





_______________________________= ________________
DiME mailing list

--0000000000004b4927056cf37bad-- From nobody Thu May 24 06:58:52 2018 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 4BEB2126DFB for ; Thu, 24 May 2018 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neYReesqGTMT for ; Thu, 24 May 2018 06:58:44 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B192127775 for ; Thu, 24 May 2018 06:58:44 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id k5-v6so1531075oiw.0 for ; Thu, 24 May 2018 06:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NUn+ReqB4XJH/Z9bGTI9rWRS4hnwGcVFUFgPZ7ZTYNM=; b=wslfoSwrx4+aVWSbNiqkhwi69UfDQNAy57NA+jrGcL+hHJujI0604CtXdHn4V2czlA IwgpWNvEcKvHmIk/sxWIXR5E58zjxjPXkv0qcpBQuJmjHwi9LnUASO+QyWOv0SIMk3gp 18bCHSEiujBjjFpeAhDSse5wbbWYwZess67qdkD4+++rDtpdGE6Iy0M/lHFpf7jTKPau tm5duAVjelrvC57JbRoyNOxyrsS7e10F9QFE/F0StI+rxXKPc3ChaemXiYbKdPfLF+Vh 1VcWaucAhXV7FTRmWequ4JcemieeFpo17NmmANvEwTA6euzBlHkDNSzKGeElQ8Kx/enR MyCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NUn+ReqB4XJH/Z9bGTI9rWRS4hnwGcVFUFgPZ7ZTYNM=; b=jy+b0qKIVuUMiQH6Ve1GJX//6NmpJWQOKotHJE1V9fczqBRnrWoPwijqzs45Y3uL2J IMMVbcZz7GBCOzfdNKC6JWn9UsXRRyzl4y7N93LKOb1hSf0FoVzE2Nbz0t/JuSS4N6ZK kaE4AEGkq3DHEmSAn5WRW3dV21sGpR73JK/vmlncQ9M9DzBewPUjY0NXy2U/hcEwu0gh e3mQs6F9Bsp/bElal47pgmOo3yec0V0jsCQpuUgsFWfzv76ssKEXsci66EqZfb38AlfE qOr/u+cL6oXTiUfdwCjfPzlLAUlQyQwVVShO/77EXFmPTkdjbq41QRe2wyU2hSSCb4Wc MfbQ== X-Gm-Message-State: ALKqPwdBsea0SngG/vyLQd+m+UwHYSUHKf5sb1CP+M3SRzhN44Hjb2Nn aEvt+vPRBfHTt2K8crsSYyBXTGgWn+iyoRymCzMoYg== X-Google-Smtp-Source: AB8JxZoiBqTGR6iaFBQxenHnZJy1zOHHmhTyT9tkxT4N60m6dv7E2AcBh35u6DfNlUH0cIcrlewvxY0ql9f6hvWS5Ck= X-Received: by 2002:aca:c754:: with SMTP id x81-v6mr3767734oif.43.1527170323461; Thu, 24 May 2018 06:58:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 24 May 2018 06:58:03 -0700 (PDT) In-Reply-To: <1842664888.4936240.1527169987125@mail.yahoo.com> References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> <1842664888.4936240.1527169987125@mail.yahoo.com> From: Eric Rescorla Date: Thu, 24 May 2018 06:58:03 -0700 Message-ID: To: Yuval Lifshitz Cc: The IESG , dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4867b056cf40c71" Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 13:58:52 -0000 --000000000000a4867b056cf40c71 Content-Type: text/plain; charset="UTF-8" On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz wrote: > more inline > > On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla > wrote: > > > > > On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz > wrote: > > *inline* > > On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla > wrote: > > > Eric Rescorla has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. > html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/ > > > > > ------------------------------ ------------------------------ ---------- > COMMENT: > ------------------------------ ------------------------------ ---------- > > Rich version of this review at: > https://mozphab-ietf. devsvcdev.mozaws.net/D3353 > > > > I only gave this a light read. Some minor comments below. > > COMMENTS > S 1.2. > > deduction of credit from the end user account when service is > > completed and refunding of reserved credit that is not used. > > > > Diameter Credit-control Server A Diameter credit-control server > acts > > as a prepaid server, performing real-time rating and credit- > > control. It is located in the home domain and is accessed by > > a definition of "home domain" would be useful > > *[yuval] base spec define "home realm" we should probably change to that* > > S 2. > > credit-control application. > > > > When an end user requests services such as SIP or messaging, the > > request is typically forwarded to a service element (e.g., SIP > Proxy) > > in the user's home domain. In some cases it might be possible that > > the service element in the visited domain can offer services to the > > also define visited domain, or at least point to a reference. > > *[yuval] base spec defined "local realm" for that. will fix* > > S 3.1. > > [ CC-Correlation-Id ] > > [ User-Equipment-Info ] > > [ User-Equipment-Info-Extension ] > > *[ Proxy-Info ] > > *[ Route-Record ] > > *[ AVP ] > > Please expand AVP on first use. > > *[yuval] it is in the base spec* > > > I'm sure it is, but you should still expand it. > > [yuval] sure we can (it would be a bit awkward though, in the world of > "Diameter" it will be like explaining what TCP stands for...) > https://tools.ietf.org/rfcmarkup?doc=7322#section-3.6 S 4. > > control client requests credit authorization from the credit-control > > server prior to allowing any service to be delivered to the end > user. > > > > In the first model, the credit-control server rates the request, > > reserves a suitable amount of money from the user's account, and > > returns the corresponding amount of credit resources. Note that > > Sorry, reserves the balance or the amount reserved? > > *[yuval] not sure what is not clear?* > > > As I said above, do you return the balance or do you return the amount of > credit that has been reserved. > > [yuval] return the reserved amount > OK, the text should say it. -Ekr > > > > S 14. > > > > Even without any modification to the messages, an adversary can > > eavesdrop on transactions that contain privacy-sensitive information > > about the user. Also, by monitoring the credit-control messages one > > can collect information about the credit-control server's billing > > models and business relationships. > > I'm having trouble reading these two paragraphs. Are they about what > happens if TLS isn't used? > > *[yuval] will clarify. see here: *https://github.com/ > lbertz02/rfc4006bis/issues/51 > > > > This doesn't seem dramatically clearer. What sort of an adversary can do > that? > > [yuval] in some cases e2e security is not possible, this is what this > section is addressing, the github issue is to clarify that > > -Ekr > > > > > > > ______________________________ _________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/ listinfo/dime > > > > --000000000000a4867b056cf40c71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz <<= a href=3D"mailto:yuvalif@yahoo.com" target=3D"_blank">yuvalif@yahoo.com= > wrote:
more inline

=20
=20
On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.co= m> wrote:




On Wed, May 23, 2018 at 11:33= PM, Yuval Lifshitz <yuvalif@yahoo.com= > wrote:
inline

=20
=20
On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:


Eric Rescorla has entered the fol= lowing ballot position for
draft-i= etf-dime-rfc4006bis-08: No Objection

When responding, please keep t= he subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut th= is
introductory paragraph, however= .)


for mo= re information about IESG DISCUSS and COMMENT positions.
=


The document, along with other ballot posi= tions, can be found here:


------------------------= ------ ------------------------------ ----------
COMMENT:
----------= -------------------- ------------------------------ ----------

Rich= version of this review at:


I only gave this a= light read. Some minor comments below.

COMMENTS
=
S 1.2.
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 deduction of credit from the end user account = when service is
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 completed and refunding of reserved credit that is not used.=
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 Diameter Credit-control Serve= r=C2=A0 A Diameter credit-control server acts
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a prepaid server, performin= g real-time rating and credit-
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 control.=C2=A0 It is located in the home doma= in and is accessed by

a definition of "home domain" would= be useful

[yuval] base spec de= fine "home realm" we should probably change to that

S 2.
>=C2=A0 =C2=A0 =C2= =A0 credit-control application.
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 When an end user requests services such as SIP or messaging, the
>=C2=A0 =C2=A0 =C2=A0 request is typi= cally forwarded to a service element (e.g., SIP Proxy)
>=C2=A0 =C2=A0 =C2=A0 in the user's home domain= .=C2=A0 In some cases it might be possible that
>=C2=A0 =C2=A0 =C2=A0 the service element in the visited d= omain can offer services to the
also define visited domain, or at l= east point to a reference.

[yuv= al] base spec defined "local realm" for that. will fix=

S 3.1.
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CC-Correlation-Id ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Us= er-Equipment-Info ]
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extension ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *[ Proxy-Info ]
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *= [ AVP ]

<= div dir=3D"ltr">Please expand AVP on first use.

[yuval] it is in the base spec

I'm = sure it is, but you should still expand it.

<= /div>
[yuval] sure we can (it would be a bit awkward though= , in the world of "Diameter" it will be like explaining what TCP = stands for...)
<= /div>


S 4.
>=C2=A0 =C2=A0 =C2=A0 control client re= quests credit authorization from the credit-control
>=C2=A0 =C2=A0 =C2=A0 server prior to allowing any ser= vice to be delivered to the end user.
>=C2=A0
>=C2=A0 =C2=A0= =C2=A0 In the first model, the credit-control server rates the request,
>=C2=A0 =C2=A0 =C2=A0 reserves a = suitable amount of money from the user's account, and
>=C2=A0 =C2=A0 =C2=A0 returns the corresponding = amount of credit resources.=C2=A0 Note that

Sorry, reserves the bal= ance or the amount reserved?

[y= uval] not sure what is not clear?
<= /div>

As I said above, do yo= u return the balance or do you return the amount of credit that has been re= served.

[yuval]= return the reserved amount

OK, the te= xt should say it.

-Ekr


<= div>


S 14.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 Even without any modification to the mess= ages, an adversary can
>=C2=A0 = =C2=A0 =C2=A0 eavesdrop on transactions that contain privacy-sensitive info= rmation
>=C2=A0 =C2=A0 =C2=A0 a= bout the user.=C2=A0 Also, by monitoring the credit-control messages one
>=C2=A0 =C2=A0 =C2=A0 can collect= information about the credit-control server's billing
>=C2=A0 =C2=A0 =C2=A0 models and business relat= ionships.

I'm having trouble reading these two paragraphs. Are = they about what
happens if TLS isn= 't used?

[yuval] will clari= fy. see here:=C2=A0https://g= ithub.com/ lbertz02/rfc4006bis/issues/51
<= /div>

This doesn't seem = dramatically clearer. What sort of an adversary can do that?

[yuval] in some cases e2e sec= urity is not possible, this is what this section is addressing, the github = issue is to clarify that

-Ekr






=
______________________________ _________________
DiME mailing list


--000000000000a4867b056cf40c71-- From nobody Thu May 24 07:03:31 2018 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 688BD12E048 for ; Thu, 24 May 2018 07:03:20 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDj3GyjsqgO4 for ; Thu, 24 May 2018 07:03:17 -0700 (PDT) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DD2127863 for ; Thu, 24 May 2018 07:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527170594; bh=k3IOqo7/5jKqqD9ySx9uvwwaWL7iqUWagXiAI7XwPfc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=uauxnp/017GgLUCwpGyosqSwHVu94m3q+Ti0hbCof6tnMJDVJv4m1O0eJr74ZbgdMoh/5SwWrPJSPyl1Blf7xaj7t/cXBzq1NcV20yOdGxndLzEeGcuUh1mehvY09tPHXvbzgEGJC8cVdxfGmOeJ7e250+X9ZcvTOJ74G8VK9yfAsw9GCm675+vdgvq38553mQbwvegYQrUhMKpRYHbU8eVjv0RPIbs+w8/xcGEEKiEPkySxv7fqzZoVACCFdR48R1EY+Yyv7QMvxWVzVpLI/ZulxIErc8lbJeSkDfM0LdM3A89gIDL8zOIwgsNJWgI7uo1UjVSjjCc/o/AzN8FI7A== X-YMail-OSG: CzsoFsIVM1m_kDKe53SljwQn2SQoDxI_8IK08yDbgsw0KcG0Rw7lb2WIvLdqeln zCJnKTRkZb0wKMJPECDyfScYqLb.7Sfhy2AkLLt4_OYLuBbyi3hrmOkJl2NYUKPUZcvFvg5E5YWb EtzQiVg18q3AEovN9l8SXOLjColF_wr4Lu6MqvkMWr5cS_kmCkVD_Yjubcw_5XXZ3WQYmRZk3_WI uhstgLC9FY1iPFHuH1i3_MNokCK0dtPVDVH81Ytlq043nTOE7yjLA9NHGUWS_dnmtPIp4c5Co.4r 2ySHNPoQzqBgil3LQ5kgbgR8CyU6j7ZqznrOtyU0z4EycEHFzV7tO4xILPEyR_GaQpK3qe0I2ZW7 A4gEtzIkqAhk4svgav4AR_jLeHzrInoz3krMRYBWXgh6XNOtkDHDMl.z0d.XhfVfIL.S8r8GO.m4 zC5bnghfLvhLJJ8bDMhWAr7Nq1TNY8_xt8P8XctjlkmPaVHShNnERi9JkCfAG2oZURZIz2dGiqVY AdoqTk00HPe_H6dLkP1RlQfYCCPN0KlK39XxMRotTpFMXEV0Xr65LxDp8yRNL5MOWVdIp573jASh dXIH4IPd_D39CfQs1GYoPOkj3w.Qr0kothFKuQoECOrbaZSkUZp4Za..U9ZTvcj6Pm7EILWkdzWn 1FFOToOXtmkpmVFVQGwwb5ODcFA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 14:03:14 +0000 Date: Thu, 24 May 2018 13:53:07 +0000 (UTC) From: Yuval Lifshitz To: Eric Rescorla Cc: The IESG , dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <1842664888.4936240.1527169987125@mail.yahoo.com> In-Reply-To: References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4936239_362820500.1527169987119" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 14:03:21 -0000 ------=_Part_4936239_362820500.1527169987119 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable more inline On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla wrote: =20 =20 =20 On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz wrote: inline On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla wrote: =20 =20 Eric Rescorla has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/ ------------------------------ ------------------------------ ---------- COMMENT: ------------------------------ ------------------------------ ---------- Rich version of this review at: https://mozphab-ietf. devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deduction of credit from the end user account = when service is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 completed and refunding of reserved credit tha= t is not used. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Diameter Credit-control Server=C2=A0 A Diameter credi= t-control server acts >=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a prepaid server, performing real-time rati= ng and credit- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 control.=C2=A0 It is located in the home domai= n and is accessed by a definition of "home domain" would be useful [yuval] base spec define "home realm" we should probably change to that S 2. >=C2=A0 =C2=A0 =C2=A0 credit-control application. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 When an end user requests services such as SIP or mes= saging, the >=C2=A0 =C2=A0 =C2=A0 request is typically forwarded to a service element (= e.g., SIP Proxy) >=C2=A0 =C2=A0 =C2=A0 in the user's home domain.=C2=A0 In some cases it mig= ht be possible that >=C2=A0 =C2=A0 =C2=A0 the service element in the visited domain can offer s= ervices to the also define visited domain, or at least point to a reference. [yuval] base spec defined "local realm" for that. will fix S 3.1. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CC-Correlation-Id ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extensi= on ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Proxy-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] Please expand AVP on first use. [yuval] it is in the base spec I'm sure it is, but you should still expand it.=20 [yuval] sure we can (it would be a bit awkward though, in the world of "Dia= meter" it will be like explaining what TCP stands for...) S 4. >=C2=A0 =C2=A0 =C2=A0 control client requests credit authorization from the= credit-control >=C2=A0 =C2=A0 =C2=A0 server prior to allowing any service to be delivered = to the end user. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 In the first model, the credit-control server rates t= he request, >=C2=A0 =C2=A0 =C2=A0 reserves a suitable amount of money from the user's a= ccount, and >=C2=A0 =C2=A0 =C2=A0 returns the corresponding amount of credit resources.= =C2=A0 Note that Sorry, reserves the balance or the amount reserved? [yuval] not sure what is not clear? As I said above, do you return the balance or do you return the amount of c= redit that has been reserved. [yuval] return the reserved amount S 14. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Even without any modification to the messages, an adv= ersary can >=C2=A0 =C2=A0 =C2=A0 eavesdrop on transactions that contain privacy-sensit= ive information >=C2=A0 =C2=A0 =C2=A0 about the user.=C2=A0 Also, by monitoring the credit-= control messages one >=C2=A0 =C2=A0 =C2=A0 can collect information about the credit-control serv= er's billing >=C2=A0 =C2=A0 =C2=A0 models and business relationships. I'm having trouble reading these two paragraphs. Are they about what happens if TLS isn't used? [yuval] will clarify. see here:=C2=A0https://github.com/ lbertz02/rfc4006bi= s/issues/51 This doesn't seem dramatically clearer. What sort of an adversary can do th= at? [yuval] in some cases e2e security is not possible, this is what this secti= on is addressing, the github issue is to clarify that -Ekr ______________________________ _________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/ listinfo/dime =20 =20 ------=_Part_4936239_362820500.1527169987119 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
more inline

=20
=20
On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:




O= n Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz <yuvalif@yahoo.com> wrote:
inline

=20
=20
On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:


Eric Rescorla has entered the following ballot position for<= br clear=3D"none">
draft-ietf-dime-rfc4006bis-08: No = Objection

When responding, please keep the subject line intact and = reply to all
email addresses inclu= ded in the To and CC lines. (Feel free to cut this
=
introductory paragraph, however.)
=


for more information about IESG D= ISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



------------------------------ -----------------------= ------- ----------
COMMENT:
------------------------------ ---------= --------------------- ----------
<= br clear=3D"none">
Rich version of this review at:
h= ttps://mozphab-ietf. devsvcdev.mozaws.net/D3353


I only gave this a light read. Some minor commen= ts below.

COMMENTS
S 1.2.<= br clear=3D"none">
>        d= eduction of credit from the end user account when service is
>        completed and r= efunding of reserved credit that is not used.
> 
> = ;     Diameter Credit-control Server  A Diameter credit-cont= rol server acts
>    =     as a prepaid server, performing real-time rating and credit-=
>        = control.  It is located in the home domain and is accessed by

= a definition of "home domain" would be useful

[yuval] base spec define "home realm" we should probably ch= ange to that

S 2.
>     = credit-control application.
>&= nbsp;
>      W= hen an end user requests services such as SIP or messaging, the
>      request is typically= forwarded to a service element (e.g., SIP Proxy)
<= div dir=3D"ltr">>      in the user's home domain.  I= n some cases it might be possible that
>      the service element in the visited domain can= offer services to the

also define visited domain, or at least po= int to a reference.

[yuval] ba= se spec defined "local realm" for that. will fix
<= br clear=3D"none">
S 3.1.
>                &= nbsp;                 [ CC-Correla= tion-Id ]
>     =                     &nbs= p;       [ User-Equipment-Info ]
>                =                   [ User-Equi= pment-Info-Extension ]
>  =                      = ;           *[ Proxy-Info ]
>              &nb= sp;                   *[ Route= -Record ]
>     =                     &nbs= p;       *[ AVP ]
<= br clear=3D"none">
Please expand AVP on first use.

[yuval] it is in the base spec

I'm sure it is, but you should still expand it.

[yuval] sure we can (it would be a bit awkw= ard though, in the world of "Diameter" it will be like explaining what TCP = stands for...)



S 4.
>&nbs= p;     control client requests credit authorization from the cred= it-control
>     = ; server prior to allowing any service to be delivered to the end user.
> 
=
>      In the first model, the credit-co= ntrol server rates the request,
&g= t;      reserves a suitable amount of money from the user's = account, and
>    &nb= sp; returns the corresponding amount of credit resources.  Note that

Sorry, reserves the balance or the amount reserved?

= [yuval] not sure what is not clear?

=
As I said above, do you return the balance or do you return the = amount of credit that has been reserved.

[yuval] return the reserved amount



S 14.
> 
>      Even without an= y modification to the messages, an adversary can
>      eavesdrop on transactions that cont= ain privacy-sensitive information
= >      about the user.  Also, by monitoring the cred= it-control messages one
> =     can collect information about the credit-control server's bi= lling
>      mod= els and business relationships.
I'm having trouble reading these tw= o paragraphs. Are they about what
= happens if TLS isn't used?

[yu= val] will clarify. see here: https://github.com/ lbertz02/rfc4006bis/issues/51

This do= esn't seem dramatically clearer. What sort of an adversary can do that?

[yuval] in some case= s e2e security is not possible, this is what this section is addressing, th= e github issue is to clarify that

-Ekr






____________= __________________ _________________
DiME mailing list
=
------=_Part_4936239_362820500.1527169987119-- From nobody Thu May 24 07:12:32 2018 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 DF009127078 for ; Thu, 24 May 2018 07:12:27 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4VRl4IYS0K5 for ; Thu, 24 May 2018 07:12:25 -0700 (PDT) Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F55A124D6C for ; Thu, 24 May 2018 07:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527171144; bh=MsaREu7U7MFLxMLx9bEMs9f/QSLDGDe+OJrFIqFK4Ek=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cRKhw0LpWH++Vf+egdDeOx5IFshYtD+sjsgi/vvYtSB7KuPXUrY+COf/QgQrby1PXFrvjmhjXmfyqJ3qZr1DLdwfZPUMYkTL3lXhJn45m2TbGoPje4kRe5FgZ0VJycgPmA0b9ctGfD9gyalNNfAQtgHzNjQOTOHwIeob/oq7wY8n4HKoOMdiYfG8xd5cMMOwfDuy6y8J6RtH0DsuhoVFIRwWv67phuuf07KI0vPKE2i6U2ZC9T07ansO/X8cO2w1RUMquyjXK+5GOzTf1Dn1nWM0evEyRkOxB5zQBHkDCxRzCRCR9ceP99sH4IF287pzsmOl6/ZETHAaoGoUc5uQvA== X-YMail-OSG: 9Gx4F5cVM1kjxGMdlsT1ktqwHywek6BvPfjyPlLUCjD3DNdTVi2YDmGZEovGGyo taHPczQNo6oaayPxYoK.m2lxEI6z0ex.Fwr66LauImqRKcomJDKC.jSoN0LRXEAv3ofmI1IoiUza 3g2ggH1rXgfbUHXs9JqHmJsx4701ku3qhXiNPT3DdIbNz9aC2WJiv4F6ECyTnpwzwpm6cWfG8Jtw 2xXXEnE5WYzxdOfIMDgZpT3UQ2ZLFOtoktW5VtUfseW0o9fKO7qVbpgalx3Zfy2BgFNcC4c588bm d13eFvyicgouerJk6upt4pcxOHcnhpBYpmHMbfrNsLWkTTpVo4BxKy9Nygh6u_Wcx3c53eKRw7Eb EoMQ4c0hRKrCy0Jj4bqpUxTkgAkDWmX0EXxSSo8Vq3VvirS9laIKUgC0pko.BGjF2Xy0GGLUs8I5 CeSIZipY29gFAw1ZTlVlOhsWABqQFevv96_l1H2.oAab9f1Wpx0Cfi5hv7tXIYWMG6aZ5YjOLcAV 2_swqs9Y7zim1KkRYk3c7e2k6M2E5e5BdNSAA.W07sIZ1_EtbK.WGeSsC9OWEYEu2XffRYZLAs73 fKF3ryQZDFT7cy3LfWixqwsF18hN_4OuO4qvvyna2XsaMYYd4ohMCSVUvE5cqsVgNQ.wHLuJO7bV tDfKwBIQWibfLH6.3YkM.vxDkaA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 14:12:24 +0000 Date: Thu, 24 May 2018 14:12:20 +0000 (UTC) From: Yuval Lifshitz To: Eric Rescorla Cc: The IESG , dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <1337069826.4959599.1527171140082@mail.yahoo.com> In-Reply-To: References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> <1842664888.4936240.1527169987125@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4959598_653131198.1527171140074" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 14:12:28 -0000 ------=_Part_4959598_653131198.1527171140074 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inline On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric Rescorla wrote: =20 =20 =20 On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz wrote: more inline On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla wrote: =20 =20 =20 On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz wrote: inline On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla wrote: =20 =20 Eric Rescorla has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/ ------------------------------ ------------------------------ ---------- COMMENT: ------------------------------ ------------------------------ ---------- Rich version of this review at: https://mozphab-ietf. devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deduction of credit from the end user account = when service is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 completed and refunding of reserved credit tha= t is not used. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Diameter Credit-control Server=C2=A0 A Diameter credi= t-control server acts >=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a prepaid server, performing real-time rati= ng and credit- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 control.=C2=A0 It is located in the home domai= n and is accessed by a definition of "home domain" would be useful [yuval] base spec define "home realm" we should probably change to that S 2. >=C2=A0 =C2=A0 =C2=A0 credit-control application. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 When an end user requests services such as SIP or mes= saging, the >=C2=A0 =C2=A0 =C2=A0 request is typically forwarded to a service element (= e.g., SIP Proxy) >=C2=A0 =C2=A0 =C2=A0 in the user's home domain.=C2=A0 In some cases it mig= ht be possible that >=C2=A0 =C2=A0 =C2=A0 the service element in the visited domain can offer s= ervices to the also define visited domain, or at least point to a reference. [yuval] base spec defined "local realm" for that. will fix S 3.1. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CC-Correlation-Id ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extensi= on ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Proxy-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] Please expand AVP on first use. [yuval] it is in the base spec I'm sure it is, but you should still expand it.=20 [yuval] sure we can (it would be a bit awkward though, in the world of "Dia= meter" it will be like explaining what TCP stands for...) https://tools.ietf.org/rfcmarkup?doc=3D7322#section-3.6 [yuval] in the list, but not marked as "well known". OTOH, that document gi= ves some freedom to the RFC editor. Given that the first couple of occurren= ces=C2=A0of AVP in the spec are in titles and inside ABNF, there isn't a re= asonable place to expand that. If someone tries to read any Diameter applic= ation spec, without the base one they would probably run into other issues = as well S 4. >=C2=A0 =C2=A0 =C2=A0 control client requests credit authorization from the= credit-control >=C2=A0 =C2=A0 =C2=A0 server prior to allowing any service to be delivered = to the end user. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 In the first model, the credit-control server rates t= he request, >=C2=A0 =C2=A0 =C2=A0 reserves a suitable amount of money from the user's a= ccount, and >=C2=A0 =C2=A0 =C2=A0 returns the corresponding amount of credit resources.= =C2=A0 Note that Sorry, reserves the balance or the amount reserved? [yuval] not sure what is not clear? As I said above, do you return the balance or do you return the amount of c= redit that has been reserved. [yuval] return the reserved amount OK, the text should say it. [yuval] ok. will rephrase -Ekr S 14. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Even without any modification to the messages, an adv= ersary can >=C2=A0 =C2=A0 =C2=A0 eavesdrop on transactions that contain privacy-sensit= ive information >=C2=A0 =C2=A0 =C2=A0 about the user.=C2=A0 Also, by monitoring the credit-= control messages one >=C2=A0 =C2=A0 =C2=A0 can collect information about the credit-control serv= er's billing >=C2=A0 =C2=A0 =C2=A0 models and business relationships. I'm having trouble reading these two paragraphs. Are they about what happens if TLS isn't used? [yuval] will clarify. see here:=C2=A0https://github.com/ lbertz02/rfc4006bi= s/issues/51 This doesn't seem dramatically clearer. What sort of an adversary can do th= at? [yuval] in some cases e2e security is not possible, this is what this secti= on is addressing, the github issue is to clarify that -Ekr ______________________________ _________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/ listinfo/dime =20 =20 =20 ------=_Part_4959598_653131198.1527171140074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline

=20
=20
On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:


On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz <= /span><yuvalif@yahoo.com> wrote:
more inline

=20
=20
On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:



On Wed, = May 23, 2018 at 11:33 PM, Yuval Lifshitz <= yuvalif@yahoo.com> wrote:
inline

=20
=20
On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:


Eric Resc= orla has entered the following ballot position for
=
draft-ietf-dime-rfc4006bis-08: No Objection

When r= esponding, please keep the subject line intact and reply to all
email addresses included in the To and CC lin= es. (Feel free to cut this
introdu= ctory paragraph, however.)


Please refer to https://www.= ietf.org/iesg/ statement/discuss-criteria. html
for more information about IESG DISCUSS and COMMENT posit= ions.


The document, along= with other ballot positions, can be found here:
https://data= tracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/



---= --------------------------- ------------------------------ ----------
COMMENT:
------------------------------ ------------------------------ --= --------

=
Rich version of this review at:
https://mozphab-ietf. dev= svcdev.mozaws.net/D3353


I only gave this a light read. Some minor comments below.

COMMEN= TS
S 1.2.
=
>        deduction of credit from = the end user account when service is
>        completed and refunding of reserved cre= dit that is not used.
>  =
>      Diameter= Credit-control Server  A Diameter credit-control server acts
>        as a prep= aid server, performing real-time rating and credit-
>        control.  It is loc= ated in the home domain and is accessed by

a definition of "home do= main" would be useful

[yuval] = base spec define "home realm" we should probably change to that<= br clear=3D"none">

S 2.
>      credit-control application.
=
> 
>      When an end user requests services such as SIP o= r messaging, the
>   =   request is typically forwarded to a service element (e.g., SIP Prox= y)
>      in the= user's home domain.  In some cases it might be possible that
>      the service eleme= nt in the visited domain can offer services to the
=

also define visi= ted domain, or at least point to a reference.

[yuval] base spec defined "local realm" for that. will fix<= /i>

S 3.1.
<= div dir=3D"ltr">>               =                   [ CC-Corre= lation-Id ]
>    &nbs= p;                     &n= bsp;       [ User-Equipment-Info ]
=
>               = ;                   [ User-Eq= uipment-Info-Extension ]
> = ;                     &nb= sp;           *[ Proxy-Info ]
>              &= nbsp;                   *[ Rou= te-Record ]
>    &nbs= p;                     &n= bsp;       *[ AVP ]

Please expand AVP on first use.<= br clear=3D"none">

[yuval] it is in the base spe= c

I'm sure it is, but you should still expand it.
<= div>
[yuval] sure we can (it woul= d be a bit awkward though, in the world of "Diameter" it will be like expla= ining what TCP stands for...)


[yuval] in the list, but not marked as "well known". OTOH, that document= gives some freedom to the RFC editor. Given that the first couple of occur= rences of AVP in the spec are in titles and inside ABNF, there isn't a= reasonable place to expand that. If someone tries to read any Diameter app= lication spec, without the base one they would probably run into other issu= es as well

S 4.
>      control cli= ent requests credit authorization from the credit-control
>      server prior to allowing a= ny service to be delivered to the end user.
> 
>  =     In the first model, the credit-control server rates the reque= st,
>      reser= ves a suitable amount of money from the user's account, and
>      returns the correspondin= g amount of credit resources.  Note that

Sorry, reserves the b= alance or the amount reserved?
[yuval] not sure what is not clear?

As I said above, do= you return the balance or do you return the amount of credit that has been= reserved.

[yuval] retu= rn the reserved amount

OK, the text should say it.

[yuval] ok. will rephrase

-Ekr



<= /span>

S 14.
> 
<= div dir=3D"ltr">>      Even without any modification to t= he messages, an adversary can
>=       eavesdrop on transactions that contain privacy-sensiti= ve information
>    &= nbsp; about the user.  Also, by monitoring the credit-control messages= one
>      can = collect information about the credit-control server's billing
>      models and business re= lationships.

I'm having trouble reading these two paragraphs. Are t= hey about what
happens if TLS isn'= t used?

<= div dir=3D"ltr">[yuval] will clarify. = see here: https://githu= b.com/ lbertz02/rfc4006bis/issues/51

This doesn't seem dramatic= ally clearer. What sort of an adversary can do that?

[yuval] in some cases e2e security is not pos= sible, this is what this section is addressing, the github issue is to clar= ify that

-Ekr

=

<= br clear=3D"none">



_______= _______________________ _________________
DiME mailing = list


------=_Part_4959598_653131198.1527171140074-- From nobody Thu May 24 07:26:52 2018 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 4482912E741 for ; Thu, 24 May 2018 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08T1y6g8GM92 for ; Thu, 24 May 2018 07:26:47 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D24512E034 for ; Thu, 24 May 2018 07:26:47 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id m11-v6so2157177otf.3 for ; Thu, 24 May 2018 07:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JSkbxKfrqxskg+f/mD+1b9GogOr3fFeVxKLdvH9tnzw=; b=LbCO9FmHG8OOQSjNWfr2fcJErvBGh+Iut6ujLiLQLrrK5HQY0QuTWylk+LriTVTHv2 fHQGRyUxJpMc8096DZehnOPhkOt/rAjMz3LYmPLjKmgmUfpg2IiKpkfpJtWLti86osxw NLgnOR/Kl0NUimHB1eNXR6lu6OSEjIvhv3YSwT1JrRZO8G5NM40l/PAdMMDDV2meFpCB sGsirttC2x/XqHs/ywAd2P9D5x7vtxbKobP2HL7Vndg65ina7/P/M8NIZTul7Whib3zG 8azMY+cOKofCcdbEKXQfLYTZsuGimdDc/N9azbFTkxZd7nL1ZC5kKAy/r+N65vlN8WhS JsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JSkbxKfrqxskg+f/mD+1b9GogOr3fFeVxKLdvH9tnzw=; b=C5pkI1eRrSJ/c+10MfrCOS9Djkn4wQbrkLcp58GDo8H2KEDKJ/wtpM0GjquNSUdCaS d7IK9Doj87XCfv4eYst2JDhz5aYnsU3qO5/R+lzqjo3siwhIXiVG4z/sgOD+SnDXZH8u gT3X2Z6II7j6JrSJxJSCl9aSOKP9vY87ZhBn06HAg2yGp1Y+XLjZ64+8BK22Dr4GygNs 5XxqeRzDRDiD4fvKJhsS5SgEvUz4nCuQqlrBGyYFHzj4fZuF3BNhyraZiCh0RXzCrt0M S1aymrFf8+hnS8y428N6HLHnhcpKX80r1MjgQ00T97wE1mf1pewTbAcCdFKSCPKH0Rss NdIg== X-Gm-Message-State: ALKqPwcqQw69hmxmT4SKLJqOGn7Q8sXOOituxAZE9LAgwhgxli1a7qc6 E1H2UO4VYSdWByxrkqPncnx36m7WzsPYz/o5fui3dA== X-Google-Smtp-Source: AB8JxZqJ6m9Iwk8uvhXIkoEMMp3qK3zbhyDgUIKPcpPOSHO0qXz+H/LYSQ71pgGvnP9svu+c4vgRq5G0/fVuW2m6710= X-Received: by 2002:a9d:719a:: with SMTP id o26-v6mr5188154otj.44.1527172006483; Thu, 24 May 2018 07:26:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 24 May 2018 07:26:06 -0700 (PDT) In-Reply-To: <1337069826.4959599.1527171140082@mail.yahoo.com> References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> <1842664888.4936240.1527169987125@mail.yahoo.com> <1337069826.4959599.1527171140082@mail.yahoo.com> From: Eric Rescorla Date: Thu, 24 May 2018 07:26:06 -0700 Message-ID: To: Yuval Lifshitz Cc: The IESG , dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000f528da056cf47066" Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 14:26:51 -0000 --000000000000f528da056cf47066 Content-Type: text/plain; charset="UTF-8" On Thu, May 24, 2018 at 7:12 AM, Yuval Lifshitz wrote: > *inline* > > On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric Rescorla > wrote: > > > > > On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz wrote: > > more inline > > On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla > wrote: > > > > > On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz > wrote: > > *inline* > > On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla > wrote: > > > Eric Rescorla has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. > html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/ > > > > > ------------------------------ ------------------------------ ---------- > COMMENT: > ------------------------------ ------------------------------ ---------- > > Rich version of this review at: > https://mozphab-ietf. devsvcdev.mozaws.net/D3353 > > > > I only gave this a light read. Some minor comments below. > > COMMENTS > S 1.2. > > deduction of credit from the end user account when service is > > completed and refunding of reserved credit that is not used. > > > > Diameter Credit-control Server A Diameter credit-control server > acts > > as a prepaid server, performing real-time rating and credit- > > control. It is located in the home domain and is accessed by > > a definition of "home domain" would be useful > > *[yuval] base spec define "home realm" we should probably change to that* > > S 2. > > credit-control application. > > > > When an end user requests services such as SIP or messaging, the > > request is typically forwarded to a service element (e.g., SIP > Proxy) > > in the user's home domain. In some cases it might be possible that > > the service element in the visited domain can offer services to the > > also define visited domain, or at least point to a reference. > > *[yuval] base spec defined "local realm" for that. will fix* > > S 3.1. > > [ CC-Correlation-Id ] > > [ User-Equipment-Info ] > > [ User-Equipment-Info-Extension ] > > *[ Proxy-Info ] > > *[ Route-Record ] > > *[ AVP ] > > Please expand AVP on first use. > > *[yuval] it is in the base spec* > > > I'm sure it is, but you should still expand it. > > [yuval] sure we can (it would be a bit awkward though, in the world of > "Diameter" it will be like explaining what TCP stands for...) > > > https://tools.ietf.org/rfcmarkup?doc=7322#section-3.6 > > *[yuval] in the list, but not marked as "well known". OTOH, that document > gives some freedom to the RFC editor. Given that the first couple of > occurrences of AVP in the spec are in titles and inside ABNF, there isn't a > reasonable place to expand that. If someone tries to read any Diameter > application spec, without the base one they would probably run into other > issues as well* > Put it in the glossary at the start. -Ekr > > S 4. > > control client requests credit authorization from the credit-control > > server prior to allowing any service to be delivered to the end > user. > > > > In the first model, the credit-control server rates the request, > > reserves a suitable amount of money from the user's account, and > > returns the corresponding amount of credit resources. Note that > > Sorry, reserves the balance or the amount reserved? > > *[yuval] not sure what is not clear?* > > > As I said above, do you return the balance or do you return the amount of > credit that has been reserved. > > [yuval] return the reserved amount > > > OK, the text should say it. > > *[yuval] ok. will rephrase* > > -Ekr > > > > > > S 14. > > > > Even without any modification to the messages, an adversary can > > eavesdrop on transactions that contain privacy-sensitive information > > about the user. Also, by monitoring the credit-control messages one > > can collect information about the credit-control server's billing > > models and business relationships. > > I'm having trouble reading these two paragraphs. Are they about what > happens if TLS isn't used? > > *[yuval] will clarify. see here: *https://github.com/ > lbertz02/rfc4006bis/issues/51 > > > > This doesn't seem dramatically clearer. What sort of an adversary can do > that? > > [yuval] in some cases e2e security is not possible, this is what this > section is addressing, the github issue is to clarify that > > -Ekr > > > > > > > ______________________________ _________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/ listinfo/dime > > > > > --000000000000f528da056cf47066 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 24, 2018 at 7:12 AM, Yuval Lifshitz <<= a href=3D"mailto:yuvalif@yahoo.com" target=3D"_blank">yuvalif@yahoo.com= > wrote:
inline

=20
=20
On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.co= m> wrote:




On Thu, May 24, = 2018 at 6:53 AM, Yuval Lifshitz <yuvalif@yahoo.com> wrote:
more inline

=20
=20
On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:




On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz <= ;yuvalif@yahoo.com> wrote:
inline

=20
=20
On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:


Eric Rescorla has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: No Ob= jection

<= div dir=3D"ltr">When responding, please keep the subject line intact and re= ply to all
email addresses include= d in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG D= ISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



------------------------------ -----------------------= ------- ----------
COMMENT:
------------------------------ ---------= --------------------- ----------
<= br clear=3D"none">
Rich version of this review at:
h= ttps://mozphab-ietf. devsvcdev.mozaws.net/D3353


I only gave this a light read. Some minor commen= ts below.

COMMENTS
S 1.2.<= br clear=3D"none">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 d= eduction of credit from the end user account when service is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 completed and r= efunding of reserved credit that is not used.
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 Diameter Credit-control Server=C2=A0 A Diameter credit-co= ntrol server acts
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 as a prepaid server, performing real-time rating and cre= dit-
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 control.=C2=A0 It is located in the home domain and is accessed by

a definition of "home domain" would be useful

= [yuval] base spec define "home realm&quo= t; we should probably change to that

S 2.
&g= t;=C2=A0 =C2=A0 =C2=A0 credit-control application.
=
>=C2=A0
>= =C2=A0 =C2=A0 =C2=A0 When an end user requests services such as SIP or mess= aging, the
>=C2=A0 =C2=A0 =C2= =A0 request is typically forwarded to a service element (e.g., SIP Proxy)
>=C2=A0 =C2=A0 =C2=A0 in the use= r's home domain.=C2=A0 In some cases it might be possible that
>=C2=A0 =C2=A0 =C2=A0 the service eleme= nt in the visited domain can offer services to the
=

also define visi= ted domain, or at least point to a reference.

[yuval] base spec defined "local realm" for that. = will fix

S= 3.1.
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [ CC-Correlation-Id ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipme= nt-Info ]
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extension ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *= [ Proxy-Info ]
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ]
<= div dir=3D"ltr">>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ]

Please expand AVP on first use.

[yuval] it is in the base spec

I'm sure it is= , but you should still expand it.

[yuval] sure we can (it would be a bit awkward though, in the w= orld of "Diameter" it will be like explaining what TCP stands for= ...)

<= div style=3D"color:rgb(38,40,42);font-family:"Helvetica Neue",Hel= vetica,Arial,sans-serif;font-size:13px">https://tools.ietf.org/rfcmarkup?doc=3D7322#section-3.6

=
[yuval] in the list, but not marked as "well known"= . OTOH, that document gives some freedom to the RFC editor. Given that the = first couple of occurrences=C2=A0of AVP in the spec are in titles and insid= e ABNF, there isn't a reasonable place to expand that. If someone tries= to read any Diameter application spec, without the base one they would pro= bably run into other issues as well
=

=C2=A0Put it= in the glossary at the start.

-Ekr

=


S 4.
>=C2= =A0 =C2=A0 =C2=A0 control client requests credit authorization from the cre= dit-control
>=C2=A0 =C2=A0 =C2= =A0 server prior to allowing any service to be delivered to the end user.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 In the first model, the credit-= control server rates the request,
= >=C2=A0 =C2=A0 =C2=A0 reserves a suitable amount of money from the user&= #39;s account, and
>=C2=A0 =C2= =A0 =C2=A0 returns the corresponding amount of credit resources.=C2=A0 Note= that

Sorry, reserves the balance or the amount reserved?

= [yuval] not sure what is not clear?=

As I said above, do you return the balance or do you return= the amount of credit that has been reserved.

=
[yuval] return the reserved amount
=

OK, the text should say it.

[yuval] ok. will rephrase

-Ekr

<= blockquote class=3D"m_-3265273038063010048ydp7c9c31c0yiv4118272216gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">




S 14.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 Even without an= y modification to the messages, an adversary can
>=C2=A0 =C2=A0 =C2=A0 eavesdrop on transactions that cont= ain privacy-sensitive information
= >=C2=A0 =C2=A0 =C2=A0 about the user.=C2=A0 Also, by monitoring the cred= it-control messages one
>=C2=A0= =C2=A0 =C2=A0 can collect information about the credit-control server'= s billing
>=C2=A0 =C2=A0 =C2=A0= models and business relationships.

I'm having trouble reading = these two paragraphs. Are they about what
happens if TLS isn't used?

[yuval] will clarify. see here:=C2=A0https://github.com/ lbertz02/rfc4006bis/issues/51

=
This doesn't seem dramatically clearer. What sort of an adversary = can do that?

[yuval] in= some cases e2e security is not possible, this is what this section is addr= essing, the github issue is to clarify that

-Ekr





______________________________ _________________
DiME mailing list



--000000000000f528da056cf47066-- From nobody Thu May 24 07:47:28 2018 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 01862127023 for ; Thu, 24 May 2018 07:47:26 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnZ1Nu4oTxR8 for ; Thu, 24 May 2018 07:47:23 -0700 (PDT) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372D812E873 for ; Thu, 24 May 2018 07:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527173242; bh=qb6OJe1YYIgQ2PjCChNnPGQZmi6Uy/FjceC2Ai2LgJ4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=TzzSAvg6/D2voQWrtd/6/Ur36Pbt6TUsoVfZaxkIaM7JE7PphZJP3ugNMRisvl+f0xgx1iTU746wSsYpaoRd/YF/NjN+8bAtB9AqR5u8XdtmGB7J+YjD0zTTcHd6NYelKXYKiTwICyfnEgkRFf+/e4x89Dvbk/0K3aCWqt05OqseVDX3gvLgg8NnkwYIdNflR5Oac7OC1+6YdomBet5KAFKQNm59gaqzTFtnSwF/VfmjH3aVUeugocnjWWunJKi5UnY5hcswmn168CeeWhFsQSbGBax4a7UhMB0tRr/r1fn+V2wv9Dnmymp/sOzbsnXhfPoDC/ha4mWuF3FfZWVYqg== X-YMail-OSG: eVnfbVUVM1lN5o4z8JxdJLjrd9EfRqJzQn2.t8LdUaXrboUNOKGdTzfMjbc3uiX k1h6mVozhau8jVjk_wHU53oD95H2_2ddGezQyfRrHhNlVQghvL.ReeBCee_yHYUMyIFPli.7ly4a JGqbNQp8tUzFH6Hmn1EOneXKtrAJcl4DMtuLOxbS7MrtagYxCG3I67nq0r2Y6dpJvZ7TlcQuuImc K1Pgb_6SSiOXJUNaHxJORxsvRliyzKwUamhkJOQVpYLcGaJaplUAcmxZlup6bMdQUDd4K.jZKVhJ 8eXL7xkrGkLcffWn08kcWnh.HxdYvIKcRnqcMz.fte0HJkkKYJNFz8aPBHILVwHlHKhAAhcCwOx0 7F1Mp9zHHKlBMS_aIs3zlG0.USa7d.aNddyIks9imj.Xd3kIhEbl55D4flMJ4JKkT_Kb6_xWBzEt ONR1m.CAWMZMUO64DzrOdPRcwXfb1pt40UKTIRH2TkexzQ2rCEQAnIzkRWxNCV8cUOtfI.WRXq6Z _FkoKH8J_ao8GphLZU9SCakIL5MEiF8HV6DfmJLr3APpsFK02M91pitaqVbyP1T4VShVolrn3AyQ S5xXYAk4k2RKImCOmBaeSXrkiIbF1d5SJkLUEX30DvxhehAZVnso63qWVmjrIsTfn7tbqcbECi0. f4lTTgD.k4wt_fgkchhrdy.6tP1nycw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 14:47:22 +0000 Date: Thu, 24 May 2018 14:37:18 +0000 (UTC) From: Yuval Lifshitz To: Eric Rescorla Cc: The IESG , dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <352182332.4945946.1527172638186@mail.yahoo.com> In-Reply-To: References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> <1842664888.4936240.1527169987125@mail.yahoo.com> <1337069826.4959599.1527171140082@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4945944_996791147.1527172638177" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 14:47:26 -0000 ------=_Part_4945944_996791147.1527172638177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ok. will add AVP to section 1.2 On Thursday, May 24, 2018, 5:26:47 p.m. GMT+3, Eric Rescorla wrote: =20 =20 =20 On Thu, May 24, 2018 at 7:12 AM, Yuval Lifshitz wrote: inline On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric Rescorla wrote: =20 =20 =20 On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz wrote: more inline On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla wrote: =20 =20 =20 On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz wrote: inline On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla wrote: =20 =20 Eric Rescorla has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/ ------------------------------ ------------------------------ ---------- COMMENT: ------------------------------ ------------------------------ ---------- Rich version of this review at: https://mozphab-ietf. devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deduction of credit from the end user account = when service is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 completed and refunding of reserved credit tha= t is not used. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Diameter Credit-control Server=C2=A0 A Diameter credi= t-control server acts >=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a prepaid server, performing real-time rati= ng and credit- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 control.=C2=A0 It is located in the home domai= n and is accessed by a definition of "home domain" would be useful [yuval] base spec define "home realm" we should probably change to that S 2. >=C2=A0 =C2=A0 =C2=A0 credit-control application. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 When an end user requests services such as SIP or mes= saging, the >=C2=A0 =C2=A0 =C2=A0 request is typically forwarded to a service element (= e.g., SIP Proxy) >=C2=A0 =C2=A0 =C2=A0 in the user's home domain.=C2=A0 In some cases it mig= ht be possible that >=C2=A0 =C2=A0 =C2=A0 the service element in the visited domain can offer s= ervices to the also define visited domain, or at least point to a reference. [yuval] base spec defined "local realm" for that. will fix S 3.1. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CC-Correlation-Id ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ User-Equipment-Info-Extensi= on ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Proxy-Info ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Route-Record ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] Please expand AVP on first use. [yuval] it is in the base spec I'm sure it is, but you should still expand it.=20 [yuval] sure we can (it would be a bit awkward though, in the world of "Dia= meter" it will be like explaining what TCP stands for...) https://tools.ietf.org/ rfcmarkup?doc=3D7322#section-3.6 [yuval] in the list, but not marked as "well known". OTOH, that document gi= ves some freedom to the RFC editor. Given that the first couple of occurren= ces=C2=A0of AVP in the spec are in titles and inside ABNF, there isn't a re= asonable place to expand that. If someone tries to read any Diameter applic= ation spec, without the base one they would probably run into other issues = as well =C2=A0Put it in the glossary at the start. -Ekr S 4. >=C2=A0 =C2=A0 =C2=A0 control client requests credit authorization from the= credit-control >=C2=A0 =C2=A0 =C2=A0 server prior to allowing any service to be delivered = to the end user. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 In the first model, the credit-control server rates t= he request, >=C2=A0 =C2=A0 =C2=A0 reserves a suitable amount of money from the user's a= ccount, and >=C2=A0 =C2=A0 =C2=A0 returns the corresponding amount of credit resources.= =C2=A0 Note that Sorry, reserves the balance or the amount reserved? [yuval] not sure what is not clear? As I said above, do you return the balance or do you return the amount of c= redit that has been reserved. [yuval] return the reserved amount OK, the text should say it. [yuval] ok. will rephrase -Ekr S 14. >=C2=A0=20 >=C2=A0 =C2=A0 =C2=A0 Even without any modification to the messages, an adv= ersary can >=C2=A0 =C2=A0 =C2=A0 eavesdrop on transactions that contain privacy-sensit= ive information >=C2=A0 =C2=A0 =C2=A0 about the user.=C2=A0 Also, by monitoring the credit-= control messages one >=C2=A0 =C2=A0 =C2=A0 can collect information about the credit-control serv= er's billing >=C2=A0 =C2=A0 =C2=A0 models and business relationships. I'm having trouble reading these two paragraphs. Are they about what happens if TLS isn't used? [yuval] will clarify. see here:=C2=A0https://github.com/ lbertz02/rfc4006bi= s/issues/51 This doesn't seem dramatically clearer. What sort of an adversary can do th= at? [yuval] in some cases e2e security is not possible, this is what this secti= on is addressing, the github issue is to clarify that -Ekr ______________________________ _________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/ listinfo/dime =20 =20 =20 =20 ------=_Part_4945944_996791147.1527172638177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ok. will add AVP to section 1.2

=20
=20
On Thursday, May 24, 2018, 5:26:47 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> wrote:



On Thu, May 24, 2018 at 7:12 AM, Y= uval Lifshitz <yuvalif@yahoo.com> wrote:
inline

=20
=20
On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> w= rote:

=

=

=

On Thu, May 24, 2018 at 6:53 AM, Yuval= Lifshitz &l= t;yuvalif@yahoo.com>= ; wrote:
more inline

=20
=20
On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> w= rote:




On Wed, May 23, 20= 18 at 11:33 PM, Yuval Lifshitz <yuvalif@yahoo.com> wrote:
inline

=20
=20
On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric= Rescorla <ekr@rtfm.com> w= rote:


Eric Rescorla has entered the following ballot po= sition for
draft-ietf-dime-rfc4006= bis-08: No Objection

When responding, please keep the subject line = intact and reply to all
email addr= esses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information a= bout IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be f= ound here:



------------------------------ ----------= -------------------- ----------
CO= MMENT:
---------------------------= --- ------------------------------ ----------

Rich version of this = review at:

=
I only gave this a light read. So= me minor comments below.

COMMENTS
S 1.2.
>    =     deduction of credit from the end user account when service i= s
>        = completed and refunding of reserved credit that is not used.
> 
>      Diameter Credit-control Server  A Di= ameter credit-control server acts
= >        as a prepaid server, performing real-time = rating and credit-
>  &nbs= p;     control.  It is located in the home domain and is ac= cessed by

a definition of "home domain" would be useful

[yuval] base spec define "home realm" we = should probably change to that

S 2.
>      credit-control application.
> 
>      When an end user requests services such as SIP = or messaging, the
>   = ;   request is typically forwarded to a service element (e.g., SIP Pro= xy)
>      in th= e user's home domain.  In some cases it might be possible that
>      the service elem= ent in the visited domain can offer services to the

also define vis= ited domain, or at least point to a reference.

[yuval] base spec defined "local realm" for that. will fix=

S 3.1.
>     = ;                     &nb= sp;       [ CC-Correlation-Id ]
>                &= nbsp;                 [ User-Equip= ment-Info ]
>    &nbs= p;                     &n= bsp;       [ User-Equipment-Info-Extension ]
>            &n= bsp;                     = *[ Proxy-Info ]
>    =                      = ;         *[ Route-Record ]
>                &= nbsp;                 *[ AVP ]

Please expand AVP on first use.

[yuval] it is in the base spec

I'm sure it is, but= you should still expand it.

[yuval] sure we can (it would be a bit awkward though, in the world = of "Diameter" it will be like explaining what TCP stands for...)


[yuval] in the list,= but not marked as "well known". OTOH, that document gives some freedom to = the RFC editor. Given that the first couple of occurrences of AVP in t= he spec are in titles and inside ABNF, there isn't a reasonable place to ex= pand that. If someone tries to read any Diameter application spec, without = the base one they would probably run into other issues as well
=
 Put it in the glossary at the start.

-Ekr



=
S 4.
>      control client re= quests credit authorization from the credit-control
>      server prior to allowing any ser= vice to be delivered to the end user.
> 
>   =   In the first model, the credit-control server rates the request,
>      reserves a = suitable amount of money from the user's account, and
>      returns the corresponding amou= nt of credit resources.  Note that

Sorry, reserves the balance= or the amount reserved?

[yuva= l] not sure what is not clear?

As I said above, do you r= eturn the balance or do you return the amount of credit that has been reser= ved.

[yuval] return the= reserved amount

OK, the text should= say it.

=
[yuval] ok. will re= phrase

-Ekr


<= div>


S 14.
> 
>      Even without any modification to the messages,= an adversary can
>   = ;   eavesdrop on transactions that contain privacy-sensitive informati= on
>      about = the user.  Also, by monitoring the credit-control messages one
>      can collect info= rmation about the credit-control server's billing
<= div dir=3D"ltr">>      models and business relationships.=

I'm having trouble reading these two paragraphs. Are they about wh= at
happens if TLS isn't used?

[yuval] will clarify. see here:&nb= sp;https://github.com/ lbert= z02/rfc4006bis/issues/51

This doesn't seem dramatically clearer= . What sort of an adversary can do that?

[yuval] in some cases e2e security is not possible, this = is what this section is addressing, the github issue is to clarify that

-Ekr<= /div>





<= br clear=3D"none">
______________________________ ___= ______________
DiME = mailing list


=

------=_Part_4945944_996791147.1527172638177-- From nobody Thu May 24 11:57:24 2018 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 4FC4012EABE; Thu, 24 May 2018 11:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOMHVKz2fivV; Thu, 24 May 2018 11:57:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1861276AF; Thu, 24 May 2018 11:57:14 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4OIvC0J077610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 May 2018 13:57:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <1C923B71-0BD7-4F8C-BAFF-11E966718756@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A6E750EE-69F8-4B57-B799-A96A60B6CF48"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 24 May 2018 13:57:11 -0500 In-Reply-To: Cc: Yuval Lifshitz , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org To: Eric Rescorla References: <152713326803.29850.11203075814656303164.idtracker@ietfa.amsl.com> <2012436261.4832236.1527143593730@mail.yahoo.com> <1842664888.4936240.1527169987125@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 18:57:16 -0000 --Apple-Mail=_A6E750EE-69F8-4B57-B799-A96A60B6CF48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 24, 2018, at 8:58 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz = wrote: > more inline >=20 > On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla = wrote: >=20 >=20 >=20 >=20 > On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz = wrote: > inline >=20 > On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla = wrote: >=20 >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-dime-rfc4006bis-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however..) >=20 >=20 > Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. = html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/ >=20 >=20 >=20 > ------------------------------ ------------------------------ = ---------- > COMMENT: > ------------------------------ ------------------------------ = ---------- >=20 > Rich version of this review at: > https://mozphab-ietf. devsvcdev.mozaws.net/D3353 >=20 >=20 > I only gave this a light read. Some minor comments below. >=20 > COMMENTS > S 1.2. > > deduction of credit from the end user account when service is > > completed and refunding of reserved credit that is not used. > > > > Diameter Credit-control Server A Diameter credit-control = server acts > > as a prepaid server, performing real-time rating and credit- > > control. It is located in the home domain and is accessed by >=20 > a definition of "home domain" would be useful >=20 > [yuval] base spec define "home realm" we should probably change to = that >=20 > S 2. > > credit-control application. > > > > When an end user requests services such as SIP or messaging, = the > > request is typically forwarded to a service element (e.g., SIP = Proxy) > > in the user's home domain.. In some cases it might be possible = that > > the service element in the visited domain can offer services to = the >=20 > also define visited domain, or at least point to a reference. >=20 > [yuval] base spec defined "local realm" for that. will fix >=20 > S 3.1. > > [ CC-Correlation-Id ] > > [ User-Equipment-Info ] > > [ User-Equipment-Info-Extension ] > > *[ Proxy-Info ] > > *[ Route-Record ] > > *[ AVP ] >=20 > Please expand AVP on first use. >=20 > [yuval] it is in the base spec >=20 > I'm sure it is, but you should still expand it. >=20 > [yuval] sure we can (it would be a bit awkward though, in the world of = "Diameter" it will be like explaining what TCP stands for...) >=20 > https://tools.ietf.org/rfcmarkup?doc=3D7322#section-3.6 Ekr is correct, the Diameter usage of AVP is not marked as = =E2=80=9Csufficiently well-known to not need to expand=E2=80=9D in the = abbreviation registry. Not to mention, many people in the real-time = media community will also think of it as =E2=80=9Caudio-visual profile" >=20 > S 4. > > control client requests credit authorization from the = credit-control > > server prior to allowing any service to be delivered to the end = user. > > > > In the first model, the credit-control server rates the = request, > > reserves a suitable amount of money from the user's account, = and > > returns the corresponding amount of credit resources. Note = that >=20 > Sorry, reserves the balance or the amount reserved? >=20 > [yuval] not sure what is not clear? >=20 > As I said above, do you return the balance or do you return the amount = of credit that has been reserved. >=20 > [yuval] return the reserved amount >=20 > OK, the text should say it. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 > S 14. > > > > Even without any modification to the messages, an adversary can > > eavesdrop on transactions that contain privacy-sensitive = information > > about the user. Also, by monitoring the credit-control = messages one > > can collect information about the credit-control server's = billing > > models and business relationships. >=20 > I'm having trouble reading these two paragraphs. Are they about what > happens if TLS isn't used? >=20 > [yuval] will clarify. see here: https://github.com/ = lbertz02/rfc4006bis/issues/51 >=20 > This doesn't seem dramatically clearer. What sort of an adversary can = do that? >=20 > [yuval] in some cases e2e security is not possible, this is what this = section is addressing, the github issue is to clarify that >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 > ______________________________ _________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/ listinfo/dime >=20 >=20 --Apple-Mail=_A6E750EE-69F8-4B57-B799-A96A60B6CF48 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsHCwcACgkQgFZKbJXz 1A1x4w//bb48FbtyVx3B9EOOAdQpDOed4ShfeprDO+pno6vwmUjqPpp24JXfHlJF bM9br7vtC6LuZYz5aH0fyh4MshJG81RXKWTQ+Fo+40AoGLRYSEl5cBPNVL7nfLXd pm1C7SlQpvADjcXKaUzKBDQVJa4RxmW63lDIE/B0gqvFaoapAybQoSflDDe78AEn T+Ua9RXmsEFP1qVvgknNH37tGvLzH09r6XZb/UOVrzI9kN0B5LPA2Aks8ziZyNyO DsYCFGUg0be8liN+XECd15ykNpKKdy0BW1CJm+NysSmIji7ekW6lAOfc0NcN/VtK 5DV4QzXAQbIhVEusi0u4P6uHIhtR4Ca/b18Yn6IarDWGauXZPhuwJ7MB7V2xuntc I+W0d3/8JRRCf2WnLo7RlQea+neorB1J91qssU7a1hXVILTAMOOE5oqrGhz2Mi1t naZUlDJYVwVXBMr+OkeM+y4lSst9Yuk4YR4aUV3Va58ZrZVNMb2UE+V4HUqpJ7iY UsilOCiO12lhnT8rjuqEcvhBz1TA+RfH+Z6NaM1g8VvUu01481zJ3ss+Kt/65KmI z/9+DCfk0lAha/BuXM2y3f7kBSIbzEVdX+BSsnjeZ/+ULjaHdDpkGg/fw57dNsMR jWBfX/aZpMDAkzA0PNrkGwSAbGQF6fmCGW4by9H87VnQCRhPR1w= =vng3 -----END PGP SIGNATURE----- --Apple-Mail=_A6E750EE-69F8-4B57-B799-A96A60B6CF48-- From nobody Thu May 24 12:17:42 2018 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 7EC3A12946D; Thu, 24 May 2018 12:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivmt5AqSXj-U; Thu, 24 May 2018 12:17:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2EC129502; Thu, 24 May 2018 12:17:36 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4OJHXBU080828 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 May 2018 14:17:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C98424EF-5E35-4EF8-934E-7462DB430444"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 24 May 2018 14:17:31 -0500 In-Reply-To: <20180524131619.GH32807@kduck.kaduk.org> Cc: Spencer Dawkins at IETF , yuvalif=40yahoo.com@dmarc.ietf.org, draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG To: Benjamin Kaduk References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524131619.GH32807@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 19:17:41 -0000 --Apple-Mail=_C98424EF-5E35-4EF8-934E-7462DB430444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 24, 2018, at 8:16 AM, Benjamin Kaduk wrote: >=20 > [trimming some quoted material] > On Thu, May 24, 2018 at 08:01:04AM -0500, Spencer Dawkins at IETF = wrote: >> Keeping in mind that this is Benjamin's ballot thread, so what he = thinks >> matters more than what I think ... >>=20 >> On Thu, May 24, 2018 at 1:20 AM Yuval Lifshitz > 40yahoo.com@dmarc.ietf.org> wrote: >>=20 >>> *inline* >>>=20 >>> On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk < >>> kaduk@mit.edu> wrote: >>>=20 >>>=20 >>> On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: >>>> On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell < >>> ben@nostrum.com> wrote: >>>>=20 >>>>=20 >>>>> On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> With the redirection schemes covered in Section 5.6.2, it sounds >>>>> like the user can be redirected (at the application protocol = level, >>>>> e.g., HTTP or SIP) to a top-up server to purchase more credits. I >>>>> don't see a way described how user agents can distinguish between = a >>>>> Diameter-induced redirect and an attacker-induced redirect to a >>>>> (potentially phishing) site that accepts payment information. To = be >>>>> clear, the scenario here is that a user is using a = credit-controlled >>>>> application session to talk to "arbitrary application servers", >>>>> including potentially attacker-controllled HTTP/SIP/etc. servers; >>>>> the attacker could introduce a redirect to a phishing page that = asks >>>>> for payment information, and the user would be led to believe that >>>>> this was the normal flow for "my prepaid balance has been used = up", >>>>> and give their payment information to the phishing site. I think >>>>> that either user agents need to give some indication that this >>>>> DIAMETER-level redirect is different than an >>>>> application-protocol-level redirect (e.g., http) or the Security >>>>> Considerations need to mention the risk of acclimating users to >>>>> arbitrary websites redirecting to sites asking for payment >>>>> credentials, which may or may not be legitimate sites. >>>>>=20 >>>>=20 >>>> I think it=E2=80=99s reasonable to mention the concern in the = security >>> considerations. But I don=E2=80=99t see how a redirection based on = this >>> specification is any different than any other time an HTTP browser = or SIP >>> UA connects to a resource based on an arbitrary URL. >>>=20 >>> In some sense, it's not. My claim is more that users are being >>> conditioned to expect payment prompts to appear at "arbitrary times" >>> than a specific flaw in this workflow. >>>=20 >>>=20 >>>> But to put some more context around this, the Diameter client is >>> typically a Network Access Server (NAS) that the end user is using = for >>> network access. The user is already at the mercy of that NAS, and = that NAS >>> is at the mercy of the credit-control application server. The = user=E2=80=99s trust >>> in that NAS seems to have the same issues whether or not this = Diameter >>> application is used. >>>>=20 >>>> [yuval] agree with Ben, if someone bad took control over the NAS, = they >>> can do much worse >>>=20 >>> I agree that the NAS could send traffic to "wherever", but my >>> objection could perhaps be categorized as more "social" than >>> "technical". Maybe I should attempt to give an example (and you can >>> point out if I misunderstand things). >>>=20 >>> I believe that a "normal usage" of this technology could be for a >>> user with a prepaid data plan to be using a web browser, and, e.g., >>> connect successfully to https://example.com. Suppose that this >>> request used up their last remaining credits, and they click on a >>> link from that page. Instead of going to the actual target of that >>> link, they are redirected to the data plan owner's top-up page, >>> which displays a message "your balance is zero; please enter credit >>> card information to purchase more data", the user pays, and can >>> potentially even be redirected back to the actual target of the link >>> they clicked on (though that's not key to my example). Let's >>> consider what would happen in an "attack scenario", where the same >>> user has plenty of data quota remaining, and goes to >>> https://honest-achmed.com. They click on a link from that page, >>> which instead of going to an "actual site" that would be expected >>> from the context surrounding the link, actually goes to >>> http://[IP address controlled by attacker]/topup.html, which is >>> designed to look as similar as possible to the actual data plan >>> owner's top-up page. The user may then enter their payment >>> information, and get redirected to a site with actual content, >>> believing that they have obtained more data quota from their >>> provider, when in reality they have given their credit card >>> information to a phisher. >>>=20 >>> I don't see what mechanism is in place to allow the user to be able >>> to distinguish between the "normal usage" scenario and the "attack >>> scenario". I also understand that this sort of technology is >>> already deployed and is seen as useful by both users and data >>> providers, so it seems unrealistic to expect to be able to get rid >>> of this usage entirely. I do think that it is unreasonable for us >>> to enable this behavior without documenting the risks to the user, >>> though. >>>=20 >>> *[yuval] I guess that there is nothing in the spec that technically >>> enables phishing, however, it makes the social engineering part of = it >>> easier. How about the following addition to the security sections:* >>> *"It is RECOMMENDED that operators put in place mechanisms that = would help >>> their subscribers identify a valid redirect operation from a = malicious one"* >>>=20 >>=20 >> I wouldn't dream of saying this is not a good idea, but I do wonder = if this >> is the right document to call attention to that problem. It sure = sounds >> more generic than "topping off my access credit". >=20 > I also am not saying this is not a good idea, but... >=20 >> Are the right people who need to be aware of that problem in order to = fix >> it going to look to this document for guidance? >>=20 >> If the answer is "yes", go for it, but if that advice needs to be = somewhere >> more visible, please do the right thing. >=20 > ... it's unclear to me that this document is the right place for > such guidance. That is, instead of a concrete recommendation, I had > in mind just giving some extra facts that would allow the reader to > consider the security implications of their deployment (this is the > Security Considerations, after all), as in something like: >=20 > This document includes a redirection facility whereby the service > provider can redirect (in an application-specific way) the end user > to an alternate location when their credits have expired. This is > useful in that it allows for the user to return to normal service > quickly, but also exposes additional risks and attack surface. In > particular, this redirection can potentially occur at an > arbitrary point in a user's session, potentially without any > additional contextual confirmation available to the user that the > redirection is driven by the network. Such a confirmation is > important because, in many application protocols, the communication > peer is also capable of inducing redirection, and when the peer is > an attacker, the redirection can be to an attacker-controlled site. > In particular, such sites may be "phishing" sites designed to appear > similar to legitimate payment sites in an attempt to obtain users' > payment information for fraudulent uses. Because of the potentially > harmful consequences of arbitrary redirection by an attacker (such > as to phishing sites), it can be important for users and service > providers to be aware of the risk and take measures to ensure that > sensitive information (such as payment information) is only used for > legitmiate purposes. If an out-of-band signalling channel is > available to provide contextual information that a redirection is > triggered by the network as opposed to a communications peer, that > can provide a highly effective mechanism for remediating this class > of risk. >=20 > (The above may well be too wordy and could benefit from editing, of > course.) Based on our discussion on the telechat, how about something like the = following? "This document includes a redirection facility whereby the service provider can redirect (in an application-specific way) the end user to an alternate location when their credits have expired. This is useful in that it allows for the user to return to normal service quickly, but also exposes additional risks and attack surface. In particular, this redirection can potentially occur at an arbitrary point in a user's session, potentially without any additional contextual confirmation available to the user that the redirection is driven by the network. This lack of confirmation matters because, in many application protocols, the communication peer is also capable of inducing redirection. When the peer is an attacker, the redirection can be to an attacker-controlled site. In particular, such sites may be "phishing" sites designed to appear similar to legitimate payment sites in an attempt to obtain users' payment information for fraudulent uses. When users become used to such redirection, they may have difficulty distinguishing such attacks from legitimate redirections. Because of the potentially harmful consequences of arbitrary redirection by an attacker (such as to phishing sites), it can be important for users and service providers to be aware of the risk and take measures to ensure that sensitive information (such as payment information) is only used for legitmiate purposes. Operators should follow industry best practices for the specific application layer protocol to reduce the chances that such attacks could be mistaken for legitimate redirection. The details of such practice are out of scope for this document." >=20 > -Benjamin >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_C98424EF-5E35-4EF8-934E-7462DB430444 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsHD8sACgkQgFZKbJXz 1A2Qig//eOuJmDHI5WVriZr6fnw48Y/eG+hI2WEf7YmwGprwW4KGrLIiF6xEhawm HxjXbnpZR0e1HCPNPOJHKZzzcEmMQ1r89TJ1HswydA4+loV0KSJ/RwDBT9zgNy1t EnoWEALOpiBXp9SFOxFa7PhcqYECP5zhJE03Aumhe+6jZvp7TcQ2VNLbt+6Htf4g W1mHDrXlB9KDF6RPgnf2nfs6vvikSr9CyhW+TgU+njXgA9gvebl7/DCfNH20czPb TMjIROnfQS54L7JVXl97nB5k4gia9ioGI/CGSe0VNUN6TLmLGk6rUxuvwUOov6FJ tFiuJjAEM15wDrZXogBFXoNoqQijmCjb4tgUOq2vszO8S1UgdwYjVT9o05nOviHz 1+l2T4Tdn/tIYZd1dvhzW0NMVCzYGlhWmgAJrytsNzFoHyipmu8wi12CgCMO2LtL bT+6B4LAQEoCHxBh8yiuAhRgYsy1V0JdG7Eq22euItlEpqXXI8Xo9tW74qJyhFQl C0jJaOp9AJDMJwDKP7iRcF6FSlvXlMaeFbBllINspxRNd29Vrv6vrIBJpiS40m1Z d4D581ytYdjjPJj6qIAOBswSdYeZ8bLw5QruAKyZVuTI25yJuHZAQ86IqYlD5XSw 1iXmclspplhfgtm/i8Rpu3GyiGy5gqwf3UeHjtFKGiy1r7Agn/g= =x/dq -----END PGP SIGNATURE----- --Apple-Mail=_C98424EF-5E35-4EF8-934E-7462DB430444-- From nobody Thu May 24 12:24:18 2018 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 77947129BBF; Thu, 24 May 2018 12:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjwtMLWaCo2T; Thu, 24 May 2018 12:24:14 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366F1127869; Thu, 24 May 2018 12:24:14 -0700 (PDT) X-AuditID: 12074423-6abff700000069f1-26-5b07115c31e9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 58.D6.27121.C51170B5; Thu, 24 May 2018 15:24:12 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w4OJOAuR010972; Thu, 24 May 2018 15:24:10 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4OJO1eJ013462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 May 2018 15:24:05 -0400 Date: Thu, 24 May 2018 14:24:01 -0500 From: Benjamin Kaduk To: Ben Campbell Cc: Spencer Dawkins at IETF , yuvalif=40yahoo.com@dmarc.ietf.org, draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG Message-ID: <20180524192400.GL32807@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524131619.GH32807@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKKsWRmVeSWpSXmKPExsUixCmqrBsjyB5tcGifjMX8ztPsFmsPplnM 7V3BZrFk4gRWixl/JjJbLJuyh9micfVPFgd2jxPLrrB67Jx1l91jyZKfTB6zdj5hCWCJ4rJJ Sc3JLEst0rdL4MrYNvkOc8FNzYprBxewNTDeUupi5OCQEDCReP0nuouRi0NIYDGTxPUbt5kh nI2MEj/P97NAOFeZJFa+XQuU4eRgEVCVeHT+HSOIzSagItHQfRksLiKgJPG8eStYA7PALUaJ jvt/wRLCAtkSnyZMYAOxeYHWnVrRBbViD7PE2+8XGCESghInZz5hAbGZBcokLmzrYQa5j1lA WmL5Pw6QMKeAvcSZ5S2sILaogLLE3r5D7BMYBWYh6Z6FpHsWQjdEWEvixr+XTBjC2hLLFr5m hrBtJdate8+ygJF9FaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRlAssbso72B8 2ed9iFGAg1GJh3fDAbZoIdbEsuLK3EOMkhxMSqK8a/8BhfiS8lMqMxKLM+KLSnNSiw8xqgDt erRh9QVGKZa8/LxUJRHe7l9AdbwpiZVVqUX5MGXSHCxK4rw5ixijhQTSE0tSs1NTC1KLYLIy HBxKErzyAuzRQoJFqempFWmZOSUIaSYOzkOMEhw8QMPngtTwFhck5hZnpkPkTzHqcnS8n9LD LAR2gZQ4bytIkQBIUUZpHtwcUGqUyN5f84pRHOhFYd61IFU8wLQKN+kV0BImoCUXlzODLClJ REhJNTDmV7+f+zX9t7nnwnfXG+ur2NkmeW1/0iiZHn/7/ZW++tK1291O1Z3LucvHk5aeGx2+ 56lU/BdLifnnE0v51+969Er+uMMGRW4D1mt3Rer990mUmmbN73zRyz8rg6HsPNftTY+y4ja0 XZv4qVJEetnGGHnNwwz9Exg1S24++9bMsjFOYeLnQ55KLMUZiYZazEXFiQBPvZhPaAMAAA== Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 19:24:17 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 24, 2018 at 02:17:31PM -0500, Ben Campbell wrote: >=20 >=20 > > On May 24, 2018, at 8:16 AM, Benjamin Kaduk wrote: > >=20 > > ... it's unclear to me that this document is the right place for > > such guidance. That is, instead of a concrete recommendation, I had > > in mind just giving some extra facts that would allow the reader to > > consider the security implications of their deployment (this is the > > Security Considerations, after all), as in something like: > >=20 > > This document includes a redirection facility whereby the service > > provider can redirect (in an application-specific way) the end user > > to an alternate location when their credits have expired. This is > > useful in that it allows for the user to return to normal service > > quickly, but also exposes additional risks and attack surface. In > > particular, this redirection can potentially occur at an > > arbitrary point in a user's session, potentially without any > > additional contextual confirmation available to the user that the > > redirection is driven by the network. Such a confirmation is > > important because, in many application protocols, the communication > > peer is also capable of inducing redirection, and when the peer is > > an attacker, the redirection can be to an attacker-controlled site. > > In particular, such sites may be "phishing" sites designed to appear > > similar to legitimate payment sites in an attempt to obtain users' > > payment information for fraudulent uses. Because of the potentially > > harmful consequences of arbitrary redirection by an attacker (such > > as to phishing sites), it can be important for users and service > > providers to be aware of the risk and take measures to ensure that > > sensitive information (such as payment information) is only used for > > legitmiate purposes. If an out-of-band signalling channel is > > available to provide contextual information that a redirection is > > triggered by the network as opposed to a communications peer, that > > can provide a highly effective mechanism for remediating this class > > of risk. > >=20 > > (The above may well be too wordy and could benefit from editing, of > > course.) >=20 > Based on our discussion on the telechat, how about something like the fol= lowing? >=20 > "This document includes a redirection facility whereby the service > provider can redirect (in an application-specific way) the end user > to an alternate location when their credits have expired. This is > useful in that it allows for the user to return to normal service > quickly, but also exposes additional risks and attack surface. In > particular, this redirection can potentially occur at an > arbitrary point in a user's session, potentially without any > additional contextual confirmation available to the user that the > redirection is driven by the network. This lack of confirmation matters > because, in many application protocols, the communication > peer is also capable of inducing redirection. When the peer is > an attacker, the redirection can be to an attacker-controlled site. > In particular, such sites may be "phishing" sites designed to appear > similar to legitimate payment sites in an attempt to obtain users' > payment information for fraudulent uses. When users become used > to such redirection, they may have difficulty distinguishing such "such" might be ambiguous here; maybe "network-induced" or "network-driven"? > attacks from legitimate redirections. >=20 > Because of the potentially > harmful consequences of arbitrary redirection by an attacker (such > as to phishing sites), it can be important for users and service > providers to be aware of the risk and take measures to ensure that > sensitive information (such as payment information) is only used for > legitmiate purposes. Operators should follow industry best practices I see my typo for "legitimate" is preserved :) > for the specific application layer protocol to reduce the chances that > such attacks could be mistaken for legitimate redirection. The details > of such practice are out of scope for this document." The above nitpicking aside, I think this text suffices to resolve my DISCUSS point. (And I guess we're going with removing "instead of" to resolve the other one?) -Benjamin --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlsHEUYACgkQKNmm82Tr dRLTPAwfaSxPys1lNX2tc8ZjJS2df5M12HcygXMIMbGZNWtzYTaZ5On856dnejAy MSGjNNpyXRmco/Ed63qvVAss/Itrg/cXnXu4rpemId3NEF9x9PK3EMnJx1HK/SWh sd2SSESooLZShh9qcUdRdPcatohn8Nvvzs7J8JXO7cMhmx6a53gCbA3Bdg7lD7N5 fLaxTmkjMonGfal2joQVPp74MeyIzL6X7R5lqU1oJ/B3rFbZ50Jq6VD99AhYBhRi 3dSB6R5MMs4UArFiU2XWeyywS7F6vT57odp8xwqI9kvTgBbz0pvrEqggKD0exV7F 5XwJDaxnQfk51oOnDoG50SEYYlrXvpFXepXR86HgaQ00UXt6e7LKagDUUT+7VRQ8 rvYG1F1qHstoFeOLZv++E2uJ0H4lgsnYRaL+wnLQqsshzLwqpswd8f1l1vjEVvsx eJg9oESLB0R9/qKgOUGRM5jMvieGp0X/sLzlT8u7tA/+uF5p9qMpvczYP1JFl2+T 4B58lGBhNOXGkQ== =UiLk -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From nobody Thu May 24 12:29:38 2018 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 A414112E8C7; Thu, 24 May 2018 12:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMxLRm4nwTVL; Thu, 24 May 2018 12:29:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DA712EB0B; Thu, 24 May 2018 12:29:26 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4OJTNd0082711 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 May 2018 14:29:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8E437D6E-E5E3-4CCA-9BDB-50FC16CDC3AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 24 May 2018 14:29:22 -0500 In-Reply-To: <20180524192400.GL32807@kduck.kaduk.org> Cc: Spencer Dawkins at IETF , yuvalif=40yahoo.com@dmarc.ietf.org, draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org, IESG To: Benjamin Kaduk References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524131619.GH32807@kduck.kaduk.org> <20180524192400.GL32807@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 19:29:31 -0000 --Apple-Mail=_8E437D6E-E5E3-4CCA-9BDB-50FC16CDC3AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 24, 2018, at 2:24 PM, Benjamin Kaduk wrote: >=20 > On Thu, May 24, 2018 at 02:17:31PM -0500, Ben Campbell wrote: >>=20 >>=20 >>> On May 24, 2018, at 8:16 AM, Benjamin Kaduk wrote: >>>=20 >>> ... it's unclear to me that this document is the right place for >>> such guidance. That is, instead of a concrete recommendation, I had >>> in mind just giving some extra facts that would allow the reader to >>> consider the security implications of their deployment (this is the >>> Security Considerations, after all), as in something like: >>>=20 >>> This document includes a redirection facility whereby the service >>> provider can redirect (in an application-specific way) the end user >>> to an alternate location when their credits have expired. This is >>> useful in that it allows for the user to return to normal service >>> quickly, but also exposes additional risks and attack surface. In >>> particular, this redirection can potentially occur at an >>> arbitrary point in a user's session, potentially without any >>> additional contextual confirmation available to the user that the >>> redirection is driven by the network. Such a confirmation is >>> important because, in many application protocols, the communication >>> peer is also capable of inducing redirection, and when the peer is >>> an attacker, the redirection can be to an attacker-controlled site. >>> In particular, such sites may be "phishing" sites designed to appear >>> similar to legitimate payment sites in an attempt to obtain users' >>> payment information for fraudulent uses. Because of the potentially >>> harmful consequences of arbitrary redirection by an attacker (such >>> as to phishing sites), it can be important for users and service >>> providers to be aware of the risk and take measures to ensure that >>> sensitive information (such as payment information) is only used for >>> legitmiate purposes. If an out-of-band signalling channel is >>> available to provide contextual information that a redirection is >>> triggered by the network as opposed to a communications peer, that >>> can provide a highly effective mechanism for remediating this class >>> of risk. >>>=20 >>> (The above may well be too wordy and could benefit from editing, of >>> course.) >>=20 >> Based on our discussion on the telechat, how about something like the = following? >>=20 >> "This document includes a redirection facility whereby the service >> provider can redirect (in an application-specific way) the end user >> to an alternate location when their credits have expired. This is >> useful in that it allows for the user to return to normal service >> quickly, but also exposes additional risks and attack surface. In >> particular, this redirection can potentially occur at an >> arbitrary point in a user's session, potentially without any >> additional contextual confirmation available to the user that the >> redirection is driven by the network. This lack of confirmation = matters >> because, in many application protocols, the communication >> peer is also capable of inducing redirection. When the peer is >> an attacker, the redirection can be to an attacker-controlled site. >> In particular, such sites may be "phishing" sites designed to appear >> similar to legitimate payment sites in an attempt to obtain users' >> payment information for fraudulent uses. When users become used >> to such redirection, they may have difficulty distinguishing such >=20 > "such" might be ambiguous here; maybe "network-induced" or > "network-driven=E2=80=9D? Good point. >=20 >> attacks from legitimate redirections. >>=20 >> Because of the potentially >> harmful consequences of arbitrary redirection by an attacker (such >> as to phishing sites), it can be important for users and service >> providers to be aware of the risk and take measures to ensure that >> sensitive information (such as payment information) is only used for >> legitmiate purposes. Operators should follow industry best practices >=20 > I see my typo for "legitimate" is preserved :) >=20 >> for the specific application layer protocol to reduce the chances = that >> such attacks could be mistaken for legitimate redirection. The = details >> of such practice are out of scope for this document." >=20 > The above nitpicking aside, I think this text suffices to resolve my > DISCUSS point. > (And I guess we're going with removing "instead of" > to resolve the other one?) That is my understanding. But in both cases, I suggest holding your = DISCUSS until the updates show up in a revised draft. Thanks! Ben. --Apple-Mail=_8E437D6E-E5E3-4CCA-9BDB-50FC16CDC3AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsHEpIACgkQgFZKbJXz 1A1scA/+KrL48DV9+5XrmmrRPed8JnbMFVO3VLq7F8QCn8VvP80bOMeZIlcF7thj zFMugCDfdG6FKAYK4kvrRwOCqYVcx+g6bl2Sq3cw65TAmt8XziPgHzE+woeBK4/4 SBDcsfk6BrDWYuNAFv0Nr0Xz2KQrTbmXdw4pRPe2rjuLY0my9J5H2EAh/kAQzjys 45KKdq6BbJ7dCiHNSV2f/XedUDONO7r3/st+XNSr/WaOmZw4zxgOE8CiTfVPZHIA 5Ii49Ha1hULR3ubcjwrCqjdZ9JLWPTQ2hBoBzwJr91bBEvdeOoEQDcq7wWgjNqht 7oSAkdQIm/AcnADqJJwStDcRFOuMX3SiqnZENnWaNOcfCS4Q1n4InZALly/tSYB2 iPLL9c0jjvh/X77dwkuUqaGg5jr+ZfA1OtKMDCKnYvNMsiHluvAftWrILf1jOSEC t3zB9ZLhTHdZEopViTpsPm/kIXYIdNSfjMqrjv2BwIFGL+l0qQp3U6PxB4awLBf2 4fIv2j5xp/MFNM4rOqHDtpW4iWnEeYWXoSX5u0YXeL1B4vn4l444t1ISfEvv6QD9 3Kn+0OHWMz9ubfi/b4/nrExcY4qFNmadQXBbZDvlrzc9QukcEMpxXVMC8sbr8joa JzX7WicEY+5TRVlF9PJReg2OwCqN5ZCejPxJqKXY6Lnzlt747hE= =iglp -----END PGP SIGNATURE----- --Apple-Mail=_8E437D6E-E5E3-4CCA-9BDB-50FC16CDC3AA-- From nobody Thu May 24 14:27:56 2018 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 D91C912D7E4; Thu, 24 May 2018 14:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18Cwzd6Qw84G; Thu, 24 May 2018 14:27:51 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB13127873; Thu, 24 May 2018 14:27:50 -0700 (PDT) X-AuditID: 1209190d-e0bff70000006054-cb-5b072e55d7fd Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 46.54.24660.55E270B5; Thu, 24 May 2018 17:27:49 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w4OLRkxj028271; Thu, 24 May 2018 17:27:47 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4OLRfQ9022225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 May 2018 17:27:44 -0400 Date: Thu, 24 May 2018 16:27:42 -0500 From: Benjamin Kaduk To: Yuval Lifshitz Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <20180524212739.GP32807@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1467920717.4840713.1527142671894@mail.yahoo.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrBuqxx5tsKdNw2J+52l2i7UH0yzm 9q5gs1gycQKrxYw/E5ktjn97yO7A5rFkyU8mj1k7n7B4zJp1mCmAOYrLJiU1J7MstUjfLoEr Y1X7CeaCQ+sYKzreb2BqYOzqYOxi5OSQEDCROPn6BnsXIxeHkMBiJomzrU0sEM5GRol7b9dD OVeZJCasuMTWxcjBwSKgKnH+QRpIN5uAikRD92VmEFtEQE3iceMNNpB6ZoF+RonrZ8+DJYQF siU+TZjABmLzAq1bsuQSE8TQqUwSd5b/ZIJICEqcnPmEBcRmFlCX+DPvEjPIMmYBaYnl/zgg wvISzVtng83kFLCT+Np8CaxVVEBZYm/fIfYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXSC83s0QvNaV0EyM4GiR5dzD+u+t1iFGAg1GJh5fjMFu0EGtiWXFl 7iFGSQ4mJVHetf+AQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4u38B5XhTEiurUovyYVLSHCxK 4rzZixijhQTSE0tSs1NTC1KLYLIyHBxKErwhuuzRQoJFqempFWmZOSUIaSYOTpDhPEDDXUBq eIsLEnOLM9Mh8qcYdTk63k/pYRZiycvPS5US5z2mA1QkAFKUUZoHNweUxCSy99e8YhQHekuY dzHIKB5gAoSb9ApoCRPQkovLmUGWlCQipKQaGO+0zzgfVOJcqLNywpStC2xCeNlVD/bq3f3T PyPO+lTcgurjAgZnu7K/9j1fq1C/5uxiu6JrM19L/Ev8sIjp/fxt8sxLq5WvPn+5JiLyb2S9 9uXFD5U+2Lh90IxovO508O0cho8lszskzlUeiAs+qcGW6hSw43zvMwb9vVMPThE0Np1ukm+6 JFuJpTgj0VCLuag4EQDRd3ELPQMAAA== Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 24 May 2018 21:27:55 -0000 Catching up on the non-redirect items... On Thu, May 24, 2018 at 06:17:51AM +0000, Yuval Lifshitz wrote: > inline > On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk wrote: > > [re-sending since my client crashed during the first attempt and I > don't see the message in the archives.  I attempted to reconstruct > my message from a scrollback buffer, but there may be some artifacts > with missing or duplicated text] > > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > >  Thanks Ben and Benjamin! Comments inline > >    On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell wrote: > > > >  Hi Benjamin, > > > > I’ve cherry-picked a few points, inline: > > > > Thanks! > > > > Ben. > > > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > > > I appear to have a different understanding of Section 5.6.2, though, > > > with a different potential issue (but again, it's possible that I'm > > > confused to how things work): > > > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > > like the user can be redirected (at the application protocol level, > > > e.g., HTTP or SIP) to a top-up server to purchase more credits.  I > > > don't see a way described how user agents can distinguish between a > > > Diameter-induced redirect and an attacker-induced redirect to a > > > (potentially phishing) site that accepts payment information.  To be > > > clear, the scenario here is that a user is using a credit-controlled > > > application session to talk to "arbitrary application servers", > > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > > the attacker could introduce a redirect to a phishing page that asks > > > for payment information, and the user would be led to believe that > > > this was the normal flow for "my prepaid balance has been used up", > > > and give their payment information to the phishing site. I think > > > that either user agents need to give some indication that this > > > DIAMETER-level redirect is different than an > > > application-protocol-level redirect (e.g., http) or the Security > > > Considerations need to mention the risk of acclimating users to > > > arbitrary websites redirecting to sites asking for payment > > > credentials, which may or may not be legitimate sites. > > > > > > > I think it’s reasonable to mention the concern in the security considerations. But I don’t see how a redirection based on this specification is any different than any other time an HTTP browser or SIP UA connects to a resource based on an arbitrary URL. > > In some sense, it's not.  My claim is more that users are being > conditioned to expect payment prompts to appear at "arbitrary times" > than a specific flaw in this workflow. > > > > But to put some more context around this, the Diameter client is typically a Network Access Server (NAS) that the end user is using for network access. The user is already at the mercy of that NAS, and that NAS is at the mercy of the credit-control application server. The user’s trust in that NAS seems to have the same issues whether or not this Diameter application is used. > > > > [yuval] agree with Ben, if someone bad took control over the NAS, they can do much worse > > I agree that the NAS could send traffic to "wherever", but my > objection could perhaps be categorized as more "social" than > "technical".  Maybe I should attempt to give an example (and you can > point out if I misunderstand things). > > I believe that a "normal usage" of this technology could be for a > user with a prepaid data plan to be using a web browser, and, e.g., > connect successfully to https://example.com. Suppose that this > request used up their last remaining credits, and they click on a > link from that page.  Instead of going to the actual target of that > link, they are redirected to the data plan owner's top-up page, > which displays a message "your balance is zero; please enter credit > card information to purchase more data", the user pays, and can > potentially even be redirected back to the actual target of the link > they clicked on (though that's not key to my example).  Let's > consider what would happen in an "attack scenario", where the same > user has plenty of data quota remaining, and goes to > https://honest-achmed.com. They click on a link from that page, > which instead of going to an "actual site" that would be expected > from the context surrounding the link, actually goes to > http://[IP address controlled by attacker]/topup.html, which is > designed to look as similar as possible to the actual data plan > owner's top-up page.  The user may then enter their payment > information, and get redirected to a site with actual content, > believing that they have obtained more data quota from their > provider, when in reality they have given their credit card > information to a phisher. > > I don't see what mechanism is in place to allow the user to be able > to distinguish between the "normal usage" scenario and the "attack > scenario".  I also understand that this sort of technology is > already deployed and is seen as useful by both users and data > providers, so it seems unrealistic to expect to be able to get rid > of this usage entirely.  I do think that it is unreasonable for us > to enable this behavior without documenting the risks to the user, > though. > > [yuval] I guess that there is nothing in the spec that technically enables phishing, however, it makes the social engineering part of it easier. How about the following addition to the security sections:"It is RECOMMENDED that operators put in place mechanisms that would help their subscribers identify a valid redirect operation from a malicious one" > > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > > > >  If the Final-Unit-Action AVP is set to REDIRECT at least the > > >  Redirect-Server-Extension AVP MUST be present. > > > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > > section 8.64 even internally inconsistent, too?) about > > > "Redirect-Server AVP, in addition to or instead of the > > > Redirect-Server-Extension AVP", in particular, the "instead of" > > > portion.  (The ABNF-based formal language spec in 8.68 does match up > > > with the above MUST, though.) > > > > Would changing “in addition to or instead of” in 8.64 to just “in addition to” help? > > > > Authors: Please comment if that works, given the backwards-compatibility concern. > > [yuval] the cumbersome text is because of backward compatibility issue. Would appriciate suggestion for better phrasing. The idea is the following:* We have an existing AVP that can carry some information* We need more information, but we cannot modify the existing one, so we added a new AVP (which, unlike the old one, is future proof)* If you have a peer that does not support the new spec, but only need the old info, you can use the old AVP. what makes the spec backward compatible to the old one* If you have need to send the new info, you have to use the new AVP, but in this case an older peer does not make sense > > To Ben, I believe that just "in addition to" resolves the internal > inconsistency.  However, it sounds like that may not be the best > solution from a deployment perspective, and perhaps the formal > definition in Section 8.68 (and the body text) should be relaxed to > allow either the -Extension or non-Extension form. > [yuval] will remove "instead of" I guess my first response did not adequately respond to your request for better phrasing. Unfortunately, I don't think just different phrasing would suffice if we want to retain the ability to use just the legacy AVP. (If we don't want to retain that ability, then removing the "instead of" is the right thing to do.) To regain the ability to just use Redirect-Server without Redirect-Server-Extension, the text in section 8.68 would need to have OLD: If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server-Extension AVP MUST be present. The Filter-Rule AVP NEW: If the Final-Unit-Action AVP is set to REDIRECT, at least one of the Redirect-Server and Redirect-Server-Extension AVPs MUST be present. The Filter-Rule AVP And probably also to change the formal syntax (though I guess technically it is not necessary, it would be misleading to leave it as-is): OLD: QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > { Final-Unit-Action } *[ Filter-Rule ] *[ Filter-Id ] [ Redirect-Server-Extension ] *[ AVP ] NEW: QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > { Final-Unit-Action } *[ Filter-Rule ] *[ Filter-Id ] [ Redirect-Server ] [ Redirect-Server-Extension ] *[ AVP ] (Am I reading RFC 6733 correctly that the ABNF '/' operator is not used in CCF?) > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Some additional significant but not necessarily DISCUSS-worthy > > > comments, followed by more editorial- and nit-level things. > > > > > > In Section 1.3, "Advertising Application Support" uses the same > > > Auth-Application-ID value as for RFC 4006; what are the interop > > > consequences of this? > > > [yuval] this was done to make interops easier - this is why we kept this RFC backward compatible with RFC4006 > > > Alissa already noted that the text about how to split (sub-)AVPs > > > between the foo and foo-Extension AVPs is inconsistent among them -- > > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > > send [in the old one]", but Subscription-Id-Extension has separate > > > text about "[i]f full backward compatibility with [RFC4006] is > > > required" and slightly different behavior described.  We should try > > > to catch all instances of this sort of backwards compatibility and > > > make them consistent. > > > > I agree. > > [yuval] will look to unify the text > > I see that there was some discussion on Alissa's ballot thread that > there may indeed be special considerations for one AVP.  If so, > that's fine, but the reasoning should probably be included in the > document to explain the apparent disparity. > > [yuval] ok > > > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > > > might benefit from additional text about the expected contents.  A > > > lot of the time when we use a UTF8 container for names (whether > > > domain names or other kinds), we specify what normalization form and > > > canonicalization are performed, whether domain names are A-labels or > > > U-labels, etc., as there's a lot of potential flexibility not all of > > > which is good.  In this case, since the communication is only > > > between trusted actors, perhaps the additional restrictions are not > > > needed, but I am curious if the topic was raised in the WG. > > > > On reflection, shouldn’t that be based on whatever rules already exist for the URL scheme? And if some scheme doesn’t have well defined behavior for non-ascii labels, is that the concern of this application? > > It is probably a matter for the URL scheme, yes.  So at most we > could note here that "individual URL schemes may restrict the > contents of the UTF8String", but as I imply in my original comment, > it's far from clear to me that we actually need to say anything in > this specific case. > > > > > > > Thank you for adding the Privacy Considerations and list of > > > Privacy-Sensitive AVPs! > > > > > > Section 14 > > > > > >  [...] The Diameter credit- > > >  control application is often used within one domain, and there may be > > >  a single hop between the peers.  In these environments, the use of > > >  TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > > > I did not see any concrete guidance on what would suffice in other > > > environments (with multiple hops between peers).  Is this the realm > > > of the mythical "end-to-end security mechanism" for Diameter that is > > > much-desired?  (The last paragraph does have guidance on what might > > > *not* suffice, which is not exactly the same thing.) > > > > > > > Sort of, but in real world deployments the “often used within one domain” (assuming domain means “trust domain”, which should be clarified) effectively overrides everything else. That is far from ideal, but it’s the reality. So it basically comes down to keep everything in the trust domain, or if you cross a non-trusted network then use TLS or IPSec. > > > > There’s no solution to safely traverse a non-trusted Diameter agent. The mythical e2e mechanism could conceivably give us that.  (someday, along with world peace and a post-scarcity economy). > > > > [yuval] as Ben and Lyle wrote, if your messages need to go through agents that belong to a 3rd party, you have risks. In this case, AVP level encryption (which is not standardized yet...) is the only option for to ensure privacy. So, the only thing we can do here is to highlight the risks.  > > Do we want to say something about "at present, there is not a > general reliable security solution for other environments"?  (To be > clear, I do not insiste that we do so.) > > [yuval] not sure if AVP level ancryption would ever happen... would keep text as is > > > >  Even without any modification to the messages, an adversary can > > >  eavesdrop on transactions that contain privacy-sensitive information > > >  about the user. > > > > > > This ("an adversary can") makes it sounds as if there is no > > > confidentiality protection anywhere in the system, but that's what > > > TLS/DTLS/IPSec are supposed to provide.  So maybe "an adversary that > > > can eavesdrop on transactions can obtain privacy-sensitive > > > information [...]" is better. > > > > > > > Good point, I agree your suggestion is better.[yuval] ok > > > > > (Editorial- and nit-level stuff follows.) > > > > > > Section 4 > > > > > >  A flexible credit-control application specific failure handling is > > >  defined in which the home service provider can model the credit- > > >  control client behavior according to its own credit risk management > > >  policy. > > > > > > This sentence is hard to parse -- in "credit-control application > > > specific" what does "specific" bind to?  What is being modelled?  Is > > > anything being controlled (as opposed to modelled)? > > [yuval] ok. so how about: > > "Flexible failure handling, specific to the credit-control, is defined in the application.This allows the the service provider to control the credit-control client behavior according to its ownrisk management policy" > > That's much better; thanks! > > > > Section 4.1.1 > > > > > >  2.  The Service-Parameter-Info AVP MAY be used as a container to pass > > >  legacy rating information in its original encoded form (e.g., ASN.1 > > >  BER).  [...] > > > > > > Why BER and not DER?  The unnecessary flexibility in BER vs. DER has > > > been known to tickle parser bugs and create security > > > vulnerabilities. > > >  > > [yuval] this is just an example of legacy stuff you have no control over > > > > > Section 4.1.2 > > > > > >  [...] To > > >  facilitate interoperability, it is RECOMMENDED that the rating input > > >  and the values of the Service-Context-Id be coordinated via an > > >  informational RFC or other permanent and readily available reference. > > >  The specification of another cooperative standardization body (e.g., > > >  3GPP, OMA, or 3GPP2) SHOULD be used. > > > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > > >  > > [yuval] yes, seems a bit awkward. How about: > > "To facilitate interoperability, it is RECOMMENDED that the rating input > > and the values of the Service-Context-Id be coordinated via an > > informational RFC or other permanent and readily available reference, > > preferably, of another cooperative standardization body (e.g., > >  3GPP, OMA, or 3GPP2)." > > Sounds good. > > > > Section 5.1.1 > > > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > > seems that this text could be reworded to just talk about a > > > "constant rate" or "constant level per fixed time period" or > > > similar. > > >  > > [yuval] "constant rate" could mean sub-second resolution as well. The grants are in seconds, so, IMO, this phrasing is more accurate > > It seems that it's only more accurate if leap seconds are ignored. > (I suppose you could explicitly disclaim "(ignoring leap seconds)" > or similar.) > > [yuval] will add > > > > Section 5.1.2 > > > > > >  [...] > > >  timer (Section 13) every time a CCR message with the value > > >  UPDATE_REQUEST is sent while they are in PendingU state.  When > > >  answers to all pending messages are received, the state machine moves > > >  to OPEN state, and Tx is stopped. > > > > > > Transmission, or the Tx timer (is stopped)? > > >  > > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense of "transmission" in the RFC > > (I think that "Tx timer" was fairly consistently used throughout the > rest of the document; it may make sense to be fully consistent about > it.) > > [yuval] will fix in the doc > > > > Using a different title for Section 5.2.2 might make the parallel > > > between it and Section 5.2.1 more clear.  That is, perhaps something > > > like "First Interrogation Included with Authorization Messages". > > >  > > [yuval] make sense > > > > > Section 5.7 > > > > > >  [...] It is RECOMMENDED that the client complement the credit- > > >  control failure procedures with backup accounting flow toward an > > >  accounting server. [...] > > > > > > Nit: it looks like there's a missing article here, maybe "a backup > > > accounting flow" is better. > > >  > > [yuval] the rest of the paragraph describe such "backup accounting flow". See what comes after "For example" > > I just meant that it sounds like you need to add the word "a" in > order for the grammar to make sense.  (But perhaps "the" is the > right word; I wasn't sure.) > > [yuval] ok > > >  The AAA transport profile [RFC3539] defines the application layer > > >  watchdog algorithm that enables failover from a peer that has failed > > >  and is controlled by a watchdog timer (Tw) defined in [RFC3539]. > > > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > > >  > > [yuval] would imagine there are other algorithms out there... should fix > > > > > Section 6.2 > > > > > > Should there be text indicating how the client indicates what > > > service the balance check is being requested for? > > >  > > [yuval] didn't find any reference to service information for "EVET_REQUEST" type messages (direct debit, refund, balance check and price enquiry). Seems like that in the IEC section of 3GPP TS 32.299, they added their own mechanism for "direct debit", and "refund", and leave "balance check" and "price enquiry" as references to RFC4006. Unless I've missed something, this seems like a missing part of the spec. > > > [yuval] hmm. seems like "event requests" should be looked at (probably at the light of 3GPP 32.299 IEC concept). But for sure *not* as part of this work. I was mostly wondering whether this section should say anything about including the Service-Identifier AVP. Looking back at the document now, though, maybe this question does not actually make sense. -Benjamin > > > Section 8.54 > > > > > > Maybe give a section reference in RFC 3580 for how the formatting is > > > done? > > >  > > [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 in our RFC > > > > > Section 12 > > > > > >  [...] Initially, such Expert discussions take place on the AAA > > >  WG mailing list. > > > > > > That list appears to be dead, suggesting that this text should be > > > updated.  (I also agree with Adam's comments about updating the IANA Considerations.) > > >  > > [yuval] i don't know the process here - not sure how to change it. > > With respect to the "expert discussions take place" text, I think it > could just be removed. > > Discussion of the detailed updates to the IANA actions should > probably happen in Adam's ballot thread. > > > > Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3? > > [yuval] should be added there as well > > Great, thanks. > > > -Benjamin > > > | > | > | | > Example Domain > > > | > > | > > | > > > > From nobody Fri May 25 08:17:22 2018 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 488391200C5; Fri, 25 May 2018 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejcDW2NLsKUu; Fri, 25 May 2018 08:17:16 -0700 (PDT) Received: from mailport7.csra.com (mailport7.csra.com [131.131.83.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F5E127137; Fri, 25 May 2018 08:17:15 -0700 (PDT) Received: from csrrdu1exm027.corp.csra.com (HELO mail.csra.com) ([10.176.90.37]) by mailport7.csra.com with ESMTP/TLS/AES256-SHA; 25 May 2018 11:17:13 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.176.90.35) by CSRRDU1EXM026.corp.csra.com (10.176.90.36) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 25 May 2018 11:17:12 -0400 Received: from CSRRDU1EXM025.corp.csra.com ([10.176.90.35]) by CSRRDU1EXM025.corp.csra.com ([10.176.90.35]) with mapi id 15.00.1365.000; Fri, 25 May 2018 11:17:12 -0400 From: "Gunn, Janet P (CNV)" To: Ben Campbell , "draft-ietf-dime-doic-rate-control.all@ietf.org" CC: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-doic-rate-control-08 Thread-Index: AQHT7NclzbNywRlTQ0SaTYZnmhQyRKRAgGhQ Date: Fri, 25 May 2018 15:17:12 +0000 Message-ID: References: <8FB01050-7B63-4A1B-B50A-974D0FA448C4@nostrum.com> In-Reply-To: <8FB01050-7B63-4A1B-B50A-974D0FA448C4@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: =?utf-8?B?UEcxbGRHRStQR0YwSUc1dFBTSmliMlI1TG5SNGRDSWdjRDBpWXpwY2RYTmxj?= =?utf-8?B?bk5jWjNWdWJtcGNZWEJ3WkdGMFlWeHliMkZ0YVc1blhEQTVaRGcwT1dJMkxU?= =?utf-8?B?TXlaRE10TkdFME1DMDROV1ZsTFRaaU9EUmlZVEk1WlRNMVlseHRjMmR6WEcx?= =?utf-8?B?elp5MWlNVEUxT0RaaE5TMDJNREpsTFRFeFpUZ3RZbVZtWlMxbE5HRTBOekUz?= =?utf-8?B?WTJOaFpHWmNZVzFsTFhSbGMzUmNZakV4TlRnMllUWXROakF5WlMweE1XVTRM?= =?utf-8?B?V0psWm1VdFpUUmhORGN4TjJOallXUm1ZbTlrZVM1MGVIUWlJSE42UFNJNE9U?= =?utf-8?B?UTJJaUIwUFNJeE16RTNNVGN6TlRBek1EUXlPVEE1TXpZaUlHZzlJbUZUVkM5?= =?utf-8?B?R1MwSmtOMUUyU0hZeGJISnphMlYyTWxCSU1YWXZRVDBpSUdsa1BTSWlJR0pz?= =?utf-8?B?UFNJd0lpQmliejBpTVNJZ1kyazlJbU5CUVVGQlJWSklWVEZTVTFKVlJrNURa?= =?utf-8?B?MVZCUVVwM1IwRkJRalJ0UzFKNlR5OVVWRUZrTUdVeFZYZDBRVU5OTHpOU04x?= =?utf-8?B?WlVRekJCU1hvNFMwRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?SVFVRkJRVUZ6UW1kQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZG?= =?utf-8?B?UVVGUlFVSkJRVUZCU0RNck1GQm5RVUZCUVVGQlFVRkJRVUZCUVVGQlNqUkJR?= =?utf-8?B?VUZDYUVGSFVVRmFRVUo1UVVkVlFXTjNRbnBCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVVZCUVVGQlFVRkJRVUZCWjBG?= =?utf-8?B?QlFVRkJRVzVuUVVGQlIwMUJXWGRDWmtGSFRVRmtVVUo2UVVoUlFXSjNRblJC?= =?utf-8?B?UmpoQldWRkNkVUZJYTBGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGUlFVRkJR?= =?utf-8?B?VUZCUVVGQlEwRkJRVUZCUVVObFFVRkJRVmwzUWpGQlNFMUJaRUZDZGtGSE1F?= =?utf-8?B?RllkMEozUVVkVlFXTm5RbnBCUnpoQlltZEJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUpCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkNRVUZCUVVGQlFVRkJRVWxCUVVGQlFVRktORUZCUVVKcVFVaFZRV04z?= =?utf-8?B?UWpCQlJ6aEJZbEZDWmtGSVFVRmhRVUp3UVVkelFWcFJRalZCU0dOQlluZENl?= =?utf-8?B?VUZIVVVGamQwRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUlVGQlFVRkJRVUZCUVVGblFVRkJRVUZCYm1kQlFV?= =?utf-8?B?RkhUVUZrVVVKNlFVaFJRV0ozUW5SQlJqaEJZMEZDYjBGSE9FRmlaMEpzUVVj?= =?utf-8?B?MFFXUlJRblJCUjBsQldsRkNlVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFWRkJRVUZCUVVGQlFVRkRRVUZC?= =?utf-8?B?UVVGQlEyVkJRVUZCV1hkQ01VRklUVUZrUVVKMlFVY3dRVmgzUW5wQlNFMUJZ?= =?utf-8?B?bWRCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUpCUVVGQlFV?= =?utf-8?B?RkJRVUZCU1VGQlFVRkJRVW8wUVVGQlFtdEJTR2RCV0hkQ2FrRkhPRUZhUVVK?= =?utf-8?B?c1FVaE5RVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGRlFVRkJRVUZCUVVGQlFXZEJRVUZCUVVGdVowRkJRVWRWUVdKUlFtaEJS?= =?utf-8?B?MnRCWWtGQ1prRkhSVUZhUVVKclFVaEpRVnBSUW5wQlNFMUJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUYzUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJVVUZCUVVGQlFVRkJRVU5CUVVGQlFVRkRaVUZCUVVG?= =?utf-8?B?aFFVSnFRVWhCUVZsM1FucEJSamhCV1hkQ2RrRkhVVUZhVVVKNlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUWtGQlFVRkJRVUZCUVVGSlFVRkJR?= =?utf-8?B?VUZCU2pSQlFVRkNkMEZJWjBGWWQwSnFRVWM0UVZwQlFteEJTRTFCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVG?= =?utf-8?B?QlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZC?= =?utf-8?B?UVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJR?= =?utf-8?B?VUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFV?= =?utf-8?B?RkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVVGQlFVVkJRVUZCUVVG?= =?utf-8?Q?BQUFBZ0FBQUFBQSIvPjwvbWV0YT4=3D?= x-dg-rorf: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.76.253.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] draft-ietf-dime-doic-rate-control-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2018 15:17:20 -0000 Tm90IGFuIGF1dGhvciwgYnV0IEkgaGF2ZSBhIHN0cm9uZyBpbnRlcmVzdCBpbiB0aGlzIElELiAg Q29tbWVudHMgaW4gbGluZS4NCkphbmV0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBEaU1FIDxkaW1lLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCZW4gQ2FtcGJl bGwNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDE4IDE6MzEgQU0NClRvOiBkcmFmdC1pZXRm LWRpbWUtZG9pYy1yYXRlLWNvbnRyb2wuYWxsQGlldGYub3JnDQpDYzogZGltZUBpZXRmLm9yZw0K U3ViamVjdDogW0RpbWVdIGRyYWZ0LWlldGYtZGltZS1kb2ljLXJhdGUtY29udHJvbC0wOA0KDQpT dWJzdGFudGl2ZSBDb21tZW50czoNCg0KR2VuZXJhbDoNClRoZSBkb2N1bWVudCBzZWVtcyBpbmNv bnNpc3RlbnQgYWJvdXQgd2hldGhlciByYXRlIGxpbWl0cyBhcmUgb25seSByZXBvcnRlZCBkdXJp bmcgb3ZlcmxvYWQgY29uZGl0aW9ucywgb3IgaW4gYWR2YW5jZSBvZiBvdmVybG9hZCBjb25kaXRp b25zLg0KDQo8SlBHPiBJIHRoaW5rIHRoYXQgd291bGQgYmUgImxvY2FsIHBvbGljeSIgb2YgdGhl IHNlcnZpbmcgKHJlcG9ydGluZykgbm9kZSwgYW5kIGluZGVwZW5kZW50IG9mIHRoZSBwcm90b2Nv bCB1c2VkIHRvIGNvbW11bmljYXRlIGl0LiAgSSB0aGluayBtb3N0IGNhc2VzIHdvdWxkIGJlIHJl YWN0aXZlLCBidXQgSSBjYW4gc2VlIHNpdHVhdGlvbnMgd2hlcmUgaXQgY291bGQgYmUgcHJvYWN0 aXZlLjxKUEc+DQoNCknigJlkIGxpa2UgdG8gc2VlIHRoZSBuZWVkIHRvIGFsbG9jYXRlIHRoZSBy YXRlIGxpbWl0IGFjcm9zcyBhbGwgcG90ZW50aWFsIHNvdXJjZXMgb2YgdHJhZmZpYyBnaXZlbiBz b21lIG1vcmUgZW1waGFzaXMuIChNYXliZSBhIHN1Yi1zZWN0aW9uIG9mIGl0cyBvd24/KQ0KDQo8 SlBHPiBJIGFncmVlLCBidXQgYWdhaW4gSSBzZWUgdGhhdCBhcyAibG9jYWwgcG9saWN5IiBvZiB0 aGUgc2VydmluZyAocmVwb3J0aW5nKSBub2RlLiBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBtYXkgYmUg cmVhY3Rpbmcgbm9kZXMgdGhhdCBkbyBub3Qgc3VwcG9ydCB0aGUgcmF0ZSBhYmF0ZW1lbnQgYWxn b3JpdGhtLjxKUEc+DQoNCg0KwqcxOg0KLSDigJwgV2hpbGUgdGhpcyBjYW4gZWZmZWN0aXZlbHkg ZGVjcmVhc2UgdGhlIGxvYWQgaGFuZGxlZCBieSB0aGUNCiAgIHNlcnZlciwgaXQgZG9lcyBub3Qg ZGlyZWN0bHkgYWRkcmVzcyBjYXNlcyB3aGVyZSB0aGUgcmF0ZSBvZiBhcnJpdmFsDQogICBvZiBz ZXJ2aWNlIHJlcXVlc3RzIGluY3JlYXNlcyBxdWlja2x5LiINCg0KSSB0aGluayBpdCBmYWlscyB0 byBhZGRyZXNzIGNhc2VzIHdoZXJlIHRoZSBsb2FkIGNoYW5nZXMgcmFwaWRseSBpbiBlaXRoZXIg ZGlyZWN0aW9uLCByaWdodD8gQXQgbGVhc3QsIHRoZSBmb2xsb3dpbmcgdGV4dCBzZWVtcyB0byBz YXkgdGhhdC4NCg0KPEpQRz4gSSBhZ3JlZS4gIFdoZW4gdGhlcmUgYXJlIHJhcGlkIGZsdWN0dWF0 aW9ucyBpbiB0aGUgb2ZmZXJlZCBsb2FkLCB0aGUgImxvc3MiIGFsZ29yaXRobSBlcnJzIGJvdGgg aW4gIHRocm90dGxpbmcgVE9PIE1VQ0ggd2hlbiB0aGVyZSBpcyBhIGRpcCBpbiBvZmZlcmVkIGxv YWQsIGFuZCB0aHJvdHRsaW5nIE5PVCBFTk9VR0ggd2hlbiB0aGVyZSBpcyBhIHNwaWtlIGluIG9m ZmVyZWQgbG9hZC48SlBHPg0KDQoNCg0KwqczOiBEb2VzIHRoZSBuZWVkIGZvciBmdXR1cmUgcmVw b3J0IHR5cGVzIHRvIGNvbnNpZGVyIHRoZSByYXRlIGFsZ29yaXRobSBoYXZlIElBTkEgaW1wbGlj YXRpb25zPw0KDQrCpzUuMTogVGhlIGZpcnN0IHBhcmFncmFwaCBpbmRpY2F0ZXMgc3RhdGUgc2hv dWxkIGJlIGtlcHQgZm9yIGV2ZXJ5IHJlYWN0aW5nIG5vZGUgdG8gd2hpY2ggaXQgc2VuZHMgYW4g T0xSLiBCdXQgdGhlIDV0aCBwYXJhZ3JhcGggY2FuIGJlIGludGVycHJldGVkIHRvIHNheSBpdCBz ZW5kcyBhbiBPTFIgdG8gZXZlcnkgcmVhY3Rpbmcgbm9kZSB3aXRoIHdoaWNoIGl0IGhhcyBuZWdv dGlhdGVkIHVzZSBvZiB0aGUgcmF0ZSBhbGdvcml0aG0uIChzZWUgZ2VuZXJhbCBjb21tZW50KS4N Cg0Kwqc1LjQ6IFRoZSBmaXJzdCBwYXJhZ3JhcGggc2VlbXMgdG8gc3VnZ2VzdCB0aGUgcmVhY3Rp bmcgbm9kZSBrZWVwcyBPQ1MgZm9yIGV2ZXJ5IHNlcnZlciB0aGF0IGhhcyBpbmRpY2F0ZWQgc3Vw cG9ydCBmb3IgdGhlIHJhdGUgYWxnb3JpdGhtLCBub3QganVzdCBub2RlcyB0aGF0IGhhdmUgc2Vu dCBPTFJzLiBJcyB0aGF0IHRoZSBpbnRlbnQ/DQoNCsKnNS42LCBmaXJzdCBwYXJhZ3JhcGg6IFRo ZSBNQVkgc2VlbXMgd2VlayBoZXJlLiBJIGtub3cgYW5kIGFncmVlIHRoYXQgd2UgZG9u4oCZdCB3 YW50IHRvIGZvcmNlIGEgcGFydGljdWxhciBhcHBsaWNhdGlvbi4gQnV0IGRvbuKAmXQgd2UgbmVl ZCB0byBzYXkgdGhhdCBpZiBhbiBpbXBsZW1lbnRhdGlvbiB1c2VzIGEgZGlmZmVyZW50IGFsZ29y aXRobSwgaXQgTVVTVCBoYXZlIHRoZSBzYW1lIGJlaGF2aW9yIGFzIHRoZSBhbGdvcml0aG0gaW4g c2VjdGlvbiA3Pw0KDQo8SlBHPiBJIHRoaW5rIGl0IE1VU1QgImxpbWl0IHRoZSBtZXNzYWdlIHJh dGUgdG8gdGhlIE9DLU1heGltdW0tUmF0ZSBBVlAgdmFsdWUgaW4gdW5pdHMgb2YgbWVzc2FnZXMg cGVyIHNlY29uZCIgKGFzIHN0YXRlZCBpbiA3LjMuMSkuICBUaGUgYWxnb3JpdGhtIGRlc2NyaWJl ZCBpbiB0aGUgcmVzdCBvZiA3LjMuMSBhbmQgNy4zLjIgaXMgc29tZXdoYXQgbW9yZSBzb3BoaXN0 aWNhdGVkLCBhbGxvd2luZyBmb3IgYSBzbW9vdGhpbmcgZmFjdG9yIChUQVUpIGFuZCBwcmlvcml0 aXphdGlvbi4gIEkgZG8gbm90IHRoaW5rIHdlIG5lZWQgIHRvIHNheSB0aGF0IHRoZSBzZWxlY3Rl ZCBhbGdvcml0aG0gTVVTVCBoYXZlIHRob3NlIGZlYXR1cmVzLjxKUEc+DQoNCsKnNy4yLCB0aGly ZCBhbmQgNHRoIHBhcmFncmFwaHM6IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBpcyB0 cnlpbmcgdG8gc2F5LiBQbGVhc2UgZWxhYm9yYXRlLg0KDQo8SlBHPjNyZCBwYXJhIC0gSnVzdCBh cyBhICJmb3IgaW5zdGFuY2UiLSBpZiB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgNTAvc2Vjb25kIGxv dyBwcmlvcml0eSBtZXNzYWdlcyBhbmQgNTAvc2Vjb25kIGhpZ2ggcHJpb3JpdHkgbWVzc2FnZXMg dGhhdCBpdCB3YW50IHRvIHNlbmQsIGFuZCBoYXMgYSByYXRlIGxpbWl0IG9mIDc1L3NlY29uZCwg aXQgd2lsbCBzZW5kIDI1L3NlY29uZCBsb3cgcHJpb3JpdHkgbWVzc2FnZXMgYW5kIDUwIC9zZWNv bmQgaGlnaCBwcmlvcml0eSBtZXNzYWdlcy4gIFRoZSBsaW1pdCBvZiA3NS9zZWNvbmQgYXBwbGll cyB0byB0aGUgY29tYmluZWQgc3RyZWFtIG9mIGhpZ2ggYW5kIGxvdyBwcmlvcml0eSBtZXNzYWdl cywgZXZlbiB0aG91Z2ggb25seSB0aGUgbG93IHByaW9yaXR5IG1lc3NhZ2VzIGFyZSBiZWluZyBh YmF0ZWQuPEpQRyA+DQoNCjxKUEc+IDR0aCBwYXJhIC0gaW4gdGhlIHNhbWUgZXhhbXBsZSwgaXQg Y291bGQgYmUgdGhhdCB0aGUgaGlnaCBwcmlvcml0eSBtZXNzYWdlcyB0eXBpY2FsbHkgcmVxdWly ZSBtb3JlIHByb2Nlc3NpbmcgcmVzb3VyY2VzIChjcHUsIGV0YykgdGhhbiB0aGUgbG93IHByaW9y aXR5IG1lc3NhZ2VzIChvciB2aWNlIHZlcnNhKS4gIFNvIGN1dHRpbmcgdGhlIHJhdGUgdG8gNzUv c2VjIG1heSBOT1QgcHJvZHVjZSB0aGUgZXhwZWN0ZWQgcmVkdWN0aW9uIGluIHJlc291cmNlIHVz YWdlLjxKUEc+DQoNCg0KLTZ0aCBwYXJhZ3JhcGg6IOKAnCAgbWF5IHJlY2VpdmUgcmVxdWVzdHMg YXQgYSByYXRlIGJlbG93IGl0cyB0YXJnZXQgbWF4aW11bSBEaWFtZXRlciAgcmVxdWVzdCByYXRl IHdoaWxlIG90aGVycyBhYm92ZSB0aGF0IHRhcmdldCByYXRlLiAgQnV0IHRoZSByZXN1bHRpbmcg cmVxdWVzdCByYXRlIHByZXNlbnRlZCB0byB0aGUgb3ZlcmxvYWRlZCByZXBvcnRpbmcgbm9kZSB3 aWxsIGNvbnZlcmdlIHRvd2FyZHMgdGhlIHRhcmdldCBEaWFtZXRlciByZXF1ZXN0IHJhdGUu4oCd DQoNCldoeSBkbyB3ZSBleHBlY3QgdHJhZmZpYyB0byBjb252ZXJnZSB0byB0aGUgcmF0ZSBsaW1p dD8gSXQgc2VlbXMgbGlrZSB0aGF0IHdvbid0IGhhcHBlbiBpZiBzb21lIHJlcG9ydGluZyBub2Rl cyBhcmUgbm90IHNlbmRpbmcgYXQgZnVsbCBjYXBhY2l0eSwgdW5sZXNzIHdvcmsgY2FuIGJlIHNo aWZ0ZWQgZnJvbSB0aGUgaGlnaC1yYXRlIHNvdXJjZXMgdG8gdGhlIHNsb3ctcmF0ZSBvbmVzLg0K DQo8SlBHPiBQcm9iYWJseSB3b3VsZCBiZSBiZXR0ZXIgdG8gc2F5IHRoYXQgaXQgIndpbGwgY29u dmVyZ2UgIHRvd2FyZCBhIHJhdGUgYXQgb3IgYmVsb3cgdGhlIHRhcmdldCBEaWFtZXRlciByZXF1 ZXN0IHJhdGUu4oCdPEpQRz4NCg0Kwqc3LjMuMTogcGFyYWdyYXBoIHN0YXJ0aW5nIHdpdGgg4oCc IEluIHNpdHVhdGlvbnMgd2hlcmUgcmVhY3Rpbmcgbm9kZXMgYXJlIGNvbmZpZ3VyZWQgd2l0aCBz b21lIGtub3dsZWRnZeKAnQ0KDQp0aGF0IHJlcXVpcmVzIGtub3dsZWRnZSBvZiBvdGhlciB0cmFm ZmljIHNvdXJjZXMsIG5vdCBqdXN0IGtub3dsZWRnZSBvZiB0aGUgcmVwb3J0aW5nIG5vZGUuDQoN ClRoZSBleGFtcGxlIGNvZGUgc2F5cyB0byB0cmFuc21pdCBhIG1lc3NhZ2UgaWYgKFhwIDw9IFRB VSkuIEJ1dCB0aGUgdGV4dCBzYWlkIHRoZSBsaW1pdCB3YXMg4oCcVCtUQVUpLg0KDQo8SlBHPiBJ IHRoaW5rIGl0IGlzIHN1cHBvc2VkIHRvIGJlICJUK1RBVSI8SlBHPg0KDQrCpzk6IEkgdGhpbmsg dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG5lZWQgbW9yZSB0aG91Z2h0LiBXaGF0IGFyZSB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3BlY2lmaWMgdG8gdGhlIHJhdGUgYWxnb3JpdGht PyBJZiB0aGVyZSBhcmVu4oCZdCBhbnksIHRoZW4gcGxlYXNlIGRlc2NyaWJlIHRoZSByYXRpb25h bCBiZWhpbmQgdGhhdC4gQnV0IEkgc3VzcGVjdCB0aGVyZSBhcmUsIGZvciBleGFtcGxlLCBjYW4g dGhpcyBiZSB1c2VkIGZvciBhIERvUz8gQ2FuIGl0IGJlIHVzZWQgdG8gaGVscCBfbWl0aWdhdGVf IGEgRG9TPyBDb3VsZCBvbmUgcmVhY3Rpbmcgbm9kZSBjYXVzZSBvdGhlcnMgdG8gYmUgdHJhZmZp YyBzdGFydmVkPw0KDQo8SlBHPkl0IGlzIHBvc3NpYmxlIHRoYXQgYSByZWFjdGluZyBub2RlIHRo YXQgZG9lcyBub3Qgc3VwcG9ydCBvdmVybG9hZCBjb250cm9sIGNvdWxkIHN0YXJ2ZSB0aGUgbm9k ZXMgdGhhdCBkbyBzdXBwb3J0IG92ZXJsb2FkIGNvbnRyb2wsIGJ1dCB0aGlzIGlzIGFsc28gdHJ1 ZSBvZiB0aGUgbG9zcyBiYXNlZCB2ZXJzaW9uPEpQRz4NCg0KRWRpdG9yaWFsIENvbW1lbnRzOg0K DQpHZW5lcmFsOiBJRE5pdHMgcmV0dXJucyBzZXZlcmFsIGlzc3Vlcy4gU29tZSBvZiB0aG9zZSBt YXkgYmUgZXJyb3JzIG9uIGl0cyBwYXJ0LCBidXQgSeKAmW0gcHJldHR5IHN1cmUgc29tZSBvZiB0 aGVtIGFyZSByZWFsLiBQbGVhc2UgcmVzb2x2ZSB0aGVzZS4NCg0KUmVxdWlyZW1lbnRzOiBUaGVy ZSBhcmUgaW5zdGFuY2VzIG9mIGxvd2VyIGNhc2Ug4oCcbXVzdOKAnSBhbmQg4oCcc2hvdWxk4oCd LiBQbGVhc2UgdXNlIHRoZSBuZXcgYm9pbGVycGxhdGUgZnJvbSBSRkMgODE3NC4NCg0KwqcxDQot IOKAnHByb3RlY3QgdGhlIHN0YWJpbGl0eeKAnSBzZWVtcyBhd2t3YXJkLiBNYXliZSDigJxlbnN1 cmUgdGhlIHN0YWJpbGl0eeKAnT8NCi0gQWxzbyBzLyDigJxzdWJqZWN0ZWQgd2l0aOKAnSAvIOKA nHN1YmplY3RlZCB0b+KAnS4uDQoNCi0gUGxlYXNlIGNpdGUgdGhlIGRlZmluaXRpb25zIGZvciDi gJxyZXBvcnRpbmcgbm9kZeKAnSBhbmQg4oCccmVhY3Rpbmcgbm9kZeKAnS4gSSBrbm93IHRoZXkg YXJlIGRlZmluZWQgbGF0ZXIsIGJ1dCB0aGVzZSBhcmUgc29tZXdoYXQgbm9uLWludHVpdGl2ZSBj b25jZXB0cyBhbmQgcGVvcGxlIHdpbGwgbGlrZWx5IHN0dW1ibGUgb3ZlciB0aGUgdGVybXMgd2hl biB0aGV5IGFyZSB1c2VkIGJlZm9yZSB0aGV5IGFyZSBkZWZpbmVkLg0KLSBQbGVhc2UgZXhwYW5k IERPSUMgYW5kIFNPQyBvbiBmaXJzdCBtZW50aW9uIGluIHRoZSBib2R5LiAoRXZlbiBpZiB0aGV5 IHdlcmUgZXhwYW5kZWQgaW4gdGhlIGFic3RyYWN0LikNCg0KwqcyOg0KIC0gRGVmaW5pdGlvbnMg b2Yg4oCcRGlhbWV0ZXIgTm9kZeKAnSBhbmQg4oCcRGlhbWV0ZXIgRW5kcG9pbnTigJ06IFBsZWFz ZSB1c2UgcHJvcGVyIGNpdGF0aW9ucyByYXRoZXIgdGhhbiBqdXN0IHJlZmVycmluZyB0byB0aGUg UkZDIGluIHRleHQuIEZvciBleGFtcGxlOiDigJxEaWFtZXRlciBOb2RlOiBBIERpYW1ldGVyIGNs aWVudCwgc2VydmVyLCBvciBhZ2VudC4gIFtSRkM2NzMzXeKAnQ0KDQrCpzQsDQotIGZpcnN0IHBh cmFncmFwaDoNCuKAlCDigJxUaGlzIGV4dGVuc2lvbiBkZWZpbmVz4oCdOiBJIHRoaW5rIHRoaXMg c2hvdWxkIHNheSDigJxUaGlzIGRvY3VtZW50IGRlZmluZXPigKbigJ0NCuKAlCBQbGVhc2UgY29u c2lkZXIgYWN0aXZlIHZvaWNlIGZvciB0aGUgbGFzdCBzZW50ZW5jZS4NCg0KLSAybmQgcGFyYWdy YXBoOiBUaGUgZmlyc3Qgc2VudGVuY2Ugc2VlbXMgYXdrd2FyZC4gQ29uc2lkZXIgc29tZXRoaW5n IHRvIHRoZSBlZmZlY3Qgb2Yg4oCcU2luY2UgYWxsIG5vZGVzIHRoYXQgc3VwcG9ydCBET0lDIGFy ZSByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSBsb3NzIGFsZ29yaXRobeKApuKAnQ0KDQotIDNyZCBw YXJhZ3JhcGg6IFRoaXMgcGFyYWdyYXBoIHNlZW1zIHRvIGJlbG9uZyBhcyBwYXJ0IG9mIHRoZSBw cmV2aW91cyBwYXJhZ3JhcGguDQoNCi0gNHRoIHBhcmFncmFwaDog4oCcIEFWUCBpbiB0aGUgc2Vu dCB0byB0aGUgRE9JQyByZWFjdGluZyBub2Rlc+KAnTogTWlzc2luZyB3b3JkKHMpPw0KDQotNXRo IHBhcmFncmFwaDog4oCcQSByZXBvcnRpbmcgbm9kZSBNQVkgc2VsZWN04oCm4oCdIDogSXMgdGhh dCBhIG5ldyBwZXJtaXNzaW9uLCBvciBhIHN0YXRlbWVudCBvZiBmYWN0Pw0KDQrCpzUuMSwgdGhp cmQgcGFyYWdyYXBoOiBUaGUgdGV4dCBpcyBub3QgY2xlYXIgd2hldGhlciB0aGlzIG1lYW5zIE9D UyBzaG91bGQgYmUgbWFpbnRhaW5lZCBwZXIgc3VwcG9ydGVkIGFwcGxpY2F0aW9uLCBldGMsIG9y IHRoYXQgaXQgc2hvdWxkIG1haW50YWluIHN0YXRlIHdoZW4gdGhlIHJhdGUgYWxnb3JpdGhtIG9u IGEgcGVyIHN1cHBvcnRlZCBhcHBsaWNhdGlvbiwgZXRjLCBiYXNpcy4NCi0gNHRoIHBhcmFncmFw aDogcy9vdmVyb2xvYWQvb3ZlcmxvYWQNCg0Kwqc1LjM6IDJuZCBwYXJhZ3JhcGg6IFRoaXMgc2Vl bXMgbGlrZSBhIHJlZHVuZGFudCByZXN0YXRlbWVudCBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoLg0K LSB0aGlyZCBwYXJhZ3JhcGg6IFRoZSBmaXJzdCBzZW50ZW5jZSBpcyBjb252b2x1dGVkOyBjYW4g aXQgYmUgYnJva2VuIGludG8gc2ltcGxlciBzZW50ZW5jZXM/DQoNCsKnNi4xLjEsIGRlZmluaXRp b24gb2YgIiBPTFJfUkFURV9BTEdPUklUSE3igJ06IFR3byBwZXJpb2RzIGF0IGVuZCBvZiBzZW50 ZW5jZS4NCg0KDQrCpzcuMSwgMm5kIHBhcmFncmFwaDog4oCcIHNpZ25hbCBvbmUgYW5vdGhlciBz dXBwb3J0IGZvciByYXRlLWJhc2VkIG92ZXJsb2FkDQogICBjb250cm9s4oCdOiBUaGlzIHNlZW1z IGF3a3dhcmQ7IGFyZSB0aGVyZSBtaXNzaW5nIHdvcmRzPw0KDQrCpzcuMiwgbGFzdCB0d28gcGFy YWdyYXBoczogVGhlIE1VU1RzIGRvIG5vdCBzZWVtIG5lY2Vzc2FyeS4gMjExOSBrZXl3b3JkcyBz aG91bGQgYmUgdXNlZCB3aGVuIHRoZXJlIGlzIHNvbWUgc29ydCBvZiBjaG9pY2Ugb3Igcm9vbSBm b3IgZXJyb3IuIFlvdSBkb27igJl0IG5lZWQgdGhlbSB0byBkZWZpbmUgdGhlIGJhc2ljIG9wZXJh dGlvbiBvZiB0aGUgcHJvdG9jb2wuDQoNCsKnNy4zLjE6IEkgZm91bmQgdGhlIHRleHQgaGFyZCB0 byBmb2xsb3cuIEl0IHdvdWxkIGhlbHAgdG8gZGVjbGFyZSBhbGwgdGhlIGlkZW50aWZpZXJzIGFu ZCBpbml0aWFsaXphdGlvbiB1cCBmcm9udCwgYW5kIHRvIHByZXNlbnQgdGhpbmdzIGluIG1vcmUg b2YgYSBzdGVwd2lzZSBmYXNoaW9uLg0KDQotIFQgaXMgZWZmZWN0aXZlbHkgYSB0aW1lIGludGVy dmFsLCByaWdodD8gSXQgd291bGQgaGVscCB0byBzYXkgdGhhdCwgZXNwZWNpYWxseSBsYXRlciB3 aGVuIHlvdSBzdWJ0cmFjdCBhIGRpZmZlcmVudCB0aW1lIGludGVydmFsIGZyb20gaXQuDQoNCi0g cGFyYWdyYXBoIDk6IFNob3VsZCDigJxhZG1pdOKAnSBiZSDigJxlbWl04oCdPw0KDQotIHRoZSBl eGFtcGxlIGNvZGUgaGFzIHNldmVyYWwgbWVudGlvbnMgb2YgU0lQIHJlcXVlc3RzLg0KDQrCpzcu My4yOiDigJwgUmVxdWVzdCBjYW5kaWRhdGVzIGZvciByZWR1Y3Rpb24sIHJlcXVlc3RzIG5vdCBz dWJqZWN0IHRvIHJlZHVjdGlvbiAoZXhjZXB0IHVuZGVyIGV4dGVudWF0aW5nIGNpcmN1bXN0YW5j ZXMgd2hlbiB0aGVyZSBhcmVu4oCZdCBhbnkgbWVzc2FnZXMgaW4gdGhlIGZpcnN0IGNhdGVnb3J5 IHRoYXQgY2FuIGJlIHJlZHVjZWQpLuKAnTogVGhhdCBzZWVtcyBsaWtlIGFuIGF3a3dhcmQgd2F5 IHRvIHNheSB0aGF0IHRoZSBzZWNvbmQgY2F0ZWdvcnkgaXMgdGhlIHNldCBvZiByZXF1ZXN0cyB0 aGF0IGlzIG9ubHkgc3ViamVjdCB0byByZWR1Y3Rpb24gaWYgdGhlcmUgYXJlIG5vIG1lc3NhZ2Vz IGxlZnQgaW4gdGhlIGZpcnN0IGNhdGVnb3J5Lg0KDQo8SlBHPiBZZXMsIHRoYXQgaXMgd2hhdCBp dCBtZWFucy48SlBHPg0KDQotIOKAnCBUaGlzIGNhbiBiZSBnZW5lcmFsaXplZCB0byBuIHByaW9y aXRpZXMgdXNpbmcgbiB0aHJlc2hvbGRzIGZvciBuPjIgaW4gdGhlIG9idmlvdXMgd2F5LuKAnTog SSBzdWdnZXN0IHlvdSByZWZyYWluIGZyb20gY2FsbGluZyBpdCDigJxvYnZpb3VzIi4NCg0Kwqc3 LjMuMzogUGFyYWdyYXBoIHN0YXJ0aW5nIHdpdGgg4oCcIFRoZW4gKG9ubHkpIGlmIHRoZSBhcnJp dmFsIGlzIGFkbWl0dGVkLCBpbmNyZWFzZSB0aGUgYnVja2V0IGJ5IGFuIGFtb3VudOKApuKAnTog SSB0aGluayB5b3UgaW5jcmVhc2UgdGhlIGJ1Y2tldCBfY291bnRfLCByaWdodD8NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIGNv bnRhaW5zIGluZm9ybWF0aW9uIGZyb20gQ1NSQSB0aGF0IG1heSBiZSBhdHRvcm5leS1jbGllbnQg cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24g aW4gdGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHVzZSBieSB0aGUgaW5kaXZpZHVh bChzKSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGJlbGlldmUgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCBtZSBpbW1lZGlhdGVs eSBhbmQgYmUgYXdhcmUgdGhhdCBhbnkgdXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3Ry aWJ1dGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlbWFpbCBzaGFsbCBub3Qg b3BlcmF0ZSB0byBiaW5kIENTUkEgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVz cyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGlu aXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlbWFpbCBmb3Igc3VjaCBw dXJwb3NlLg0K From nobody Sun May 27 04:09:18 2018 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 D1BE812D964 for ; Sun, 27 May 2018 04:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyjRv4dJOU5j for ; Sun, 27 May 2018 04:09:11 -0700 (PDT) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6436112D963 for ; Sun, 27 May 2018 04:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527419349; bh=gzZFNvu/CqqA9y19GCj1SSEpgS/Z6GUTK3u7AV48Blk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=r3fpPxxiUmoNwEe/FCT1YnVQuGH9v6eiQqUJgCmKosVv2hUg2vcCPL6Ibp7W4fJ+SLv+sW7E/9/jprzxgFtRIO+DRfwmm6zyGqmbswLt3XzkLmlE5GxO3XJ8hc6a8sq0OIqMygxmYG9imiv8ss0D7JQo0EZbSX8+C34i/ici7Vw+IVxSLrnn0sQ5x+VYIyxejG6E9I5XNTO55Tgul1t0nU8G+gIVmN+oxDh3XMsPGNN2Gxu//+CxpxT+u5wy+UfsBH/nXas6Z7PztDZmMPTEAOJuIkZuQYK4k7iM9+a44SMCcP31MOsYrcTSrmCsviiwc6xkf+KWkVrRXvRIiYjhVA== X-YMail-OSG: SPpBrrMVM1kFie5wSV0.j4yfqsvXSkgaYWkhTQY0e7pjI8ST598dKDbDwgFvQ2Q L88LOPtvR3TAw5JT9GLIEktd0GNuqA28VGhRzo8G5V5sXlTFHJnO8vyS38v5By8fWDsXA2bGXyz2 GysxIUKOp6Q7h6d1LmEgc3ZiZHyS.eDI9f_hZz71ejhFV1SspONdyIUCrIgb8Mmf6Qy1YhXz_RD_ bAPoPLZJoY_dMHPnDDqKa7QUw4fref7YD9jR0xAJ46vn8VxzPIk31WtB2d2i3dmGjWYZBLGWHiRP xb4ws1PrdStnH16GdrFY5lIpodhsifQeHP1R9f_0fPD1_ynAvSlCLlcFWOej3p7LajZoE_6DsUcT uSfYmUE24O.fqz0sbTKfLvZGCExdMtrH50p2WSWFyXOBAUN.AOrv6eDY5uo0wbK_phC5DwZ7Pctw o.GZoBfgNPtUsFjlmbNWyJN._gqnHyISV8mmFWHaL_h63bnNWbalEbOoLjKmoJe48D_sAc8b5Tbo eG9SKNKAfPER6_cO8FG.2iMSesXW10b3lqMf76QxbEQvn8hl78RCSe8FO9OyI3qfs_A1SLwI2edJ TZyZ.DwpuM0UmmO4y3g0T1ZesPtFXmQfvQFXnU0lkHSr5cQpMJGvFUeaUoh8En2Xly4NSGd0PzE6 rXTI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Sun, 27 May 2018 11:09:09 +0000 Date: Sun, 27 May 2018 10:59:04 +0000 (UTC) From: Yuval Lifshitz To: Benjamin Kaduk Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <502594613.5761891.1527418744898@mail.yahoo.com> In-Reply-To: <20180524212739.GP32807@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524212739.GP32807@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5761890_522810928.1527418744892" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 27 May 2018 11:09:16 -0000 ------=_Part_5761890_522810928.1527418744892 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable QoS-Final-Unit-Indication ::=3D < AVP Header: TBD17 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 { Final-Unit-Action }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Rule ]=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 *[ Filter-Id ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Redirect-Server ]=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[ Redirect-Server-Extension ]=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] if the peer is 4006, and new redirect format is not needed, then sending th= e legacy "Redirect-Server" AVP inside the=C2=A0new "QoS-Final-Unit-Indicati= on" AVP, won't help with backward compatibility. As the peer won't be able = to parse the=C2=A0"QoS-Final-Unit-Indication" AVP. On Friday, May 25, 2018, 12:27:50 a.m. GMT+3, Benjamin Kaduk wrote: =20 =20 Catching up on the non-redirect items... On Thu, May 24, 2018 at 06:17:51AM +0000, Yuval Lifshitz wrote: >=C2=A0 inline >=C2=A0 =C2=A0 On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kad= uk wrote:=C2=A0=20 >=C2=A0=20 >=C2=A0 [re-sending since my client crashed during the first attempt and I > don't see the message in the archives.=C2=A0 I attempted to reconstruct > my message from a scrollback buffer, but there may be some artifacts > with missing or duplicated text] >=20 > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > >=C2=A0 Thanks Ben and Benjamin! Comments inline > >=C2=A0 =C2=A0 On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbe= ll wrote: > > > >=C2=A0 Hi Benjamin, > > > > I=E2=80=99ve cherry-picked a few points, inline: > > > > Thanks! > > > > Ben. > > > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > > > I appear to have a different understanding of Section 5.6.2, though, > > > with a different potential issue (but again, it's possible that I'm > > > confused to how things work): > > > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > > like the user can be redirected (at the application protocol level, > > > e.g., HTTP or SIP) to a top-up server to purchase more credits.=C2=A0= I > > > don't see a way described how user agents can distinguish between a > > > Diameter-induced redirect and an attacker-induced redirect to a > > > (potentially phishing) site that accepts payment information.=C2=A0 T= o be > > > clear, the scenario here is that a user is using a credit-controlled > > > application session to talk to "arbitrary application servers", > > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > > the attacker could introduce a redirect to a phishing page that asks > > > for payment information, and the user would be led to believe that > > > this was the normal flow for "my prepaid balance has been used up", > > > and give their payment information to the phishing site. I think > > > that either user agents need to give some indication that this > > > DIAMETER-level redirect is different than an > > > application-protocol-level redirect (e.g., http) or the Security > > > Considerations need to mention the risk of acclimating users to > > > arbitrary websites redirecting to sites asking for payment > > > credentials, which may or may not be legitimate sites. > > > > > > > I think it=E2=80=99s reasonable to mention the concern in the security = considerations. But I don=E2=80=99t see how a redirection based on this spe= cification is any different than any other time an HTTP browser or SIP UA c= onnects to a resource based on an arbitrary URL. >=20 > In some sense, it's not.=C2=A0 My claim is more that users are being > conditioned to expect payment prompts to appear at "arbitrary times" > than a specific flaw in this workflow. >=20 >=20 > > But to put some more context around this, the Diameter client is typica= lly a Network Access Server (NAS) that the end user is using for network ac= cess. The user is already at the mercy of that NAS, and that NAS is at the = mercy of the credit-control application server. The user=E2=80=99s trust in= that NAS seems to have the same issues whether or not this Diameter applic= ation is used. > > > > [yuval] agree with Ben, if someone bad took control over the NAS, they = can do much worse >=20 > I agree that the NAS could send traffic to "wherever", but my > objection could perhaps be categorized as more "social" than > "technical".=C2=A0 Maybe I should attempt to give an example (and you can > point out if I misunderstand things). >=20 > I believe that a "normal usage" of this technology could be for a > user with a prepaid data plan to be using a web browser, and, e.g., > connect successfully to https://example.com. Suppose that this > request used up their last remaining credits, and they click on a > link from that page.=C2=A0 Instead of going to the actual target of that > link, they are redirected to the data plan owner's top-up page, > which displays a message "your balance is zero; please enter credit > card information to purchase more data", the user pays, and can > potentially even be redirected back to the actual target of the link > they clicked on (though that's not key to my example).=C2=A0 Let's > consider what would happen in an "attack scenario", where the same > user has plenty of data quota remaining, and goes to > https://honest-achmed.com. They click on a link from that page, > which instead of going to an "actual site" that would be expected > from the context surrounding the link, actually goes to > http://[IP address controlled by attacker]/topup.html, which is > designed to look as similar as possible to the actual data plan > owner's top-up page.=C2=A0 The user may then enter their payment > information, and get redirected to a site with actual content, > believing that they have obtained more data quota from their > provider, when in reality they have given their credit card > information to a phisher. >=20 > I don't see what mechanism is in place to allow the user to be able > to distinguish between the "normal usage" scenario and the "attack > scenario".=C2=A0 I also understand that this sort of technology is > already deployed and is seen as useful by both users and data > providers, so it seems unrealistic to expect to be able to get rid > of this usage entirely.=C2=A0 I do think that it is unreasonable for us > to enable this behavior without documenting the risks to the user, > though. >=20 > [yuval] I guess that there is nothing in the spec that technically enable= s phishing, however, it makes the social engineering part of it easier. How= about the following addition to the security sections:"It is RECOMMENDED t= hat operators put in place mechanisms that would help their subscribers ide= ntify a valid redirect operation from a malicious=C2=A0one" > > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > > > >=C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the > > >=C2=A0 Redirect-Server-Extension AVP MUST be present. > > > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > > section 8.64 even internally inconsistent, too?) about > > > "Redirect-Server AVP, in addition to or instead of the > > > Redirect-Server-Extension AVP", in particular, the "instead of" > > > portion.=C2=A0 (The ABNF-based formal language spec in 8.68 does matc= h up > > > with the above MUST, though.) > > > > Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64 t= o just =E2=80=9Cin addition to=E2=80=9D help? > > > > Authors: Please comment if that works, given the backwards-compatibilit= y concern. > > [yuval] the cumbersome text is because of backward compatibility issue.= Would appriciate suggestion for better phrasing. The idea is the following= :* We have an existing AVP that can carry some information* We need more in= formation, but we cannot modify the existing one, so we added a new AVP (wh= ich, unlike the old one, is future proof)* If you have a peer that does not= support the new spec, but only need the old info, you can use the old AVP.= what makes the spec backward compatible to the old one* If you have need t= o send the new info, you have to use the new AVP, but in this case an older= peer does not make sense >=20 > To Ben, I believe that just "in addition to" resolves the internal > inconsistency.=C2=A0 However, it sounds like that may not be the best > solution from a deployment perspective, and perhaps the formal > definition in Section 8.68 (and the body text) should be relaxed to > allow either the -Extension or non-Extension form. > [yuval] will remove "instead of" I guess my first response did not adequately respond to your request for better phrasing.=C2=A0 Unfortunately, I don't think just different phrasing would suffice if we want to retain the ability to use just the legacy AVP.=C2=A0 (If we don't want to retain that ability, then removing the "instead of" is the right thing to do.) To regain the ability to just use Redirect-Server without Redirect-Server-Extension, the text in section 8.68 would need to have OLD: =C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the =C2=A0 Redirect-Server-Extension AVP MUST be present.=C2=A0 The Filter-Rule= AVP NEW: =C2=A0 If the Final-Unit-Action AVP is set to REDIRECT, at least one of the =C2=A0 Redirect-Server and Redirect-Server-Extension AVPs MUST be present. =C2=A0 The Filter-Rule AVP And probably also to change the formal syntax (though I guess technically it is not necessary, it would be misleading to leave it as-is): OLD: =C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS-Final-Unit-Indication ::=3D < AVP Header: T= BD17 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { Final-Unit-Action } =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Rule ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Id ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Redirect-Server-Extension ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] NEW: =C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS-Final-Unit-Indication ::=3D < AVP Header: T= BD17 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { Final-Unit-Action } =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Rule ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Id ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Redirect-Server ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Redirect-Server-Extension ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] (Am I reading RFC 6733 correctly that the ABNF '/' operator is not used in CCF?) > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Some additional significant but not necessarily DISCUSS-worthy > > > comments, followed by more editorial- and nit-level things. > > > > > > In Section 1.3, "Advertising Application Support" uses the same > > > Auth-Application-ID value as for RFC 4006; what are the interop > > > consequences of this? > > >=C2=A0[yuval] this was done to make interops easier - this is why we k= ept this RFC backward compatible with RFC4006 > > > Alissa already noted that the text about how to split (sub-)AVPs > > > between the foo and foo-Extension AVPs is inconsistent among them -- > > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > > send [in the old one]", but Subscription-Id-Extension has separate > > > text about "[i]f full backward compatibility with [RFC4006] is > > > required" and slightly different behavior described.=C2=A0 We should = try > > > to catch all instances of this sort of backwards compatibility and > > > make them consistent. > > > > I agree. > > [yuval] will look to unify the text >=20 > I see that there was some discussion on Alissa's ballot thread that > there may indeed be special considerations for one AVP.=C2=A0 If so, > that's fine, but the reasoning should probably be included in the > document to explain the apparent disparity. >=20 > [yuval] ok >=20 > > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > > > might benefit from additional text about the expected contents.=C2=A0= A > > > lot of the time when we use a UTF8 container for names (whether > > > domain names or other kinds), we specify what normalization form and > > > canonicalization are performed, whether domain names are A-labels or > > > U-labels, etc., as there's a lot of potential flexibility not all of > > > which is good.=C2=A0 In this case, since the communication is only > > > between trusted actors, perhaps the additional restrictions are not > > > needed, but I am curious if the topic was raised in the WG. > > > > On reflection, shouldn=E2=80=99t that be based on whatever rules alread= y exist for the URL scheme? And if some scheme doesn=E2=80=99t have well de= fined behavior for non-ascii labels, is that the concern of this applicatio= n? >=20 > It is probably a matter for the URL scheme, yes.=C2=A0 So at most we > could note here that "individual URL schemes may restrict the > contents of the UTF8String", but as I imply in my original comment, > it's far from clear to me that we actually need to say anything in > this specific case. >=20 > > > > > > Thank you for adding the Privacy Considerations and list of > > > Privacy-Sensitive AVPs! > > > > > > Section 14 > > > > > >=C2=A0 [...] The Diameter credit- > > >=C2=A0 control application is often used within one domain, and there = may be > > >=C2=A0 a single hop between the peers.=C2=A0 In these environments, th= e use of > > >=C2=A0 TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > > > I did not see any concrete guidance on what would suffice in other > > > environments (with multiple hops between peers).=C2=A0 Is this the re= alm > > > of the mythical "end-to-end security mechanism" for Diameter that is > > > much-desired?=C2=A0 (The last paragraph does have guidance on what mi= ght > > > *not* suffice, which is not exactly the same thing.) > > > > > > > Sort of, but in real world deployments the =E2=80=9Coften used within o= ne domain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D, w= hich should be clarified) effectively overrides everything else. That is fa= r from ideal, but it=E2=80=99s the reality. So it basically comes down to k= eep everything in the trust domain, or if you cross a non-trusted network t= hen use TLS or IPSec. > > > > There=E2=80=99s no solution to safely traverse a non-trusted Diameter a= gent. The mythical e2e mechanism could conceivably give us that.=C2=A0 (som= eday, along with world peace and a post-scarcity economy). > > > > [yuval] as Ben and Lyle wrote, if your messages need to go through agen= ts that belong to a 3rd party, you have risks. In this case, AVP level encr= yption (which is not standardized=C2=A0yet...) is the only option for to en= sure privacy. So, the only thing we can do here is to highlight the risks.= =C2=A0 >=20 > Do we want to say something about "at present, there is not a > general reliable security solution for other environments"?=C2=A0 (To be > clear, I do not insiste that we do so.) >=20 > [yuval] not sure if AVP level ancryption would ever happen... would keep = text as is >=20 > > >=C2=A0 Even without any modification to the messages, an adversary can > > >=C2=A0 eavesdrop on transactions that contain privacy-sensitive inform= ation > > >=C2=A0 about the user. > > > > > > This ("an adversary can") makes it sounds as if there is no > > > confidentiality protection anywhere in the system, but that's what > > > TLS/DTLS/IPSec are supposed to provide.=C2=A0 So maybe "an adversary = that > > > can eavesdrop on transactions can obtain privacy-sensitive > > > information [...]" is better. > > > > > > > Good point, I agree your suggestion is better.[yuval] ok > > > > > (Editorial- and nit-level stuff follows.) > > > > > > Section 4 > > > > > >=C2=A0 A flexible credit-control application specific failure handling= is > > >=C2=A0 defined in which the home service provider can model the credit= - > > >=C2=A0 control client behavior according to its own credit risk manage= ment > > >=C2=A0 policy. > > > > > > This sentence is hard to parse -- in "credit-control application > > > specific" what does "specific" bind to?=C2=A0 What is being modelled?= =C2=A0 Is > > > anything being controlled (as opposed to modelled)? > > [yuval] ok. so how about: > > "Flexible failure handling, specific to the credit-control, is defined = in the application.This allows the the service provider to control the cred= it-control client behavior according to its ownrisk management policy" >=20 > That's much better; thanks! >=20 > > > Section 4.1.1 > > > > > >=C2=A0 2.=C2=A0 The Service-Parameter-Info AVP MAY be used as a contai= ner to pass > > >=C2=A0 legacy rating information in its original encoded form (e.g., A= SN.1 > > >=C2=A0 BER).=C2=A0 [...] > > > > > > Why BER and not DER?=C2=A0 The unnecessary flexibility in BER vs. DER= has > > > been known to tickle parser bugs and create security > > > vulnerabilities. > > >=C2=A0 > > [yuval] this is just an example of legacy stuff you have no control ove= r > > > > > Section 4.1.2 > > > > > >=C2=A0 [...] To > > >=C2=A0 facilitate interoperability, it is RECOMMENDED that the rating = input > > >=C2=A0 and the values of the Service-Context-Id be coordinated via an > > >=C2=A0 informational RFC or other permanent and readily available refe= rence. > > >=C2=A0 The specification of another cooperative standardization body (= e.g., > > >=C2=A0 3GPP, OMA, or 3GPP2) SHOULD be used. > > > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > > >=C2=A0 > > [yuval] yes, seems a bit awkward. How about: > > "To=C2=A0facilitate interoperability, it is RECOMMENDED that the rating= input > > and the values of the Service-Context-Id be coordinated via an > > informational RFC or other permanent and readily available reference, > > preferably, of another cooperative standardization body (e.g., > > =C2=A03GPP, OMA, or 3GPP2)." >=20 > Sounds good. >=20 > > > Section 5.1.1 > > > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > > seems that this text could be reworded to just talk about a > > > "constant rate" or "constant level per fixed time period" or > > > similar. > > >=C2=A0 > > [yuval] "constant rate" could mean sub-second resolution as well. The g= rants are in seconds, so, IMO, this phrasing is more accurate >=20 > It seems that it's only more accurate if leap seconds are ignored. > (I suppose you could explicitly disclaim "(ignoring leap seconds)" > or similar.) >=20 > [yuval] will add >=20 > > > Section 5.1.2 > > > > > >=C2=A0 [...] > > >=C2=A0 timer (Section 13) every time a CCR message with the value > > >=C2=A0 UPDATE_REQUEST is sent while they are in PendingU state.=C2=A0 = When > > >=C2=A0 answers to all pending messages are received, the state machine= moves > > >=C2=A0 to OPEN state, and Tx is stopped. > > > > > > Transmission, or the Tx timer (is stopped)? > > >=C2=A0 > > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense o= f "transmission" in the RFC >=20 > (I think that "Tx timer" was fairly consistently used throughout the > rest of the document; it may make sense to be fully consistent about > it.) >=20 > [yuval] will fix in the doc >=20 > > > Using a different title for Section 5.2.2 might make the parallel > > > between it and Section 5.2.1 more clear.=C2=A0 That is, perhaps somet= hing > > > like "First Interrogation Included with Authorization Messages". > > >=C2=A0 > > [yuval] make sense > > > > > Section 5.7 > > > > > >=C2=A0 [...] It is RECOMMENDED that the client complement the credit- > > >=C2=A0 control failure procedures with backup accounting flow toward a= n > > >=C2=A0 accounting server. [...] > > > > > > Nit: it looks like there's a missing article here, maybe "a backup > > > accounting flow" is better. > > >=C2=A0 > > [yuval] the rest of the paragraph describe such "backup accounting flow= ". See what comes after "For example" >=20 > I just meant that it sounds like you need to add the word "a" in > order for the grammar to make sense.=C2=A0 (But perhaps "the" is the > right word; I wasn't sure.) >=20 > [yuval] ok > > >=C2=A0 The AAA transport profile [RFC3539] defines the application lay= er > > >=C2=A0 watchdog algorithm that enables failover from a peer that has f= ailed > > >=C2=A0 and is controlled by a watchdog timer (Tw) defined in [RFC3539]= . > > > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > > >=C2=A0 > > [yuval] would imagine there are other algorithms out there... should fi= x > > > > > Section 6.2 > > > > > > Should there be text indicating how the client indicates what > > > service the balance check is being requested for? > > >=C2=A0 > > [yuval] didn't find any reference to service information for "EVET_REQU= EST" type messages (direct debit, refund, balance check and price enquiry).= Seems like that in the IEC section of 3GPP TS 32.299, they added their own= mechanism for "direct debit", and "refund", and leave "balance check" and = "price enquiry" as references to RFC4006. Unless I've missed something, thi= s seems like a missing part of the spec. > > > [yuval] hmm. seems like "event requests"=C2=A0should be looked at (probab= ly at the light of 3GPP 32.299 IEC concept). But for sure *not* as part of = this work. I was mostly wondering whether this section should say anything about including the Service-Identifier AVP.=C2=A0 Looking back at the document now, though, maybe this question does not actually make sense. -Benjamin > > > Section 8.54 > > > > > > Maybe give a section reference in RFC 3580 for how the formatting is > > > done? > > >=C2=A0 > > [yuval] see section 3.21 in RFC3580, this is also true for section 8.50= in our RFC > > > > > Section 12 > > > > > >=C2=A0 [...] Initially, such Expert discussions take place on the AAA > > >=C2=A0 WG mailing list. > > > > > > That list appears to be dead, suggesting that this text should be > > > updated.=C2=A0 (I also agree with Adam's comments about updating the = IANA Considerations.) > > >=C2=A0 > > [yuval] i don't know the process here - not sure how to change it. >=20 > With respect to the "expert discussions take place" text, I think it > could just be removed. >=20 > Discussion of the detailed updates to the IANA actions should > probably happen in Adam's ballot thread. >=20 > > > Why is the disclaimer in Section B.4 (and other examples) not needed = in Section B.3? > > [yuval] should be added there as well >=20 > Great, thanks. >=20 >=20 > -Benjamin >=20 >=20 > |=20 > |=20 > |=C2=A0 |=20 > Example Domain >=20 >=20 >=C2=A0 | >=20 >=C2=A0 | >=20 >=C2=A0 | >=20 >=20 >=20 >=C2=A0=20 =20 ------=_Part_5761890_522810928.1527418744892 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
QoS-Final-Unit-Indication ::=3D < AVP Header= : TBD17 >
             =             { Final-Unit-Action }
=                      = ;     *[ Filter-Rule ]
        &nbs= p;                 *[ Filter-Id ]
                  &nb= sp;        [ Redirect-Server ]
    =                      = ;  [ Redirect-Server-Extension ]
       =                   *[ AVP ]
if the peer is 4006, and new redirect format is no= t needed, then sending the legacy "Redirect-Server" AVP inside the new= "QoS-Final-Unit-Indication" AVP, won't help with backward compatibility. A= s the peer won't be able to parse the "QoS-Final-Unit-Indication= " AVP.
=20
=20
On Friday, May 25, 2018, 12:27:50 a.m. GMT+3, Benja= min Kaduk <kaduk@mit.edu> wrote:


Catching up on the non-redirect items...

On= Thu, May 24, 2018 at 06:17:51AM +0000, Yuval Lifshitz wrote:
> = inline
>    On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+= 3, Benjamin Kaduk <kaduk@mit.edu> wrote: 
> 
>&nbs= p; [re-sending since my client crashed during the first attempt and I
&g= t; don't see the message in the archives.  I attempted to reconstruct<= br>> my message from a scrollback buffer, but there may be some artifact= s
> with missing or duplicated text]
>
> On Wed, May 23,= 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote:
> >  Thanks = Ben and Benjamin! Comments inline
> >    On Wednesday, M= ay 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell <ben@nostrum.com> wrote:=
> >
> >  Hi Benjamin,
> >
> > I= =E2=80=99ve cherry-picked a few points, inline:
> >
> > T= hanks!
> >
> > Ben.
> >
> > > On May= 22, 2018, at 8:48 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> > = >
> > > Benjamin Kaduk has entered the following ballot posi= tion for
> > > draft-ietf-dime-rfc4006bis-08: Discuss
> &= gt; >
> > > When responding, please keep the subject line in= tact and reply to all
> > > email addresses included in the To = and CC lines. (Feel free to cut this
> > > introductory paragra= ph, however.)
> > >
> > >
> > > Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html
> > > for more information about IESG DISCUSS and COMM= ENT positions.
> > >
> > >
> > > The do= cument, along with other ballot positions, can be found here:
> > = > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc40= 06bis/
> > >
> > >
> > >
> &g= t; > -------------------------------------------------------------------= ---
> > > DISCUSS:
> > > --------------------------= --------------------------------------------
> > >
> >= > I support Alissa's Discuss point about sensitive AVPs.
> > &= gt;
> > > I appear to have a different understanding of Section= 5.6.2, though,
> > > with a different potential issue (but aga= in, it's possible that I'm
> > > confused to how things work):<= br>> > >
> > > With the redirection schemes covered in= Section 5.6.2, it sounds
> > > like the user can be redirected= (at the application protocol level,
> > > e.g., HTTP or SIP) t= o a top-up server to purchase more credits.  I
> > > don't= see a way described how user agents can distinguish between a
> >= > Diameter-induced redirect and an attacker-induced redirect to a
&g= t; > > (potentially phishing) site that accepts payment information.&= nbsp; To be
> > > clear, the scenario here is that a user is us= ing a credit-controlled
> > > application session to talk to "a= rbitrary application servers",
> > > including potentially atta= cker-controllled HTTP/SIP/etc. servers;
> > > the attacker coul= d introduce a redirect to a phishing page that asks
> > > for p= ayment information, and the user would be led to believe that
> > = > this was the normal flow for "my prepaid balance has been used up",> > > and give their payment information to the phishing site. I = think
> > > that either user agents need to give some indicatio= n that this
> > > DIAMETER-level redirect is different than an<= br>> > > application-protocol-level redirect (e.g., http) or the S= ecurity
> > > Considerations need to mention the risk of acclim= ating users to
> > > arbitrary websites redirecting to sites as= king for payment
> > > credentials, which may or may not be leg= itimate sites.
> > >
> >
> > I think it=E2=80= =99s reasonable to mention the concern in the security considerations. But = I don=E2=80=99t see how a redirection based on this specification is any di= fferent than any other time an HTTP browser or SIP UA connects to a resourc= e based on an arbitrary URL.
>
> In some sense, it's not. = ; My claim is more that users are being
> conditioned to expect payme= nt prompts to appear at "arbitrary times"
> than a specific flaw in t= his workflow.
>
>
> > But to put some more context a= round this, the Diameter client is typically a Network Access Server (NAS) = that the end user is using for network access. The user is already at the m= ercy of that NAS, and that NAS is at the mercy of the credit-control applic= ation server. The user=E2=80=99s trust in that NAS seems to have the same i= ssues whether or not this Diameter application is used.
> >
>= ; > [yuval] agree with Ben, if someone bad took control over the NAS, th= ey can do much worse
>
> I agree that the NAS could send traff= ic to "wherever", but my
> objection could perhaps be categorized as = more "social" than
> "technical".  Maybe I should attempt to giv= e an example (and you can
> point out if I misunderstand things).
= >
> I believe that a "normal usage" of this technology could be f= or a
> user with a prepaid data plan to be using a web browser, and, = e.g.,
> connect successfully to https://example.com. Suppose that this
> request = used up their last remaining credits, and they click on a
> link from= that page.  Instead of going to the actual target of that
> lin= k, they are redirected to the data plan owner's top-up page,
> which = displays a message "your balance is zero; please enter credit
> card = information to purchase more data", the user pays, and can
> potentia= lly even be redirected back to the actual target of the link
> they c= licked on (though that's not key to my example).  Let's
> consid= er what would happen in an "attack scenario", where the same
> user h= as plenty of data quota remaining, and goes to
> https://honest-achmed.com. They = click on a link from that page,
> which instead of going to an "actua= l site" that would be expected
> from the context surrounding the lin= k, actually goes to
> http://[IP address controlled by attacker]/topu= p.html, which is
> designed to look as similar as possible to the act= ual data plan
> owner's top-up page.  The user may then enter th= eir payment
> information, and get redirected to a site with actual c= ontent,
> believing that they have obtained more data quota from thei= r
> provider, when in reality they have given their credit card
&g= t; information to a phisher.
>
> I don't see what mechanism is= in place to allow the user to be able
> to distinguish between the "= normal usage" scenario and the "attack
> scenario".  I also unde= rstand that this sort of technology is
> already deployed and is seen= as useful by both users and data
> providers, so it seems unrealisti= c to expect to be able to get rid
> of this usage entirely.  I d= o think that it is unreasonable for us
> to enable this behavior with= out documenting the risks to the user,
> though.
>
> [yu= val] I guess that there is nothing in the spec that technically enables phi= shing, however, it makes the social engineering part of it easier. How abou= t the following addition to the security sections:"It is RECOMMENDED that o= perators put in place mechanisms that would help their subscribers identify= a valid redirect operation from a malicious one"
> > > Se= parately, in Section 8.68 (for QoS-Final-Unit-Indication):
> > >= ;
> > >  If the Final-Unit-Action AVP is set to REDIRECT a= t least the
> > >  Redirect-Server-Extension AVP MUST be p= resent.
> > >
> > > This MUST seems in conflict wit= h the text in 8.64 (actually, is
> > > section 8.64 even intern= ally inconsistent, too?) about
> > > "Redirect-Server AVP, in a= ddition to or instead of the
> > > Redirect-Server-Extension AV= P", in particular, the "instead of"
> > > portion.  (The A= BNF-based formal language spec in 8.68 does match up
> > > with= the above MUST, though.)
> >
> > Would changing =E2=80= =9Cin addition to or instead of=E2=80=9D in 8.64 to just =E2=80=9Cin additi= on to=E2=80=9D help?
> >
> > Authors: Please comment if t= hat works, given the backwards-compatibility concern.
> > [yuval] = the cumbersome text is because of backward compatibility issue. Would appri= ciate suggestion for better phrasing. The idea is the following:* We have a= n existing AVP that can carry some information* We need more information, b= ut we cannot modify the existing one, so we added a new AVP (which, unlike = the old one, is future proof)* If you have a peer that does not support the= new spec, but only need the old info, you can use the old AVP. what makes = the spec backward compatible to the old one* If you have need to send the n= ew info, you have to use the new AVP, but in this case an older peer does n= ot make sense
>
> To Ben, I believe that just "in addition to"= resolves the internal
> inconsistency.  However, it sounds like= that may not be the best
> solution from a deployment perspective, a= nd perhaps the formal
> definition in Section 8.68 (and the body text= ) should be relaxed to
> allow either the -Extension or non-Extension= form.
> [yuval] will remove "instead of"

I guess my first res= ponse did not adequately respond to your request
for better phrasing.&nb= sp; Unfortunately, I don't think just different
phrasing would suffice i= f we want to retain the ability to use
just the legacy AVP.  (If we= don't want to retain that ability, then
removing the "instead of" is th= e right thing to do.)

To regain the ability to just use Redirect-Ser= ver without
Redirect-Server-Extension, the text in section 8.68 would ne= ed to
have

OLD:
  If the Final-Unit-Action AVP is set to= REDIRECT at least the
  Redirect-Server-Extension AVP MUST be pre= sent.  The Filter-Rule AVP

NEW:
  If the Final-Unit-Ac= tion AVP is set to REDIRECT, at least one of the
  Redirect-Server= and Redirect-Server-Extension AVPs MUST be present.
  The Filter-= Rule AVP

And probably also to change the formal syntax (though I gue= ss
technically it is not necessary, it would be misleading to leave itas-is):

OLD:
        QoS-Final-Unit-Indica= tion ::=3D < AVP Header: TBD17 >
         = ;                     &nb= sp;   { Final-Unit-Action }
          &nb= sp;                     &= nbsp; *[ Filter-Rule ]
              =                     *[ Fi= lter-Id ]
                 =                 [ Redirect-Server= -Extension ]
                &nb= sp;                 *[ AVP ]
NEW:
        QoS-Final-Unit-Indication ::=3D < = AVP Header: TBD17 >
              =                     { Fi= nal-Unit-Action }
               = ;                   *[ Filter-= Rule ]
                  &n= bsp;               *[ Filter-Id ]
&nb= sp;                     &= nbsp;           [ Redirect-Server ]
  &nb= sp;                     &= nbsp;         [ Redirect-Server-Extension ]
  =                      = ;           *[ AVP ]

(Am I reading RFC 6733= correctly that the ABNF '/' operator is not
used in CCF?)

> &= gt; >
> > > ------------------------------------------------= ----------------------
> > > COMMENT:
> > > -------= ---------------------------------------------------------------
> >= ; >
> > > Some additional significant but not necessarily DI= SCUSS-worthy
> > > comments, followed by more editorial- and ni= t-level things.
> > >
> > > In Section 1.3, "Advert= ising Application Support" uses the same
> > > Auth-Application= -ID value as for RFC 4006; what are the interop
> > > consequen= ces of this?
> > > [yuval] this was done to make interops = easier - this is why we kept this RFC backward compatible with RFC4006
&= gt; > > Alissa already noted that the text about how to split (sub-)A= VPs
> > > between the foo and foo-Extension AVPs is inconsisten= t among them --
> > > e.g., Redirect-Server-Extension and User-= Equipment-Info say "SHOULD
> > > send [in the old one]", but Su= bscription-Id-Extension has separate
> > > text about "[i]f ful= l backward compatibility with [RFC4006] is
> > > required" and = slightly different behavior described.  We should try
> > >= ; to catch all instances of this sort of backwards compatibility and
>= ; > > make them consistent.
> >
> > I agree.
>= ; > [yuval] will look to unify the text
>
> I see that ther= e was some discussion on Alissa's ballot thread that
> there may inde= ed be special considerations for one AVP.  If so,
> that's fine,= but the reasoning should probably be included in the
> document to e= xplain the apparent disparity.
>
> [yuval] ok
>
>= > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-= URL)
> > > might benefit from additional text about the expecte= d contents.  A
> > > lot of the time when we use a UTF8 co= ntainer for names (whether
> > > domain names or other kinds), = we specify what normalization form and
> > > canonicalization a= re performed, whether domain names are A-labels or
> > > U-labe= ls, etc., as there's a lot of potential flexibility not all of
> >= > which is good.  In this case, since the communication is only> > > between trusted actors, perhaps the additional restrictions= are not
> > > needed, but I am curious if the topic was raised= in the WG.
> >
> > On reflection, shouldn=E2=80=99t that= be based on whatever rules already exist for the URL scheme? And if some s= cheme doesn=E2=80=99t have well defined behavior for non-ascii labels, is t= hat the concern of this application?
>
> It is probably a matt= er for the URL scheme, yes.  So at most we
> could note here tha= t "individual URL schemes may restrict the
> contents of the UTF8Stri= ng", but as I imply in my original comment,
> it's far from clear to = me that we actually need to say anything in
> this specific case.
= >
> > >
> > > Thank you for adding the Privacy = Considerations and list of
> > > Privacy-Sensitive AVPs!
>= ; > >
> > > Section 14
> > >
> > >= ;  [...] The Diameter credit-
> > >  control applicat= ion is often used within one domain, and there may be
> > >&nbs= p; a single hop between the peers.  In these environments, the use of<= br>> > >  TLS/TCP, DTLS/SCTP or IPsec is sufficient.
> = > >
> > > I did not see any concrete guidance on what wou= ld suffice in other
> > > environments (with multiple hops betw= een peers).  Is this the realm
> > > of the mythical "end-= to-end security mechanism" for Diameter that is
> > > much-desi= red?  (The last paragraph does have guidance on what might
> >= ; > *not* suffice, which is not exactly the same thing.)
> > &g= t;
> >
> > Sort of, but in real world deployments the =E2= =80=9Coften used within one domain=E2=80=9D (assuming domain means =E2=80= =9Ctrust domain=E2=80=9D, which should be clarified) effectively overrides = everything else. That is far from ideal, but it=E2=80=99s the reality. So i= t basically comes down to keep everything in the trust domain, or if you cr= oss a non-trusted network then use TLS or IPSec.
> >
> > = There=E2=80=99s no solution to safely traverse a non-trusted Diameter agent= . The mythical e2e mechanism could conceivably give us that.  (someday= , along with world peace and a post-scarcity economy).
> >
>= > [yuval] as Ben and Lyle wrote, if your messages need to go through ag= ents that belong to a 3rd party, you have risks. In this case, AVP level en= cryption (which is not standardized yet...) is the only option for to = ensure privacy. So, the only thing we can do here is to highlight the risks= . 
>
> Do we want to say something about "at present, the= re is not a
> general reliable security solution for other environmen= ts"?  (To be
> clear, I do not insiste that we do so.)
> <= br>> [yuval] not sure if AVP level ancryption would ever happen... would= keep text as is
>
> > >  Even without any modifica= tion to the messages, an adversary can
> > >  eavesdrop on= transactions that contain privacy-sensitive information
> > >&= nbsp; about the user.
> > >
> > > This ("an adversa= ry can") makes it sounds as if there is no
> > > confidentialit= y protection anywhere in the system, but that's what
> > > TLS/= DTLS/IPSec are supposed to provide.  So maybe "an adversary that
&g= t; > > can eavesdrop on transactions can obtain privacy-sensitive
= > > > information [...]" is better.
> > >
> >=
> > Good point, I agree your suggestion is better.[yuval] ok
&= gt; >
> > > (Editorial- and nit-level stuff follows.)
>= ; > >
> > > Section 4
> > >
> > >=   A flexible credit-control application specific failure handling is> > >  defined in which the home service provider can model= the credit-
> > >  control client behavior according to i= ts own credit risk management
> > >  policy.
> > = >
> > > This sentence is hard to parse -- in "credit-control= application
> > > specific" what does "specific" bind to? = ; What is being modelled?  Is
> > > anything being control= led (as opposed to modelled)?
> > [yuval] ok. so how about:
>= ; > "Flexible failure handling, specific to the credit-control, is defin= ed in the application.This allows the the service provider to control the c= redit-control client behavior according to its ownrisk management policy">
> That's much better; thanks!
>
> > > Sect= ion 4.1.1
> > >
> > >  2.  The Service-Pa= rameter-Info AVP MAY be used as a container to pass
> > > = legacy rating information in its original encoded form (e.g., ASN.1
>= ; > >  BER).  [...]
> > >
> > > Why= BER and not DER?  The unnecessary flexibility in BER vs. DER has
&= gt; > > been known to tickle parser bugs and create security
> = > > vulnerabilities.
> > > 
> > [yuval] thi= s is just an example of legacy stuff you have no control over
> ><= br>> > > Section 4.1.2
> > >
> > >  [= ...] To
> > >  facilitate interoperability, it is RECOMMEN= DED that the rating input
> > >  and the values of the Ser= vice-Context-Id be coordinated via an
> > >  informational= RFC or other permanent and readily available reference.
> > >&= nbsp; The specification of another cooperative standardization body (e.g.,<= br>> > >  3GPP, OMA, or 3GPP2) SHOULD be used.
> > &= gt;
> > > The RECOMMENDED and SHOULD seem slightly in conflict.=
> > > 
> > [yuval] yes, seems a bit awkward. How= about:
> > "To facilitate interoperability, it is RECOMMENDE= D that the rating input
> > and the values of the Service-Context-= Id be coordinated via an
> > informational RFC or other permanent = and readily available reference,
> > preferably, of another cooper= ative standardization body (e.g.,
> >  3GPP, OMA, or 3GPP2)."=
>
> Sounds good.
>
> > > Section 5.1.1
= > > >
> > > As noted elsewhere, 60 seconds per minute = does not always hold; it
> > > seems that this text could be re= worded to just talk about a
> > > "constant rate" or "constant = level per fixed time period" or
> > > similar.
> > >= ; 
> > [yuval] "constant rate" could mean sub-second resoluti= on as well. The grants are in seconds, so, IMO, this phrasing is more accur= ate
>
> It seems that it's only more accurate if leap seconds = are ignored.
> (I suppose you could explicitly disclaim "(ignoring le= ap seconds)"
> or similar.)
>
> [yuval] will add
>=
> > > Section 5.1.2
> > >
> > > = [...]
> > >  timer (Section 13) every time a CCR message = with the value
> > >  UPDATE_REQUEST is sent while they ar= e in PendingU state.  When
> > >  answers to all pend= ing messages are received, the state machine moves
> > >  = to OPEN state, and Tx is stopped.
> > >
> > > Trans= mission, or the Tx timer (is stopped)?
> > > 
> >= [yuval] well, "Tx" is overloaded :-( but we never use it in the sense of "= transmission" in the RFC
>
> (I think that "Tx timer" was fair= ly consistently used throughout the
> rest of the document; it may ma= ke sense to be fully consistent about
> it.)
>
> [yuval]= will fix in the doc
>
> > > Using a different title for= Section 5.2.2 might make the parallel
> > > between it and Sec= tion 5.2.1 more clear.  That is, perhaps something
> > > l= ike "First Interrogation Included with Authorization Messages".
> >= ; > 
> > [yuval] make sense
> >
> > >= Section 5.7
> > >
> > >  [...] It is RECOMMEN= DED that the client complement the credit-
> > >  control = failure procedures with backup accounting flow toward an
> > >&= nbsp; accounting server. [...]
> > >
> > > Nit: it = looks like there's a missing article here, maybe "a backup
> > >= ; accounting flow" is better.
> > > 
> > [yuval] = the rest of the paragraph describe such "backup accounting flow". See what = comes after "For example"
>
> I just meant that it sounds like= you need to add the word "a" in
> order for the grammar to make sens= e.  (But perhaps "the" is the
> right word; I wasn't sure.)
&= gt;
> [yuval] ok
> > >  The AAA transport profile [= RFC3539] defines the application layer
> > >  watchdog alg= orithm that enables failover from a peer that has failed
> > >&= nbsp; and is controlled by a watchdog timer (Tw) defined in [RFC3539].
&= gt; > >
> > > Nit: Is it "the" watchdog algorithm or "an"= watchdog algorithm?
> > > 
> > [yuval] would ima= gine there are other algorithms out there... should fix
> >
>= ; > > Section 6.2
> > >
> > > Should there be= text indicating how the client indicates what
> > > service th= e balance check is being requested for?
> > > 
> >= ; [yuval] didn't find any reference to service information for "EVET_REQUES= T" type messages (direct debit, refund, balance check and price enquiry). S= eems like that in the IEC section of 3GPP TS 32.299, they added their own m= echanism for "direct debit", and "refund", and leave "balance check" and "p= rice enquiry" as references to RFC4006. Unless I've missed something, this = seems like a missing part of the spec.
> >
> [yuval] hmm. se= ems like "event requests" should be looked at (probably at the light o= f 3GPP 32.299 IEC concept). But for sure *not* as part of this work.
I was mostly wondering whether this section should say anything
about i= ncluding the Service-Identifier AVP.  Looking back at the
document = now, though, maybe this question does not actually make
sense.

-B= enjamin

> > > Section 8.54
> > >
> > &= gt; Maybe give a section reference in RFC 3580 for how the formatting is> > > done?
> > > 
> > [yuval] see sect= ion 3.21 in RFC3580, this is also true for section 8.50 in our RFC
> = >
> > > Section 12
> > >
> > > = [...] Initially, such Expert discussions take place on the AAA
> >= ; >  WG mailing list.
> > >
> > > That list= appears to be dead, suggesting that this text should be
> > > = updated.  (I also agree with Adam's comments about updating the IANA C= onsiderations.)
> > > 
> > [yuval] i don't know t= he process here - not sure how to change it.
>
> With respect = to the "expert discussions take place" text, I think it
> could just = be removed.
>
> Discussion of the detailed updates to the IANA= actions should
> probably happen in Adam's ballot thread.
> > > > Why is the disclaimer in Section B.4 (and other examples) = not needed in Section B.3?
> > [yuval] should be added there as we= ll
>
> Great, thanks.
>
>
> -Benjamin
&= gt;
>
> |
> |
> |  |
> Example Doma= in
>
>
>  |
>
>  |
>
&= gt;  |
>
>
>
> 
------=_Part_5761890_522810928.1527418744892-- From nobody Tue May 29 11:24:35 2018 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 512E712EABB; Tue, 29 May 2018 11:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpHTt8zAZL_t; Tue, 29 May 2018 11:24:29 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE47E12EB06; Tue, 29 May 2018 11:24:28 -0700 (PDT) X-AuditID: 1209190d-525ff700000042e4-4e-5b0d9adbadcb Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.3F.17124.BDA9D0B5; Tue, 29 May 2018 14:24:27 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4TIOPaY004589; Tue, 29 May 2018 14:24:26 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4TIOKrc018928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 May 2018 14:24:23 -0400 Date: Tue, 29 May 2018 13:24:20 -0500 From: Benjamin Kaduk To: Yuval Lifshitz Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <20180529182419.GJ27985@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524212739.GP32807@kduck.kaduk.org> <502594613.5761891.1527418744898@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <502594613.5761891.1527418744898@mail.yahoo.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixG6nrnt7Fm+0wbL/chbzO0+zW6w9mGYx t3cFm8WSiRNYLWb8mchscfzbQ3YHNo8lS34yecza+YTFY9asw0wBzFFcNimpOZllqUX6dglc GcsvhhXM2c9Y8X/rOvYGxkVTGbsYOTkkBEwkHv9tB7K5OIQEFjNJvD09mQXC2cgocbljERuE c5VJouP2ERaQFhYBVYkTmyewgdhsAioSDd2XmUFsEQE1iceNN8AamAX6GSWunz0PlhAWyJb4 NAGigRdo3951r1lBbCGBz0wSe7r4IeKCEidnPgFbwCygLvFn3iWgXg4gW1pi+T8OiLC8RPPW 2WAjOQVsJd6cXQY2UlRAWWJv3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEzpzg1 Wbc4OTEvL7VI10gvN7NELzWldBMjKBY4JXl3MP6763WIUYCDUYmHtyOKN1qINbGsuDL3EKMk B5OSKK9FEVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG/pXp5oId6UxMqq1KJ8mJQ0B4uSOG/2 IsZoIYH0xJLU7NTUgtQimKwMB4eSBO+5mUBDBYtS01Mr0jJzShDSTBycIMN5gIbPAanhLS5I zC3OTIfIn2LU5eh4P6WHWYglLz8vVUqctxykSACkKKM0D24OKIVJZO+vecUoDvSWMC8nMKEJ 8QDTH9ykV0BLmICWPJnIDbKkJBEhJdXAaLs1rs2P7dt8vyd5FQnBmn09z4+2LJA6fa5+b8/F Ljafu3c2sTVza4mu2hY9W+XmvDkuVywYAvkPTbutx//qXobXvt8/alXbrk916//8dfXvTKaa F9XcU2quXtIJcMtjT565bGaIdN0vw2Wb7nDF/rPOWmTom8/wmde98Nk+rW+sTKcfthwMV2Ip zkg01GIuKk4EALF3nLY8AwAA Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 18:24:34 -0000 Ah, of course you are correct that this CCF change makes no sense. Sorry for my confusion on this matter. (Does the body text change make sense to you, though?) -Benjamin On Sun, May 27, 2018 at 10:59:04AM +0000, Yuval Lifshitz wrote: > QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > >                           { Final-Unit-Action }                          *[ Filter-Rule ]                          *[ Filter-Id ]                           [ Redirect-Server ]                           [ Redirect-Server-Extension ]                          *[ AVP ] > if the peer is 4006, and new redirect format is not needed, then sending the legacy "Redirect-Server" AVP inside the new "QoS-Final-Unit-Indication" AVP, won't help with backward compatibility. As the peer won't be able to parse the "QoS-Final-Unit-Indication" AVP. > On Friday, May 25, 2018, 12:27:50 a.m. GMT+3, Benjamin Kaduk wrote: > > Catching up on the non-redirect items... > > On Thu, May 24, 2018 at 06:17:51AM +0000, Yuval Lifshitz wrote: > >  inline > >    On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk wrote:  > >  > >  [re-sending since my client crashed during the first attempt and I > > don't see the message in the archives.  I attempted to reconstruct > > my message from a scrollback buffer, but there may be some artifacts > > with missing or duplicated text] > > > > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > > >  Thanks Ben and Benjamin! Comments inline > > >    On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell wrote: > > > > > >  Hi Benjamin, > > > > > > I’ve cherry-picked a few points, inline: > > > > > > Thanks! > > > > > > Ben. > > > > > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > > > > > I appear to have a different understanding of Section 5.6.2, though, > > > > with a different potential issue (but again, it's possible that I'm > > > > confused to how things work): > > > > > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > > > like the user can be redirected (at the application protocol level, > > > > e.g., HTTP or SIP) to a top-up server to purchase more credits.  I > > > > don't see a way described how user agents can distinguish between a > > > > Diameter-induced redirect and an attacker-induced redirect to a > > > > (potentially phishing) site that accepts payment information.  To be > > > > clear, the scenario here is that a user is using a credit-controlled > > > > application session to talk to "arbitrary application servers", > > > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > > > the attacker could introduce a redirect to a phishing page that asks > > > > for payment information, and the user would be led to believe that > > > > this was the normal flow for "my prepaid balance has been used up", > > > > and give their payment information to the phishing site. I think > > > > that either user agents need to give some indication that this > > > > DIAMETER-level redirect is different than an > > > > application-protocol-level redirect (e.g., http) or the Security > > > > Considerations need to mention the risk of acclimating users to > > > > arbitrary websites redirecting to sites asking for payment > > > > credentials, which may or may not be legitimate sites. > > > > > > > > > > I think it’s reasonable to mention the concern in the security considerations. But I don’t see how a redirection based on this specification is any different than any other time an HTTP browser or SIP UA connects to a resource based on an arbitrary URL. > > > > In some sense, it's not.  My claim is more that users are being > > conditioned to expect payment prompts to appear at "arbitrary times" > > than a specific flaw in this workflow. > > > > > > > But to put some more context around this, the Diameter client is typically a Network Access Server (NAS) that the end user is using for network access. The user is already at the mercy of that NAS, and that NAS is at the mercy of the credit-control application server. The user’s trust in that NAS seems to have the same issues whether or not this Diameter application is used. > > > > > > [yuval] agree with Ben, if someone bad took control over the NAS, they can do much worse > > > > I agree that the NAS could send traffic to "wherever", but my > > objection could perhaps be categorized as more "social" than > > "technical".  Maybe I should attempt to give an example (and you can > > point out if I misunderstand things). > > > > I believe that a "normal usage" of this technology could be for a > > user with a prepaid data plan to be using a web browser, and, e.g., > > connect successfully to https://example.com. Suppose that this > > request used up their last remaining credits, and they click on a > > link from that page.  Instead of going to the actual target of that > > link, they are redirected to the data plan owner's top-up page, > > which displays a message "your balance is zero; please enter credit > > card information to purchase more data", the user pays, and can > > potentially even be redirected back to the actual target of the link > > they clicked on (though that's not key to my example).  Let's > > consider what would happen in an "attack scenario", where the same > > user has plenty of data quota remaining, and goes to > > https://honest-achmed.com. They click on a link from that page, > > which instead of going to an "actual site" that would be expected > > from the context surrounding the link, actually goes to > > http://[IP address controlled by attacker]/topup.html, which is > > designed to look as similar as possible to the actual data plan > > owner's top-up page.  The user may then enter their payment > > information, and get redirected to a site with actual content, > > believing that they have obtained more data quota from their > > provider, when in reality they have given their credit card > > information to a phisher. > > > > I don't see what mechanism is in place to allow the user to be able > > to distinguish between the "normal usage" scenario and the "attack > > scenario".  I also understand that this sort of technology is > > already deployed and is seen as useful by both users and data > > providers, so it seems unrealistic to expect to be able to get rid > > of this usage entirely.  I do think that it is unreasonable for us > > to enable this behavior without documenting the risks to the user, > > though. > > > > [yuval] I guess that there is nothing in the spec that technically enables phishing, however, it makes the social engineering part of it easier. How about the following addition to the security sections:"It is RECOMMENDED that operators put in place mechanisms that would help their subscribers identify a valid redirect operation from a malicious one" > > > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > > > > > >  If the Final-Unit-Action AVP is set to REDIRECT at least the > > > >  Redirect-Server-Extension AVP MUST be present. > > > > > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > > > section 8.64 even internally inconsistent, too?) about > > > > "Redirect-Server AVP, in addition to or instead of the > > > > Redirect-Server-Extension AVP", in particular, the "instead of" > > > > portion.  (The ABNF-based formal language spec in 8.68 does match up > > > > with the above MUST, though.) > > > > > > Would changing “in addition to or instead of” in 8.64 to just “in addition to” help? > > > > > > Authors: Please comment if that works, given the backwards-compatibility concern. > > > [yuval] the cumbersome text is because of backward compatibility issue. Would appriciate suggestion for better phrasing. The idea is the following:* We have an existing AVP that can carry some information* We need more information, but we cannot modify the existing one, so we added a new AVP (which, unlike the old one, is future proof)* If you have a peer that does not support the new spec, but only need the old info, you can use the old AVP. what makes the spec backward compatible to the old one* If you have need to send the new info, you have to use the new AVP, but in this case an older peer does not make sense > > > > To Ben, I believe that just "in addition to" resolves the internal > > inconsistency.  However, it sounds like that may not be the best > > solution from a deployment perspective, and perhaps the formal > > definition in Section 8.68 (and the body text) should be relaxed to > > allow either the -Extension or non-Extension form. > > [yuval] will remove "instead of" > > I guess my first response did not adequately respond to your request > for better phrasing.  Unfortunately, I don't think just different > phrasing would suffice if we want to retain the ability to use > just the legacy AVP.  (If we don't want to retain that ability, then > removing the "instead of" is the right thing to do.) > > To regain the ability to just use Redirect-Server without > Redirect-Server-Extension, the text in section 8.68 would need to > have > > OLD: >   If the Final-Unit-Action AVP is set to REDIRECT at least the >   Redirect-Server-Extension AVP MUST be present.  The Filter-Rule AVP > > NEW: >   If the Final-Unit-Action AVP is set to REDIRECT, at least one of the >   Redirect-Server and Redirect-Server-Extension AVPs MUST be present. >   The Filter-Rule AVP > > And probably also to change the formal syntax (though I guess > technically it is not necessary, it would be misleading to leave it > as-is): > > OLD: >         QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > >                                   { Final-Unit-Action } >                                   *[ Filter-Rule ] >                                   *[ Filter-Id ] >                                   [ Redirect-Server-Extension ] >                                   *[ AVP ] > > NEW: >         QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > >                                   { Final-Unit-Action } >                                   *[ Filter-Rule ] >                                   *[ Filter-Id ] >                                   [ Redirect-Server ] >                                   [ Redirect-Server-Extension ] >                                   *[ AVP ] > > (Am I reading RFC 6733 correctly that the ABNF '/' operator is not > used in CCF?) > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > Some additional significant but not necessarily DISCUSS-worthy > > > > comments, followed by more editorial- and nit-level things. > > > > > > > > In Section 1.3, "Advertising Application Support" uses the same > > > > Auth-Application-ID value as for RFC 4006; what are the interop > > > > consequences of this? > > > > [yuval] this was done to make interops easier - this is why we kept this RFC backward compatible with RFC4006 > > > > Alissa already noted that the text about how to split (sub-)AVPs > > > > between the foo and foo-Extension AVPs is inconsistent among them -- > > > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > > > send [in the old one]", but Subscription-Id-Extension has separate > > > > text about "[i]f full backward compatibility with [RFC4006] is > > > > required" and slightly different behavior described.  We should try > > > > to catch all instances of this sort of backwards compatibility and > > > > make them consistent. > > > > > > I agree. > > > [yuval] will look to unify the text > > > > I see that there was some discussion on Alissa's ballot thread that > > there may indeed be special considerations for one AVP.  If so, > > that's fine, but the reasoning should probably be included in the > > document to explain the apparent disparity. > > > > [yuval] ok > > > > > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) > > > > might benefit from additional text about the expected contents.  A > > > > lot of the time when we use a UTF8 container for names (whether > > > > domain names or other kinds), we specify what normalization form and > > > > canonicalization are performed, whether domain names are A-labels or > > > > U-labels, etc., as there's a lot of potential flexibility not all of > > > > which is good.  In this case, since the communication is only > > > > between trusted actors, perhaps the additional restrictions are not > > > > needed, but I am curious if the topic was raised in the WG. > > > > > > On reflection, shouldn’t that be based on whatever rules already exist for the URL scheme? And if some scheme doesn’t have well defined behavior for non-ascii labels, is that the concern of this application? > > > > It is probably a matter for the URL scheme, yes.  So at most we > > could note here that "individual URL schemes may restrict the > > contents of the UTF8String", but as I imply in my original comment, > > it's far from clear to me that we actually need to say anything in > > this specific case. > > > > > > > > > > Thank you for adding the Privacy Considerations and list of > > > > Privacy-Sensitive AVPs! > > > > > > > > Section 14 > > > > > > > >  [...] The Diameter credit- > > > >  control application is often used within one domain, and there may be > > > >  a single hop between the peers.  In these environments, the use of > > > >  TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > > > > > I did not see any concrete guidance on what would suffice in other > > > > environments (with multiple hops between peers).  Is this the realm > > > > of the mythical "end-to-end security mechanism" for Diameter that is > > > > much-desired?  (The last paragraph does have guidance on what might > > > > *not* suffice, which is not exactly the same thing.) > > > > > > > > > > Sort of, but in real world deployments the “often used within one domain” (assuming domain means “trust domain”, which should be clarified) effectively overrides everything else. That is far from ideal, but it’s the reality. So it basically comes down to keep everything in the trust domain, or if you cross a non-trusted network then use TLS or IPSec. > > > > > > There’s no solution to safely traverse a non-trusted Diameter agent. The mythical e2e mechanism could conceivably give us that.  (someday, along with world peace and a post-scarcity economy). > > > > > > [yuval] as Ben and Lyle wrote, if your messages need to go through agents that belong to a 3rd party, you have risks. In this case, AVP level encryption (which is not standardized yet...) is the only option for to ensure privacy. So, the only thing we can do here is to highlight the risks.  > > > > Do we want to say something about "at present, there is not a > > general reliable security solution for other environments"?  (To be > > clear, I do not insiste that we do so.) > > > > [yuval] not sure if AVP level ancryption would ever happen... would keep text as is > > > > > >  Even without any modification to the messages, an adversary can > > > >  eavesdrop on transactions that contain privacy-sensitive information > > > >  about the user. > > > > > > > > This ("an adversary can") makes it sounds as if there is no > > > > confidentiality protection anywhere in the system, but that's what > > > > TLS/DTLS/IPSec are supposed to provide.  So maybe "an adversary that > > > > can eavesdrop on transactions can obtain privacy-sensitive > > > > information [...]" is better. > > > > > > > > > > Good point, I agree your suggestion is better.[yuval] ok > > > > > > > (Editorial- and nit-level stuff follows.) > > > > > > > > Section 4 > > > > > > > >  A flexible credit-control application specific failure handling is > > > >  defined in which the home service provider can model the credit- > > > >  control client behavior according to its own credit risk management > > > >  policy. > > > > > > > > This sentence is hard to parse -- in "credit-control application > > > > specific" what does "specific" bind to?  What is being modelled?  Is > > > > anything being controlled (as opposed to modelled)? > > > [yuval] ok. so how about: > > > "Flexible failure handling, specific to the credit-control, is defined in the application.This allows the the service provider to control the credit-control client behavior according to its ownrisk management policy" > > > > That's much better; thanks! > > > > > > Section 4.1.1 > > > > > > > >  2.  The Service-Parameter-Info AVP MAY be used as a container to pass > > > >  legacy rating information in its original encoded form (e.g., ASN.1 > > > >  BER).  [...] > > > > > > > > Why BER and not DER?  The unnecessary flexibility in BER vs. DER has > > > > been known to tickle parser bugs and create security > > > > vulnerabilities. > > > >  > > > [yuval] this is just an example of legacy stuff you have no control over > > > > > > > Section 4.1.2 > > > > > > > >  [...] To > > > >  facilitate interoperability, it is RECOMMENDED that the rating input > > > >  and the values of the Service-Context-Id be coordinated via an > > > >  informational RFC or other permanent and readily available reference. > > > >  The specification of another cooperative standardization body (e.g., > > > >  3GPP, OMA, or 3GPP2) SHOULD be used. > > > > > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > > > >  > > > [yuval] yes, seems a bit awkward. How about: > > > "To facilitate interoperability, it is RECOMMENDED that the rating input > > > and the values of the Service-Context-Id be coordinated via an > > > informational RFC or other permanent and readily available reference, > > > preferably, of another cooperative standardization body (e.g., > > >  3GPP, OMA, or 3GPP2)." > > > > Sounds good. > > > > > > Section 5.1.1 > > > > > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > > > seems that this text could be reworded to just talk about a > > > > "constant rate" or "constant level per fixed time period" or > > > > similar. > > > >  > > > [yuval] "constant rate" could mean sub-second resolution as well. The grants are in seconds, so, IMO, this phrasing is more accurate > > > > It seems that it's only more accurate if leap seconds are ignored. > > (I suppose you could explicitly disclaim "(ignoring leap seconds)" > > or similar.) > > > > [yuval] will add > > > > > > Section 5.1.2 > > > > > > > >  [...] > > > >  timer (Section 13) every time a CCR message with the value > > > >  UPDATE_REQUEST is sent while they are in PendingU state.  When > > > >  answers to all pending messages are received, the state machine moves > > > >  to OPEN state, and Tx is stopped. > > > > > > > > Transmission, or the Tx timer (is stopped)? > > > >  > > > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense of "transmission" in the RFC > > > > (I think that "Tx timer" was fairly consistently used throughout the > > rest of the document; it may make sense to be fully consistent about > > it.) > > > > [yuval] will fix in the doc > > > > > > Using a different title for Section 5.2.2 might make the parallel > > > > between it and Section 5.2.1 more clear.  That is, perhaps something > > > > like "First Interrogation Included with Authorization Messages". > > > >  > > > [yuval] make sense > > > > > > > Section 5.7 > > > > > > > >  [...] It is RECOMMENDED that the client complement the credit- > > > >  control failure procedures with backup accounting flow toward an > > > >  accounting server. [...] > > > > > > > > Nit: it looks like there's a missing article here, maybe "a backup > > > > accounting flow" is better. > > > >  > > > [yuval] the rest of the paragraph describe such "backup accounting flow". See what comes after "For example" > > > > I just meant that it sounds like you need to add the word "a" in > > order for the grammar to make sense.  (But perhaps "the" is the > > right word; I wasn't sure.) > > > > [yuval] ok > > > >  The AAA transport profile [RFC3539] defines the application layer > > > >  watchdog algorithm that enables failover from a peer that has failed > > > >  and is controlled by a watchdog timer (Tw) defined in [RFC3539]. > > > > > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > > > >  > > > [yuval] would imagine there are other algorithms out there... should fix > > > > > > > Section 6.2 > > > > > > > > Should there be text indicating how the client indicates what > > > > service the balance check is being requested for? > > > >  > > > [yuval] didn't find any reference to service information for "EVET_REQUEST" type messages (direct debit, refund, balance check and price enquiry). Seems like that in the IEC section of 3GPP TS 32.299, they added their own mechanism for "direct debit", and "refund", and leave "balance check" and "price enquiry" as references to RFC4006. Unless I've missed something, this seems like a missing part of the spec. > > > > > [yuval] hmm. seems like "event requests" should be looked at (probably at the light of 3GPP 32.299 IEC concept). But for sure *not* as part of this work. > > I was mostly wondering whether this section should say anything > about including the Service-Identifier AVP.  Looking back at the > document now, though, maybe this question does not actually make > sense. > > -Benjamin > > > > > Section 8.54 > > > > > > > > Maybe give a section reference in RFC 3580 for how the formatting is > > > > done? > > > >  > > > [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 in our RFC > > > > > > > Section 12 > > > > > > > >  [...] Initially, such Expert discussions take place on the AAA > > > >  WG mailing list. > > > > > > > > That list appears to be dead, suggesting that this text should be > > > > updated.  (I also agree with Adam's comments about updating the IANA Considerations.) > > > >  > > > [yuval] i don't know the process here - not sure how to change it. > > > > With respect to the "expert discussions take place" text, I think it > > could just be removed. > > > > Discussion of the detailed updates to the IANA actions should > > probably happen in Adam's ballot thread. > > > > > > Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3? > > > [yuval] should be added there as well > > > > Great, thanks. > > > > > > -Benjamin > > > > > > | > > | > > |  | > > Example Domain > > > > > >  | > > > >  | > > > >  | > > > > > > > >  > From nobody Tue May 29 12:05:00 2018 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 A2FAA12EB46 for ; Tue, 29 May 2018 12:04:58 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R1H2O4ifcqC for ; Tue, 29 May 2018 12:04:52 -0700 (PDT) Received: from sonic301-4.consmr.mail.bf2.yahoo.com (sonic301-4.consmr.mail.bf2.yahoo.com [74.6.129.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213D512E86A for ; Tue, 29 May 2018 12:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527620691; bh=aoGapdBSmd00xm4p/hJuEFU6D3IV+Pe5eyFDlPznYV4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=GYSr6m9j0U0Uncn9snLmQQE/lMKYlmR7iEkfDtijV/1T0Xt2V7rFujJ45tRi2LqtkcR84HmxVhOBfO48IfXHEo1W6dmIcKP6G3RB+yXvSTH3+xEVy6devFu5mLHaNkUgqwXGdqUKGgwqYOovZms1PY2Pa4GHUZ9a9WAEKcVWCGvjCkMMfaHwDSoS/ZIPFMMyLqyq+BFgtnfOvwCgpAxb/9gH7whmCtW9PmcwH1NixUTCfG8KeoIfw0JtE7PjC3ZKlH2DBMasyQc841Gmoiu4HttHQ0fkp6Lt5tClDfBl/3z9lwHB9JqZwxFIPnBqa4GBcJMEzvR3mmCwIhZl5FF3kg== X-YMail-OSG: RWlp3HEVM1k1FgDBqyjVcKbkJOnu.UxoaCwDYn56ZQIgjmny5FSSTbzoSXTNRNt nNsQ6tUlUrNfwlhPCeKu3LVKW6a4ZjCNNBqtoNvls5.rIBDu332xXM.jpQcC.2MT3zxNAPOIYmkG 4aURfmNP7QR2hgxR3ooPyrHQdrgEFbHYnj0rKLylu762HeFNlhPo1ZUelJp0G9OjLwDWkhmcZPke XK.hJUi2vzfpAFERZCMWK7UUx7HGgH0DQxe.XjsTZSYN9qXqHy_jm5ZpBGgPV6sqgPHD4WFV51oR c.7GY..ER.pGi1ohP_kShlSJNs19FeGQPq1IuKOJMFd5w8ey39ijJCdzk_ZNtAOZdvOAmGOriJhM WCzG27QB3hPn_H471k95Tou30L6dm2mik4MAOHpjsj6KMCUkIzVaiDHD3c0uETC7QMp6V7wNOrlM 0JyClQLQyvg5lZbszhEV4H_mC6N4yYHlKKC6sg3HK1zznRlPJiKWExO2.V3RykRS4WOtL8b4foOC IC1A1qf07LlyBWMz7pGgfPnOFioHTPa7KiMak.WkPXNMvoQCn7kBRYdHumHZi3w3r2mbWeCQ0nBS 24R3Majn99k94hx_CEcAT2OlTN5NM_mMXfZhftwfTp6lE2Ly_kkAHMIp1q79SmuDBnVflGxLJemZ _UuzMwGw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Tue, 29 May 2018 19:04:51 +0000 Date: Tue, 29 May 2018 18:54:49 +0000 (UTC) From: Yuval Lifshitz To: Benjamin Kaduk Cc: Ben Campbell , dime-chairs@ietf.org, dime@ietf.org, The IESG , draft-ietf-dime-rfc4006bis@ietf.org Message-ID: <1294588061.6493079.1527620089234@mail.yahoo.com> In-Reply-To: <20180529182419.GJ27985@kduck.kaduk.org> References: <152699690275.31181.16673564293046142291.idtracker@ietfa.amsl.com> <57F7AC78-C094-402D-8834-3AC049EED31E@nostrum.com> <380581659.4450262.1527064311638@mail.yahoo.com> <20180523135822.GA32807@kduck.kaduk.org> <1467920717.4840713.1527142671894@mail.yahoo.com> <20180524212739.GP32807@kduck.kaduk.org> <502594613.5761891.1527418744898@mail.yahoo.com> <20180529182419.GJ27985@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6493078_282856483.1527620089226" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Archived-At: Subject: Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 19:04:59 -0000 ------=_Part_6493078_282856483.1527620089226 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes, the new text you proposed makes sense, and is more clear. Yuval On Tuesday, May 29, 2018, 9:24:28 p.m. GMT+3, Benjamin Kaduk wrote: =20 =20 Ah, of course you are correct that this CCF change makes no sense. Sorry for my confusion on this matter. (Does the body text change make sense to you, though?) -Benjamin On Sun, May 27, 2018 at 10:59:04AM +0000, Yuval Lifshitz wrote: >=C2=A0 QoS-Final-Unit-Indication ::=3D < AVP Header: TBD17 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 { Final-Unit-Action }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Rule ]=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 *[ Filter-Id ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Redirect-Server ]=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[ Redirect-Server-Extension ]=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] > if the peer is 4006, and new redirect format is not needed, then sending = the legacy "Redirect-Server" AVP inside the=C2=A0new "QoS-Final-Unit-Indica= tion" AVP, won't help with backward compatibility. As the peer won't be abl= e to parse the=C2=A0"QoS-Final-Unit-Indication" AVP. >=C2=A0 =C2=A0 On Friday, May 25, 2018, 12:27:50 a.m. GMT+3, Benjamin Kaduk= wrote:=C2=A0=20 >=C2=A0=20 >=C2=A0 Catching up on the non-redirect items... >=20 > On Thu, May 24, 2018 at 06:17:51AM +0000, Yuval Lifshitz wrote: > >=C2=A0 inline > >=C2=A0 =C2=A0 On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin K= aduk wrote:=C2=A0=20 > >=C2=A0=20 > >=C2=A0 [re-sending since my client crashed during the first attempt and = I > > don't see the message in the archives.=C2=A0 I attempted to reconstruct > > my message from a scrollback buffer, but there may be some artifacts > > with missing or duplicated text] > >=20 > > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote: > > >=C2=A0 Thanks Ben and Benjamin! Comments inline > > >=C2=A0 =C2=A0 On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Camp= bell wrote: > > > > > >=C2=A0 Hi Benjamin, > > > > > > I=E2=80=99ve cherry-picked a few points, inline: > > > > > > Thanks! > > > > > > Ben. > > > > > > > On May 22, 2018, at 8:48 AM, Benjamin Kaduk wrote: > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-dime-rfc4006bis-08: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to a= ll > > > > email addresses included in the To and CC lines. (Feel free to cut = this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteri= a.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------= --- > > > > DISCUSS: > > > > -------------------------------------------------------------------= --- > > > > > > > > I support Alissa's Discuss point about sensitive AVPs. > > > > > > > > I appear to have a different understanding of Section 5.6.2, though= , > > > > with a different potential issue (but again, it's possible that I'm > > > > confused to how things work): > > > > > > > > With the redirection schemes covered in Section 5.6.2, it sounds > > > > like the user can be redirected (at the application protocol level, > > > > e.g., HTTP or SIP) to a top-up server to purchase more credits.=C2= =A0 I > > > > don't see a way described how user agents can distinguish between a > > > > Diameter-induced redirect and an attacker-induced redirect to a > > > > (potentially phishing) site that accepts payment information.=C2=A0= To be > > > > clear, the scenario here is that a user is using a credit-controlle= d > > > > application session to talk to "arbitrary application servers", > > > > including potentially attacker-controllled HTTP/SIP/etc. servers; > > > > the attacker could introduce a redirect to a phishing page that ask= s > > > > for payment information, and the user would be led to believe that > > > > this was the normal flow for "my prepaid balance has been used up", > > > > and give their payment information to the phishing site. I think > > > > that either user agents need to give some indication that this > > > > DIAMETER-level redirect is different than an > > > > application-protocol-level redirect (e.g., http) or the Security > > > > Considerations need to mention the risk of acclimating users to > > > > arbitrary websites redirecting to sites asking for payment > > > > credentials, which may or may not be legitimate sites. > > > > > > > > > > I think it=E2=80=99s reasonable to mention the concern in the securit= y considerations. But I don=E2=80=99t see how a redirection based on this s= pecification is any different than any other time an HTTP browser or SIP UA= connects to a resource based on an arbitrary URL. > >=20 > > In some sense, it's not.=C2=A0 My claim is more that users are being > > conditioned to expect payment prompts to appear at "arbitrary times" > > than a specific flaw in this workflow. > >=20 > >=20 > > > But to put some more context around this, the Diameter client is typi= cally a Network Access Server (NAS) that the end user is using for network = access. The user is already at the mercy of that NAS, and that NAS is at th= e mercy of the credit-control application server. The user=E2=80=99s trust = in that NAS seems to have the same issues whether or not this Diameter appl= ication is used. > > > > > > [yuval] agree with Ben, if someone bad took control over the NAS, the= y can do much worse > >=20 > > I agree that the NAS could send traffic to "wherever", but my > > objection could perhaps be categorized as more "social" than > > "technical".=C2=A0 Maybe I should attempt to give an example (and you c= an > > point out if I misunderstand things). > >=20 > > I believe that a "normal usage" of this technology could be for a > > user with a prepaid data plan to be using a web browser, and, e.g., > > connect successfully to https://example.com. Suppose that this > > request used up their last remaining credits, and they click on a > > link from that page.=C2=A0 Instead of going to the actual target of tha= t > > link, they are redirected to the data plan owner's top-up page, > > which displays a message "your balance is zero; please enter credit > > card information to purchase more data", the user pays, and can > > potentially even be redirected back to the actual target of the link > > they clicked on (though that's not key to my example).=C2=A0 Let's > > consider what would happen in an "attack scenario", where the same > > user has plenty of data quota remaining, and goes to > > https://honest-achmed.com. They click on a link from that page, > > which instead of going to an "actual site" that would be expected > > from the context surrounding the link, actually goes to > > http://[IP address controlled by attacker]/topup.html, which is > > designed to look as similar as possible to the actual data plan > > owner's top-up page.=C2=A0 The user may then enter their payment > > information, and get redirected to a site with actual content, > > believing that they have obtained more data quota from their > > provider, when in reality they have given their credit card > > information to a phisher. > >=20 > > I don't see what mechanism is in place to allow the user to be able > > to distinguish between the "normal usage" scenario and the "attack > > scenario".=C2=A0 I also understand that this sort of technology is > > already deployed and is seen as useful by both users and data > > providers, so it seems unrealistic to expect to be able to get rid > > of this usage entirely.=C2=A0 I do think that it is unreasonable for us > > to enable this behavior without documenting the risks to the user, > > though. > >=20 > > [yuval] I guess that there is nothing in the spec that technically enab= les phishing, however, it makes the social engineering part of it easier. H= ow about the following addition to the security sections:"It is RECOMMENDED= that operators put in place mechanisms that would help their subscribers i= dentify a valid redirect operation from a malicious=C2=A0one" > > > > Separately, in Section 8.68 (for QoS-Final-Unit-Indication): > > > > > > > >=C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the > > > >=C2=A0 Redirect-Server-Extension AVP MUST be present. > > > > > > > > This MUST seems in conflict with the text in 8.64 (actually, is > > > > section 8.64 even internally inconsistent, too?) about > > > > "Redirect-Server AVP, in addition to or instead of the > > > > Redirect-Server-Extension AVP", in particular, the "instead of" > > > > portion.=C2=A0 (The ABNF-based formal language spec in 8.68 does ma= tch up > > > > with the above MUST, though.) > > > > > > Would changing =E2=80=9Cin addition to or instead of=E2=80=9D in 8.64= to just =E2=80=9Cin addition to=E2=80=9D help? > > > > > > Authors: Please comment if that works, given the backwards-compatibil= ity concern. > > > [yuval] the cumbersome text is because of backward compatibility issu= e. Would appriciate suggestion for better phrasing. The idea is the followi= ng:* We have an existing AVP that can carry some information* We need more = information, but we cannot modify the existing one, so we added a new AVP (= which, unlike the old one, is future proof)* If you have a peer that does n= ot support the new spec, but only need the old info, you can use the old AV= P. what makes the spec backward compatible to the old one* If you have need= to send the new info, you have to use the new AVP, but in this case an old= er peer does not make sense > >=20 > > To Ben, I believe that just "in addition to" resolves the internal > > inconsistency.=C2=A0 However, it sounds like that may not be the best > > solution from a deployment perspective, and perhaps the formal > > definition in Section 8.68 (and the body text) should be relaxed to > > allow either the -Extension or non-Extension form. > > [yuval] will remove "instead of" >=20 > I guess my first response did not adequately respond to your request > for better phrasing.=C2=A0 Unfortunately, I don't think just different > phrasing would suffice if we want to retain the ability to use > just the legacy AVP.=C2=A0 (If we don't want to retain that ability, then > removing the "instead of" is the right thing to do.) >=20 > To regain the ability to just use Redirect-Server without > Redirect-Server-Extension, the text in section 8.68 would need to > have >=20 > OLD: > =C2=A0 If the Final-Unit-Action AVP is set to REDIRECT at least the > =C2=A0 Redirect-Server-Extension AVP MUST be present.=C2=A0 The Filter-Ru= le AVP >=20 > NEW: > =C2=A0 If the Final-Unit-Action AVP is set to REDIRECT, at least one of t= he > =C2=A0 Redirect-Server and Redirect-Server-Extension AVPs MUST be present= . > =C2=A0 The Filter-Rule AVP >=20 > And probably also to change the formal syntax (though I guess > technically it is not necessary, it would be misleading to leave it > as-is): >=20 > OLD: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS-Final-Unit-Indication ::=3D < AVP Header:= TBD17 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { Final-Unit-Action } > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Rule ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Id ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Redirect-Server-Extension ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] >=20 > NEW: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS-Final-Unit-Indication ::=3D < AVP Header:= TBD17 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { Final-Unit-Action } > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Rule ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ Filter-Id ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Redirect-Server ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ Redirect-Server-Extension ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[ AVP ] >=20 > (Am I reading RFC 6733 correctly that the ABNF '/' operator is not > used in CCF?) >=20 > > > > > > > > -------------------------------------------------------------------= --- > > > > COMMENT: > > > > -------------------------------------------------------------------= --- > > > > > > > > Some additional significant but not necessarily DISCUSS-worthy > > > > comments, followed by more editorial- and nit-level things. > > > > > > > > In Section 1.3, "Advertising Application Support" uses the same > > > > Auth-Application-ID value as for RFC 4006; what are the interop > > > > consequences of this? > > > >=C2=A0[yuval] this was done to make interops easier - this is why we= kept this RFC backward compatible with RFC4006 > > > > Alissa already noted that the text about how to split (sub-)AVPs > > > > between the foo and foo-Extension AVPs is inconsistent among them -= - > > > > e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD > > > > send [in the old one]", but Subscription-Id-Extension has separate > > > > text about "[i]f full backward compatibility with [RFC4006] is > > > > required" and slightly different behavior described.=C2=A0 We shoul= d try > > > > to catch all instances of this sort of backwards compatibility and > > > > make them consistent. > > > > > > I agree. > > > [yuval] will look to unify the text > >=20 > > I see that there was some discussion on Alissa's ballot thread that > > there may indeed be special considerations for one AVP.=C2=A0 If so, > > that's fine, but the reasoning should probably be included in the > > document to explain the apparent disparity. > >=20 > > [yuval] ok > >=20 > > > > The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL= ) > > > > might benefit from additional text about the expected contents.=C2= =A0 A > > > > lot of the time when we use a UTF8 container for names (whether > > > > domain names or other kinds), we specify what normalization form an= d > > > > canonicalization are performed, whether domain names are A-labels o= r > > > > U-labels, etc., as there's a lot of potential flexibility not all o= f > > > > which is good.=C2=A0 In this case, since the communication is only > > > > between trusted actors, perhaps the additional restrictions are not > > > > needed, but I am curious if the topic was raised in the WG. > > > > > > On reflection, shouldn=E2=80=99t that be based on whatever rules alre= ady exist for the URL scheme? And if some scheme doesn=E2=80=99t have well = defined behavior for non-ascii labels, is that the concern of this applicat= ion? > >=20 > > It is probably a matter for the URL scheme, yes.=C2=A0 So at most we > > could note here that "individual URL schemes may restrict the > > contents of the UTF8String", but as I imply in my original comment, > > it's far from clear to me that we actually need to say anything in > > this specific case. > >=20 > > > > > > > > Thank you for adding the Privacy Considerations and list of > > > > Privacy-Sensitive AVPs! > > > > > > > > Section 14 > > > > > > > >=C2=A0 [...] The Diameter credit- > > > >=C2=A0 control application is often used within one domain, and ther= e may be > > > >=C2=A0 a single hop between the peers.=C2=A0 In these environments, = the use of > > > >=C2=A0 TLS/TCP, DTLS/SCTP or IPsec is sufficient. > > > > > > > > I did not see any concrete guidance on what would suffice in other > > > > environments (with multiple hops between peers).=C2=A0 Is this the = realm > > > > of the mythical "end-to-end security mechanism" for Diameter that i= s > > > > much-desired?=C2=A0 (The last paragraph does have guidance on what = might > > > > *not* suffice, which is not exactly the same thing.) > > > > > > > > > > Sort of, but in real world deployments the =E2=80=9Coften used within= one domain=E2=80=9D (assuming domain means =E2=80=9Ctrust domain=E2=80=9D,= which should be clarified) effectively overrides everything else. That is = far from ideal, but it=E2=80=99s the reality. So it basically comes down to= keep everything in the trust domain, or if you cross a non-trusted network= then use TLS or IPSec. > > > > > > There=E2=80=99s no solution to safely traverse a non-trusted Diameter= agent. The mythical e2e mechanism could conceivably give us that.=C2=A0 (s= omeday, along with world peace and a post-scarcity economy). > > > > > > [yuval] as Ben and Lyle wrote, if your messages need to go through ag= ents that belong to a 3rd party, you have risks. In this case, AVP level en= cryption (which is not standardized=C2=A0yet...) is the only option for to = ensure privacy. So, the only thing we can do here is to highlight the risks= .=C2=A0 > >=20 > > Do we want to say something about "at present, there is not a > > general reliable security solution for other environments"?=C2=A0 (To b= e > > clear, I do not insiste that we do so.) > >=20 > > [yuval] not sure if AVP level ancryption would ever happen... would kee= p text as is > >=20 > > > >=C2=A0 Even without any modification to the messages, an adversary c= an > > > >=C2=A0 eavesdrop on transactions that contain privacy-sensitive info= rmation > > > >=C2=A0 about the user. > > > > > > > > This ("an adversary can") makes it sounds as if there is no > > > > confidentiality protection anywhere in the system, but that's what > > > > TLS/DTLS/IPSec are supposed to provide.=C2=A0 So maybe "an adversar= y that > > > > can eavesdrop on transactions can obtain privacy-sensitive > > > > information [...]" is better. > > > > > > > > > > Good point, I agree your suggestion is better.[yuval] ok > > > > > > > (Editorial- and nit-level stuff follows.) > > > > > > > > Section 4 > > > > > > > >=C2=A0 A flexible credit-control application specific failure handli= ng is > > > >=C2=A0 defined in which the home service provider can model the cred= it- > > > >=C2=A0 control client behavior according to its own credit risk mana= gement > > > >=C2=A0 policy. > > > > > > > > This sentence is hard to parse -- in "credit-control application > > > > specific" what does "specific" bind to?=C2=A0 What is being modelle= d?=C2=A0 Is > > > > anything being controlled (as opposed to modelled)? > > > [yuval] ok. so how about: > > > "Flexible failure handling, specific to the credit-control, is define= d in the application.This allows the the service provider to control the cr= edit-control client behavior according to its ownrisk management policy" > >=20 > > That's much better; thanks! > >=20 > > > > Section 4.1.1 > > > > > > > >=C2=A0 2.=C2=A0 The Service-Parameter-Info AVP MAY be used as a cont= ainer to pass > > > >=C2=A0 legacy rating information in its original encoded form (e.g.,= ASN.1 > > > >=C2=A0 BER).=C2=A0 [...] > > > > > > > > Why BER and not DER?=C2=A0 The unnecessary flexibility in BER vs. D= ER has > > > > been known to tickle parser bugs and create security > > > > vulnerabilities. > > > >=C2=A0 > > > [yuval] this is just an example of legacy stuff you have no control o= ver > > > > > > > Section 4.1.2 > > > > > > > >=C2=A0 [...] To > > > >=C2=A0 facilitate interoperability, it is RECOMMENDED that the ratin= g input > > > >=C2=A0 and the values of the Service-Context-Id be coordinated via a= n > > > >=C2=A0 informational RFC or other permanent and readily available re= ference. > > > >=C2=A0 The specification of another cooperative standardization body= (e.g., > > > >=C2=A0 3GPP, OMA, or 3GPP2) SHOULD be used. > > > > > > > > The RECOMMENDED and SHOULD seem slightly in conflict. > > > >=C2=A0 > > > [yuval] yes, seems a bit awkward. How about: > > > "To=C2=A0facilitate interoperability, it is RECOMMENDED that the rati= ng input > > > and the values of the Service-Context-Id be coordinated via an > > > informational RFC or other permanent and readily available reference, > > > preferably, of another cooperative standardization body (e.g., > > > =C2=A03GPP, OMA, or 3GPP2)." > >=20 > > Sounds good. > >=20 > > > > Section 5.1.1 > > > > > > > > As noted elsewhere, 60 seconds per minute does not always hold; it > > > > seems that this text could be reworded to just talk about a > > > > "constant rate" or "constant level per fixed time period" or > > > > similar. > > > >=C2=A0 > > > [yuval] "constant rate" could mean sub-second resolution as well. The= grants are in seconds, so, IMO, this phrasing is more accurate > >=20 > > It seems that it's only more accurate if leap seconds are ignored. > > (I suppose you could explicitly disclaim "(ignoring leap seconds)" > > or similar.) > >=20 > > [yuval] will add > >=20 > > > > Section 5.1.2 > > > > > > > >=C2=A0 [...] > > > >=C2=A0 timer (Section 13) every time a CCR message with the value > > > >=C2=A0 UPDATE_REQUEST is sent while they are in PendingU state.=C2= =A0 When > > > >=C2=A0 answers to all pending messages are received, the state machi= ne moves > > > >=C2=A0 to OPEN state, and Tx is stopped. > > > > > > > > Transmission, or the Tx timer (is stopped)? > > > >=C2=A0 > > > [yuval] well, "Tx" is overloaded :-( but we never use it in the sense= of "transmission" in the RFC > >=20 > > (I think that "Tx timer" was fairly consistently used throughout the > > rest of the document; it may make sense to be fully consistent about > > it.) > >=20 > > [yuval] will fix in the doc > >=20 > > > > Using a different title for Section 5.2.2 might make the parallel > > > > between it and Section 5.2.1 more clear.=C2=A0 That is, perhaps som= ething > > > > like "First Interrogation Included with Authorization Messages". > > > >=C2=A0 > > > [yuval] make sense > > > > > > > Section 5.7 > > > > > > > >=C2=A0 [...] It is RECOMMENDED that the client complement the credit= - > > > >=C2=A0 control failure procedures with backup accounting flow toward= an > > > >=C2=A0 accounting server. [...] > > > > > > > > Nit: it looks like there's a missing article here, maybe "a backup > > > > accounting flow" is better. > > > >=C2=A0 > > > [yuval] the rest of the paragraph describe such "backup accounting fl= ow". See what comes after "For example" > >=20 > > I just meant that it sounds like you need to add the word "a" in > > order for the grammar to make sense.=C2=A0 (But perhaps "the" is the > > right word; I wasn't sure.) > >=20 > > [yuval] ok > > > >=C2=A0 The AAA transport profile [RFC3539] defines the application l= ayer > > > >=C2=A0 watchdog algorithm that enables failover from a peer that has= failed > > > >=C2=A0 and is controlled by a watchdog timer (Tw) defined in [RFC353= 9]. > > > > > > > > Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? > > > >=C2=A0 > > > [yuval] would imagine there are other algorithms out there... should = fix > > > > > > > Section 6.2 > > > > > > > > Should there be text indicating how the client indicates what > > > > service the balance check is being requested for? > > > >=C2=A0 > > > [yuval] didn't find any reference to service information for "EVET_RE= QUEST" type messages (direct debit, refund, balance check and price enquiry= ). Seems like that in the IEC section of 3GPP TS 32.299, they added their o= wn mechanism for "direct debit", and "refund", and leave "balance check" an= d "price enquiry" as references to RFC4006. Unless I've missed something, t= his seems like a missing part of the spec. > > > > > [yuval] hmm. seems like "event requests"=C2=A0should be looked at (prob= ably at the light of 3GPP 32.299 IEC concept). But for sure *not* as part o= f this work. >=20 > I was mostly wondering whether this section should say anything > about including the Service-Identifier AVP.=C2=A0 Looking back at the > document now, though, maybe this question does not actually make > sense. >=20 > -Benjamin >=20 > > > > Section 8.54 > > > > > > > > Maybe give a section reference in RFC 3580 for how the formatting i= s > > > > done? > > > >=C2=A0 > > > [yuval] see section 3.21 in RFC3580, this is also true for section 8.= 50 in our RFC > > > > > > > Section 12 > > > > > > > >=C2=A0 [...] Initially, such Expert discussions take place on the AA= A > > > >=C2=A0 WG mailing list. > > > > > > > > That list appears to be dead, suggesting that this text should be > > > > updated.=C2=A0 (I also agree with Adam's comments about updating th= e IANA Considerations.) > > > >=C2=A0 > > > [yuval] i don't know the process here - not sure how to change it. > >=20 > > With respect to the "expert discussions take place" text, I think it > > could just be removed. > >=20 > > Discussion of the detailed updates to the IANA actions should > > probably happen in Adam's ballot thread. > >=20 > > > > Why is the disclaimer in Section B.4 (and other examples) not neede= d in Section B.3? > > > [yuval] should be added there as well > >=20 > > Great, thanks. > >=20 > >=20 > > -Benjamin > >=20 > >=20 > > |=20 > > |=20 > > |=C2=A0 |=20 > > Example Domain > >=20 > >=20 > >=C2=A0 | > >=20 > >=C2=A0 | > >=20 > >=C2=A0 | > >=20 > >=20 > >=20 > >=C2=A0=20 >=C2=A0=20 =20 ------=_Part_6493078_282856483.1527620089226 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes, the new text you proposed makes sense, and is more cl= ear.

Yuval

=20
=20
On Tuesday, May 29, 2018, 9:24:28 p.m. GMT+3, Benja= min Kaduk <kaduk@mit.edu> wrote:


Ah, of course you are correct that this CCF change= makes no sense.
Sorry for my confusion on this matter.(Does the body text change make sense to you, though?)

-Benjamin

On Sun, May 27, 2018 a= t 10:59:04AM +0000, Yuval Lifshitz wrote:
>  QoS-= Final-Unit-Indication ::=3D < AVP Header: TBD17 >
&= gt;                     &= nbsp;     { Final-Unit-Action }         =                 *[ Filter-Rule ]&n= bsp;                     =     *[ Filter-Id ]             = ;              [ Redirect-Server ] =                     &nbs= p;    [ Redirect-Server-Extension ]        &n= bsp;                 *[ AVP ]
> if the peer is 4006, and new redirect format is not neede= d, then sending the legacy "Redirect-Server" AVP inside the new "QoS-F= inal-Unit-Indication" AVP, won't help with backward compatibility. As the p= eer won't be able to parse the "QoS-Final-Unit-Indication" AVP.
>    On Friday, May 25, 2018, 12:27:50 a.m. GMT+3= , Benjamin Kaduk <kaduk@mit.edu> wrote: 
> 
>  Catching up on the non-redir= ect items...
>
> On Thu, May 24,= 2018 at 06:17:51AM +0000, Yuval Lifshitz wrote:
> >= ;  inline
> >    On Wednesday, May 2= 3, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk <kaduk@mit.edu&g= t; wrote: 
> > 
> = >  [re-sending since my client crashed during the first attempt and= I
> > don't see the message in the archives. = I attempted to reconstruct
> > my message from a s= crollback buffer, but there may be some artifacts
> &g= t; with missing or duplicated text]
> >
> > On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshit= z wrote:
> > >  Thanks Ben and Benjamin! Co= mments inline
> > >    On Wednesday, M= ay 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell <ben@nostrum.com= > wrote:
> > >
> >= ; >  Hi Benjamin,
> > >
> > > I=E2=80=99ve cherry-picked a few points, inline:
> > >
> > > Thanks!
> > >
> > > Ben.
> > >
> > > > On May 22, 2018,= at 8:48 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> > > >
> > > > Benjami= n Kaduk has entered the following ballot position for
>= ; > > > draft-ietf-dime-rfc4006bis-08: Discuss
&= gt; > > >
> > > > When responding, p= lease keep the subject line intact and reply to all
> = > > > email addresses included in the To and CC lines. (Feel free = to cut this
> > > > introductory paragraph, h= owever.)
> > > >
> > = > >
> > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<= /a>
> > > > for more information about IESG D= ISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The do= cument, along with other ballot positions, can be found here:
> > > > https://datatracker= .ietf.org/doc/draft-ietf-dime-rfc4006bis/
> > &= gt; >
> > > >
> > = > >
> > > > ---------------------------= -------------------------------------------
> > >= ; > DISCUSS:
> > > > ---------------------= -------------------------------------------------
> &g= t; > >
> > > > I support Alissa's Discu= ss point about sensitive AVPs.
> > > >
> > > > I appear to have a different understanding = of Section 5.6.2, though,
> > > > with a diff= erent potential issue (but again, it's possible that I'm
= > > > > confused to how things work):
> &g= t; > >
> > > > With the redirection sch= emes covered in Section 5.6.2, it sounds
> > > &= gt; like the user can be redirected (at the application protocol level,
> > > > e.g., HTTP or SIP) to a top-up server to= purchase more credits.  I
> > > > don't= see a way described how user agents can distinguish between a
> > > > Diameter-induced redirect and an attacker-induced= redirect to a
> > > > (potentially phishing)= site that accepts payment information.  To be
> = > > > clear, the scenario here is that a user is using a credit-co= ntrolled
> > > > application session to talk = to "arbitrary application servers",
> > > > i= ncluding potentially attacker-controllled HTTP/SIP/etc. servers;
> > > > the attacker could introduce a redirect to a = phishing page that asks
> > > > for payment i= nformation, and the user would be led to believe that
>= ; > > > this was the normal flow for "my prepaid balance has been = used up",
> > > > and give their payment info= rmation to the phishing site. I think
> > > >= that either user agents need to give some indication that this
> > > > DIAMETER-level redirect is different than an
> > > > application-protocol-level redirect (e.g= ., http) or the Security
> > > > Consideratio= ns need to mention the risk of acclimating users to
> = > > > arbitrary websites redirecting to sites asking for payment> > > > credentials, which may or may not be l= egitimate sites.
> > > >
&g= t; > >
> > > I think it=E2=80=99s reasonab= le to mention the concern in the security considerations. But I don=E2=80= =99t see how a redirection based on this specification is any different tha= n any other time an HTTP browser or SIP UA connects to a resource based on = an arbitrary URL.
> >
> > = In some sense, it's not.  My claim is more that users are being
> > conditioned to expect payment prompts to appear at "a= rbitrary times"
> > than a specific flaw in this wo= rkflow.
> >
> >
> > > But to put some more context around this, the Diam= eter client is typically a Network Access Server (NAS) that the end user is= using for network access. The user is already at the mercy of that NAS, an= d that NAS is at the mercy of the credit-control application server. The us= er=E2=80=99s trust in that NAS seems to have the same issues whether or not= this Diameter application is used.
> > >
> > > [yuval] agree with Ben, if someone bad took cont= rol over the NAS, they can do much worse
> >
> > I agree that the NAS could send traffic to "wherever= ", but my
> > objection could perhaps be categorize= d as more "social" than
> > "technical".  Mayb= e I should attempt to give an example (and you can
> &= gt; point out if I misunderstand things).
> >
> > I believe that a "normal usage" of this technology = could be for a
> > user with a prepaid data plan to= be using a web browser, and, e.g.,
> > connect suc= cessfully to https://example.com. Suppose that this
> >= ; request used up their last remaining credits, and they click on a
> > link from that page.  Instead of going to the act= ual target of that
> > link, they are redirected to= the data plan owner's top-up page,
> > which displ= ays a message "your balance is zero; please enter credit
= > > card information to purchase more data", the user pays, and can> > potentially even be redirected back to the actua= l target of the link
> > they clicked on (though th= at's not key to my example).  Let's
> > consid= er what would happen in an "attack scenario", where the same
> > user has plenty of data quota remaining, and goes to
> > https://honest-achmed.com. They click on a link from= that page,
> > which instead of going to an "actua= l site" that would be expected
> > from the context= surrounding the link, actually goes to
> > http://= [IP address controlled by attacker]/topup.html, which is
= > > designed to look as similar as possible to the actual data plan> > owner's top-up page.  The user may then ent= er their payment
> > information, and get redirecte= d to a site with actual content,
> > believing that= they have obtained more data quota from their
> > = provider, when in reality they have given their credit card
> > information to a phisher.
> >
> > I don't see what mechanism is in place to allow the us= er to be able
> > to distinguish between the "norma= l usage" scenario and the "attack
> > scenario".&nb= sp; I also understand that this sort of technology is
>= ; > already deployed and is seen as useful by both users and data
> > providers, so it seems unrealistic to expect to be ab= le to get rid
> > of this usage entirely.  I d= o think that it is unreasonable for us
> > to enabl= e this behavior without documenting the risks to the user,
> > though.
> >
> >= ; [yuval] I guess that there is nothing in the spec that technically enable= s phishing, however, it makes the social engineering part of it easier. How= about the following addition to the security sections:"It is RECOMMENDED t= hat operators put in place mechanisms that would help their subscribers ide= ntify a valid redirect operation from a malicious one"
> > > > Separately, in Section 8.68 (for QoS-Final-Unit-Indi= cation):
> > > >
> > = > >  If the Final-Unit-Action AVP is set to REDIRECT at least th= e
> > > >  Redirect-Server-Extension AVP= MUST be present.
> > > >
&= gt; > > > This MUST seems in conflict with the text in 8.64 (actua= lly, is
> > > > section 8.64 even internally = inconsistent, too?) about
> > > > "Redirect-S= erver AVP, in addition to or instead of the
> > >= ; > Redirect-Server-Extension AVP", in particular, the "instead of"
> > > > portion.  (The ABNF-based formal lan= guage spec in 8.68 does match up
> > > > with= the above MUST, though.)
> > >
> > > Would changing =E2=80=9Cin addition to or instead of=E2=80= =9D in 8.64 to just =E2=80=9Cin addition to=E2=80=9D help?
> > >
> > > Authors: Please comment i= f that works, given the backwards-compatibility concern.
= > > > [yuval] the cumbersome text is because of backward compatibi= lity issue. Would appriciate suggestion for better phrasing. The idea is th= e following:* We have an existing AVP that can carry some information* We n= eed more information, but we cannot modify the existing one, so we added a = new AVP (which, unlike the old one, is future proof)* If you have a peer th= at does not support the new spec, but only need the old info, you can use t= he old AVP. what makes the spec backward compatible to the old one* If you = have need to send the new info, you have to use the new AVP, but in this ca= se an older peer does not make sense
> >
> > To Ben, I believe that just "in addition to" resolves t= he internal
> > inconsistency.  However, it so= unds like that may not be the best
> > solution fro= m a deployment perspective, and perhaps the formal
> &= gt; definition in Section 8.68 (and the body text) should be relaxed to
> > allow either the -Extension or non-Extension form.=
> > [yuval] will remove "instead of"
>
> I guess my first response did not adequat= ely respond to your request
> for better phrasing.&nbs= p; Unfortunately, I don't think just different
> phras= ing would suffice if we want to retain the ability to use
> just the legacy AVP.  (If we don't want to retain that ability, = then
> removing the "instead of" is the right thing to= do.)
>
> To regain the ability = to just use Redirect-Server without
> Redirect-Server-= Extension, the text in section 8.68 would need to
> ha= ve
>
> OLD:
&g= t;   If the Final-Unit-Action AVP is set to REDIRECT at least the
>   Redirect-Server-Extension AVP MUST be present.&nb= sp; The Filter-Rule AVP
>
> NEW:=
>   If the Final-Unit-Action AVP is set to REDIR= ECT, at least one of the
>   Redirect-Server and = Redirect-Server-Extension AVPs MUST be present.
> &nbs= p; The Filter-Rule AVP
>
> And p= robably also to change the formal syntax (though I guess
= > technically it is not necessary, it would be misleading to leave it> as-is):
>
>= OLD:
>         QoS-Final-Unit-Ind= ication ::=3D < AVP Header: TBD17 >
>   &nb= sp;                     &= nbsp;         { Final-Unit-Action }
&= gt;                     &= nbsp;             *[ Filter-Rule ]
>                 &nbs= p;                 *[ Filter-Id ]>               &nbs= p;                   [ Redirec= t-Server-Extension ]
>         &nb= sp;                     &= nbsp;   *[ AVP ]
>
> NEW:>         QoS-Final-Unit-Indication= ::=3D < AVP Header: TBD17 >
>     &nb= sp;                     &= nbsp;       { Final-Unit-Action }
> &nb= sp;                     &= nbsp;           *[ Filter-Rule ]
>                    =               *[ Filter-Id ]
>                 &nbs= p;                 [ Redirect-Serve= r ]
>              =                     [ Re= direct-Server-Extension ]
>        = ;                     &nb= sp;     *[ AVP ]
>
> (= Am I reading RFC 6733 correctly that the ABNF '/' operator is not
> used in CCF?)
>
>= > > >
> > > > ---------------------= -------------------------------------------------
> &g= t; > > COMMENT:
> > > > ---------------= -------------------------------------------------------
&= gt; > > >
> > > > Some additional si= gnificant but not necessarily DISCUSS-worthy
> > &g= t; > comments, followed by more editorial- and nit-level things.
> > > >
> > > > In Sec= tion 1.3, "Advertising Application Support" uses the same
> > > > Auth-Application-ID value as for RFC 4006; what are th= e interop
> > > > consequences of this?
> > > > [yuval] this was done to make interop= s easier - this is why we kept this RFC backward compatible with RFC4006> > > > Alissa already noted that the text abou= t how to split (sub-)AVPs
> > > > between the= foo and foo-Extension AVPs is inconsistent among them --
> > > > e.g., Redirect-Server-Extension and User-Equipment-Inf= o say "SHOULD
> > > > send [in the old one]",= but Subscription-Id-Extension has separate
> > >= ; > text about "[i]f full backward compatibility with [RFC4006] is
> > > > required" and slightly different behavior = described.  We should try
> > > > to cat= ch all instances of this sort of backwards compatibility and
> > > > make them consistent.
> > &= gt;
> > > I agree.
> > &= gt; [yuval] will look to unify the text
> >
> > I see that there was some discussion on Alissa's ball= ot thread that
> > there may indeed be special cons= iderations for one AVP.  If so,
> > that's fin= e, but the reasoning should probably be included in the
&= gt; > document to explain the apparent disparity.
>= >
> > [yuval] ok
> > <= br clear=3D"none">> > > > The use of UTF8String for URLs and UR= Is (e.g., Redirect-Address-URL)
> > > > might= benefit from additional text about the expected contents.  A
> > > > lot of the time when we use a UTF8 container = for names (whether
> > > > domain names or ot= her kinds), we specify what normalization form and
> &= gt; > > canonicalization are performed, whether domain names are A-la= bels or
> > > > U-labels, etc., as there's a = lot of potential flexibility not all of
> > > &g= t; which is good.  In this case, since the communication is only
> > > > between trusted actors, perhaps the additi= onal restrictions are not
> > > > needed, but= I am curious if the topic was raised in the WG.
> >= ; >
> > > On reflection, shouldn=E2=80=99t th= at be based on whatever rules already exist for the URL scheme? And if some= scheme doesn=E2=80=99t have well defined behavior for non-ascii labels, is= that the concern of this application?
> >
> > It is probably a matter for the URL scheme, yes. = So at most we
> > could note here that "individual= URL schemes may restrict the
> > contents of the U= TF8String", but as I imply in my original comment,
> &= gt; it's far from clear to me that we actually need to say anything in
> > this specific case.
> > > > > >
> > > > T= hank you for adding the Privacy Considerations and list of
> > > > Privacy-Sensitive AVPs!
> > &= gt; >
> > > > Section 14
> > > >
> > > >  [...] The = Diameter credit-
> > > >  control applic= ation is often used within one domain, and there may be
&= gt; > > >  a single hop between the peers.  In these env= ironments, the use of
> > > >  TLS/TCP, = DTLS/SCTP or IPsec is sufficient.
> > > >
> > > > I did not see any concrete guidance on w= hat would suffice in other
> > > > environmen= ts (with multiple hops between peers).  Is this the realm
> > > > of the mythical "end-to-end security mechanism" f= or Diameter that is
> > > > much-desired?&nbs= p; (The last paragraph does have guidance on what might
&= gt; > > > *not* suffice, which is not exactly the same thing.)
> > > >
> > >
> > > Sort of, but in real world deployments the =E2=80= =9Coften used within one domain=E2=80=9D (assuming domain means =E2=80=9Ctr= ust domain=E2=80=9D, which should be clarified) effectively overrides every= thing else. That is far from ideal, but it=E2=80=99s the reality. So it bas= ically comes down to keep everything in the trust domain, or if you cross a= non-trusted network then use TLS or IPSec.
> > >= ;
> > > There=E2=80=99s no solution to safely tr= averse a non-trusted Diameter agent. The mythical e2e mechanism could conce= ivably give us that.  (someday, along with world peace and a post-scar= city economy).
> > >
> >= > [yuval] as Ben and Lyle wrote, if your messages need to go through ag= ents that belong to a 3rd party, you have risks. In this case, AVP level en= cryption (which is not standardized yet...) is the only option for to = ensure privacy. So, the only thing we can do here is to highlight the risks= . 
> >
> > Do we want= to say something about "at present, there is not a
> = > general reliable security solution for other environments"?  (To = be
> > clear, I do not insiste that we do so.)
> >
> > [yuval] not sure if AV= P level ancryption would ever happen... would keep text as is
> >
> > > >  Even without an= y modification to the messages, an adversary can
> >= ; > >  eavesdrop on transactions that contain privacy-sensitive = information
> > > >  about the user.
> > > >
> > > > Th= is ("an adversary can") makes it sounds as if there is no
> > > > confidentiality protection anywhere in the system, but= that's what
> > > > TLS/DTLS/IPSec are suppo= sed to provide.  So maybe "an adversary that
> &g= t; > > can eavesdrop on transactions can obtain privacy-sensitive
> > > > information [...]" is better.
> > > >
> > >
> > > Good point, I agree your suggestion is better.[yuval] = ok
> > >
> > > > (= Editorial- and nit-level stuff follows.)
> > > &= gt;
> > > > Section 4
> = > > >
> > > >  A flexible credi= t-control application specific failure handling is
> &= gt; > >  defined in which the home service provider can model th= e credit-
> > > >  control client behavi= or according to its own credit risk management
> > = > >  policy.
> > > >
> > > > This sentence is hard to parse -- in "credit-contr= ol application
> > > > specific" what does "s= pecific" bind to?  What is being modelled?  Is
= > > > > anything being controlled (as opposed to modelled)?
> > > [yuval] ok. so how about:
&= gt; > > "Flexible failure handling, specific to the credit-control, i= s defined in the application.This allows the the service provider to contro= l the credit-control client behavior according to its ownrisk management po= licy"
> >
> > That's much = better; thanks!
> >
> > &g= t; > Section 4.1.1
> > > >
> > > >  2.  The Service-Parameter-Info AVP MAY be= used as a container to pass
> > > >  le= gacy rating information in its original encoded form (e.g., ASN.1
> > > >  BER).  [...]
>= ; > > >
> > > > Why BER and not DER?=   The unnecessary flexibility in BER vs. DER has
>= ; > > > been known to tickle parser bugs and create security
> > > > vulnerabilities.
> &g= t; > > 
> > > [yuval] this is just an= example of legacy stuff you have no control over
> &g= t; >
> > > > Section 4.1.2
> > > >
> > > >  [...] To=
> > > >  facilitate interoperability, i= t is RECOMMENDED that the rating input
> > > >= ;  and the values of the Service-Context-Id be coordinated via an
> > > >  informational RFC or other permanen= t and readily available reference.
> > > >&nb= sp; The specification of another cooperative standardization body (e.g.,> > > >  3GPP, OMA, or 3GPP2) SHOULD be us= ed.
> > > >
> > > = > The RECOMMENDED and SHOULD seem slightly in conflict.
> > > > 
> > > [yuval] yes, s= eems a bit awkward. How about:
> > > "To fa= cilitate interoperability, it is RECOMMENDED that the rating input
> > > and the values of the Service-Context-Id be coordi= nated via an
> > > informational RFC or other pe= rmanent and readily available reference,
> > > p= referably, of another cooperative standardization body (e.g.,
> > >  3GPP, OMA, or 3GPP2)."
> >= ;
> > Sounds good.
> > > > > > Section 5.1.1
> &g= t; > >
> > > > As noted elsewhere, 60 s= econds per minute does not always hold; it
> > >= > seems that this text could be reworded to just talk about a
> > > > "constant rate" or "constant level per fixed = time period" or
> > > > similar.
> > > > 
> > > [yuval] "c= onstant rate" could mean sub-second resolution as well. The grants are in s= econds, so, IMO, this phrasing is more accurate
> >=
> > It seems that it's only more accurate if leap= seconds are ignored.
> > (I suppose you could expl= icitly disclaim "(ignoring leap seconds)"
> > or si= milar.)
> >
> > [yuval] wi= ll add
> >
> > > > S= ection 5.1.2
> > > >
> &= gt; > >  [...]
> > > >  timer= (Section 13) every time a CCR message with the value
>= ; > > >  UPDATE_REQUEST is sent while they are in PendingU st= ate.  When
> > > >  answers to all = pending messages are received, the state machine moves
&g= t; > > >  to OPEN state, and Tx is stopped.
> > > >
> > > > Transmission, or= the Tx timer (is stopped)?
> > > > 
> > > [yuval] well, "Tx" is overloaded :-( but we n= ever use it in the sense of "transmission" in the RFC
>= ; >
> > (I think that "Tx timer" was fairly con= sistently used throughout the
> > rest of the docum= ent; it may make sense to be fully consistent about
> = > it.)
> >
> > [yuval] = will fix in the doc
> >
> >= ; > > Using a different title for Section 5.2.2 might make the parall= el
> > > > between it and Section 5.2.1 more = clear.  That is, perhaps something
> > > &g= t; like "First Interrogation Included with Authorization Messages".
> > > > 
> > > [yuva= l] make sense
> > >
> > = > > Section 5.7
> > > >
> > > >  [...] It is RECOMMENDED that the client comple= ment the credit-
> > > >  control failur= e procedures with backup accounting flow toward an
> &= gt; > >  accounting server. [...]
> > &g= t; >
> > > > Nit: it looks like there's a = missing article here, maybe "a backup
> > > >= accounting flow" is better.
> > > > > > > [yuval] the rest of the paragraph describe s= uch "backup accounting flow". See what comes after "For example"
> >
> > I just meant that it sound= s like you need to add the word "a" in
> > order fo= r the grammar to make sense.  (But perhaps "the" is the
> > right word; I wasn't sure.)
> >
> > [yuval] ok
> > > >&nb= sp; The AAA transport profile [RFC3539] defines the application layer
> > > >  watchdog algorithm that enables fail= over from a peer that has failed
> > > > = ; and is controlled by a watchdog timer (Tw) defined in [RFC3539].
> > > >
> > > > Nit: Is= it "the" watchdog algorithm or "an" watchdog algorithm?
= > > > > 
> > > [yuval] would im= agine there are other algorithms out there... should fix
= > > >
> > > > Section 6.2
> > > >
> > > > Should = there be text indicating how the client indicates what
&g= t; > > > service the balance check is being requested for?
> > > > 
> > > [yuva= l] didn't find any reference to service information for "EVET_REQUEST" type= messages (direct debit, refund, balance check and price enquiry). Seems li= ke that in the IEC section of 3GPP TS 32.299, they added their own mechanis= m for "direct debit", and "refund", and leave "balance check" and "price en= quiry" as references to RFC4006. Unless I've missed something, this seems l= ike a missing part of the spec.
> > >
> > [yuval] hmm. seems like "event requests" should be= looked at (probably at the light of 3GPP 32.299 IEC concept). But for sure= *not* as part of this work.
>
>= I was mostly wondering whether this section should say anything
> about including the Service-Identifier AVP.  Looking ba= ck at the
> document now, though, maybe this question = does not actually make
> sense.
>=
> -Benjamin
>
> > > > Section 8.54
> > > >> > > > Maybe give a section reference in RFC 3= 580 for how the formatting is
> > > > done?> > > > 
> > >= [yuval] see section 3.21 in RFC3580, this is also true for section 8.50 in= our RFC
> > >
> > > = > Section 12
> > > >
>= ; > > >  [...] Initially, such Expert discussions take place = on the AAA
> > > >  WG mailing list.
> > > >
> > > > Th= at list appears to be dead, suggesting that this text should be
> > > > updated.  (I also agree with Adam's comment= s about updating the IANA Considerations.)
> > >= > 
> > > [yuval] i don't know the proce= ss here - not sure how to change it.
> >
> > With respect to the "expert discussions take place" tex= t, I think it
> > could just be removed.
> >
> > Discussion of the detailed= updates to the IANA actions should
> > probably ha= ppen in Adam's ballot thread.
> >
> > > > Why is the disclaimer in Section B.4 (and other examp= les) not needed in Section B.3?
> > > [yuval] sh= ould be added there as well
> >
= > > Great, thanks.
> >
>= ; >
> > -Benjamin
> > <= br clear=3D"none">> >
> > |
> > |
> > |  |
&g= t; > Example Domain
> >
> = >
> >  |
> >
> >  |
> >
> >  |
> >
> &= gt;
> >
> > 
> 
------=_Part_6493078_282856483.1527620089226-- From nobody Thu May 31 06:21:39 2018 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 8B20912EBA4; Thu, 31 May 2018 06:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSwTdgd_ydxk; Thu, 31 May 2018 06:21:32 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0129.outbound.protection.outlook.com [104.47.37.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95A212EA5A; Thu, 31 May 2018 06:21:31 -0700 (PDT) Received: from SN4PR0501CA0054.namprd05.prod.outlook.com (2603:10b6:803:41::31) by BLUPR05MB740.namprd05.prod.outlook.com (2a01:111:e400:89d::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Thu, 31 May 2018 13:21:29 +0000 Received: from BY2NAM01FT004.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::206) by SN4PR0501CA0054.outlook.office365.com (2603:10b6:803:41::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.820.11 via Frontend Transport; Thu, 31 May 2018 13:21:28 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2NAM01FT004.mail.protection.outlook.com (10.152.69.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.820.8 via Frontend Transport; Thu, 31 May 2018 13:21:28 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w4VDB4Es032679; Thu, 31 May 2018 08:21:27 -0500 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by plsapdm2.corp.sprint.com with ESMTP id 2j75cnju06-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 May 2018 08:21:27 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 31 May 2018 09:21:26 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1365.000; Thu, 31 May 2018 08:21:26 -0500 From: "Bertz, Lyle T [CTO]" To: Adam Roach , Yuval Lifshitz , The IESG CC: "dime-chairs@ietf.org" , "dime@ietf.org" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) Thread-Index: AQHT8VTq2naWep0nYkytV0Gi480JwqQ9XdGAgABagQCADCZT4A== Date: Thu, 31 May 2018 13:21:25 +0000 Message-ID: References: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> <1651457572.4445831.1527066817455@mail.yahoo.com> <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com> In-Reply-To: <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.25] Content-Type: multipart/alternative; boundary="_000_f7e4de8ae7954438b764b279c88733afplswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39380400002)(346002)(39860400002)(396003)(376002)(2980300002)(438002)(189003)(199004)(575784001)(86362001)(39060400002)(54906003)(72206003)(59450400001)(8676002)(4546004)(7696005)(26005)(966005)(336012)(6346003)(97736004)(53546011)(6246003)(68736007)(102836004)(81166006)(3846002)(76176011)(186003)(81156014)(606006)(6116002)(790700001)(5660300001)(33964004)(356003)(24736004)(108616005)(236005)(6306002)(7736002)(478600001)(476003)(5250100002)(2906002)(2900100001)(5890100001)(486006)(53946003)(54896002)(14454004)(4326008)(126002)(426003)(53936002)(106002)(8936002)(316002)(110136005)(84326002)(446003)(11346002)(16586007)(45080400002)(229853002)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB740; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT004; 1:6PS+U9r/rpkEQl8OkDJQBesPamiJes/3ViehFg87hgppt2u77FjloBNCuaXvkvi5RKGkjyRl3C1MQQxRh9vI5MBcHkBpqT4XUGh1892QCj0c/n5U+PDDwDdXXgfVcYWa X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:BLUPR05MB740; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB740; 3:MfKr/2cKtT9guCPeNPbV3aQ+hCD7CUsq8WW958ak0XpxDM1m3pFLqt+UV+KZ7nOF7gF9pXv2F9DWOusemMs1BszuvKqWymd9MOvg+8YxCgJieZY6GF2AhrNTBAcnkq+H+/VYvTSssPJACpQD0SsayTJbQpCqbfAG/bRNdlQC3YG1NeAd1+kpcDOauPJC6UuoNNhJShkCnc/sRyH2Y+TNWuNBkhpqP0+Bw+6mu+g89ZDuW+vmUqnswHj0cfZgeAyOZQo9hjnTGZIMTra0nmOBR2ZkuTbIDFnD/y5hQl8C94haVfq4XjW6vMPsFQCMr5mj6vRmHmdRoTrIIEKNoLAKLZrwqGnGkGQ7/IVJzeEeAtU=; 25:RFHWfBjhh6c/mZhuxWth2Qq8ykwzV41l2D1dfnrU5sPpGhaML6PzUdF4xGY4lP5Hnf76N3GXz1yuovfCE5Mgxpzkryn/aFC1snMh6TPu1TUAU8PM+Ay9fdRYMhNLYvwIjiX5mfy12p0e207NTAnGmUs06eqQSFWm4PunQrwmCz+NncjXniO0mYUkoj9O0YdloZEEMEkpyMVaWwDbO5L03jYSPwECvnX5UDgwkgorMbs92dzeIAZdkvPe5eunEoWxckZyTPZR/560ZLvNuBCGtMU8zLAuC5zcFJMMQ1Fdeu/G8mthE7VX9+L1MtGZQcWbcmBMhC5ug5y/lnDsg8gTbw== X-MS-TrafficTypeDiagnostic: BLUPR05MB740: X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB740; 31:rr0Xw2U8xn0UQARbgquBg39Tnc5nrYYWceDdZ7JH95w0wC2T1yFcsRPRZVe5y6oCCOeNQzhKZCv6OiJstP9k4oK4gG3ACZ4TOtKJLba0zlpjphY7LzhjV9V2f/0kJoqmtO/Y0mIxwWnijAnPngMLUXJQR5PpO/BjVPWFxolyiI5SspDjvCgy1KFlbwZjDuiBF8T1d6gKvU2tIEA9XKnTtH9N1oYH3GdPcU4P+9+JQhY=; 20:pP3djbJRpplN+hmhJMmHupwnHvhLAYpftvJ/D7OFgzyB/QzN2owl8PyX50/Cs9Fb8k/IvFZc60M91XhgTG8CTwZE8IjWHqZlWmFqFFeg1usMSc2j44/biafRNwmgs/IlDPd+rJM4QxDpa2UxTcmYpOe/US16Na/AH77sZu3M2kRHT2oxYt8Y7D7v5OCbx2JD14YWmjoSg+lcw6qpCZjlFLqoJ/yisCCKCvDH6FoIaRVaR/j5DXRKJXLFhQrbIi8cXT68bEptkrKy9KhHh7+RkfeNGuSOMuHeZCwAW0TznSe7qb2IpsDCttv+tSzA0Tv0HeYxflYid2hVQUlEPWvTUnD/gvrE/N/7IBpCXYSPj4hG9V0Sw03CKvyMwbNZ7I6Gze4CN4uUSeTtptlNq+iqLRj9GFcq+aw+WRZRJlu/Fi/fkbDQPOWJmfnZ2CF/bqiQky0+oMWoZT+q6Yj7y+6iceKN3NchVJASGZbJHFv5La3Urw5NcKLYgYEkcZT5g2Jg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(158342451672863)(189930954265078)(788757137089)(219752817060721)(21748063052155); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93004095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BLUPR05MB740; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB740; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB740; 4:kRxXLLOeaNhVwmTkfvftzz7klpnvVOgZybNbDcdfmdPZbS16GCuxVdFOD9qDBoKPSNDMrjydyZiWfIVVWM1mAI12Lav6XHrk2+hwghWlUJnvgW+0Vjjyj4p0ZF4LmidiGQryb6sN8BDGDottr6qFbo020X7m9ZRsGBWHtYYJuSHZek9J6+hmiLuFCY4yuBY0bB4g1ucHuqZ6eqnZbABoOtnNOVasrpItthqczCvm+b01SLDa6c1Cuym2jauz0Ukp/ELiysraVw1mipC2Xc2EXRxtiBrwXMlXZJSocBkKCfq47rQpshjUBc9oYrzY/ITHfacTaGokNd2jUvctd20B1NiIUOLwoSBH3WwO7fGsT5Dg/1H9JW1hTYamnPs6JgfolaOWUzsaZvAzPjQ1W8BTOstbpTtk9A/66rJnGeNJgDxajNKlIHRp8cm4a1HC2jdVEg8A29wzTVtSXmIvV1wqTOcu5DArJF1W5rAFEOPtPEM= X-Forefront-PRVS: 06891E23FB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB740; 23:fe27fecoxiHfLtcYbQCb8x2VIr/WleEQ/VPZ0k1uY1?= =?us-ascii?Q?93DdlCXcX6Om24aOSEMIM3HlcHmYeT0fA/VJjGWKT0BBZel862eX/qia1dzt?= =?us-ascii?Q?h7ENtYRy7Qp4+zRhj2V5ZPds7e+z1cDg4lc+RTB/UITK5zMzcV9MheRjYEJd?= =?us-ascii?Q?OFJrsy2kT51/5h0SWkleBivJ6W4rzmMjC0OO3CS5lbNIrBf3n+vMN8X7n7pc?= =?us-ascii?Q?ZGDQtPQnXoxVEshafrs7yA+i8x3uxOT37L2xg9N2B3Ty7cQuSrnFqLZJfl+w?= =?us-ascii?Q?DGcdWt6v0SAn6KcdFei2ycYRzdqiHP6lp/6K4wPsqQ68Q6qkeMIV3hMZV+FR?= =?us-ascii?Q?EXjKb6EqfqC2d8oMXoEDzhEtJMpb9ECnBQDA0URiOWQjA+l6G8gJA/U6RN5x?= =?us-ascii?Q?79WvwVAF1jKWarx5aIpzQBG8wQzMPjWBaY402uK4som0bs0KgQ6azDyFEO9a?= =?us-ascii?Q?zA1sHEe3Tdav7CVx8RKl0cM99q+kTw16CApY42WJBjsyNOemoYURjsysoQmR?= =?us-ascii?Q?TeMNPCVqBdCyDIFafTJ9JyRWbhIclRnR//Mn6aUAIRZwInQ7cyTERmytbQPe?= =?us-ascii?Q?8/ZDr79/7Kidu1oeON/KBFThUcIlkWh3f7iOjilu4a9c9c4z+XT3c0iajjny?= =?us-ascii?Q?MzlN0n6lDJkbuRVv43m0tEaDl9TLprpzj3IJQdp83iHCM6xVCqDePZjdZ+rH?= =?us-ascii?Q?hux4587t+bNsg4piAfsIJdjtWHI7DvxAPcfXpYT/N/24tmPz0S3buEdVa3/t?= =?us-ascii?Q?OFC6GHE+igQzQdKnnRIEhgyCIXmtxCDTvqnXPKfMYfUdKWMYxgf2VIXBzKd6?= =?us-ascii?Q?7f00IYUPSAdW6NFQf2WF+YzhnAYehobVnxTZ1fGRYx158dOEx9sGosPFum8q?= =?us-ascii?Q?MWCLbbECQ84wupFiEBKSj/6Jtz3rB1zKjh7cpk+k1uWMgty6yA/yIinJ23oy?= =?us-ascii?Q?QhtEh47qpj9BIOPUOKKAyRRKqGIdAsVvSXk9Ij0zYlICTTxUtEDL3baZ5eCM?= =?us-ascii?Q?EKnZsxs8WFcL7nif2c8neV/7C/Phd//psBrzwToKMsUjzBlJpSyad8GUlMWX?= =?us-ascii?Q?dNVMFw19iAnq+UoJj58yAn/Jz9HQQmjKdq7hZav6dhnF6A3QKtwvBQEPKeEC?= =?us-ascii?Q?ESmEBC2JV27OCV74BmAz3Us8qwNxNsYQq4W8GCgCvk4ulNu+LstqPHr8471P?= =?us-ascii?Q?xQ+UYuERel5zR85FMti6/qMau58TCTHWzCKq+EpIU08EgqsG9OrtxonfPRFP?= =?us-ascii?Q?HQAxouUyMo3bEXh85Hp9SGibqGSJTUnJKg80IqvgpGITEm9LAbOvS90lhojM?= =?us-ascii?Q?j1oLFlVKQniEjtjV3xS0mO5IGAqN+lEk/2NlDCiQhKNhhGS2rM7cDA57BePg?= =?us-ascii?Q?CTY+tRPLviUH7Q5xu11SraYp0/AjdmqUm5sNQ+n8eClr1+xk6VJ6mqVrfJ8X?= =?us-ascii?Q?pG0b0SKcXnwQDyBdFiUdHn2TW30bkK+O5SxseojXRCElGN48pGt2wy69qpwA?= =?us-ascii?Q?ZbMcem0NKJh0Hf5RM1Lh0/M0CbUqShZV4=3D?= X-Microsoft-Antispam-Message-Info: 2KiPr9s5KrRWlYNr32W6dmenTIgQA8kjLwTSwII1dxsP/wmzSPmwtanVwoZdb3IGK7faXlw8XKwK5505ctDcHK7z7qgs1R5APr+7WPuefgpQcgGyV7hJZKmctEdm5w0RbMAne3FN7HCVEd79dO5u9vYyQ3to1WT45Brjnof4e79bsSflwfAE/H7nOzrqcTRG X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB740; 6:jS/65itKl7i/QZJtieXUGnVcn7W5YOqP52R48rSrqDZD042wYZ0Zr85trW6W8xOBzywHbAq3XeX+hIfHX4NcKJSUH0KyjcjVel5r0auiI0qgpTM2ErJPa3hMq+0ACGp8CjiewIK7LHjZffpHTqJVhBcBxR0G3d0PongDJPJZz+3aFI5S5ynZ0fNkD8lena3aVNcCtfGoYYsfQ5LUotC5NiFONeFnimxEM3f/NG06YamBuHmN34TS3h8HqHqnmeyUC1K7FyNE4szT3nJiGJ54w7JOajCwYCGJQEqivtzc4EcJEyhHiBCYPn0fqRjiiJpuW1aMu05WtnRfcSsj0U7oIkIPnAiceeOH41+Tf1KeeVOBEnbdNrqzJ7lZJSq6MH79E1LUmTb/jks55G+l/cZRcktQWXSmS6SKoAjmo9givTgi1HMlkg141LxDAIpSmme6V9qgD2/8WoticIuJI/v7jQ==; 5:Z8LKTtVldLbMRQwTHUnVk8D2HpizY81ZGSRNPxBRmXsHfFWNOuT0UkxkC+oKJOHh8KFeTNZQMTuSIwv8YGnNAwgGSiJRE41C5fGGtObTVu83UI0jVyBYLCtMbD1Ad6pNEaELbRmER3T4C8KIRfSOfl5I6WxutBkRjcs8TJBpw5M=; 24:qDV9EzldjsdzC8P6wvte8lI+LVK35U7oTa6b/FlcX8wLKql8tXv4fOo+2GlHVkyUXnOo1+SL98F8ujNW7NlBPdXl8symfQXpJB5P5k65qvk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB740; 7:HTqSFZnMy+mzYhnhx8HX/AwflQFmyHZhmsIEvgiH1Xcb4NcvxQx2vMWjY53WC79H/c6iYCzU+hE6JDkd8cud7MQbCVwCdDAeNZEXi3v1gBmKnlm4uItli0j4dX/C1+AbaU6C9mXiCVmhjPukr68Z5I9YMfQRBm/YSzqxoOGT5O1kFsvSM5ZUGtiZLKZf56GjGimkw/NdNJyEV+OA/uwtuKXeBfwRI7mj5dmX/vDFluOzKWALFm2jorugfXujk+o4 X-MS-Office365-Filtering-Correlation-Id: 68ced964-0a3b-4547-a479-08d5c6f96aef X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2018 13:21:28.4164 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 68ced964-0a3b-4547-a479-08d5c6f96aef X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB740 Archived-At: Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 31 May 2018 13:21:37 -0000 --_000_f7e4de8ae7954438b764b279c88733afplswe13m04adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIGNvbW1lbnQgYmVsb3cgb24gU2VjdGlvbiAxMi4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IFdlZG5l c2RheSwgTWF5IDIzLCAyMDE4IDk6MzggQU0NClRvOiBZdXZhbCBMaWZzaGl0eiA8eXV2YWxpZj00 MHlhaG9vLmNvbUBkbWFyYy5pZXRmLm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6 IGRpbWUtY2hhaXJzQGlldGYub3JnOyBkaW1lQGlldGYub3JnOyBkcmFmdC1pZXRmLWRpbWUtcmZj NDAwNmJpc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBBZGFtIFJvYWNoJ3MgTm8gT2Jq ZWN0aW9uIG9uIGRyYWZ0LWlldGYtZGltZS1yZmM0MDA2YmlzLTA4OiAod2l0aCBDT01NRU5UKQ0K DQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdh bml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5 b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0K T24gNS8yMy8xOCA0OjEzIEFNLCBZdXZhbCBMaWZzaGl0eiB3cm90ZToNCg0KwqcxLjE6DQoNClRo aXMgZG9jdW1lbnQgdXNlcyBsb3dlcmNhc2UgZm9ybXMgb2YgUkZDLTIxMTktZGVmaW5lZCB0ZXJt cy4gUGxlYXNlIHVwZGF0ZSB0aGlzDQpzZWN0aW9uIHRvIHVzZSB0aGUgYm9pbGVycGxhdGUgZnJv bSBSRkMgODE3NC4NCg0KW3l1dmFsXSB3ZSB1c2UgdGhlbSBpbiBsb3dlcmNhc2UsIHdpdGhvdXQg dGhlaXIgbm9ybWF0aXZlIG1lYW5pbmcuIElzIHRoaXMgYW4gaXNzdWU/DQpGb3IgZXhhbXBsZTog Ig0KYSBjb21tZXJjaWFsIGFncmVlbWVudCBtdXN0IGV4aXN0IGJldHdlZW4gdGhlDQp2aXNpdGVk IGRvbWFpbiBhbmQgdGhlIGhvbWUgZG9tYWluIiBpcyBqdXN0IGluZm9ybWF0aW9uYWwNCg0KSXQn cyBub3QgdGhlIGxhbmd1YWdlIHVzZSB0aGF0J3MgYW4gaXNzdWUuIFJGQyAyMTE5IGhhcyBiZWVu IHVwZGF0ZWQsIGFuZCBzaW5jZSB5b3UgdXNlIHRoZSBsb3dlcmNhc2UgdGVybXMsIHRoZSB1cGRh dGUgaXMgcmVsZXZhbnQgdG8geW91ciBkb2N1bWVudC4gVGhlIGZpeCBpcyB0byBzaW1wbHkgcmVw bGFjZSB5b3VyIGV4aXN0aW5nIHRleHQgd2l0aDoNCg0KICAgICAgVGhlIGtleSB3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTA0KDQogICAgICBOT1Qi LCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVE IiwNCg0KICAgICAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRv IGJlIGludGVycHJldGVkIGFzDQoNCiAgICAgIGRlc2NyaWJlZCBpbiBCQ1AgMTQ8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0 b29scy5pZXRmLm9yZyUyRmh0bWwlMkZiY3AxNCZkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHol NDBzcHJpbnQuY29tJTdDZDQ0YjgxYjgwZGVjNGFjNGFjN2IwOGQ1YzBiYWM1NjUlN0M0ZjhiYzBh Y2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MwJTdDNjM2NjI2ODMwNzY1NzQzODcyJnNk YXRhPTEwR1k0aHBZdzJ4Y1lxNkR0UXpONzI0WW5CTDNCMkh3bDJucWZDQjdrWUklM0QmcmVzZXJ2 ZWQ9MD4gW1JGQzIxMTk8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmMyMTE5JmRh dGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0NkNDRiODFiODBkZWM0YWM0 YWM3YjA4ZDVjMGJhYzU2NSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3 QzAlN0M2MzY2MjY4MzA3NjU3NDM4NzImc2RhdGE9QmZUSGVKbGJ0MFlhWFlEcEltJTJCeUZRQ0Zz REpzeTRhdE11cHhrRDBJT0dnJTNEJnJlc2VydmVkPTA+XSBbUkZDODE3NDxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz LmlldGYub3JnJTJGaHRtbCUyRnJmYzgxNzQmZGF0YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6JTQw c3ByaW50LmNvbSU3Q2Q0NGI4MWI4MGRlYzRhYzRhYzdiMDhkNWMwYmFjNTY1JTdDNGY4YmMwYWNi ZDc4NGJmNWI1NWYxYjMxMzAxZDlhZGYlN0MwJTdDMCU3QzYzNjYyNjgzMDc2NTc0Mzg3MiZzZGF0 YT16Nnc1MEZ0S0l1ZE8lMkJodVdRSVglMkZOVU9XUGxMZG04V214UkJFWDBwWDFiZyUzRCZyZXNl cnZlZD0wPl0gd2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleQ0KDQogICAgICBhcHBlYXIgaW4gYWxs IGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLg0KDQoNCg0Kwqc1LjYuMjoNCg0KPiAgVGhlIGNyZWRp dC1jb250cm9sDQo+ICBjbGllbnQgcmVjZWl2ZXMgYSBDcmVkaXQtQ29udHJvbC1BbnN3ZXIgb3Ig c2VydmljZSBzcGVjaWZpYw0KPiAgYXV0aG9yaXphdGlvbiBhbnN3ZXIgd2l0aCB0aGUgRmluYWwt VW5pdC1JbmRpY2F0aW9uIG9yIHRoZSBRb1MtRmluYWwtDQo+ICBVbml0LUluZGljYXRpb24gQVZQ IGFuZCBWYWxpZGl0eS1UaW1lIEFWUHMgYnV0IG5vIEdyYW50ZWQtU2VydmljZS0NCj4gIFVuaXQg QVZQLg0KDQpUaGlzIGhhcyB0aGUgc2FtZSBjb25mdXNpb24gYXMgYWJvdmUgcmVnYXJkaW5nIHRo ZSBhcHBsaWNhdGlvbiBvZiBsb2dpY2FsDQpjb21iaW5hdGlvbnMuIFRoZSBzZWNvbmQgaGFsZiBv ZiB0aGUgc3RhdGVtZW50IGlzIG9mIHRoZSBmb3JtICJBIG9yIEIgYW5kIEMNCmJ1dCBub3QgRCwi IHdoaWNoIGlzIHByZXR0eSBhbWJpZ3VvdXMuIEl0J3MgYWxzbyBhIGxpdHRsZSB1bmNsZWFyIHdo ZXRoZXIgdGhlDQpjbGllbnQgcmVjZWl2ZXMgYSBDcmVkaXQtQ29udHJvbC1BbnN3ZXIgKHdpdGgg QSBvciBCIGFuZCBDIGJ1dCBub3QgRCksIG9yIGp1c3QNCmEgQ3JlZGl0LUNvbnRyb2wtQW5zd2Vy IG9mIGFueSBkZXNjcmlwdGlvbiwgZnVsbCBzdG9wLg0KDQpbeXV2YWxdIGhvdyBhYm91dCB0aGlz Og0KIg0KV2hlbiB0aGUgY3JlZGl0LWNvbnRyb2wNCmNsaWVudCByZWNlaXZlcyAoZWl0aGVyIGF0 IHNlc3Npb24gb3Igc2VydmljZSBzcGVjaWZpYyBsZXZlbCkgYQ0KRmluYWwtVW5pdC1JbmRpY2F0 aW9uIEFWUCBvciBRb1MtRmluYWwtDQpVbml0LUluZGljYXRpb24gQVZQLCB0b2dldGhlciB3aXRo IFZhbGlkaXR5LVRpbWUgQVZQLA0KYnV0IHdpdGhvdXQgR3JhbnRlZC1TZXJ2aWNlLQ0KVW5pdCBB VlAsIGl0IGltbWVkaWF0ZWx5IHN0YXJ0cyB0aGUgZ3JhY2VmdWwgc2VydmljZSB0ZXJtaW5hdGlv bg0KICAgd2l0aG91dCBzZW5kaW5nIGFueSBtZXNzYWdlIHRvIHRoZSBzZXJ2ZXIuIg0KDQpTb3Vu ZHMgZ29vZCB0byBtZS4gVGhhbmtzLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzguNjU6 DQoNCj4gIFRoZSBSZWRpcmVjdC1BZGRyZXNzLUlQQWRkcmVzcyBBVlAgKEFWUCBDb2RlIFRCRDE0 KSBpcyBvZiB0eXBlDQo+ICBBZGRyZXNzIGFuZCBkZWZpbmVzIHRoZSBJUHY0IG9yIElQdjYgYWRk cmVzcyBvZiB0aGUgcmVkaXJlY3Qgc2VydmVyDQo+ICB3aXRoIHdoaWNoIHRoZSBlbmQgdXNlciBp cyB0byBiZSBjb25uZWN0ZWQgd2hlbiB0aGUgYWNjb3VudCBjYW5ub3QNCj4gIGNvdmVyIHRoZSBz ZXJ2aWNlIGNvc3QuDQoNClRoaXMgYXBwZWFycyB0byBiZSB1bmRlcnNwZWNpZmllZCwgdW5sZXNz IEkndmUgbWlzc2VkIHNvbWUgc3BlY2lmaWNhdGlvbg0KZWxzZXdoZXJlIHJlZ2FyZGluZyB3aGF0 IHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gZG8gd2l0aCB0aGlzIElQIGFkZHJlc3MuDQpXaGls ZSB0aGUgb3RoZXIgcmVkaXJlY3Rpb24gbWV0aG9kcyAoSFRUUCwgU0lQKSBoYXZlIHJlbGF0aXZl bHkgY2xlYXIgbWVhbnMgb2YNCmNvbnRhY3QgKHRoZXkgaW5kaWNhdGUgYSBwcm90b2NvbCksIHRo ZSBpbmRpY2F0aW9uIG9mIG9ubHkgYW4gSVAgYWRkcmVzcyB3aXRoDQpuZWl0aGVyIHByb3RvY29s IG5vciBwb3J0IGRvZXNuJ3Qgc2VlbSB0byBwcm92aWRlIGVub3VnaCBpbmZvcm1hdGlvbiBmb3Ig YQ0KY2xpZW50IHRvIGFjdCBvbi4gIFBsZWFzZSBlaXRoZXIgZmxlc2ggdGhpcyBvdXQgaW4gdGhp cyBzZWN0aW9uLCBvciBwb2ludCB0bw0KYW5vdGhlciBkb2N1bWVudCB0aGF0IGluZGljYXRlcyBo b3cgdGhpcyBJUCBhZGRyZXNzIGlzIHRvIGJlIHVzZWQuDQoNClt5dXZhbF0gSSB0aGluayB0aGlz IGlzIGxlZnQgdW5zcGVjaWZpZCBvbiBwdXJwb3NlLiBUaGVyZSBhcmUgbWFueSB3YXlzIHRvIHJl ZGlyZWN0IElQIGFkZHJlc3NlcyAoZS5nLiBkaWZmZXJlbnQgdHVubmVsaW5nIG1lY2hhbmlzbSks IGRvbid0IHRoaW5rIHdlIHdhbnQgdG8gbGlzdCB0aGVtIGhlcmU/W3l1dmFsXQ0KDQpJZiBpdCdz IGFuIG9wZW4tZW5kZWQgc2V0IG9mIGJlaGF2aW9ycyAob3IgYSBzZXQgb2YgYmVoYXZpb3JzIHRo YXQgaXMgdW5yZWFsaXN0aWMgdG8gbGlzdCksIHRoZW4gSSB3b3VsZCBleHBlY3QgdGhlIGRvY3Vt ZW50IHRvIGF0IGxlYXN0IGxldCBpbXBsZW1lbnRvcnMga25vdyB0aGF0IHRoZXkncmUgbm90IGdv aW5nIHRvIGZpbmQgYW55IGZ1cnRoZXIgZ3VpZGFuY2UgaW4gdGhpcyBkb2N1bWVudCBvciBvdGhl ciBSRkNzLiBQZXJoYXBzIGFkZCBzb21ldGhpbmcgbGlrZTogIlRoZSBpbnRlcnByZXRhdGlvbiBv ZiBSZWRpcmVjdC1BZGRyZXNzLUlQQWRkcmVzcyBieSB0aGUgRGlhbWV0ZXIgQ3JlZGl0LWNvbnRy b2wgQ2xpZW50IGlzIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeS4iDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KwqcxMjoNCg0KV2hlbiBuZXcgZG9jdW1lbnRzIG9ic29sZXRlIGFuIFJGQyB0 aGF0IG9yaWdpbmFsbHkgcmVnaXN0ZXJlZCB2YWx1ZXMgd2l0aCBJQU5BLA0KSSdtIHVzZWQgdG8g c2VlaW5nIHRoYXQgZG9jdW1lbnQgYWxzbyB1cGRhdGUgdGhlIElBTkEgcmVnaXN0cnkgc28gdGhh dCB0aGUNCmNvcnJlc3BvbmRpbmcgZW50cmllcyBub3cgcG9pbnQgdG8gdGhlIG5ldyBkb2N1bWVu dC4gWW91IG1heSBjb25zaWRlciB0ZXh0IHRoYXQNCmluc3RydWN0cyBJQU5BIHRvIHVwZGF0ZSB0 aGUgZXhpc3RpbmcgUkZDLTQwMDYtcmVnaXN0ZXJlZCB2YWx1ZXMgc28gdGhhdCB0aGV5DQpwb2lu dCB0byB0aGlzIGRvY3VtZW50IGluc3RlYWQgb2YgUkZDIDQwMDYuDQoNClt5dXZhbF0gZG9uJ3Qg a25vdyB3aGF0IHRoZSBwcm9jZXNzIGhlcmUuIGJ1dCBkb2VzIGl0IG5lZWQgdG8gZ28gaW50byB0 aGUgUkZDPw0KDQpUeXBpY2FsbHksIHRoYXQncyBob3cgd2UgZ2l2ZSBpbnN0cnVjdGlvbnMgdG8g SUFOQSBwZXJ0YWluaW5nIHRvIGRvY3VtZW50IHVwZGF0ZXMsIHllcy4gU2VlIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy10bHMxMy0yOCNzZWN0aW9uLTExPGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi10bHMtdGxzMTMtMjglMjNzZWN0 aW9uLTExJmRhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0NkNDRiODFi ODBkZWM0YWM0YWM3YjA4ZDVjMGJhYzU2NSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5 YWRmJTdDMCU3QzAlN0M2MzY2MjY4MzA3NjU3NDM4NzImc2RhdGE9ZnhOTUFaNjFUQ0RLb3BoUmFR Q04yanMwM2dGam1GMzhNb1BaSnREczNRYyUzRCZyZXNlcnZlZD0wPiBmb3IgYW4gZXhhbXBsZS4N Cg0KW0x5bGVdIFdlIHdpbGwgdXBkYXRlIHRoZSBkb2N1bWVudC4gQWxzbywgcGVyIEJlbuKAmXMg Q09NTUVOVCByZWdhcmRpbmcgU2VjdGlvbiAxMiB3ZSBzaG91bGQgZGV0YWlsIG91ciB1cGRhdGUg aW4gdGhpcyB0aHJlYWQuDQoNCkFzIGEgcmVtaW5kZXIgaXQgd2FzDQo+ICBJbml0aWFsbHksIHN1 Y2ggRXhwZXJ0IGRpc2N1c3Npb25zIHRha2UgcGxhY2Ugb24gdGhlIEFBQQ0KPiBXRyBtYWlsaW5n IGxpc3QuDQo+DQo+IFRoYXQgbGlzdCBhcHBlYXJzIHRvIGJlIGRlYWQsIHN1Z2dlc3RpbmcgdGhh dCB0aGlzIHRleHQgc2hvdWxkIGJlIHVwZGF0ZWQuIChJIGFsc28gYWdyZWUgd2l0aCBBZGFtJ3Mg Y29tbWVudHMgYWJvdXQgdXBkYXRpbmcgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMuKQ0KDQpUaGlz IGlzIGF0IHRoZSBib3R0b20gb2YgaGlzIGJhbGxvdCB0aHJlYWQgKGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvZGltZS9mRmNBNDFEOEZBNjh5bjhHU25WSHpwbDZNQlEpDQoN CkFyZSB5b3Ugb2theSB3aXRoIHVzZSBlbGltaW5hdGluZyB0aGlzIHRleHQgYXMgQmVuamFtaW4g cHJvcG9zZWQ/ICBBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gdXNlIHRoZSBzdGF0ZW1lbnQg4oCcVGhl IGRlZmluaXRpb24gb2YgbmV3IHZhbHVlcyBpcyBzdWJqZWN0IHRvIHRoZSBTcGVjaWZpY2F0aW9u IFJlcXVpcmVkDQogICBwb2xpY3kgW1JGQzgxMjZdLuKAnQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpBcHBlbmRpeCBCOg0KDQpBcyBhIGdlbmVyYWwgY29tbWVudCBmb3IgYWxsIG9mIHRoZSBl eGFtcGxlczogSSdtIHN1cnByaXNlZCB0aGF0IG5vbmUgb2YgdGhlDQpleGFtcGxlcyBoYXZlIGJl ZW4gdXBkYXRlZCB0byByZWZsZWN0IHRoZSBuZXdseSBkZWZpbmVkIGNhcGFiaWxpdGllcyBpbiB0 aGlzDQpkb2N1bWVudC4gRm9yIGV4YW1wbGUsIGFsbCB0aGUgZXhhbXBsZXMgaW4gdGhpcyBhcHBl bmRpeCB1c2UNCkZpbmFsLVVuaXQtSW5kaWNhdGlvbiByYXRoZXIgdGhhbiBRb1MtRmluYWwtVW5p dC1JbmRpY2F0aW9uLiBJbiBwcmFjdGljZSwgdG8NCnNob3cgbWF4aW1hbGx5IGZsZXhpYmxlIGFu ZCBjb21wYXRpYmxlIGV4YW1wbGVzLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZQ0KZXhhbXBsZXMg d291bGQgaW5jbHVkZSBib3RoIEFWUHMuIFRoaXMgYXBwbGllcyB0byBhbGwgb2YgdGhlICJFeHRl bnNpb24iDQpBVlBzIGFzIHdlbGwuDQoNClt5dXZhbF0gdGhlIGV4YW1wbGVzIGFyZSBtb3JlIGFy b3VuZCB0aGUgZmxvdyBhbmQgbGVzcyBhYm91dCB0aGUgYWN0dWFsIGNvbnRlbnQuDQpXaXRoIHJl c3BlY3QgdG8gZmxvdywgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBvbGQgYW5k IG5ldyBBVlBzIC0gYW5kIHdlIHdhbnRlZCB0byBtaW5pbWl6ZSB1bm5lY2Vzc2FyeSBjaGFuZ2Vz LiBPbmx5IGZsb3cgdGhhdCB3YXMgbW9kaWZpZWQgd2FzIHJlZmxlY3RlZCBpbiBhIG5ldyBkaWFn cmFtIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA1LjYgKCJ6ZXJvIEdTVSIpDQoNCldoaWxlIEkgZG9u J3QgYWdyZWUgd2l0aCB0aGUgcmF0aW9uYWxlIGhlcmUsIHRoaXMgaXMgYW4gZWRpdG9yaWFsIGNv bW1lbnQgYWJvdXQgYSBub24tbm9ybWF0aXZlIHBhcnQgb2YgdGhlIGRvY3VtZW50LCBzbyBpdCdz IHVsdGltYXRlbHkgeW91ciBkZWNpc2lvbi4NCg0KL2ENCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChz KS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFs bCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= --_000_f7e4de8ae7954438b764b279c88733afplswe13m04adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFj azt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUgY29tbWVudCBiZWxvdyBvbiBT ZWN0aW9uIDEyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBE aU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5B ZGFtIFJvYWNoPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDIzLCAyMDE4IDk6Mzgg QU08YnI+DQo8Yj5Ubzo8L2I+IFl1dmFsIExpZnNoaXR6ICZsdDt5dXZhbGlmPTQweWFob28uY29t QGRtYXJjLmlldGYub3JnJmd0OzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBkaW1lLWNoYWlyc0BpZXRmLm9yZzsgZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1kaW1lLXJmYzQwMDZiaXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1l XSBBZGFtIFJvYWNoJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZGltZS1yZmM0MDA2Ymlz LTA4OiAod2l0aCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpzb2xpZCAjOUM2NTAwIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdDtiYWNr Z3JvdW5kOiNGRkVCOUMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q0FVVElPTjogVGhpcyBlbWFpbCBvcmln aW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlu a3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUNCiBzZW5kZXIg YW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA1LzIzLzE4IDQ6MTMgQU0sIFl1dmFsIExpZnNo aXR6IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9InlkcDc2ZGQ5YjAxeWFob29f cXVvdGVkXzczODE5OTk1OTMiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+wqcxLjE6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzI2MjgyQSI+VGhpcyBkb2N1bWVudCB1c2VzIGxvd2VyY2FzZSBmb3JtcyBvZiBSRkMtMjExOS1k ZWZpbmVkIHRlcm1zLiBQbGVhc2UgdXBkYXRlIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjYyODJBIj5zZWN0aW9uIHRvIHVzZSB0aGUgYm9pbGVycGxhdGUgZnJvbSBSRkMgODE3NC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+W3l1 dmFsXSB3ZSB1c2UgdGhlbSBpbiBsb3dlcmNhc2UsIHdpdGhvdXQgdGhlaXIgbm9ybWF0aXZlIG1l YW5pbmcuIElzIHRoaXMgYW4gaXNzdWU/PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjYyODJBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+Rm9yIGV4YW1wbGU6ICZxdW90Ow0KPG86cD48L286cD48 L3NwYW4+PC9pPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+YSBj b21tZXJjaWFsIGFncmVlbWVudCBtdXN0IGV4aXN0IGJldHdlZW4gdGhlJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9pPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj OUQxODExIj52aXNpdGVkIGRvbWFpbiBhbmQgdGhlIGhvbWUgZG9tYWluJnF1b3Q7IGlzIGp1c3Qg aW5mb3JtYXRpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkl0J3Mgbm90IHRo ZSBsYW5ndWFnZSB1c2UgdGhhdCdzIGFuIGlzc3VlLiBSRkMgMjExOSBoYXMgYmVlbiB1cGRhdGVk LCBhbmQgc2luY2UgeW91IHVzZSB0aGUgbG93ZXJjYXNlIHRlcm1zLCB0aGUgdXBkYXRlIGlzIHJl bGV2YW50IHRvIHlvdXIgZG9jdW1lbnQuIFRoZSBmaXggaXMgdG8gc2ltcGx5IHJlcGxhY2UgeW91 ciBleGlzdGluZyB0ZXh0IHdpdGg6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUaGUga2V5IHdvcmRzICZxdW90O01VU1QmcXVvdDssICZxdW90O01V U1QgTk9UJnF1b3Q7LCAmcXVvdDtSRVFVSVJFRCZxdW90OywgJnF1b3Q7U0hBTEwmcXVvdDssICZx dW90O1NIQUxMPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5PVCZxdW90OywgJnF1b3Q7U0hPVUxEJnF1b3Q7LCAmcXVvdDtTSE9VTEQgTk9UJnF1 b3Q7LCAmcXVvdDtSRUNPTU1FTkRFRCZxdW90OywgJnF1b3Q7Tk9UIFJFQ09NTUVOREVEJnF1b3Q7 LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDtNQVkmcXVvdDssIGFuZCAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmliZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29s cy5pZXRmLm9yZyUyRmh0bWwlMkZiY3AxNCZhbXA7ZGF0YT0wMiU3QzAxJTdDbHlsZS50LmJlcnR6 JTQwc3ByaW50LmNvbSU3Q2Q0NGI4MWI4MGRlYzRhYzRhYzdiMDhkNWMwYmFjNTY1JTdDNGY4YmMw YWNiZDc4NGJmNWI1NWYxYjMxMzAxZDlhZGYlN0MwJTdDMCU3QzYzNjYyNjgzMDc2NTc0Mzg3MiZh bXA7c2RhdGE9MTBHWTRocFl3MnhjWXE2RHRRek43MjRZbkJMM0IySHdsMm5xZkNCN2tZSSUzRCZh bXA7cmVzZXJ2ZWQ9MCI+QkNQIDE0PC9hPiBbPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9y ZyUyRmh0bWwlMkZyZmMyMTE5JmFtcDtkYXRhPTAyJTdDMDElN0NseWxlLnQuYmVydHolNDBzcHJp bnQuY29tJTdDZDQ0YjgxYjgwZGVjNGFjNGFjN2IwOGQ1YzBiYWM1NjUlN0M0ZjhiYzBhY2JkNzg0 YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MwJTdDNjM2NjI2ODMwNzY1NzQzODcyJmFtcDtzZGF0 YT1CZlRIZUpsYnQwWWFYWURwSW0lMkJ5RlFDRnNESnN5NGF0TXVweGtEMElPR2clM0QmYW1wO3Jl c2VydmVkPTAiIHRpdGxlPSImcXVvdDtLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlIFJlcXVpcmVtZW50IExldmVscyZxdW90OyI+UkZDMjExOTwvYT5dIFs8YSBocmVmPSJodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzgxNzQmYW1wO2RhdGE9MDIlN0MwMSU3Q2x5 bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0NkNDRiODFiODBkZWM0YWM0YWM3YjA4ZDVjMGJhYzU2 NSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzAlN0M2MzY2MjY4MzA3 NjU3NDM4NzImYW1wO3NkYXRhPXo2dzUwRnRLSXVkTyUyQmh1V1FJWCUyRk5VT1dQbExkbThXbXhS QkVYMHBYMWJnJTNEJmFtcDtyZXNlcnZlZD0wIj5SRkM4MTc0PC9hPl0gd2hlbiwgYW5kIG9ubHkg d2hlbiwgdGhleTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXYgaWQ9InlkcDc2ZGQ5YjAxeWFob29fcXVvdGVkXzczODE5OTk1OTMiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2Mjgy QSI+wqc1LjYuMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mZ3Q7Jm5ic3A7IFRoZSBjcmVkaXQtY29u dHJvbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPiZndDsmbmJzcDsgY2xpZW50 IHJlY2VpdmVzIGEgQ3JlZGl0LUNvbnRyb2wtQW5zd2VyIG9yIHNlcnZpY2Ugc3BlY2lmaWM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mZ3Q7Jm5ic3A7IGF1dGhvcml6YXRpb24g YW5zd2VyIHdpdGggdGhlIEZpbmFsLVVuaXQtSW5kaWNhdGlvbiBvciB0aGUgUW9TLUZpbmFsLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPiZndDsmbmJzcDsgVW5pdC1JbmRpY2F0 aW9uIEFWUCBhbmQgVmFsaWRpdHktVGltZSBBVlBzIGJ1dCBubyBHcmFudGVkLVNlcnZpY2UtPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jmd0OyZuYnNwOyBVbml0IEFWUC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjYyODJBIj5UaGlzIGhhcyB0aGUgc2FtZSBjb25mdXNpb24gYXMgYWJvdmUgcmVn YXJkaW5nIHRoZSBhcHBsaWNhdGlvbiBvZiBsb2dpY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzI2MjgyQSI+Y29tYmluYXRpb25zLiBUaGUgc2Vjb25kIGhhbGYgb2YgdGhlIHN0YXRlbWVu dCBpcyBvZiB0aGUgZm9ybSAmcXVvdDtBIG9yIEIgYW5kIEM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj5idXQgbm90IEQsJnF1b3Q7IHdoaWNoIGlzIHByZXR0eSBhbWJpZ3VvdXMu IEl0J3MgYWxzbyBhIGxpdHRsZSB1bmNsZWFyIHdoZXRoZXIgdGhlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+Y2xpZW50IHJlY2VpdmVzIGEgQ3JlZGl0LUNvbnRyb2wtQW5zd2Vy ICh3aXRoIEEgb3IgQiBhbmQgQyBidXQgbm90IEQpLCBvciBqdXN0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+YSBDcmVkaXQtQ29udHJvbC1BbnN3ZXIgb2YgYW55IGRlc2NyaXB0 aW9uLCBmdWxsIHN0b3AuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiM5RDE4MTEiPlt5dXZhbF0gaG93IGFib3V0IHRoaXM6PC9zcGFuPjwvaT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+JnF1b3Q7IDxvOnA+DQo8L286cD48 L3NwYW4+PC9pPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+V2hl biB0aGUgY3JlZGl0LWNvbnRyb2wmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM5RDE4MTEiPmNsaWVudCByZWNlaXZlcyAoZWl0 aGVyIGF0IHNlc3Npb24gb3Igc2VydmljZSBzcGVjaWZpYyBsZXZlbCkgYSZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzlEMTgxMSI+RmluYWwtVW5pdC1JbmRpY2F0aW9uIEFWUCBvciBRb1MtRmluYWwtPG86cD48L286 cD48L3NwYW4+PC9pPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj OUQxODExIj5Vbml0LUluZGljYXRpb24gQVZQLCB0b2dldGhlciB3aXRoIFZhbGlkaXR5LVRpbWUg QVZQLDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+YnV0IHdpdGhvdXQgR3JhbnRlZC1T ZXJ2aWNlLTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+VW5pdCBBVlAsIGl0IGltbWVkaWF0ZWx5IHN0YXJ0cyB0 aGUgZ3JhY2VmdWwgc2VydmljZSB0ZXJtaW5hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojOUQxODExIj4m bmJzcDsgJm5ic3A7d2l0aG91dCBzZW5kaW5nIGFueSBtZXNzYWdlIHRvIHRoZSBzZXJ2ZXIuJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NClNvdW5kcyBnb29kIHRvIG1lLiBUaGFua3MuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IGlkPSJ5ZHA3NmRkOWIwMXlhaG9vX3F1b3RlZF83Mzgx OTk5NTkzIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPsKnOC42NTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mZ3Q7Jm5ic3A7IFRoZSBSZWRp cmVjdC1BZGRyZXNzLUlQQWRkcmVzcyBBVlAgKEFWUCBDb2RlIFRCRDE0KSBpcyBvZiB0eXBlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jmd0OyZuYnNwOyBBZGRyZXNzIGFuZCBk ZWZpbmVzIHRoZSBJUHY0IG9yIElQdjYgYWRkcmVzcyBvZiB0aGUgcmVkaXJlY3Qgc2VydmVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jmd0OyZuYnNwOyB3aXRoIHdoaWNoIHRo ZSBlbmQgdXNlciBpcyB0byBiZSBjb25uZWN0ZWQgd2hlbiB0aGUgYWNjb3VudCBjYW5ub3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mZ3Q7Jm5ic3A7IGNvdmVyIHRoZSBzZXJ2 aWNlIGNvc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+VGhpcyBhcHBlYXJzIHRvIGJlIHVuZGVyc3Bl Y2lmaWVkLCB1bmxlc3MgSSd2ZSBtaXNzZWQgc29tZSBzcGVjaWZpY2F0aW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+ZWxzZXdoZXJlIHJlZ2FyZGluZyB3aGF0IHRoZSBjbGll bnQgaXMgc3VwcG9zZWQgdG8gZG8gd2l0aCB0aGlzIElQIGFkZHJlc3MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzI2MjgyQSI+V2hpbGUgdGhlIG90aGVyIHJlZGlyZWN0aW9uIG1ldGhvZHMg KEhUVFAsIFNJUCkgaGF2ZSByZWxhdGl2ZWx5IGNsZWFyIG1lYW5zIG9mPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzI2MjgyQSI+Y29udGFjdCAodGhleSBpbmRpY2F0ZSBhIHByb3RvY29sKSwg dGhlIGluZGljYXRpb24gb2Ygb25seSBhbiBJUCBhZGRyZXNzIHdpdGg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMjYyODJBIj5uZWl0aGVyIHByb3RvY29sIG5vciBwb3J0IGRvZXNuJ3Qgc2Vl bSB0byBwcm92aWRlIGVub3VnaCBpbmZvcm1hdGlvbiBmb3IgYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyNjI4MkEiPmNsaWVudCB0byBhY3Qgb24uJm5ic3A7IFBsZWFzZSBlaXRoZXIgZmxl c2ggdGhpcyBvdXQgaW4gdGhpcyBzZWN0aW9uLCBvciBwb2ludCB0bzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyNjI4MkEiPmFub3RoZXIgZG9jdW1lbnQgdGhhdCBpbmRpY2F0ZXMgaG93IHRo aXMgSVAgYWRkcmVzcyBpcyB0byBiZSB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy NjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojOUQxODExIj5beXV2YWxdIEkgdGhpbmsgdGhpcyBpcyBsZWZ0IHVu c3BlY2lmaWQgb24gcHVycG9zZS4gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byByZWRpcmVjdCBJUCBh ZGRyZXNzZXMgKGUuZy4gZGlmZmVyZW50IHR1bm5lbGluZyBtZWNoYW5pc20pLCBkb24ndCB0aGlu ayB3ZSB3YW50IHRvIGxpc3QgdGhlbSBoZXJlP1t5dXZhbF08L3NwYW4+PC9pPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpJZiBpdCdzIGFuIG9wZW4tZW5kZWQgc2V0IG9mIGJlaGF2aW9ycyAob3Ig YSBzZXQgb2YgYmVoYXZpb3JzIHRoYXQgaXMgdW5yZWFsaXN0aWMgdG8gbGlzdCksIHRoZW4gSSB3 b3VsZCBleHBlY3QgdGhlIGRvY3VtZW50IHRvIGF0IGxlYXN0IGxldCBpbXBsZW1lbnRvcnMga25v dyB0aGF0IHRoZXkncmUgbm90IGdvaW5nIHRvIGZpbmQgYW55IGZ1cnRoZXIgZ3VpZGFuY2UgaW4g dGhpcyBkb2N1bWVudCBvciBvdGhlciBSRkNzLiBQZXJoYXBzIGFkZCBzb21ldGhpbmcNCiBsaWtl OiAmcXVvdDtUaGUgaW50ZXJwcmV0YXRpb24gb2YgUmVkaXJlY3QtQWRkcmVzcy1JUEFkZHJlc3Mg YnkgdGhlIERpYW1ldGVyIENyZWRpdC1jb250cm9sIENsaWVudCBpcyBhIG1hdHRlciBvZiBsb2Nh bCBwb2xpY3kuJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2IGlkPSJ5ZHA3NmRkOWIwMXlhaG9vX3F1b3RlZF83MzgxOTk5NTkzIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPsKnMTI6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2Mjgy QSI+V2hlbiBuZXcgZG9jdW1lbnRzIG9ic29sZXRlIGFuIFJGQyB0aGF0IG9yaWdpbmFsbHkgcmVn aXN0ZXJlZCB2YWx1ZXMgd2l0aCBJQU5BLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4 MkEiPkknbSB1c2VkIHRvIHNlZWluZyB0aGF0IGRvY3VtZW50IGFsc28gdXBkYXRlIHRoZSBJQU5B IHJlZ2lzdHJ5IHNvIHRoYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+ Y29ycmVzcG9uZGluZyBlbnRyaWVzIG5vdyBwb2ludCB0byB0aGUgbmV3IGRvY3VtZW50LiBZb3Ug bWF5IGNvbnNpZGVyIHRleHQgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEi Pmluc3RydWN0cyBJQU5BIHRvIHVwZGF0ZSB0aGUgZXhpc3RpbmcgUkZDLTQwMDYtcmVnaXN0ZXJl ZCB2YWx1ZXMgc28gdGhhdCB0aGV5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+ cG9pbnQgdG8gdGhpcyBkb2N1bWVudCBpbnN0ZWFkIG9mIFJGQyA0MDA2LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojOUQxODExIj5beXV2YWxdIGRvbid0IGtu b3cgd2hhdCB0aGUgcHJvY2VzcyBoZXJlLiBidXQgZG9lcyBpdCBuZWVkIHRvIGdvIGludG8gdGhl IFJGQz88L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VHlwaWNhbGx5LCB0aGF0J3MgaG93IHdlIGdpdmUgaW5zdHJ1Y3Rpb25zIHRvIElBTkEgcGVydGFp bmluZyB0byBkb2N1bWVudCB1cGRhdGVzLCB5ZXMuIFNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29s cy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXRscy10bHMxMy0yOCUyM3NlY3Rpb24tMTEm YW1wO2RhdGE9MDIlN0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0NkNDRiODFiODBk ZWM0YWM0YWM3YjA4ZDVjMGJhYzU2NSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRm JTdDMCU3QzAlN0M2MzY2MjY4MzA3NjU3NDM4NzImYW1wO3NkYXRhPWZ4Tk1BWjYxVENES29waFJh UUNOMmpzMDNnRmptRjM4TW9QWkp0RHMzUWMlM0QmYW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLXRsczEzLTI4I3NlY3Rpb24tMTE8L2E+ IGZvciBhbiBleGFtcGxlLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5b THlsZV0gV2Ugd2lsbCB1cGRhdGUgdGhlIGRvY3VtZW50LiBBbHNvLCBwZXIgQmVu4oCZcyBDT01N RU5UIHJlZ2FyZGluZyBTZWN0aW9uIDEyIHdlIHNob3VsZCBkZXRhaWwgb3VyIHVwZGF0ZSBpbiB0 aGlzIHRocmVhZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFz IGEgcmVtaW5kZXIgaXQgd2FzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZuYnNwOyBJPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzZBNzM3RDtiYWNrZ3JvdW5kOndoaXRlIj5uaXRpYWxs eSwgc3VjaCBFeHBlcnQgZGlzY3Vzc2lvbnMgdGFrZSBwbGFjZSBvbiB0aGUNCiBBQUE8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNkE3MzdEIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jmd0OyBXRyBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzZBNzM3 RDtiYWNrZ3JvdW5kOndoaXRlIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNkE3MzdEO2JhY2tncm91 bmQ6d2hpdGUiPiZndDsgVGhhdCBsaXN0IGFwcGVhcnMgdG8gYmUgZGVhZCwgc3VnZ2VzdGluZyB0 aGF0IHRoaXMgdGV4dCBzaG91bGQgYmU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNkE3 MzdEIj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj51cGRhdGVkLiAoSSBhbHNvIGFn cmVlIHdpdGggQWRhbSdzIGNvbW1lbnRzIGFib3V0IHVwZGF0aW5nIHRoZSBJQU5BIENvbnNpZGVy YXRpb25zLik8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNkE3MzdEO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzZBNzM3RDtiYWNrZ3JvdW5kOndoaXRlIj5UaGlzIGlzIGF0IHRoZSBib3R0 b20gb2YgaGlzIGJhbGxvdCB0aHJlYWQgKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvZGltZS9mRmNBNDFEOEZBNjh5bjhHU25WSHpwbDZNQlEpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNkE3MzdEO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDo1LjI1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFyZSB5b3Ugb2theSB3 aXRoIHVzZSBlbGltaW5hdGluZyB0aGlzIHRleHQgYXMgQmVuamFtaW4gcHJvcG9zZWQ/Jm5ic3A7 IEFsdGVybmF0aXZlbHksIHdlIGNhbiB1c2UgdGhlIHN0YXRlbWVudCDigJw8L3NwYW4+VGhlIGRl ZmluaXRpb24NCiBvZiBuZXcgdmFsdWVzIGlzIHN1YmplY3QgdG8gdGhlIFNwZWNpZmljYXRpb24g UmVxdWlyZWQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBpZD0ieWRwNzZkZDliMDF5YWhvb19xdW90ZWRfNzM4MTk5OTU5 MyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHBvbGljeSBbUkZDODEyNl0uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPuKAnTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYy ODJBIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJB Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5BcHBlbmRpeCBCOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyNjI4MkEiPkFzIGEgZ2VuZXJhbCBjb21tZW50IGZvciBhbGwgb2YgdGhlIGV4 YW1wbGVzOiBJJ20gc3VycHJpc2VkIHRoYXQgbm9uZSBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjYyODJBIj5leGFtcGxlcyBoYXZlIGJlZW4gdXBkYXRlZCB0byByZWZsZWN0IHRo ZSBuZXdseSBkZWZpbmVkIGNhcGFiaWxpdGllcyBpbiB0aGlzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzI2MjgyQSI+ZG9jdW1lbnQuIEZvciBleGFtcGxlLCBhbGwgdGhlIGV4YW1wbGVzIGlu IHRoaXMgYXBwZW5kaXggdXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Rmlu YWwtVW5pdC1JbmRpY2F0aW9uIHJhdGhlciB0aGFuIFFvUy1GaW5hbC1Vbml0LUluZGljYXRpb24u IEluIHByYWN0aWNlLCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPnNob3cg bWF4aW1hbGx5IGZsZXhpYmxlIGFuZCBjb21wYXRpYmxlIGV4YW1wbGVzLCBJIHdvdWxkIGV4cGVj dCB0aGF0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPmV4YW1wbGVzIHdv dWxkIGluY2x1ZGUgYm90aCBBVlBzLiBUaGlzIGFwcGxpZXMgdG8gYWxsIG9mIHRoZSAmcXVvdDtF eHRlbnNpb24mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5BVlBzIGFz IHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM5RDE4 MTEiPlt5dXZhbF0gdGhlIGV4YW1wbGVzIGFyZSBtb3JlIGFyb3VuZCB0aGUgZmxvdyBhbmQgbGVz cyBhYm91dCB0aGUgYWN0dWFsIGNvbnRlbnQuPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzlEMTgxMSI+V2l0aCByZXNwZWN0IHRvIGZsb3csIHRoZXJlIGlz IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgb2xkIGFuZCBuZXcgQVZQcyAtIGFuZCB3ZSB3YW50 ZWQgdG8gbWluaW1pemUgdW5uZWNlc3NhcnkgY2hhbmdlcy4gT25seSBmbG93IHRoYXQgd2FzIG1v ZGlmaWVkIHdhcyByZWZsZWN0ZWQgaW4gYSBuZXcgZGlhZ3JhbQ0KIGF0IHRoZSBlbmQgb2Ygc2Vj dGlvbiA1LjYgKCZxdW90O3plcm8gR1NVJnF1b3Q7KTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCldoaWxlIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUgcmF0aW9uYWxlIGhlcmUsIHRo aXMgaXMgYW4gZWRpdG9yaWFsIGNvbW1lbnQgYWJvdXQgYSBub24tbm9ybWF0aXZlIHBhcnQgb2Yg dGhlIGRvY3VtZW50LCBzbyBpdCdzIHVsdGltYXRlbHkgeW91ciBkZWNpc2lvbi48YnI+DQo8YnI+ DQovYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0K PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpUaGlzIGUtbWFp bCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug Y29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS48 YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f7e4de8ae7954438b764b279c88733afplswe13m04adsprintcom_--