From nobody Mon Feb 12 15:33:19 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 8E3E21271FD; Mon, 12 Feb 2018 15:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 cN6icx-MlDKi; Mon, 12 Feb 2018 15:33:16 -0800 (PST) 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 852BF127076; Mon, 12 Feb 2018 15:33:13 -0800 (PST) Received: from [10.0.1.105] (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 w1CNXCMr073647 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Feb 2018 17:33:13 -0600 (CST) (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.105] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_AE77D6FF-A20A-46A3-9E6C-35DCF4F8861D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> Date: Mon, 12 Feb 2018 17:33:11 -0600 Cc: dime@ietf.org, ops-ads@ietf.org To: draft-ietf-dime-rfc4006bis.all@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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: Mon, 12 Feb 2018 23:33:18 -0000 --Apple-Mail=_AE77D6FF-A20A-46A3-9E6C-35DCF4F8861D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for = the work on this; it=E2=80=99s overall a good update. However, I have = one major comment and a few minor or editorial comments. I=E2=80=99d = like to discuss the major comment prior IETF last call. The rest can be = handled along with any last call feedback. Note that for all but the major comment, I mostly reviewed the diff from = RFC 4006. 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 Major Comment: I strongly suggest that you add more privacy considerations. I realize = that it inherits its existing privacy considerations from RFC 4006, but = that was published in 2005. The IETF=E2=80=99s focus on privacy has = evolved considerably since then, and I think this draft will get = objections during IESG review without adding some more. I suggest the following: =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section = separate from the security considerations. =E2=80=94 Enumerate the AVPs that you think contain user identifiable = information, persistent identifiers, or other privacy sensitive data. =E2=80=94 Make some non-normative recommendations concerning data = minimization. That is, add a few sentences recommending that clients and = servers avoid capturing and/or log personal information beyond that = needed for the application's purpose. Minor Comments: -Section 12 and subsections: Please clarify that many of these elements = were already registered by RF 4006, and are not being = =E2=80=9Cre-registered=E2=80=9D here. ( It=E2=80=99s perfectly okay to = pull the registration information forward into the bis draft; it just = needs clarification.) Also, please consider wether existing = registrations should be updated to point to this document rather than = 4006. Appendices: Would any of the example flows benefit from including one or = more of the new AVPs? Editorial and Nits: -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to = RESTRICT_ACCESS or REDIRECT and the classification of the restricted traffic cannot be expressed using IPFilterRule, or different actions (e.g., QoS) than just allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C I have trouble parsing the sentence. -14: "Even without any modification to the messages, an adversary can invite a security threat by eavesdropping, as the transactions = contain private information about the user. =E2=80=9D I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transactions = that contain privacy-sensitive imformation=E2=80=9D --Apple-Mail=_AE77D6FF-A20A-46A3-9E6C-35DCF4F8861D 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlqCJDcACgkQgFZKbJXz 1A0TMBAAuFhe6SB3MxaNkqIWZZEltIRKD8Wf23NGAllT+pyp7V7q9IauNhKTw255 1tC5K+I8s+euoFfWvL0K5uTnNAnv7ri0IxclaKKqueh4MnSHG6mpJZaSMQiWy2xP JUtUw0ncfu512MSs+AzLCbis13VmfsxClcSpdxLOLke14T7aK/88tfn0rdLWoPiw 60yrGFNGxTvb5Dsan/XrvkG9LK+I0XXhOqEEUh6DjMOE4Gq8KLjb2YF4d7xIj8gf BkKpdWgbdPGZI+EYFOa3ySIgXTqsvdXTcwkO2m45C/iJMEADfR0TJViL3aGQUv1U +9oYEvS//so9mL0mbK4OBE+iJz9f5uzxjHgeca6lyyoEvjlxqF11siQz4u74TTZq 9hq5hOIJWnh1F1/FdMo53C+xDbfF40IGdkluhwuzTcLLvxcqa0hSMf4I1uxNWeq4 AQzDpgThRl/2ksnosIs/lWgb7tuYGvlYvd0xT78UFk1V1RMhyoAA0NhSME7Mv9qx UJH/NYTfCzng6WKfXLXL2h6noyUOouHZtLUUvkUGqs52x9P8oXmbuw3FtfRnkUOk Y211s6nwA4nAHoMyt6dfK1zpsUXgY6+Se26oWvwqCyIjoDhYfAi63A3OTl9QN7d+ jNQuIjlt0DLC4UO2datLfMbbEcjE0Al3xRMvZEEjdrVg7iVPrms= =P5mf -----END PGP SIGNATURE----- --Apple-Mail=_AE77D6FF-A20A-46A3-9E6C-35DCF4F8861D-- From nobody Wed Feb 14 07:57: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 52764129C59 for ; Wed, 14 Feb 2018 07:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 V3NYRTjk2zlY for ; Wed, 14 Feb 2018 07:57:15 -0800 (PST) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 6F152129C53 for ; Wed, 14 Feb 2018 07:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1518623834; bh=UIj+IkGnsEL9LG8ujnwKpZbrbLvfDE1ixl7JRQE0SqY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RQaQrdz7h66aARRYob9JGQzh67P+PzMGT8JRm5FvBwHIm4hGtXuWBEGPjI7OEk6r+xCV88CcCEwheXRdWepeSyGmu/+JAd1sJwwPgINnPAtYPdDjMTj93bG++3I8ZSc/mMDOEHH8KdkZJ34SS9vZhOgk5hpCEEeLE7psKGOzghauo96XFrTIWw7P5aBRh1JGneWtdU35InihSf5j72ttYQXQ8LDVTgcgrhdDgIodLLH5yGJPFZ8wrZjdA3ECesipwIfoF4g8/cW8kdguegqUZUkc9WzwYLPKWOwZnfrC10u0db8SyBDla27THBWmdQQVJREbkahKxFmUaU+hYzFFrQ== X-YMail-OSG: 5RiMRKEVM1lkHycF5ziARt3rxynHKgRomeCDQysjTj0ZbPqkvLAY36ATvZW6bBJ l5Ogl31CGSuiNFSGo2ZJiIOizhu8LaHbXaZjyj9Ov__2UrJmNIZ3GGuaQYLO8pnZ1_F6KL1BIpcw tCYhFd5AAk6zXKc5zoxpur1CZTV00iJiIL8b8EKmDhOqu3795Ow9Yvp4YUqzyLbJq3K2T.b.sjBY SVcAKbHbzFCAf5O0Bxj53S9UYlCB7YMU.HAy0le1XMN8QanhEWbjeb64RmhHob.x2WKMgppIsx.2 ix9xV3SyYxorn5LRgAshf7NlyT5tB4prtqSSru.fXvVlKjPesFDB4_LNuzNFhRxskdpz3vp7.1df S0yPzbyRaTBmxjxAl622y9Y0iuhmv3IlPU9vKrV5TVYQ3BATwj4VmgV8S.gt90x27BXVnsKsaloi Fgur_EYBdeq_1qLMn3zxLYgn1UsLykGRN62XWawLAG6CgRgtY4qYhU9zeUIwfhUrhwQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 14 Feb 2018 15:57:14 +0000 Date: Wed, 14 Feb 2018 15:56:52 +0000 (UTC) From: Yuval Lifshitz To: draft-ietf-dime-rfc4006bis.all@ietf.org, Ben Campbell Cc: ops-ads@ietf.org, dime@ietf.org Message-ID: <608352900.888044.1518623812177@mail.yahoo.com> In-Reply-To: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> References: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_888043_2004280560.1518623812174" X-Mailer: WebService/1.1.11419 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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, 14 Feb 2018 15:57:18 -0000 ------=_Part_888043_2004280560.1518623812174 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben,First, thanks for the comments! Regarding the major comment, agree this should be added, it was already ag= reed in the meeting we had in IETF96, but somehow slipped :-( Sections 12: all the AVPs mentioned in this section exists in RFC4006, and = has values that are already registered. As part of RFC4006bis we did not ad= d any AVP that requires values enumeration (this was actually one of the is= sue we tried to tackle). What would you like to see different in this secti= on?What is the process for updating IANA with the references to the new doc= ? Can this happen before RFC4006bis is officially accepted? Appendix B: the new AVPs do not impact the flows, therefore not added to th= e sample flows 8.34 agree, this is pretty bad. How about:If the Final-Unit-Action AVP is s= et to RESTRICT_ACCESS or REDIRECT and the classification of the restricted traffic cannot be expressed using IPFilterRule, or different actions (e.g., QoS) than just allowing traffic needs to be enforced, then the QoS-Final-Unit- Indication AVP SHOULD be used instead of the Final-Unit-Indication AVP. 14. agree we should simplify as you suggested =20 Best Regards, Yuval On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell wrote: =20 =20 Hi, This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the w= ork on this; it=E2=80=99s overall a good update. However, I have one major = comment and a few minor or editorial comments. I=E2=80=99d like to discuss = the major comment prior IETF last call. The rest can be handled along with = any last call feedback. Note that for all but the major comment, I mostly reviewed the diff from RF= C 4006. 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 Major Comment: I strongly suggest that you add more privacy considerations. I realize that= it inherits its existing privacy considerations from RFC 4006, but that wa= s published in 2005. The IETF=E2=80=99s focus on privacy has evolved consid= erably since then, and I think this draft will get objections during IESG r= eview without adding some more. I suggest the following: =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section separat= e from the security considerations. =E2=80=94 Enumerate the AVPs that you think contain user identifiable infor= mation, persistent identifiers, or other privacy sensitive data. =E2=80=94 Make some non-normative recommendations concerning data minimizat= ion. That is, add a few sentences recommending that clients and servers avo= id capturing and/or log personal information beyond that needed for the app= lication's purpose. Minor Comments: -Section 12 and subsections: Please clarify that many of these elements wer= e already registered by RF 4006, and are not being =E2=80=9Cre-registered= =E2=80=9D here. ( It=E2=80=99s perfectly okay to pull the registration info= rmation forward into the bis draft; it just needs clarification.) Also, ple= ase consider wether existing registrations should be updated to point to th= is document rather than 4006. Appendices: Would any of the example flows benefit from including one or mo= re of the new AVPs? Editorial and Nits: -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to RESTRICT_AC= CESS or REDIRECT and the classification of the restricted traffic cannot be expressed using IPFilterRule, or different actions (e.g., QoS) than just allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C I have trouble parsing the sentence. -14: "Even without any modification to the messages, an adversary can =C2=A0 invite a security threat by eavesdropping, as the transactions conta= in private information about the user. =E2=80=9D I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transactions th= at contain privacy-sensitive imformation=E2=80=9D _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_888043_2004280560.1518623812174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben,
First, thanks for= the comments!

Regarding the major comment, agree= this should be added, it was already agreed in the meeting we had in IETF9= 6, but somehow slipped :-(

Sections 12: all th= e AVPs mentioned in this section exists in RFC4006, and has values that are= already registered. As part of RFC4006bis we did not add any AVP that requ= ires values enumeration (this was actually one of the issue we tried to tac= kle). What would you like to see different in this section?
What = is the process for updating IANA with the references to the new doc? Can th= is happen before RFC4006bis is officially accepted?

Appendix B: the new AVPs do not impact the flows, therefore not added= to the sample flows

8.34 agree, this is = pretty bad. How about:
If the F=
inal-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
   and the classification of the restricted traffic cannot be expressed
   using IPFilterRule, or different actions (e.g., QoS) than just
   allowing traffic needs to be enforced, then the QoS-Final-Unit-
   Indication AVP SHOULD be used instead of the Final-Unit-Indication
   AVP.

14. agree we should simplify as you sugge= sted

Best Regards,

Yuva= l
=20
=20
On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Be= n Campbell <ben@nostrum.com> wrote:


Hi,
This is my AD Evaluation of draft-ietf-dime-rfc4006= bis-06. Thanks for the work on this; it=E2=80=99s overall a good update. Ho= wever, I have one major comment and a few minor or editorial comments. I=E2= =80=99d like to discuss the major comment prior IETF last call. The rest ca= n be handled along with any last call feedback.
<= br>
Note that for all but the major comment, I mostly= reviewed the diff from RFC 4006.

Thanks!

Be= n.

=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

Major Comment:

I st= rongly suggest that you add more privacy considerations. I realize that it = inherits its existing privacy considerations from RFC 4006, but that was pu= blished in 2005. The IETF=E2=80=99s focus on privacy has evolved considerab= ly since then, and I think this draft will get objections during IESG revie= w without adding some more.

I suggest the following:
=E2=80=94 Create a= =E2=80=9CPrivacy Considerations=E2=80=9D section separate from the securit= y considerations.
=E2=80=94 Enumerate the AVPs th= at you think contain user identifiable information, persistent identifiers,= or other privacy sensitive data.
=E2=80=94 Make = some non-normative recommendations concerning data minimization. That is, a= dd a few sentences recommending that clients and servers avoid capturing an= d/or log personal information beyond that needed for the application's purp= ose.

Minor Comments:

-Section 12 and subsect= ions: Please clarify that many of these elements were already registered by= RF 4006, and are not being =E2=80=9Cre-registered=E2=80=9D here. ( It=E2= =80=99s perfectly okay to pull the registration information forward into th= e bis draft; it just needs clarification.) Also, please consider wether exi= sting registrations should be updated to point to this document rather than= 4006.

Appendices: Wou= ld any of the example flows benefit from including one or more of the new A= VPs?

Editorial and Nit= s:

-Section 8.34: =E2= =80=9C If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
and the classification of the restricted traffic c= annot be expressed
using IPFilterRule, or differe= nt actions (e.g., QoS) than just
allowing QoS nee= ds to be enforced traffic, =E2=80=A6 =E2=80=9C
I have trouble parsing the sentence.

-14: "Even without any modification= to the messages, an adversary can
  invite= a security threat by eavesdropping, as the transactions contain private in= formation about the user.
=E2=80=9D
I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on tr= ansactions that contain privacy-sensitive imformation=E2=80=9D





<= br>


____________= ___________________________________
DiME mailing list
DiME@ietf.org
https= ://www.ietf.org/mailman/listinfo/dime
------=_Part_888043_2004280560.1518623812174-- From nobody Wed Feb 14 09:06: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 D601512D77E for ; Wed, 14 Feb 2018 09:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tuur44ZvGNrD for ; Wed, 14 Feb 2018 09:06:48 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 56C0D12D77A for ; Wed, 14 Feb 2018 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1518628007; bh=yOANwa+UVFhW6Tc0RuFAXSMrZ8C8EEphQjpVa+Jkd8Q=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=uHfhu438JMXgNAF3QvaIqXWKtfGVHM0s2VHKygsq4qMywpJkHDBt3dAv8ETMJRSq6zqmUyK3YLk2LO1Zl4+PFlp1wUYFLuLQ/OBkVzWNLLnwapZ2K68crLBpg+uXPVpaY/poFyQqLH+nQhBsJ/dINRSZ5iC2CqH5NUpa2kmsO1Uot80pWZJL5J7rFrLpmHnt/iDB9x95iItpP7O5xG47h6hzehIhEp5SIv/ZkUyZlPjUqJJ1yl3wFF3HkDuszjnwv9cvLQjM+tW2Tn6r4H2QWBcQzZl1Q0QbxN5dETyZGuLxtcJlO9MuglPxs9LoY5qG7KIKNujkBYvwvbgcBHxp7A== X-YMail-OSG: 32zpmpEVM1n6UUErZj0Q2q3NdVj.yf5PExxm8IhMjq_C09EaJ7uXjFBhURRfai_ MnLqMD.yeGic5QP.m_6RXG8vX8TbwCsMCiqgY7kdcXjZwXbyOGTYKy86wPZHgE7NX78BghOLdtgd pgKoTefYHNUGmCJY5W_LL2Xn93EfKeb5zDt.txAQY.IiDCaCmM91S3PdLnEu8XPLSchu7Lu.kmf1 RFceXH82o.i3FstgFricWX6VxKszlJ2Zc9oRi_HOeaDVvdr0a64c3y5hNqggGqIYC40AeH.n7_e7 gPpMAEXKx3y7IFiRkqkB3Gu.M1y_Tu6SFaHC3K_tLnJJ7TsaNeSB7.Zf4oK4RRehjyu6tRDctvey fNWS1whslI3UZL3aZQmwcPWGZx4JFYTbukJG7YUueLyp0Oe1Lawj9moMTFnAxhJ6tipDaO4dk2jV plmxpnf1Yy0kHyEb2ISLF3xuHCEXz2jmcUjd3yTAZ4Qa28oTczKqiMHOkKmGW_Q0oFA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 14 Feb 2018 17:06:47 +0000 Date: Wed, 14 Feb 2018 17:06:44 +0000 (UTC) From: Yuval Lifshitz To: draft-ietf-dime-rfc4006bis.all@ietf.org, Ben Campbell Cc: ops-ads@ietf.org, dime@ietf.org Message-ID: <868034109.936629.1518628004592@mail.yahoo.com> In-Reply-To: <608352900.888044.1518623812177@mail.yahoo.com> References: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> <608352900.888044.1518623812177@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_936628_1602665855.1518628004589" X-Mailer: WebService/1.1.11419 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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, 14 Feb 2018 17:06:52 -0000 ------=_Part_936628_1602665855.1518628004589 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding "privacy considerations". Note that the base protocol RFC does no= t have that.Ideally, this is added to base Diameter first, as many of the s= ensitive AVPs come from there.Should we try to tackle that first (though th= is would delay the RFC4006bis process)?Should we cover only 4006 AVPs and i= ssues? Best Regards, Yuval =20 On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz wrote: =20 =20 Ben,First, thanks for the comments! Regarding the major comment, agree this should be added, it was already ag= reed in the meeting we had in IETF96, but somehow slipped :-( Sections 12: all the AVPs mentioned in this section exists in RFC4006, and = has values that are already registered. As part of RFC4006bis we did not ad= d any AVP that requires values enumeration (this was actually one of the is= sue we tried to tackle). What would you like to see different in this secti= on?What is the process for updating IANA with the references to the new doc= ? Can this happen before RFC4006bis is officially accepted? Appendix B: the new AVPs do not impact the flows, therefore not added to th= e sample flows 8.34 agree, this is pretty bad. How about:If the Final-Unit-Action AVP is s= et to RESTRICT_ACCESS or REDIRECT and the classification of the restricted traffic cannot be expressed using IPFilterRule, or different actions (e.g., QoS) than just allowing traffic needs to be enforced, then the QoS-Final-Unit- Indication AVP SHOULD be used instead of the Final-Unit-Indication AVP. 14. agree we should simplify as you suggested =20 Best Regards, Yuval On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell wrote: =20 =20 Hi, This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the w= ork on this; it=E2=80=99s overall a good update. However, I have one major = comment and a few minor or editorial comments. I=E2=80=99d like to discuss = the major comment prior IETF last call. The rest can be handled along with = any last call feedback. Note that for all but the major comment, I mostly reviewed the diff from RF= C 4006. 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 Major Comment: I strongly suggest that you add more privacy considerations. I realize that= it inherits its existing privacy considerations from RFC 4006, but that wa= s published in 2005. The IETF=E2=80=99s focus on privacy has evolved consid= erably since then, and I think this draft will get objections during IESG r= eview without adding some more. I suggest the following: =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section separat= e from the security considerations. =E2=80=94 Enumerate the AVPs that you think contain user identifiable infor= mation, persistent identifiers, or other privacy sensitive data. =E2=80=94 Make some non-normative recommendations concerning data minimizat= ion. That is, add a few sentences recommending that clients and servers avo= id capturing and/or log personal information beyond that needed for the app= lication's purpose. Minor Comments: -Section 12 and subsections: Please clarify that many of these elements wer= e already registered by RF 4006, and are not being =E2=80=9Cre-registered= =E2=80=9D here. ( It=E2=80=99s perfectly okay to pull the registration info= rmation forward into the bis draft; it just needs clarification.) Also, ple= ase consider wether existing registrations should be updated to point to th= is document rather than 4006. Appendices: Would any of the example flows benefit from including one or mo= re of the new AVPs? Editorial and Nits: -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to RESTRICT_AC= CESS or REDIRECT and the classification of the restricted traffic cannot be expressed using IPFilterRule, or different actions (e.g., QoS) than just allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C I have trouble parsing the sentence. -14: "Even without any modification to the messages, an adversary can =C2=A0 invite a security threat by eavesdropping, as the transactions conta= in private information about the user. =E2=80=9D I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transactions th= at contain privacy-sensitive imformation=E2=80=9D _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_936628_1602665855.1518628004589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding "privacy consideration= s". Note that the base protocol RFC does not have that.
Ideally, = this is added to base Diameter first, as many of the sensitive AVPs come fr= om there.
Should we try to tackle that first (though this would d= elay the RFC4006bis process)?
Should we cover only 4006 AVPs and = issues?

Best Regards,

Yuval


=20
=20
On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, = Yuval Lifshitz <yuvalif@yahoo.com> wrote:


Ben,
First, thanks for the comments= !

Regarding the major comment, agree this should = be added, it was already agreed in the meeting we had in IETF96, but someho= w slipped :-(

Sections 12: all the AVPs mentio= ned in this section exists in RFC4006, and has values that are already regi= stered. As part of RFC4006bis we did not add any AVP that requires values e= numeration (this was actually one of the issue we tried to tackle). What wo= uld you like to see different in this section?
What is the proces= s for updating IANA with the references to the new doc? Can this happen bef= ore RFC4006bis is officially accepted?

Appendi= x B: the new AVPs do not impact the flows, therefore not added to the sampl= e flows

8.34 agree, this is pretty bad. H= ow about:
If the Final-Unit-Act=
ion AVP is set to RESTRICT_ACCESS or REDIRECT
   and the classification of the restricted traffic cannot be expressed
   using IPFilterRule, or different actions (e.g., QoS) than just
   allowing traffic needs to be enforced, then the QoS-Final-Unit-
   Indication AVP SHOULD be used instead of the Final-Unit-Indication
   AVP.

14. agree we should simplify as you sugge= sted

Best Regards,

Yuva= l
=20
=20
On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Be= n Campbell <ben@nostrum.com> wrote:


Hi,
This is my AD Evaluation of draft-ietf-dime-rfc4006= bis-06. Thanks for the work on this; it=E2=80=99s overall a good update. Ho= wever, I have one major comment and a few minor or editorial comments. I=E2= =80=99d like to discuss the major comment prior IETF last call. The rest ca= n be handled along with any last call feedback.
<= br>
Note that for all but the major comment, I mostly= reviewed the diff from RFC 4006.

Thanks!

Be= n.

=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

Major Comment:

I st= rongly suggest that you add more privacy considerations. I realize that it = inherits its existing privacy considerations from RFC 4006, but that was pu= blished in 2005. The IETF=E2=80=99s focus on privacy has evolved considerab= ly since then, and I think this draft will get objections during IESG revie= w without adding some more.

I suggest the following:
=E2=80=94 Create a= =E2=80=9CPrivacy Considerations=E2=80=9D section separate from the securit= y considerations.
=E2=80=94 Enumerate the AVPs th= at you think contain user identifiable information, persistent identifiers,= or other privacy sensitive data.
=E2=80=94 Make = some non-normative recommendations concerning data minimization. That is, a= dd a few sentences recommending that clients and servers avoid capturing an= d/or log personal information beyond that needed for the application's purp= ose.

Minor Comments:

-Section 12 and subsect= ions: Please clarify that many of these elements were already registered by= RF 4006, and are not being =E2=80=9Cre-registered=E2=80=9D here. ( It=E2= =80=99s perfectly okay to pull the registration information forward into th= e bis draft; it just needs clarification.) Also, please consider wether exi= sting registrations should be updated to point to this document rather than= 4006.

Appendices: Wou= ld any of the example flows benefit from including one or more of the new A= VPs?

Editorial and Nit= s:

-Section 8.34: =E2= =80=9C If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
and the classification of the restricted traffic c= annot be expressed
using IPFilterRule, or differe= nt actions (e.g., QoS) than just
allowing QoS nee= ds to be enforced traffic, =E2=80=A6 =E2=80=9C
I have trouble parsing the sentence.

-14: "Even without any modification= to the messages, an adversary can
  invite= a security threat by eavesdropping, as the transactions contain private in= formation about the user.
=E2=80=9D
I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on tr= ansactions that contain privacy-sensitive imformation=E2=80=9D





<= br>


____________= ___________________________________
DiME mailing list
DiME@ietf.org
https= ://www.ietf.org/mailman/listinfo/dime
------=_Part_936628_1602665855.1518628004589-- From nobody Wed Feb 14 09:12: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 568F712D77A; Wed, 14 Feb 2018 09:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 TrBUCdUtT6bD; Wed, 14 Feb 2018 09:12:48 -0800 (PST) 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 731AC12D77E; Wed, 14 Feb 2018 09:12:48 -0800 (PST) Received: from [10.0.1.105] (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 w1EHCkQ3011018 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 14 Feb 2018 11:12:47 -0600 (CST) (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.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D7793480-E8FE-4266-9CD3-8B8C6BCF3A63"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 14 Feb 2018 11:12:45 -0600 In-Reply-To: <868034109.936629.1518628004592@mail.yahoo.com> Cc: draft-ietf-dime-rfc4006bis.all@ietf.org, ops-ads@ietf.org, dime@ietf.org To: Yuval Lifshitz References: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> <608352900.888044.1518623812177@mail.yahoo.com> <868034109.936629.1518628004592@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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, 14 Feb 2018 17:12:51 -0000 --Apple-Mail=_D7793480-E8FE-4266-9CD3-8B8C6BCF3A63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Even if we add privacy considerations to the base protocol, I think = 4006bis would still need privacy considerations that discuss the = specific AVPs it defines. So I would go ahead and add considerations to = 4006bis and avoid the delay. The WG can discuss whether it would like to = add more general considerations to the base protocol (either in a bis = draft or an update). Thanks! Ben. > On Feb 14, 2018, at 11:06 AM, Yuval Lifshitz = wrote: >=20 > Regarding "privacy considerations". Note that the base protocol RFC = does not have that. > Ideally, this is added to base Diameter first, as many of the = sensitive AVPs come from there. > Should we try to tackle that first (though this would delay the = RFC4006bis process)? > Should we cover only 4006 AVPs and issues? >=20 > Best Regards, >=20 > Yuval >=20 >=20 > On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz = wrote: >=20 >=20 > Ben, > First, thanks for the comments! >=20 > Regarding the major comment, agree this should be added, it was = already agreed in the meeting we had in IETF96, but somehow slipped :-( >=20 > Sections 12: all the AVPs mentioned in this section exists in RFC4006, = and has values that are already registered. As part of RFC4006bis we did = not add any AVP that requires values enumeration (this was actually one = of the issue we tried to tackle). What would you like to see different = in this section? > What is the process for updating IANA with the references to the new = doc? Can this happen before RFC4006bis is officially accepted? >=20 > Appendix B: the new AVPs do not impact the flows, therefore not added = to the sample flows >=20 > 8.34 agree, this is pretty bad. How about: > If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT > and the classification of the restricted traffic cannot be = expressed > using IPFilterRule, or different actions (e.g., QoS) than just > allowing traffic needs to be enforced, then the QoS-Final-Unit- > Indication AVP SHOULD be used instead of the Final-Unit-Indication > AVP. >=20 >=20 > 14. agree we should simplify as you suggested >=20 > Best Regards, >=20 > Yuval > On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell = wrote: >=20 >=20 > Hi, >=20 > This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for = the work on this; it=E2=80=99s overall a good update. However, I have = one major comment and a few minor or editorial comments. I=E2=80=99d = like to discuss the major comment prior IETF last call. The rest can be = handled along with any last call feedback. >=20 > Note that for all but the major comment, I mostly reviewed the diff = from RFC 4006. >=20 > Thanks! >=20 > Ben. >=20 > =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 >=20 > Major Comment: >=20 > I strongly suggest that you add more privacy considerations. I realize = that it inherits its existing privacy considerations from RFC 4006, but = that was published in 2005. The IETF=E2=80=99s focus on privacy has = evolved considerably since then, and I think this draft will get = objections during IESG review without adding some more. >=20 > I suggest the following: > =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section = separate from the security considerations. > =E2=80=94 Enumerate the AVPs that you think contain user identifiable = information, persistent identifiers, or other privacy sensitive data. > =E2=80=94 Make some non-normative recommendations concerning data = minimization. That is, add a few sentences recommending that clients and = servers avoid capturing and/or log personal information beyond that = needed for the application's purpose. >=20 > Minor Comments: >=20 > -Section 12 and subsections: Please clarify that many of these = elements were already registered by RF 4006, and are not being = =E2=80=9Cre-registered=E2=80=9D here. ( It=E2=80=99s perfectly okay to = pull the registration information forward into the bis draft; it just = needs clarification.) Also, please consider wether existing = registrations should be updated to point to this document rather than = 4006. >=20 > Appendices: Would any of the example flows benefit from including one = or more of the new AVPs? >=20 > Editorial and Nits: >=20 > -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to = RESTRICT_ACCESS or REDIRECT > and the classification of the restricted traffic cannot be expressed > using IPFilterRule, or different actions (e.g., QoS) than just > allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C >=20 > I have trouble parsing the sentence. >=20 > -14: "Even without any modification to the messages, an adversary can > invite a security threat by eavesdropping, as the transactions = contain private information about the user. > =E2=80=9D > I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on = transactions that contain privacy-sensitive imformation=E2=80=9D >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_D7793480-E8FE-4266-9CD3-8B8C6BCF3A63 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlqEbg0ACgkQgFZKbJXz 1A2fZA//bXdb9yRlSD9K4zlyIaH8YVjm/pQWIqxyd7kSF2S6rVxRuFkazQTeulEf V2Z2hf2l/es9IqYvneOj7yCjd6SNGQPwnNgIJIOS4Ee5vbbco+9wAVj5ktWPkko8 MYlmUUuyqqEgjS/hgMHvvlVZJ5bk+tZG8+4dpjpxLofSGcOqVQ+zHBXnaVh5g/Vn vOwsiAl5oCJPBDf1RvRAfxCO0KFa3c5n1D1wAscGxi2tkBFSzle01hSwCfnIfOuM wvkISSHy2sG7pm5PSFnN6Guw2+DRtTszqm7c3jwfsYxkdUBRVaEwxNq/uYxrGu7y k7AJDVbuuX/2egNnsoSkVF04xBnOVWKlKQOWKiazxiLOLVadFsSQG1vhsJivHWvI JclZdu6GujDifPjH9nQbi8vos3mbgm/ma9RyjbbKjaiXqO1cKuKcD5EGHtmdXT+K /euwyGx8DuymGOn+9OwH8cJv/bOKUAuPX2pT16pkpmArdywJzMXpTqiLDJFVVioR XVrQlPliGzoW8fWSXmxiq/iP7u4UKaUPfv/3MXyWffm6GR/SLZRV8JccU+6B5YpX mv5/v0pSlkj3W/4zV1WDmZNQtf+DJCMPc5Zsc3URpNQkSpj+HEuvi+EIrH4fMZKH 1QoBDyQWkb03vYU66t/nnmTI8mfNXynx1Bos0Oo4GHEblq7dH5Y= =9vm6 -----END PGP SIGNATURE----- --Apple-Mail=_D7793480-E8FE-4266-9CD3-8B8C6BCF3A63-- From nobody Sun Feb 25 23:15: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 CA25E120721 for ; Sun, 25 Feb 2018 23:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 IwWUFnjrrqHP for ; Sun, 25 Feb 2018 23:15:52 -0800 (PST) Received: from sonic314-15.consmr.mail.bf2.yahoo.com (sonic314-15.consmr.mail.bf2.yahoo.com [74.6.132.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 1972312D0C3 for ; Sun, 25 Feb 2018 23:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1519629350; bh=SS1vpHZjcowxIQa9RVV8GVnG6Cyv80HX+9HSaLk6urk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=OE9I2U8JwYJpOOCEeQ5NKpsEhuMPwvp8BY3SPFgl0e86HuJCZ14ZQWfOhDfGx4WsR00EltGNI3kNBSQocd/0T0ICuVNqIFDNeodIrNU6ErPIMjDWpzJiXiEF7EBSeDIMvm9W7fWm06fP5cKSTllcoX0sKL4pR4iEtIXk4Wl1ekU3TP/69/wZVVTBCQDX2ub31SFiQYmK1Tg7itjjPL1jKb3iCaSve8z3cdxsJR3fJYy/mEo3Ub8hne6jFKc1nYhD8wMJPBl3tBGpI8n1pJyveXI/TdsdJscriXDXn5ECHmhBCxM477W5WdKVjicESzS7fInVbLznXZrFMsdmmizwtg== X-YMail-OSG: BZwmjzUVM1n0alfGl8IL017TzLD30FXHWZWPhIKlrwhHC1ef.R2axzLojicNoLZ aSuO7DVBZDwgx_AFVWAjGJadVSwUIXhaLxQPvweAMFlDKp0O0iI7rfznLSEIyJ6dpz46g965i6d0 FC0aIyiFVkeICEUspiRbXZdABML0pWijj_fD72N26UF5cqaAEvvof8FcpF3kvBSs23CJFOJjSNOD ryD_qwsAynonAPxzSSgqFUAveAtQFDyIPawoZSJNAgHDqCW4pt2U.NOT5IRH1rmZjj8ZRRXM98Yt AfJy2.k6_WF9CPEx2X2SC6c4jeDTu21p52U.G3GidEcb1PyWImvG8bVIiUdsiGPKsCKAcSmcfiI3 yxwlh_SRWZS3KUKB8jS3yEqHasuEiVmr5vHpGpKOWm6u3k_gLNv4FYAi2TzFA0Xvjt5nmXZ8vmlr 9beel.U16PBvT6vNFB0Di2sPfZpM1WDa7udTOcAekJ2pw0qBUZjlI.MxDjQhVtsTbVg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Mon, 26 Feb 2018 07:15:50 +0000 Date: Mon, 26 Feb 2018 07:14:40 +0000 (UTC) From: Yuval Lifshitz To: Ben Campbell Cc: draft-ietf-dime-rfc4006bis.all@ietf.org, ops-ads@ietf.org, dime@ietf.org Message-ID: <2108881588.5977405.1519629280512@mail.yahoo.com> In-Reply-To: References: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> <608352900.888044.1518623812177@mail.yahoo.com> <868034109.936629.1518628004592@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5977404_61005180.1519629280509" X-Mailer: WebService/1.1.11419 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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: Mon, 26 Feb 2018 07:15:55 -0000 ------=_Part_5977404_61005180.1519629280509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All,Would appreciate if you can review/comment on the the following new = section:15. Privacy Considerations As the Diameter protocol, and especially credit control application, deals with subscribers and their actions, extra care should be taken regarding the privacy of the subscribers. In terms of [RFC6973], both the credit-control client and credit-control server are intermediary entities, wherein the subscribers' privacy may be compromised even if no security issues exists, and only authorized entities have access to the privacy-sensitive information. 15.1. Privacy Sensitive AVPs The following AVPs contain privacy-sensitive information at different levels: 1. CC-Correlation-Id AVP: may contain privacy-sensitive information as the service-provider may encode personal information that helps it correlate different subscriptions and access technologies. 2. Check-Balance-Result AVP: contains information on the balance status of the subscriber. 3. Currency-Code AVP: contains information on the subscriber's locale. 4. Cost-Unit AVP: contains privacy-sensitive information, as a human readable format of the Cost-Information AVP. 5. Service-Identifier AVP: may contain privacy-sensitive information about the subscriber's internet activity. 6. Rating-Group AVP: may contain privacy-sensitive information about the subscriber's internet activity. 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule may be used to infer services used by the subscriber. 8. 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). Similar AVPs are: Redirect- Address-URL, Redirect-Address-SIP-URI. 9. Service-Context-Id AVP: depending with how the service-provider use it, it may contain privacy-sensitive information about the service (e.g. access technology). 10. Service-Parameter-Info AVP: depending with how the service- provider use it, it may contain privacy-sensitive information about the subscriber (e.g. location). 11. Subscription-Id-Data AVP: contains the identity of the subscriber. Similar AVPs are: Subscription-Id-E164, Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id- NAI, Subscription-Id-Private. 12. User-Equipment-Info-Value AVP: contains the identity of the device of the subscriber. Similar AVPs are: User-Equipment- Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, User-Equipment-Info-ModifiedEUI64, User-Equipment-Info-IMEI. 13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains privacy-sensitive information in its sub-AVPs (e.g IPFilterRule, redirect address). Note that some AVPs which are used in this document are defined in [RFC6733] and may contain privacy-sensitive information. These AVPs are not listed above. 15.2. Data Minimization Due to the nature of the credit control application, some personal data and identity information must be stored in both credit-control client and credit control server. This, however, could be minimized by following these guidelines: 1. Data stored in the credit-control client does not need to be persisted across sessions. All data could be deleted once the session end, and reconstructed once a new session is initialized. Note that, while the credit-control server is usually owned by the service provider with which the subscriber already has some direct legal or business relationship (where privacy level could be agreed upon), this is not always true for the credit-control client, that may be owned by a third-party. 2. Some information about the subscriber has to be stored in persistent storage in the credit-control server (e.g. identity, balance), however, per transaction information does not have to be stored in persistent storage, and per session information may be deleted from persistent storage once the session ends. 3. In some cases, per transaction information has to be stored on the credit-control server, client, or both, for regulatory, auditability or debugging reasons. However, this could be minimized by following these guidelines: A. Data retention SHOULD NOT exceed the required durations B. Transaction information SHOULD be aggregated as much as possible. E.g. prefer information per sessions vs. information per rating-group; prefer hourly byte summary vs. per transaction byte counts. C. If not strictly needed, the more sensitive information (E.g. location, equipment type) SHOULD be filtered out from such logs. Such information is often used to make rating decisions, and in this case, the rating decision should be logged instead of the data used to make them D. The credit-control server SHOULD be preferred over the credit-control client as the place where per transaction information is stored, if needed. This is due to the reasons explained in 1. 15.3. Diameter Agents Diameter agents, as described in [RFC6733], may be owned by third- parties. To prevent from privacy sensitive information from leaking into them, it is RECOMMENDED to encrypt AVPs holding such information, as listed in Section 15.1. In some cases, the Diameter agent requires access into privacy- sensitive AVPs, in order to take correct routing decisions, or even modify the content of these AVPs. In such a case it is RECOMMENDED to anonymize the identity of the subscriber, and encrypt any other AVP not used by the agent and can be used to identify the subscriber. =20 On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, Ben Campbell wrote: =20 =20 Even if we add privacy considerations to the base protocol, I think 4006bi= s would still need privacy considerations that discuss the specific AVPs it= defines. So I would go ahead and add considerations to 4006bis and avoid t= he delay. The WG can discuss whether it would like to add more general cons= iderations to the base protocol (either in a bis draft or an update). Thanks! Ben. > On Feb 14, 2018, at 11:06 AM, Yuval Lifshitz wrote: >=20 > Regarding "privacy considerations". Note that the base protocol RFC does = not have that. > Ideally, this is added to base Diameter first, as many of the sensitive A= VPs come from there. > Should we try to tackle that first (though this would delay the RFC4006bi= s process)? > Should we cover only 4006 AVPs and issues? >=20 > Best Regards, >=20 > Yuval >=20 >=20 > On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz wrote: >=20 >=20 > Ben, > First, thanks for the comments! >=20 > Regarding the major comment, agree this should be added, it was already a= greed in the meeting we had in IETF96, but somehow slipped :-( >=20 > Sections 12: all the AVPs mentioned in this section exists in RFC4006, an= d has values that are already registered. As part of RFC4006bis we did not = add any AVP that requires values enumeration (this was actually one of the = issue we tried to tackle). What would you like to see different in this sec= tion? > What is the process for updating IANA with the references to the new doc?= Can this happen before RFC4006bis is officially accepted? >=20 > Appendix B: the new AVPs do not impact the flows, therefore not added to = the sample flows >=20 > 8.34 agree, this is pretty bad. How about: > If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT >=C2=A0 =C2=A0 and the classification of the restricted traffic cannot be e= xpressed >=C2=A0 =C2=A0 using IPFilterRule, or different actions (e.g., QoS) than ju= st >=C2=A0 =C2=A0 allowing traffic needs to be enforced, then the QoS-Final-Un= it- >=C2=A0 =C2=A0 Indication AVP SHOULD be used instead of the Final-Unit-Indi= cation >=C2=A0 =C2=A0 AVP. >=20 >=20 > 14. agree we should simplify as you suggested >=20 > Best Regards, >=20 > Yuval > On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell wrote: >=20 >=20 > Hi, >=20 > This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the= work on this; it=E2=80=99s overall a good update. However, I have one majo= r comment and a few minor or editorial comments. I=E2=80=99d like to discus= s the major comment prior IETF last call. The rest can be handled along wit= h any last call feedback. >=20 > Note that for all but the major comment, I mostly reviewed the diff from = RFC 4006. >=20 > Thanks! >=20 > Ben. >=20 > =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 >=20 > Major Comment: >=20 > I strongly suggest that you add more privacy considerations. I realize th= at it inherits its existing privacy considerations from RFC 4006, but that = was published in 2005. The IETF=E2=80=99s focus on privacy has evolved cons= iderably since then, and I think this draft will get objections during IESG= review without adding some more. >=20 > I suggest the following: > =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section separ= ate from the security considerations. > =E2=80=94 Enumerate the AVPs that you think contain user identifiable inf= ormation, persistent identifiers, or other privacy sensitive data. > =E2=80=94 Make some non-normative recommendations concerning data minimiz= ation. That is, add a few sentences recommending that clients and servers a= void capturing and/or log personal information beyond that needed for the a= pplication's purpose. >=20 > Minor Comments: >=20 > -Section 12 and subsections: Please clarify that many of these elements w= ere already registered by RF 4006, and are not being =E2=80=9Cre-registered= =E2=80=9D here. ( It=E2=80=99s perfectly okay to pull the registration info= rmation forward into the bis draft; it just needs clarification.) Also, ple= ase consider wether existing registrations should be updated to point to th= is document rather than 4006. >=20 > Appendices: Would any of the example flows benefit from including one or = more of the new AVPs? >=20 > Editorial and Nits: >=20 > -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to RESTRICT_= ACCESS or REDIRECT > and the classification of the restricted traffic cannot be expressed > using IPFilterRule, or different actions (e.g., QoS) than just > allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C >=20 > I have trouble parsing the sentence. >=20 > -14: "Even without any modification to the messages, an adversary can >=C2=A0 invite a security threat by eavesdropping, as the transactions cont= ain private information about the user. > =E2=80=9D > I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transactions = that contain privacy-sensitive imformation=E2=80=9D >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime =20 ------=_Part_5977404_61005180.1519629280509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,
Would apprecia= te if you can review/comment on the the following new section:
15. Privacy Considerations As the Diameter protocol, and especially credit control application, deals with subscribers and their actions, extra care should be taken regarding the privacy of the subscribers. In terms of [RFC6973], both the credit-control client and credit-control server are intermediary entities, wherein the subscribers' privacy may be compromised even if no security issues exists, and only authorized entities have access to the privacy-sensitive information. 15.1. Privacy Sensitive AVPs The following AVPs contain privacy-sensitive information at different levels: 1. CC-Correlation-Id AVP: may contain privacy-sensitive information as the service-provider may encode personal information that helps it correlate different subscriptions and access technologies. 2. Check-Balance-Result AVP: contains information on the balance status of the subscriber. 3. Currency-Code AVP: contains information on the subscriber's locale. 4. Cost-Unit AVP: contains privacy-sensitive information, as a human readable format of the Cost-Information AVP. 5. Service-Identifier AVP: may contain privacy-sensitive information about the subscriber's internet activity. 6. Rating-Group AVP: may contain privacy-sensitive information about the subscriber's internet activity. 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule may be used to infer services used by the subscriber. 8. 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). Similar AVPs are: Redirect- Address-URL, Redirect-Address-SIP-URI. 9. Service-Context-Id AVP: depending with how the service-provider use it, it may contain privacy-sensitive information about the service (e.g. access technology). 10. Service-Parameter-Info AVP: depending with how the service- provider use it, it may contain privacy-sensitive information about the subscriber (e.g. location). 11. Subscription-Id-Data AVP: contains the identity of the subscriber. Similar AVPs are: Subscription-Id-E164, Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id- NAI, Subscription-Id-Private. 12. User-Equipment-Info-Value AVP: contains the identity of the device of the subscriber. Similar AVPs are: User-Equipment- Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, User-Equipment-Info-ModifiedEUI64, User-Equipment-Info-IMEI. 13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains privacy-sensitive information in its sub-AVPs (e.g IPFilterRule, redirect address). Note that some AVPs which are used in this document are defined in [RFC6733] and may contain privacy-sensitive information. These AVPs are not listed above. 15.2. Data Minimization Due to the nature of the credit control application, some personal data and identity information must be stored in both credit-control client and credit control server. This, however, could be minimized by following these guidelines: 1. Data stored in the credit-control client does not need to be persisted across sessions. All data could be deleted once the session end, and reconstructed once a new session is initialized. Note that, while the credit-control server is usually owned by the service provider with which the subscriber already has some direct legal or business relationship (where privacy level could be agreed upon), this is not always true for the credit-control client, that may be owned by a third-party. 2. Some information about the subscriber has to be stored in persistent storage in the credit-control server (e.g. identity, balance), however, per transaction information does not have to be stored in persistent storage, and per session information may be deleted from persistent storage once the session ends. 3. In some cases, per transaction information has to be stored on the credit-control server, client, or both, for regulatory, auditability or debugging reasons. However, this could be minimized by following these guidelines: A. Data retention SHOULD NOT exceed the required durations B. Transaction information SHOULD be aggregated as much as possible. E.g. prefer information per sessions vs. information per rating-group; prefer hourly byte summary vs. per transaction byte counts. C. If not strictly needed, the more sensitive information (E.g. location, equipment type) SHOULD be filtered out from such logs. Such information is often used to make rating decisions, and in this case, the rating decision should be logged instead of the data used to make them D. The credit-control server SHOULD be preferred over the credit-control client as the place where per transaction information is stored, if needed. This is due to the reasons explained in 1. 15.3. Diameter Agents Diameter agents, as described in [RFC6733], may be owned by third- parties. To prevent from privacy sensitive information from leaking into them, it is RECOMMENDED to encrypt AVPs holding such information, as listed in Section 15.1. In some cases, the Diameter agent requires access into privacy- sensitive AVPs, in order to take correct routing decisions, or even modify the content of these AVPs. In such a case it is RECOMMENDED to anonymize the identity of the subscriber, and encrypt any other AVP not used by the agent and can be used to identify the subscriber.



=20
=20
On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, = Ben Campbell <ben@nostrum.com> wrote:


Even if we add privacy considerat= ions to the base protocol, I think 4006bis would still need privacy conside= rations that discuss the specific AVPs it defines. So I would go ahead and = add considerations to 4006bis and avoid the delay. The WG can discuss wheth= er it would like to add more general considerations to the base protocol (e= ither in a bis draft or an update).

Th= anks!

Ben.

> On Feb 14, 20= 18, at 11:06 AM, Yuval Lifshitz <yuvalif@yahoo.com>= wrote:
>
> Regarding "privacy c= onsiderations". Note that the base protocol RFC does not have that.
> Ideally, this is added to base Diameter first, as many of t= he sensitive AVPs come from there.
> Should we try to = tackle that first (though this would delay the RFC4006bis process)?
> Should we cover only 4006 AVPs and issues?
>
> Best Regards,
>
> Yuval
>
>
> On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval= Lifshitz <yuvalif@yahoo.com> wrote:
>
>
> Ben,
> First, thanks for the comments!
>
> Regarding the major comment, agree this should be added, it= was already agreed in the meeting we had in IETF96, but somehow slipped :-= (
>
> Sections 12: all the AVPs = mentioned in this section exists in RFC4006, and has values that are alread= y registered. As part of RFC4006bis we did not add any AVP that requires va= lues enumeration (this was actually one of the issue we tried to tackle). W= hat would you like to see different in this section?
>= What is the process for updating IANA with the references to the new doc? = Can this happen before RFC4006bis is officially accepted?
>
> Appendix B: the new AVPs do not impact the fl= ows, therefore not added to the sample flows
>
> 8.34 agree, this is pretty bad. How about:
> If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT<= br clear=3D"none">>    and the classification of the restricte= d traffic cannot be expressed
>    using IPF= ilterRule, or different actions (e.g., QoS) than just
>= ;    allowing traffic needs to be enforced, then the QoS-Final-Un= it-
>    Indication AVP SHOULD be used inste= ad of the Final-Unit-Indication
>    AVP.>
>
> 14. ag= ree we should simplify as you suggested
>
> Best Regards,
>
> Yu= val
> On Tuesday, February 13, 2018, 1:33:22 AM GMT+2,= Ben Campbell <ben@nostrum.com> wrote:
>
>
> Hi,
>
> This is my AD Evaluation of draft-ietf-dime-= rfc4006bis-06. Thanks for the work on this; it=E2=80=99s overall a good upd= ate. However, I have one major comment and a few minor or editorial comment= s. I=E2=80=99d like to discuss the major comment prior IETF last call. The = rest can be handled along with any last call feedback.
&g= t;
> Note that for all but the major comment, I mostl= y reviewed the diff from RFC 4006.
>
> 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
>
> Major Comment:
>
> I strongly suggest that you add mo= re privacy considerations. I realize that it inherits its existing privacy = considerations from RFC 4006, but that was published in 2005. The IETF=E2= =80=99s focus on privacy has evolved considerably since then, and I think t= his draft will get objections during IESG review without adding some more.<= br clear=3D"none">>
> I suggest the following:
> =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2= =80=9D section separate from the security considerations.
> =E2=80=94 Enumerate the AVPs that you think contain user identifiable= information, persistent identifiers, or other privacy sensitive data.
> =E2=80=94 Make some non-normative recommendations concer= ning data minimization. That is, add a few sentences recommending that clie= nts and servers avoid capturing and/or log personal information beyond that= needed for the application's purpose.
>
> Minor Comments:
>
> -= Section 12 and subsections: Please clarify that many of these elements were= already registered by RF 4006, and are not being =E2=80=9Cre-registered=E2= =80=9D here. ( It=E2=80=99s perfectly okay to pull the registration informa= tion forward into the bis draft; it just needs clarification.) Also, please= consider wether existing registrations should be updated to point to this = document rather than 4006.
>
> A= ppendices: Would any of the example flows benefit from including one or mor= e of the new AVPs?
>
> Editorial= and Nits:
>
> -Section 8.34: = =E2=80=9C If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIREC= T
> and the classification of the restricted traffic c= annot be expressed
> using IPFilterRule, or different = actions (e.g., QoS) than just
> allowing QoS needs to = be enforced traffic, =E2=80=A6 =E2=80=9C
>
> I have trouble parsing the sentence.
> =
> -14: "Even without any modification to the messages= , an adversary can
>  invite a security threat b= y eavesdropping, as the transactions contain private information about the = user.
> =E2=80=9D
> I suggest =E2= =80=9C =E2=80=A6 an adversary can eavesdrop on transactions that contain pr= ivacy-sensitive imformation=E2=80=9D
>
>
>
>
>
>
>
&g= t;
> _______________________________________________<= br clear=3D"none">> DiME mailing list
> DiME@= ietf.org
> https://www.ietf.org/mailm= an/listinfo/dime
------=_Part_5977404_61005180.1519629280509-- From nobody Wed Feb 28 02:26:34 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 01EF612EAF8; Wed, 28 Feb 2018 02:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, 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=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 in-eAyd1yFaq; Wed, 28 Feb 2018 02:26:29 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 AF738127909; Wed, 28 Feb 2018 02:26:28 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id g72so2733396lfg.3; Wed, 28 Feb 2018 02:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aeEDzX1kEbu7oV7klUsfXO2yEENV0Sj/Z4KVswxLN0E=; b=RIMMpm130w8iu4zFS7i0IdZ6s+RiAakk/ezZOeo9MdiOWTNw1RFrR1zuNgRuMhWUQA UxWJjq6+LkmHfBC+kZIiMBvvQXf5dgqd0BnrDvyCPauG70uabGV/xxXxNpl6/22ODNe7 beJoSP2OCh/FzNjiPK7B3u7/5jXYVZoYtoGR4+tC760Eotkb+SjcbXxBJfNdzgyexHZT DPmwi3Fdk5O6i0GPR5gtnGvhecx7Xn3y8030+oTTc5uEZ4p9pqlgEDYLO4npHFoT2Gei oaEkzP+ngwUsqmTOtnDmYeWAE1fAprrb4rOGxWBXs9WhERv8ViQlVfAB9V4jdvcBniHz BLuQ== 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; bh=aeEDzX1kEbu7oV7klUsfXO2yEENV0Sj/Z4KVswxLN0E=; b=DE6rAKKwvLY0f8JtKX4Ht4/TcRzkMyfETxSjACWVAo4ny6hwQaZ4hRa+EXc1q2Dmi5 L6cYy+UsXKcffoUQ1oHBIz7+AgpUp5Iv+q2xEXU776E8jhWQtjivIWc9rg62o8ePqiIp nRs0YnlUqCN9D1H3OURr5JnpTPI67+sUoyy8onUHX60Lbzc4GahsCeJVgn76ek6nJ8Tr uVzro8BZigfPSA0oS0ypS557LEfCdXYjFPLXt8L2d8zvXl6Fce9TjpgmuiM4I4gQv0uv MzW34wAN7PKcfDjZ4C6nwnncycmKkta3BtcXgDWHvMubfy/BmsnHrGNrlmFInkBvuC8L VsHQ== X-Gm-Message-State: APf1xPCNFZgvnYX/Z7NRdpYy4meOUuU4aoAfrbvXShjezYy/IOCsHvyh 0PdvCbJn79xPVTbyRQczsGU7kmk4EC0o4e/FjY0= X-Google-Smtp-Source: AG47ELup+T5NG/2ZxTjEO3hrgCt1AHYhzTdQn8JMdaOEpmjm4WBn3jlV/PsW+wkp1aKamBdljv7fsaCta5sMAi2IfIw= X-Received: by 10.46.41.157 with SMTP id p29mr12051211ljp.137.1519813586923; Wed, 28 Feb 2018 02:26:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.154.13 with HTTP; Wed, 28 Feb 2018 02:26:26 -0800 (PST) In-Reply-To: <1911118245.6898746.1519740058412@mail.yahoo.com> References: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> <608352900.888044.1518623812177@mail.yahoo.com> <868034109.936629.1518628004592@mail.yahoo.com> <2108881588.5977405.1519629280512@mail.yahoo.com> <1911118245.6898746.1519740058412@mail.yahoo.com> From: Misha Zaytsev Date: Wed, 28 Feb 2018 13:26:26 +0300 Message-ID: To: Yuval Lifshitz , dime@ietf.org, ops-ads@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org Content-Type: multipart/alternative; boundary="001a114afba6f935930566432c24" Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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, 28 Feb 2018 10:26:33 -0000 --001a114afba6f935930566432c24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yuval, Thanks for your answers! (3) Why Destination-Realm AVP (mandatory for CCR) cannot be used by DRL for making routing decisions? In the referred section 2.8.1. RFC6733, I think this is NAS that may try to parse NAS id to extract a realm value. In my understanding, when routing DRL should deal only with so called routing AVPs, section 6.7 in RFC6733. (4) I think you can list both 2 options to cover a privacy aspect. /Misha 2018-02-27 17:00 GMT+03:00 Yuval Lifshitz : > Hi Misha, > Thank you very much for the comments! > > (1) will fix > > (2) "credit-control" is the common form in RFC4006 - will fix in the doc. > Will use "privacy-sensitive", though I could not find other references to > this term (not used in RFC6973) > > (3) Will add the following text: " > For example, a relay agent may need to look into the Subscription-Id-NAI > AVP, in order to extract the realm of the user, and use it to lookup the > destination to which the request should be routed (see: section 2.8.1 in > [RFC6733]) > " > > (4) will fix the typo. > Regarding AVP level encryption, this is more complicated. This idea > existed in RFC3588 (the old diameter base RFC), but removed from > RFC6733.Actually, section 13.3 (in RFC6733) deals with security-sensitive > AVPs, and recommend end2end encryption (At message level) as well as > avoiding agents, or making sure that the agents are trusted and don't > create a security issue. Given the privacy guidelines in RFC6973, this is > not sufficient, as security and privacy are two different things. > There was an effort to reintroduce that here: > https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03 but seems > like this did not materialized into a formal specification. > > So, I see 2 options here: > * Use the security guidelines for privacy. This would mean that privacy i= s > going to be compromised unless the agent is managed by the same entity as > the credit-control server > * Recommend AVP level encryption and mention that the actual mechanism is > outside the scope of the diameter RFC > > Unrelated question to the group - do you think it is worthwhile to revive > the end2end security work? Do you know why was it abandoned? > > Yuval > > On Tuesday, February 27, 2018, 12:36:45 PM GMT+2, Misha Zaytsev < > misha.zaytsev.rus@gmail.com> wrote: > > > Hi Yuval, > > Just firstly some editorial comments + questions: > > 1. As the Diameter protocol, and especially credit control application, > deals with subscribers and their actions, extra care should be taken > regarding the privacy of the subscribers. In terms of [RFC6973], > both the credit-control client and credit-control server are > intermediary entities, wherein the subscribers' privacy may be > compromised even if no security issues *exist*, and only authorized > entities have access to the privacy-sensitive information. > > 2. Let's use one form of writing: either "credit-control" or "credit cont= rol". The same is related to "privacy-sensitive" and "privacy sensitive" > > 3. What are privacy-sensitive AVPs used for making routing decisions mean= t here? Please list some of them. > > In some cases, the Diameter agent requires access into privacy- > sensitive AVPs, in order to take correct routing decisions, or even > modify the content of these AVPs. > > 4. What do you mean under "encrypt AVPs"? Encryption is not part of > Diameter functions... Could you elaborate your idea? > > To prevent *from (typo?)* privacy sensitive information from leaking > into them, it is RECOMMENDED to encrypt AVPs holding such > information, as listed in Section 15.1 > > Thanks in advance! > > /Misha > > > 2018-02-26 10:14 GMT+03:00 Yuval Lifshitz : > > Hi All, > Would appreciate if you can review/comment on the the following new > section: > > 15. Privacy Considerations > > As the Diameter protocol, and especially credit control application, > deals with subscribers and their actions, extra care should be taken > regarding the privacy of the subscribers. In terms of [RFC6973], > both the credit-control client and credit-control server are > intermediary entities, wherein the subscribers' privacy may be > compromised even if no security issues exists, and only authorized > entities have access to the privacy-sensitive information. > > 15.1. Privacy Sensitive AVPs > > The following AVPs contain privacy-sensitive information at different > levels: > > 1. CC-Correlation-Id AVP: may contain privacy-sensitive information > as the service-provider may encode personal information that > helps it correlate different subscriptions and access > technologies. > > 2. Check-Balance-Result AVP: contains information on the balance > status of the subscriber. > > 3. Currency-Code AVP: contains information on the subscriber's > locale. > > 4. Cost-Unit AVP: contains privacy-sensitive information, as a > human readable format of the Cost-Information AVP. > > 5. Service-Identifier AVP: may contain privacy-sensitive > information about the subscriber's internet activity. > > 6. Rating-Group AVP: may contain privacy-sensitive information > about the subscriber's internet activity. > > 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule > may be used to infer services used by the subscriber. > > 8. 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). Similar AVPs are: Redirect- > Address-URL, Redirect-Address-SIP-URI. > > 9. Service-Context-Id AVP: depending with how the service-provider > use it, it may contain privacy-sensitive information about the > service (e.g. access technology). > > 10. Service-Parameter-Info AVP: depending with how the service- > provider use it, it may contain privacy-sensitive information > about the subscriber (e.g. location). > > 11. Subscription-Id-Data AVP: contains the identity of the > subscriber. Similar AVPs are: Subscription-Id-E164, > Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id- > NAI, Subscription-Id-Private. > > 12. User-Equipment-Info-Value AVP: contains the identity of the > device of the subscriber. Similar AVPs are: User-Equipment- > Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, > User-Equipment-Info- ModifiedEUI64, User-Equipment-Info-IMEI. > > 13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains > privacy-sensitive information in its sub-AVPs (e.g IPFilterRule, > redirect address). > > Note that some AVPs which are used in this document are defined in > [RFC6733] and may contain privacy-sensitive information. These AVPs > are not listed above. > > 15.2. Data Minimization > > Due to the nature of the credit control application, some personal > data and identity information must be stored in both credit-control > client and credit control server. This, however, could be minimized > by following these guidelines: > > 1. Data stored in the credit-control client does not need to be > persisted across sessions. All data could be deleted once the > session end, and reconstructed once a new session is initialized. > Note that, while the credit-control server is usually owned by > the service provider with which the subscriber already has some > direct legal or business relationship (where privacy level could > be agreed upon), this is not always true for the credit-control > client, that may be owned by a third-party. > > 2. Some information about the subscriber has to be stored in > persistent storage in the credit-control server (e.g. identity, > balance), however, per transaction information does not have to > be stored in persistent storage, and per session information may > be deleted from persistent storage once the session ends. > > 3. In some cases, per transaction information has to be stored on > the credit-control server, client, or both, for regulatory, > auditability or debugging reasons. However, this could be > minimized by following these guidelines: > > A. Data retention SHOULD NOT exceed the required durations > > B. Transaction information SHOULD be aggregated as much as > possible. E.g. prefer information per sessions vs. > information per rating-group; prefer hourly byte summary vs. > per transaction byte counts. > > C. If not strictly needed, the more sensitive information (E.g. > location, equipment type) SHOULD be filtered out from such > logs. Such information is often used to make rating > decisions, and in this case, the rating decision should be > logged instead of the data used to make them > > D. The credit-control server SHOULD be preferred over the > credit-control client as the place where per transaction > information is stored, if needed. This is due to the reasons > explained in 1. > > 15.3. Diameter Agents > > Diameter agents, as described in [RFC6733], may be owned by third- > parties. To prevent from privacy sensitive information from leaking > into them, it is RECOMMENDED to encrypt AVPs holding such > information, as listed in Section 15.1. > > In some cases, the Diameter agent requires access into privacy- > sensitive AVPs, in order to take correct routing decisions, or even > modify the content of these AVPs. In such a case it is RECOMMENDED > to anonymize the identity of the subscriber, and encrypt any other > AVP not used by the agent and can be used to identify the subscriber. > > > > > > On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, Ben Campbell < > ben@nostrum.com> wrote: > > > Even if we add privacy considerations to the base protocol, I think > 4006bis would still need privacy considerations that discuss the specific > AVPs it defines. So I would go ahead and add considerations to 4006bis an= d > avoid the delay. The WG can discuss whether it would like to add more > general considerations to the base protocol (either in a bis draft or an > update). > > Thanks! > > Ben. > > > On Feb 14, 2018, at 11:06 AM, Yuval Lifshitz wrote: > > > > Regarding "privacy considerations". Note that the base protocol RFC doe= s > not have that. > > Ideally, this is added to base Diameter first, as many of the sensitive > AVPs come from there. > > Should we try to tackle that first (though this would delay the > RFC4006bis process)? > > Should we cover only 4006 AVPs and issues? > > > > Best Regards, > > > > Yuval > > > > > > On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz < > yuvalif@yahoo.com> wrote: > > > > > > Ben, > > First, thanks for the comments! > > > > Regarding the major comment, agree this should be added, it was already > agreed in the meeting we had in IETF96, but somehow slipped :-( > > > > Sections 12: all the AVPs mentioned in this section exists in RFC4006, > and has values that are already registered. As part of RFC4006bis we did > not add any AVP that requires values enumeration (this was actually one o= f > the issue we tried to tackle). What would you like to see different in th= is > section? > > What is the process for updating IANA with the references to the new > doc? Can this happen before RFC4006bis is officially accepted? > > > > Appendix B: the new AVPs do not impact the flows, therefore not added t= o > the sample flows > > > > 8.34 agree, this is pretty bad. How about: > > If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT > > and the classification of the restricted traffic cannot be expressed > > using IPFilterRule, or different actions (e.g., QoS) than just > > allowing traffic needs to be enforced, then the QoS-Final-Unit- > > Indication AVP SHOULD be used instead of the Final-Unit-Indication > > AVP. > > > > > > 14. agree we should simplify as you suggested > > > > Best Regards, > > > > Yuval > > On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell < > ben@nostrum.com> wrote: > > > > > > Hi, > > > > This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for > the work on this; it=E2=80=99s overall a good update. However, I have one= major > comment and a few minor or editorial comments. I=E2=80=99d like to discus= s the > major comment prior IETF last call. The rest can be handled along with an= y > last call feedback. > > > > Note that for all but the major comment, I mostly reviewed the diff fro= m > RFC 4006. > > > > 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 > > > > Major Comment: > > > > I strongly suggest that you add more privacy considerations. I realize > that it inherits its existing privacy considerations from RFC 4006, but > that was published in 2005. The IETF=E2=80=99s focus on privacy has evolv= ed > considerably since then, and I think this draft will get objections durin= g > IESG review without adding some more. > > > > I suggest the following: > > =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section sep= arate from the security > considerations. > > =E2=80=94 Enumerate the AVPs that you think contain user identifiable > information, persistent identifiers, or other privacy sensitive data. > > =E2=80=94 Make some non-normative recommendations concerning data minim= ization. > That is, add a few sentences recommending that clients and servers avoid > capturing and/or log personal information beyond that needed for the > application's purpose. > > > > Minor Comments: > > > > -Section 12 and subsections: Please clarify that many of these elements > were already registered by RF 4006, and are not being =E2=80=9Cre-registe= red=E2=80=9D here. > ( It=E2=80=99s perfectly okay to pull the registration information forwar= d into the > bis draft; it just needs clarification.) Also, please consider wether > existing registrations should be updated to point to this document rather > than 4006. > > > > Appendices: Would any of the example flows benefit from including one o= r > more of the new AVPs? > > > > Editorial and Nits: > > > > -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to RESTRIC= T_ACCESS > or REDIRECT > > and the classification of the restricted traffic cannot be expressed > > using IPFilterRule, or different actions (e.g., QoS) than just > > allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C > > > > I have trouble parsing the sentence. > > > > -14: "Even without any modification to the messages, an adversary can > > invite a security threat by eavesdropping, as the transactions contain > private information about the user. > > =E2=80=9D > > I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transaction= s that contain > privacy-sensitive imformation=E2=80=9D > > > > > > > > > > > > > > > > > > ______________________________ _________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/ listinfo/dime > > > ______________________________ _________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/ listinfo/dime > > > > --001a114afba6f935930566432c24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yuval,

Thanks for your answers!

(3) Why Destination-Realm AVP (mandatory for CCR) cann= ot be used by DRL for making routing decisions?
In the referred s= ection 2.8.1. RFC6733, I think this is NAS that may try to parse NAS id to = extract a realm value.
In my understanding, when routing DRL shou= ld deal only with so called routing AVPs, section 6.7 in RFC6733.

(4) I think you can list both 2 options to cover a privacy = aspect.

/Misha



2018-02-27 17:00 GM= T+03:00 Yuval Lifshitz <yuvalif@yahoo.com>:
Hi Misha,
Thank you very muc= h for the comments!

(1) will fix

(2) "credit-control" is the common form in RFC4006 - will= fix in the doc. Will use "privacy-sensitive", though I could not= find other references to this term (not used in RFC6973)

(3) Will add the following text: "
Fo= r example, a relay agent may need to look into the Subscription-Id-NAI AVP,= in order to extract the realm of the user, and use it to lookup the destin= ation to which the request should be routed (see: section 2.8.1 in [RFC6733= ])
"

(4) will fix the ty= po.
Regarding AVP level encryption, this is more complicated. Thi= s idea existed in RFC3588 (the old diameter base RFC), but removed from RFC= 6733.Actually, section 13.3 (in RFC6733) deals with security-sensitive AVPs= , and recommend end2end encryption (At message level) as well as avoiding a= gents, or making sure that the agents are trusted and don't create a se= curity issue. Given the privacy guidelines in RFC6973, this is not sufficie= nt, as security and privacy are two different things.
There w= as an effort to reintroduce that here: https://tools.iet= f.org/html/draft-korhonen-dime-e2e-security-03 but seems like= this did not materialized into a formal specification.

<= /div>
So, I see 2 options here:
* Use the security guidelines= for privacy. This would mean that privacy is going to be compromised unles= s the agent is managed by the same entity as the credit-control server
* Recommend AVP level encryption and mention that the actual mechanis= m is outside the scope of the diameter RFC

Unrelat= ed question to the group - do you think it is worthwhile to revive the end2= end security work? Do you know why was it abandoned?

Yuval

=20
=20
On Tuesday, February 27, 2018, 12:36:45 PM GMT+2, M= isha Zaytsev <misha.zaytsev.rus@gmail.com> wrote:


Hi Yuval,

Just fir= stly some editorial comments + questions:

1. As the Diameter protocol, and especially c=
redit control application,
   deals with subscribers and their actions, extra care should be taken
   regarding the privacy of the subscribers.  In terms of [RFC6973],
   both the credit-control client and credit-control server are
   intermediary entities, wherein the subscribers' privacy may be
   compromised even if no security issues exist, and only authorized
   entities have access to the privacy-sensitive information.
<= pre style=3D"white-space:pre-wrap;color:rgb(34,34,34);font-size:16px;font-s= tyle:normal;letter-spacing:normal;text-indent:0px;text-transform:none;word-= spacing:0px;background-color:rgb(255,255,255);text-decoration-color:initial= ">2. Let's use o= ne form of writing: either "credit-control" or "credit contr= ol". The same is related to "privacy-sensitive" and "pr= ivacy sensitive"
3. What are privacy-sensitive AVPs used for making routing=
 decisions meant here? Please list some of them.

In some cases, t=
he Diameter agent requires access into privacy-
   sensitive AVPs, in order to take correct routing decisions, or even
   modify the content of these AVPs.
4. What do you mean under = "encrypt AVPs"? Encryption is not part of Diameter functions... C= ould you elaborate your idea?
To prevent from (=
typo?) privacy sensitive information from leaking
   into them, it is RECOMMENDED to encrypt AVPs holding such
   information, as listed in Section 15.1
Thanks in advance!
/Misha

2018-02-26 10:14 GMT+03:00 Yuval Lifshitz <yuvalif@yahoo.com>:
Hi All,
Would appreciate if you can review/= comment on the the following new section:
15.  Privacy Considerations

   As the Diameter protocol, and especially credit control application,
   deals with subscribers and their actions, extra care should be taken
   regarding the privacy of the subscribers.  In terms of [RFC6973],
   both the credit-control client and credit-control server are
   intermediary entities, wherein the subscribers' privacy may be
   compromised even if no security issues exists, and only authorized
   entities have access to the privacy-sensitive information.

15.1.  Privacy Sensitive AVPs

   The following AVPs contain privacy-sensitive information at different
   levels:

   1.   CC-Correlation-Id AVP: may contain privacy-sensitive information
        as the service-provider may encode personal information that
        helps it correlate different subscriptions and access
        technologies.

   2.   Check-Balance-Result AVP: contains information on the balance
        status of the subscriber.

   3.   Currency-Code AVP: contains information on the subscriber's
        locale.

   4.   Cost-Unit AVP: contains privacy-sensitive information, as a
        human readable format of the Cost-Information AVP.

   5.   Service-Identifier AVP: may contain privacy-sensitive
        information about the subscriber's internet activity.

   6.   Rating-Group AVP: may contain privacy-sensitive information
        about the subscriber's internet activity.

   7.   Restriction-Filter-Rule AVP: the information inside IPFilterRule
        may be used to infer services used by the subscriber.

   8.   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).  Similar AVPs are: Redirect-
        Address-URL, Redirect-Address-SIP-URI.

   9.   Service-Context-Id AVP: depending with how the service-provider
        use it, it may contain privacy-sensitive information about the
        service (e.g. access technology).

   10.  Service-Parameter-Info AVP: depending with how the service-
        provider use it, it may contain privacy-sensitive information
        about the subscriber (e.g. location).

   11.  Subscription-Id-Data AVP: contains the identity of the
        subscriber.  Similar AVPs are: Subscription-Id-E164,
        Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id-
        NAI, Subscription-Id-Private.

   12.  User-Equipment-Info-Value AVP: contains the identity of the
        device of the subscriber.  Similar AVPs are: User-Equipment-
        Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64,
        User-Equipment-Info- ModifiedEUI64, User-Equipment-Info-IMEI.

   13.  QoS-Final-Unit-Indication AVP: grouped AVP which may contains
        privacy-sensitive information in its sub-AVPs (e.g IPFilterRule,
        redirect address).

   Note that some AVPs which are used in this document are defined in
   [RFC6733] and may contain privacy-sensitive information.  These AVPs
   are not listed above.

15.2.  Data Minimization

   Due to the nature of the credit control application, some personal
   data and identity information must be stored in both credit-control
   client and credit control server.  This, however, could be minimized
   by following these guidelines:

   1.  Data stored in the credit-control client does not need to be
       persisted across sessions.  All data could be deleted once the
       session end, and reconstructed once a new session is initialized.
       Note that, while the credit-control server is usually owned by
       the service provider with which the subscriber already has some
       direct legal or business relationship (where privacy level could
       be agreed upon), this is not always true for the credit-control
       client, that may be owned by a third-party.

   2.  Some information about the subscriber has to be stored in
       persistent storage in the credit-control server (e.g. identity,
       balance), however, per transaction information does not have to
       be stored in persistent storage, and per session information may
       be deleted from persistent storage once the session ends.

   3.  In some cases, per transaction information has to be stored on
       the credit-control server, client, or both, for regulatory,
       auditability or debugging reasons.  However, this could be
       minimized by following these guidelines:

       A.  Data retention SHOULD NOT exceed the required durations

       B.  Transaction information SHOULD be aggregated as much as
           possible.  E.g.  prefer information per sessions vs.
           information per rating-group; prefer hourly byte summary vs.
           per transaction byte counts.

       C.  If not strictly needed, the more sensitive information (E.g.
           location, equipment type) SHOULD be filtered out from such
           logs.  Such information is often used to make rating
           decisions, and in this case, the rating decision should be
           logged instead of the data used to make them

       D.  The credit-control server SHOULD be preferred over the
           credit-control client as the place where per transaction
           information is stored, if needed.  This is due to the reasons
           explained in 1.

15.3.  Diameter Agents

   Diameter agents, as described in [RFC6733], may be owned by third-
   parties.  To prevent from privacy sensitive information from leaking
   into them, it is RECOMMENDED to encrypt AVPs holding such
   information, as listed in Section 15.1.

   In some cases, the Diameter agent requires access into privacy-
   sensitive AVPs, in order to take correct routing decisions, or even
   modify the content of these AVPs.  In such a case it is RECOMMENDED
   to anonymize the identity of the subscriber, and encrypt any other
   AVP not used by the agent and can be used to identify the subscriber.




=20
=20
On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, = Ben Campbell <ben@nostrum.com> wrote:


Even if we add privacy considerat= ions to the base protocol, I think 4006bis would still need privacy conside= rations that discuss the specific AVPs it defines. So I would go ahead and = add considerations to 4006bis and avoid the delay. The WG can discuss wheth= er it would like to add more general considerations to the base protocol (e= ither in a bis draft or an update).

Th= anks!

Ben.

> On Feb 14= , 2018, at 11:06 AM, Yuval Lifshitz <yuvalif@yahoo.com&g= t; wrote:
>
> Regarding "pr= ivacy considerations". Note that the base protocol RFC does not have t= hat.
> Ideally, this is added to base Diameter first, = as many of the sensitive AVPs come from there.
> Shoul= d we try to tackle that first (though this would delay the RFC4006bis proce= ss)?
> Should we cover only 4006 AVPs and issues?
>
> Best Regards,
= >
> Yuval
>
>
> On Wednesday, February 14, 2018, 5:56:52 PM = GMT+2, Yuval Lifshitz <yuvalif@yahoo.com> wrote:
>
>
> Ben,
> First, thanks for the comments!
> =
> Regarding the major comment, agree this should be a= dded, it was already agreed in the meeting we had in IETF96, but somehow sl= ipped :-(
>
> Sections 12: all t= he AVPs mentioned in this section exists in RFC4006, and has values that ar= e already registered. As part of RFC4006bis we did not add any AVP that req= uires values enumeration (this was actually one of the issue we tried to ta= ckle). What would you like to see different in this section?
> What is the process for updating IANA with the references to the n= ew doc? Can this happen before RFC4006bis is officially accepted?
>
> Appendix B: the new AVPs do not impa= ct the flows, therefore not added to the sample flows
>= ;
> 8.34 agree, this is pretty bad. How about:
> If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or = REDIRECT
>=C2=A0 =C2=A0 and the classification of the = restricted traffic cannot be expressed
>=C2=A0 =C2=A0 = using IPFilterRule, or different actions (e.g., QoS) than just
>=C2=A0 =C2=A0 allowing traffic needs to be enforced, then the QoS= -Final-Unit-
>=C2=A0 =C2=A0 Indication AVP SHOULD be u= sed instead of the Final-Unit-Indication
>=C2=A0 =C2= =A0 AVP.
>
>
= > 14. agree we should simplify as you suggested
> <= br clear=3D"none">> Best Regards,
>
> Yuval
> On Tuesday, February 13, 2018, 1:33:2= 2 AM GMT+2, Ben Campbell <ben@nostrum.com> wrote:
>
>
> Hi,
>
> This is my AD Evaluation of draft= -ietf-dime-rfc4006bis-06. Thanks for the work on this; it=E2=80=99s overall= a good update. However, I have one major comment and a few minor or editor= ial comments. I=E2=80=99d like to discuss the major comment prior IETF last= call. The rest can be handled along with any last call feedback.
>
> Note that for all but the major comm= ent, I mostly reviewed the diff from RFC 4006.
>
> Thanks!
>
> B= en.
>
> =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
>
> Major Com= ment:
>
> I strongly suggest tha= t you add more privacy considerations. I realize that it inherits its exist= ing privacy considerations from RFC 4006, but that was published in 2005. T= he IETF=E2=80=99s focus on privacy has evolved considerably since then, and= I think this draft will get objections during IESG review without adding s= ome more.
>
> I suggest the foll= owing:
> =E2=80=94 Create a =E2=80=9CPrivacy Considera= tions=E2=80=9D section separate from the security considerations.
> =E2=80=94 Enumerate the AVPs that you think contain user ide= ntifiable information, persistent identifiers, or other privacy sensitive d= ata.
> =E2=80=94 Make some non-normative recommendatio= ns concerning data minimization. That is, add a few sentences recommending = that clients and servers avoid capturing and/or log personal information be= yond that needed for the application's purpose.
> =
> Minor Comments:
>
> -Section 12 and subsections: Please clarify that many of these = elements were already registered by RF 4006, and are not being =E2=80=9Cre-= registered=E2=80=9D here. ( It=E2=80=99s perfectly okay to pull the registr= ation information forward into the bis draft; it just needs clarification.)= Also, please consider wether existing registrations should be updated to p= oint to this document rather than 4006.
>
> Appendices: Would any of the example flows benefit from includi= ng one or more of the new AVPs?
>
&= gt; Editorial and Nits:
>
> -Sec= tion 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to RESTRICT_ACCESS= or REDIRECT
> and the classification of the restricte= d traffic cannot be expressed
> using IPFilterRule, or= different actions (e.g., QoS) than just
> allowing Qo= S needs to be enforced traffic, =E2=80=A6 =E2=80=9C
> =
> I have trouble parsing the sentence.
>
> -14: "Even without any modification t= o the messages, an adversary can
>=C2=A0 invite a sec= urity threat by eavesdropping, as the transactions contain private informat= ion about the user.
> =E2=80=9D
>= I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transactions t= hat contain privacy-sensitive imformation=E2=80=9D
> <= br clear=3D"none">>
>
>
>
>
>
>
> ______________________________ ___= ______________
> DiME mailing list
&= gt; DiME@ietf.org
> https://www.ietf.org/mailman/ listinfo/dime
<= /div>

__________________________= ____ _________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/ listinfo/dime


=

--001a114afba6f935930566432c24-- From nobody Wed Feb 28 03:04:30 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 25A7612EAFB for ; Wed, 28 Feb 2018 03:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 M2kztsRycHwQ for ; Wed, 28 Feb 2018 03:04:24 -0800 (PST) Received: from sonic310-13.consmr.mail.bf2.yahoo.com (sonic310-13.consmr.mail.bf2.yahoo.com [74.6.135.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 66C7212EB02 for ; Wed, 28 Feb 2018 03:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1519815843; bh=yXWPTCt4rUFbgepGGjIxXcQnqXj70mVZKqXxZDAaalM=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=rvUeVLVLQWAXEEIbT1rvsVjhCgGlQW1Ok97X5/MQiUKtP42zZIcUp/BxM12d3nD4A1jzsVZe6JINPJAmrrRdJVfUwou2zBiODMMoC+0M6kX/TZicnHWxWY88ogMsZaCaeOrtsi/0r6xHgGG6oCnCDOrX9xqTHwho1RaOKYnp+GplAJIaZUlDp+Hxeur0WUwHngHptw2hLlvjP85FUZ/UrMSBnzBRLoMZrlx83YZjsWXDtJXQFkAcDCN08K33dIXfLnCCf+xvZvUeEgG8MMuq9wUqdFgZPukoCVUtEA3+ojLU9HxBtt9XcxmqBQbXDByNKeVg9DQBKxuH5CcgIHZ3zQ== X-YMail-OSG: hJJrHHUVM1lDiUT6rQn2efBRgC9r4epb8tgDW_yPVso.fImD_CER5P6MrNVmkCu VH3vIG4ZFruCTkxTBFyQKmDTFIcCmsuP3gM5GCrJLPKUG2OUZwgMHiUBSZPmz_Es_Pg0LhT4W_0M U5Zm2x9AnAwZP_wn3UhtNLWSPGaceHTes2xhSopvRu9MOJv2Xq80WNgVgWWdpyGmHJJmU9wL_Rf2 z36bKP7p4z2Don50iMj_kP8dDHcSrPU44Cy9ixfQBUNn154qENaDB6vNGVA_R3qSy.8utWhQzF31 Txa5a3Aekrda4pacfOo7MUuJKdMhZVIQftrAybP7Qh8cr3vBt_K4eY0si8ALrv1_NKpdZvYkwBb3 3d7bgs2IZfdfqpyIcTdqlBwoFkyOVK4IjqpndEQ0YMQhlMlWLltLDYDq33i0VQj2j2CCHd3GHbFn zjmp.ohkAJVFcv1sT5ctFDOXfGa1rBNgwjhZiDw.pVtkSwSVoWZ.Vhei8OZ1n0d1MLQA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Feb 2018 11:04:03 +0000 Date: Wed, 28 Feb 2018 10:53:08 +0000 (UTC) From: Yuval Lifshitz To: dime@ietf.org, ops-ads@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org, Misha Zaytsev Message-ID: <1158167302.7541463.1519815188891@mail.yahoo.com> In-Reply-To: References: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com> <608352900.888044.1518623812177@mail.yahoo.com> <868034109.936629.1518628004592@mail.yahoo.com> <2108881588.5977405.1519629280512@mail.yahoo.com> <1911118245.6898746.1519740058412@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7541462_2058517286.1519815188886" X-Mailer: WebService/1.1.11419 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06 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, 28 Feb 2018 11:04:29 -0000 ------=_Part_7541462_2058517286.1519815188886 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (3) The destination-realm is the realm of the destination-host, not necessa= rily the realm inside the subscriber's NAI. But anyway, to fix both issues,= I suggest an example based on the MCC/MNC chunk of an IMSI with a proxy ag= ent:" For example, a proxy agent may need to look into the Subscription-Id-IMSI A= VP, in order to extract the mobile country and network codes of the user, a= nd use them to lookup the destination to which the request should be routed= (see: section 2.8.2 in [RFC6733]) " On Wednesday, February 28, 2018, 12:26:28 PM GMT+2, Misha Zaytsev wrote: =20 =20 Hi Yuval, Thanks for your answers! (3) Why Destination-Realm AVP (mandatory for CCR) cannot be used by DRL for= making routing decisions?In the referred section 2.8.1. RFC6733, I think t= his is NAS that may try to parse NAS id to extract a realm value.In my unde= rstanding, when routing DRL should deal only with so called routing AVPs, s= ection 6.7 in RFC6733. (4) I think you can list both 2 options to cover a privacy aspect. /Misha 2018-02-27 17:00 GMT+03:00 Yuval Lifshitz : Hi Misha,Thank you very much for the comments! (1) will fix (2) "credit-control" is the common form in RFC4006 - will fix in the doc. W= ill use "privacy-sensitive", though I could not find other references to th= is term (not used in RFC6973) (3) Will add the following text: "For example, a relay agent may need to lo= ok into the Subscription-Id-NAI AVP, in order to extract the realm of the u= ser, and use it to lookup the destination to which the request should be ro= uted (see: section 2.8.1 in [RFC6733])" (4) will fix the typo.Regarding AVP level encryption, this is more complica= ted. This idea existed in RFC3588 (the old diameter base RFC), but removed = from RFC6733.Actually, section 13.3 (in RFC6733) deals with security-sensit= ive AVPs, and recommend end2end encryption (At message level) as well as av= oiding agents, or making sure that the agents are trusted and don't create = a security issue. Given the privacy guidelines in RFC6973, this is not suff= icient, as security and privacy are two different things. There was an effort to reintroduce that here: https://tools.ietf.org/html/d= r aft-korhonen-dime-e2e-security -03 but seems like this did not materializ= ed into a formal specification. So, I see 2 options here:* Use the security guidelines for privacy. This wo= uld mean that privacy is going to be compromised unless the agent is manage= d by the same entity as the credit-control server* Recommend AVP level encr= yption and mention that the actual mechanism is outside the scope of the di= ameter RFC Unrelated question to the group - do you think it is worthwhile to revive t= he end2end security work? Do you know why was it abandoned? Yuval On Tuesday, February 27, 2018, 12:36:45 PM GMT+2, Misha Zaytsev wrote: =20 =20 Hi Yuval, Just firstly some editorial comments + questions: 1. As the Diameter protocol, and especially credit control application, deals with subscribers and their actions, extra care should be taken regarding the privacy of the subscribers. In terms of [RFC6973], both the credit-control client and credit-control server are intermediary entities, wherein the subscribers' privacy may be compromised even if no security issues exist, and only authorized entities have access to the privacy-sensitive information.2. Let's use o= ne form of writing: either "credit-control" or "credit control". The same i= s related to "privacy-sensitive" and "privacy sensitive"3. What are privacy= -sensitive AVPs used for making routing decisions meant here? Please list s= ome of them. In some cases, the Diameter agent requires access into privacy- sensitive AVPs, in order to take correct routing decisions, or even modify the content of these AVPs.4. What do you mean under "encrypt AVPs= "? Encryption is not part of Diameter functions... Could you elaborate your= idea?To prevent from (typo?) privacy sensitive information from leaking into them, it is RECOMMENDED to encrypt AVPs holding such information, as listed in Section 15.1Thanks in advance!/Misha 2018-02-26 10:14 GMT+03:00 Yuval Lifshitz : Hi All,Would appreciate if you can review/comment on the the following new = section:15. Privacy Considerations As the Diameter protocol, and especially credit control application, deals with subscribers and their actions, extra care should be taken regarding the privacy of the subscribers. In terms of [RFC6973], both the credit-control client and credit-control server are intermediary entities, wherein the subscribers' privacy may be compromised even if no security issues exists, and only authorized entities have access to the privacy-sensitive information. 15.1. Privacy Sensitive AVPs The following AVPs contain privacy-sensitive information at different levels: 1. CC-Correlation-Id AVP: may contain privacy-sensitive information as the service-provider may encode personal information that helps it correlate different subscriptions and access technologies. 2. Check-Balance-Result AVP: contains information on the balance status of the subscriber. 3. Currency-Code AVP: contains information on the subscriber's locale. 4. Cost-Unit AVP: contains privacy-sensitive information, as a human readable format of the Cost-Information AVP. 5. Service-Identifier AVP: may contain privacy-sensitive information about the subscriber's internet activity. 6. Rating-Group AVP: may contain privacy-sensitive information about the subscriber's internet activity. 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule may be used to infer services used by the subscriber. 8. 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). Similar AVPs are: Redirect- Address-URL, Redirect-Address-SIP-URI. 9. Service-Context-Id AVP: depending with how the service-provider use it, it may contain privacy-sensitive information about the service (e.g. access technology). 10. Service-Parameter-Info AVP: depending with how the service- provider use it, it may contain privacy-sensitive information about the subscriber (e.g. location). 11. Subscription-Id-Data AVP: contains the identity of the subscriber. Similar AVPs are: Subscription-Id-E164, Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id- NAI, Subscription-Id-Private. 12. User-Equipment-Info-Value AVP: contains the identity of the device of the subscriber. Similar AVPs are: User-Equipment- Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, User-Equipment-Info- ModifiedEUI64, User-Equipment-Info-IMEI. 13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains privacy-sensitive information in its sub-AVPs (e.g IPFilterRule, redirect address). Note that some AVPs which are used in this document are defined in [RFC6733] and may contain privacy-sensitive information. These AVPs are not listed above. 15.2. Data Minimization Due to the nature of the credit control application, some personal data and identity information must be stored in both credit-control client and credit control server. This, however, could be minimized by following these guidelines: 1. Data stored in the credit-control client does not need to be persisted across sessions. All data could be deleted once the session end, and reconstructed once a new session is initialized. Note that, while the credit-control server is usually owned by the service provider with which the subscriber already has some direct legal or business relationship (where privacy level could be agreed upon), this is not always true for the credit-control client, that may be owned by a third-party. 2. Some information about the subscriber has to be stored in persistent storage in the credit-control server (e.g. identity, balance), however, per transaction information does not have to be stored in persistent storage, and per session information may be deleted from persistent storage once the session ends. 3. In some cases, per transaction information has to be stored on the credit-control server, client, or both, for regulatory, auditability or debugging reasons. However, this could be minimized by following these guidelines: A. Data retention SHOULD NOT exceed the required durations B. Transaction information SHOULD be aggregated as much as possible. E.g. prefer information per sessions vs. information per rating-group; prefer hourly byte summary vs. per transaction byte counts. C. If not strictly needed, the more sensitive information (E.g. location, equipment type) SHOULD be filtered out from such logs. Such information is often used to make rating decisions, and in this case, the rating decision should be logged instead of the data used to make them D. The credit-control server SHOULD be preferred over the credit-control client as the place where per transaction information is stored, if needed. This is due to the reasons explained in 1. 15.3. Diameter Agents Diameter agents, as described in [RFC6733], may be owned by third- parties. To prevent from privacy sensitive information from leaking into them, it is RECOMMENDED to encrypt AVPs holding such information, as listed in Section 15.1. In some cases, the Diameter agent requires access into privacy- sensitive AVPs, in order to take correct routing decisions, or even modify the content of these AVPs. In such a case it is RECOMMENDED to anonymize the identity of the subscriber, and encrypt any other AVP not used by the agent and can be used to identify the subscriber. =20 On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, Ben Campbell wrote: =20 =20 Even if we add privacy considerations to the base protocol, I think 4006bi= s would still need privacy considerations that discuss the specific AVPs it= defines. So I would go ahead and add considerations to 4006bis and avoid t= he delay. The WG can discuss whether it would like to add more general cons= iderations to the base protocol (either in a bis draft or an update). Thanks! Ben. > On Feb 14, 2018, at 11:06 AM, Yuval Lifshitz wrote: >=20 > Regarding "privacy considerations". Note that the base protocol RFC does = not have that. > Ideally, this is added to base Diameter first, as many of the sensitive A= VPs come from there. > Should we try to tackle that first (though this would delay the RFC4006bi= s process)? > Should we cover only 4006 AVPs and issues? >=20 > Best Regards, >=20 > Yuval >=20 >=20 > On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz wrote: >=20 >=20 > Ben, > First, thanks for the comments! >=20 > Regarding the major comment, agree this should be added, it was already a= greed in the meeting we had in IETF96, but somehow slipped :-( >=20 > Sections 12: all the AVPs mentioned in this section exists in RFC4006, an= d has values that are already registered. As part of RFC4006bis we did not = add any AVP that requires values enumeration (this was actually one of the = issue we tried to tackle). What would you like to see different in this sec= tion? > What is the process for updating IANA with the references to the new doc?= Can this happen before RFC4006bis is officially accepted? >=20 > Appendix B: the new AVPs do not impact the flows, therefore not added to = the sample flows >=20 > 8.34 agree, this is pretty bad. How about: > If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT >=C2=A0 =C2=A0 and the classification of the restricted traffic cannot be e= xpressed >=C2=A0 =C2=A0 using IPFilterRule, or different actions (e.g., QoS) than ju= st >=C2=A0 =C2=A0 allowing traffic needs to be enforced, then the QoS-Final-Un= it- >=C2=A0 =C2=A0 Indication AVP SHOULD be used instead of the Final-Unit-Indi= cation >=C2=A0 =C2=A0 AVP. >=20 >=20 > 14. agree we should simplify as you suggested >=20 > Best Regards, >=20 > Yuval > On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell wrote: >=20 >=20 > Hi, >=20 > This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the= work on this; it=E2=80=99s overall a good update. However, I have one majo= r comment and a few minor or editorial comments. I=E2=80=99d like to discus= s the major comment prior IETF last call. The rest can be handled along wit= h any last call feedback. >=20 > Note that for all but the major comment, I mostly reviewed the diff from = RFC 4006. >=20 > Thanks! >=20 > Ben. >=20 > =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 >=20 > Major Comment: >=20 > I strongly suggest that you add more privacy considerations. I realize th= at it inherits its existing privacy considerations from RFC 4006, but that = was published in 2005. The IETF=E2=80=99s focus on privacy has evolved cons= iderably since then, and I think this draft will get objections during IESG= review without adding some more. >=20 > I suggest the following: > =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section separ= ate from the security considerations. > =E2=80=94 Enumerate the AVPs that you think contain user identifiable inf= ormation, persistent identifiers, or other privacy sensitive data. > =E2=80=94 Make some non-normative recommendations concerning data minimiz= ation. That is, add a few sentences recommending that clients and servers a= void capturing and/or log personal information beyond that needed for the a= pplication's purpose. >=20 > Minor Comments: >=20 > -Section 12 and subsections: Please clarify that many of these elements w= ere already registered by RF 4006, and are not being =E2=80=9Cre-registered= =E2=80=9D here. ( It=E2=80=99s perfectly okay to pull the registration info= rmation forward into the bis draft; it just needs clarification.) Also, ple= ase consider wether existing registrations should be updated to point to th= is document rather than 4006. >=20 > Appendices: Would any of the example flows benefit from including one or = more of the new AVPs? >=20 > Editorial and Nits: >=20 > -Section 8.34: =E2=80=9C If the Final-Unit-Action AVP is set to RESTRICT_= ACCESS or REDIRECT > and the classification of the restricted traffic cannot be expressed > using IPFilterRule, or different actions (e.g., QoS) than just > allowing QoS needs to be enforced traffic, =E2=80=A6 =E2=80=9C >=20 > I have trouble parsing the sentence. >=20 > -14: "Even without any modification to the messages, an adversary can >=C2=A0 invite a security threat by eavesdropping, as the transactions cont= ain private information about the user. > =E2=80=9D > I suggest =E2=80=9C =E2=80=A6 an adversary can eavesdrop on transactions = that contain privacy-sensitive imformation=E2=80=9D >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ______________________________ _________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/ listinfo/dime =20 ______________________________ _________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/ listinfo/dime =20 =20 ------=_Part_7541462_2058517286.1519815188886 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(3) The destination-realm is the= realm of the destination-host, not necessarily the realm inside the subscr= iber's NAI.
But anyway, to fix both issues, I suggest an example= based on the MCC/MNC chunk of an IMSI with a proxy agent:
"
<= /div>
For example, a proxy agent may need to look into= =20 the Subscription-Id-IMSI AVP, in order to extract the mobile country and ne= twork codes of the user,=20 and use them to lookup the destination to which the request should be=20 routed (see: section 2.8.2 in [RFC6733])
"
=20
=20
On Wednesday, February 28, 2018, 12:26:28 PM GMT+2,= Misha Zaytsev <misha.zaytsev.rus@gmail.com> wrote:


Hi= Yuval,

Thanks for your answers!

(3) Why Destination-Realm AVP (mandatory fo= r CCR) cannot be used by DRL for making routing decisions?
In the= referred section 2.8.1. RFC6733, I think this is NAS that may try to parse= NAS id to extract a realm value.
In my understanding, when routi= ng DRL should deal only with so called routing AVPs, section 6.7 in RFC6733= .

(4) I think you can list both 2 o= ptions to cover a privacy aspect.

/= Misha



2018-02-27 17:00 GMT+03:00 Yuval Lifshitz = <yuva= lif@yahoo.com>:
Hi Misha,
Thank you very muc= h for the comments!

(1) will fix

(2) "credit-control" is the common fo= rm in RFC4006 - will fix in the doc. Will use "privacy-sensitive", though I= could not find other references to this term (not used in RFC6973)

(3) Will add the following text: "
For example, a relay agent may need to look i= nto the Subscription-Id-NAI AVP, in order to extract the realm of the user,= and use it to lookup the destination to which the request should be routed= (see: section 2.8.1 in [RFC6733])
"

(4) will fix the typo.
Rega= rding AVP level encryption, this is more complicated. This idea existed in = RFC3588 (the old diameter base RFC), but removed from RFC6733.Actually, sec= tion 13.3 (in RFC6733) deals with security-sensitive AVPs, and recommend en= d2end encryption (At message level) as well as avoiding agents, or making s= ure that the agents are trusted and don't create a security issue. Given th= e privacy guidelines in RFC6973, this is not sufficient, as security and pr= ivacy are two different things.
There was an e= ffort to reintroduce that here: https://tools.ietf.org/html/dr aft-korhonen-dime-e2e-security -03= but seems like this did not materialized into a formal specification.<= br clear=3D"none">

So, I see 2 opti= ons here:
* Use the security guidelines for privacy. This would m= ean that privacy is going to be compromised unless the agent is managed by = the same entity as the credit-control server
* Recommend AVP leve= l encryption and mention that the actual mechanism is outside the scope of = the diameter RFC

Unrelated question= to the group - do you think it is worthwhile to revive the end2end securit= y work? Do you know why was it abandoned?

Yuval

=20
=20
On Tuesday, February 27, 2018, 12:36:45 PM GMT+2, M= isha Zaytsev <misha.zaytsev.rus@gmail.com> wrote:


Hi Yuval,

Just firstly some editorial comments + questions:

1. As the Diameter protocol, and especially =
credit control application,
   deals with subscribers and their actions, extra care should be taken
   regarding the privacy of the subscribers.  In terms of [RFC6973],
   both the credit-control client and credit-control server are
   intermediary entities, wherein the subscribers' privacy may be
   compromised even if no security issues exist, and only authorized
   entities have access to the privacy-sensitive information.
<= pre style=3D"white-space:pre-wrap;color:rgb(34,34,34);font-size:16px;font-s= tyle:normal;letter-spacing:normal;text-indent:0px;text-transform:none;word-= spacing:0px;background-color:rgb(255,255,255);text-decoration-color:initial= ;">2. Let's use one = form of writing: either "credit-control" or "credit control". The same is r= elated to "privacy-sensitive" and "privacy sensitive"
3. What are privacy-sensi=
tive AVPs used for making routing decisions meant here? Please list some of=
 them.

In some cases, =
the Diameter agent requires access into privacy-
   sensitive AVPs, in order to take correct routing decisions, or even
   modify the content of these AVPs.
4. What do you mean under = "encrypt AVPs"? Encryption is not part of Diameter functions... Could you e= laborate your idea?
To prevent from (typo?) privacy sensitive information from leaking
   into them, it is RECOMMENDED to encrypt AVPs holding such
   information, as listed in Section 15.1
Thanks in advance!
/Misha

2018-02-26= 10:14 GMT+03:00 Yuval Lifshitz <yuvalif@yahoo.com>:
Hi All,
Would appreciate if you can review/comment on th= e the following new section:
15.  Privacy Considerations

   As the Diameter protocol, and especially credit control application,
   deals with subscribers and their actions, extra care should be taken
   regarding the privacy of the subscribers.  In terms of [RFC6973],
   both the credit-control client and credit-control server are
   intermediary entities, wherein the subscribers' privacy may be
   compromised even if no security issues exists, and only authorized
   entities have access to the privacy-sensitive information.

15.1.  Privacy Sensitive AVPs

   The following AVPs contain privacy-sensitive information at different
   levels:

   1.   CC-Correlation-Id AVP: may contain privacy-sensitive information
        as the service-provider may encode personal information that
        helps it correlate different subscriptions and access
        technologies.

   2.   Check-Balance-Result AVP: contains information on the balance
        status of the subscriber.

   3.   Currency-Code AVP: contains information on the subscriber's
        locale.

   4.   Cost-Unit AVP: contains privacy-sensitive information, as a
        human readable format of the Cost-Information AVP.

   5.   Service-Identifier AVP: may contain privacy-sensitive
        information about the subscriber's internet activity.

   6.   Rating-Group AVP: may contain privacy-sensitive information
        about the subscriber's internet activity.

   7.   Restriction-Filter-Rule AVP: the information inside IPFilterRule
        may be used to infer services used by the subscriber.

   8.   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).  Similar AVPs are: Redirect-
        Address-URL, Redirect-Address-SIP-URI.

   9.   Service-Context-Id AVP: depending with how the service-provider
        use it, it may contain privacy-sensitive information about the
        service (e.g. access technology).

   10.  Service-Parameter-Info AVP: depending with how the service-
        provider use it, it may contain privacy-sensitive information
        about the subscriber (e.g. location).

   11.  Subscription-Id-Data AVP: contains the identity of the
        subscriber.  Similar AVPs are: Subscription-Id-E164,
        Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id-
        NAI, Subscription-Id-Private.

   12.  User-Equipment-Info-Value AVP: contains the identity of the
        device of the subscriber.  Similar AVPs are: User-Equipment-
        Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64,
        User-Equipment-Info- ModifiedEUI64, User-Equipment-Info-IMEI.

   13.  QoS-Final-Unit-Indication AVP: grouped AVP which may contains
        privacy-sensitive information in its sub-AVPs (e.g IPFilterRule,
        redirect address).

   Note that some AVPs which are used in this document are defined in
   [RFC6733] and may contain privacy-sensitive information.  These AVPs
   are not listed above.

15.2.  Data Minimization

   Due to the nature of the credit control application, some personal
   data and identity information must be stored in both credit-control
   client and credit control server.  This, however, could be minimized
   by following these guidelines:

   1.  Data stored in the credit-control client does not need to be
       persisted across sessions.  All data could be deleted once the
       session end, and reconstructed once a new session is initialized.
       Note that, while the credit-control server is usually owned by
       the service provider with which the subscriber already has some
       direct legal or business relationship (where privacy level could
       be agreed upon), this is not always true for the credit-control
       client, that may be owned by a third-party.

   2.  Some information about the subscriber has to be stored in
       persistent storage in the credit-control server (e.g. identity,
       balance), however, per transaction information does not have to
       be stored in persistent storage, and per session information may
       be deleted from persistent storage once the session ends.

   3.  In some cases, per transaction information has to be stored on
       the credit-control server, client, or both, for regulatory,
       auditability or debugging reasons.  However, this could be
       minimized by following these guidelines:

       A.  Data retention SHOULD NOT exceed the required durations

       B.  Transaction information SHOULD be aggregated as much as
           possible.  E.g.  prefer information per sessions vs.
           information per rating-group; prefer hourly byte summary vs.
           per transaction byte counts.

       C.  If not strictly needed, the more sensitive information (E.g.
           location, equipment type) SHOULD be filtered out from such
           logs.  Such information is often used to make rating
           decisions, and in this case, the rating decision should be
           logged instead of the data used to make them

       D.  The credit-control server SHOULD be preferred over the
           credit-control client as the place where per transaction
           information is stored, if needed.  This is due to the reasons
           explained in 1.

15.3.  Diameter Agents

   Diameter agents, as described in [RFC6733], may be owned by third-
   parties.  To prevent from privacy sensitive information from leaking
   into them, it is RECOMMENDED to encrypt AVPs holding such
   information, as listed in Section 15.1.

   In some cases, the Diameter agent requires access into privacy-
   sensitive AVPs, in order to take correct routing decisions, or even
   modify the content of these AVPs.  In such a case it is RECOMMENDED
   to anonymize the identity of the subscriber, and encrypt any other
   AVP not used by the agent and can be used to identify the subscriber.




=20
=20
On Wednesday, February 14, 2018, 7:12:49 PM GMT+2, = Ben Campbell <ben@nostrum.c= om> wrote:


Even if we add privacy considerat= ions to the base protocol, I think 4006bis would still need privacy conside= rations that discuss the specific AVPs it defines. So I would go ahead and = add considerations to 4006bis and avoid the delay. The WG can discuss wheth= er it would like to add more general considerations to the base protocol (e= ither in a bis draft or an update).

Th= anks!

Ben.

> On Feb 14, 2018, at 11:06 AM, Yuval Lifshitz <yuvalif@yahoo.com> wrote:>
> Regarding "privacy considerati= ons". Note that the base protocol RFC does not have that.
> Ideally, this is added to base Diameter first, as many of the sensiti= ve AVPs come from there.
> Should we try to tackle tha= t first (though this would delay the RFC4006bis process)?
> Should we cover only 4006 AVPs and issues?
> > Best Regards,
>
> Yuval
>
>
> On Wednesday, February 14, 2018, 5:56:52 PM GMT+2, Yuval Lifshitz = <yuvalif@yahoo.com&= gt; wrote:
>
>
> Ben,
> First, thanks for the comments!
>
> Regarding the major comment, agree t= his should be added, it was already agreed in the meeting we had in IETF96,= but somehow slipped :-(
>
> Sec= tions 12: all the AVPs mentioned in this section exists in RFC4006, and has= values that are already registered. As part of RFC4006bis we did not add a= ny AVP that requires values enumeration (this was actually one of the issue= we tried to tackle). What would you like to see different in this section?=
> What is the process for updating IANA with the refe= rences to the new doc? Can this happen before RFC4006bis is officially acce= pted?
>
> Appendix B: the new AV= Ps do not impact the flows, therefore not added to the sample flows
>
> 8.34 agree, this is pretty bad. How= about:
> If the Final-Unit-Action AVP is set to RESTR= ICT_ACCESS or REDIRECT
>    and the classifi= cation of the restricted traffic cannot be expressed
>=     using IPFilterRule, or different actions (e.g., QoS) than jus= t
>    allowing traffic needs to be enforced= , then the QoS-Final-Unit-
>    Indication A= VP SHOULD be used instead of the Final-Unit-Indication
&g= t;    AVP.
>
>
> 14. agree we should simplify as you suggested
>
> Best Regards,
> > Yuval
> On Tuesday, February 13, = 2018, 1:33:22 AM GMT+2, Ben Campbell <ben@nostrum.com> wrote:
>
>
> Hi,
>
> This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. T= hanks for the work on this; it=E2=80=99s overall a good update. However, I = have one major comment and a few minor or editorial comments. I=E2=80=99d l= ike to discuss the major comment prior IETF last call. The rest can be hand= led along with any last call feedback.
>
> Note that for all but the major comment, I mostly reviewed the d= iff from RFC 4006.
>
> Thanks!>
> Ben.
> <= br clear=3D"none">> =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
>
> Major Comment:
>= ;
> I strongly suggest that you add more privacy cons= iderations. I realize that it inherits its existing privacy considerations = from RFC 4006, but that was published in 2005. The IETF=E2=80=99s focus on = privacy has evolved considerably since then, and I think this draft will ge= t objections during IESG review without adding some more.
>
> I suggest the following:
&g= t; =E2=80=94 Create a =E2=80=9CPrivacy Considerations=E2=80=9D section sepa= rate from the security considerations.
> =E2=80=94 Enu= merate the AVPs that you think contain user identifiable information, persi= stent identifiers, or other privacy sensitive data.
> = =E2=80=94 Make some non-normative recommendations concerning data minimizat= ion. That is, add a few sentences recommending that clients and servers avo= id capturing and/or log personal information beyond that needed for the app= lication's purpose.
>
> Minor Co= mments:
>
> -Section 12 and subs= ections: Please clarify that many of these elements were already registered= by RF 4006, and are not being =E2=80=9Cre-registered=E2=80=9D here. ( It= =E2=80=99s perfectly okay to pull the registration information forward into= the bis draft; it just needs clarification.) Also, please consider wether = existing registrations should be updated to point to this document rather t= han 4006.
>
> Appendices: Would = any of the example flows benefit from including one or more of the new AVPs= ?
>
> Editorial and Nits:
>
> -Section 8.34: =E2=80=9C If the Fi= nal-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
> and the classification of the restricted traffic cannot be expressed<= br clear=3D"none">> using IPFilterRule, or different actions (e.g., QoS)= than just
> allowing QoS needs to be enforced traffic= , =E2=80=A6 =E2=80=9C
>
> I have= trouble parsing the sentence.
>
&g= t; -14: "Even without any modification to the messages, an adversary can>  invite a security threat by eavesdropping, as t= he transactions contain private information about the user.
> =E2=80=9D
> I suggest =E2=80=9C =E2=80=A6 an a= dversary can eavesdrop on transactions that contain privacy-sensitive imfor= mation=E2=80=9D
>
>
>
>
>
>
>
>
> ______________________________ _________________
&g= t; DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/ listinfo/dime

_____________= _________________ _________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/ listinfo/dime


=

<= /div> ------=_Part_7541462_2058517286.1519815188886--