[Insipid] draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"
"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Wed, 17 May 2017 04:17 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5012EB07; Tue, 16 May 2017 21:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MxQnnHqamEW; Tue, 16 May 2017 21:17:40 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [18.104.22.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8D912EC83; Tue, 16 May 2017 21:14:27 -0700 (PDT)
Received: from [22.214.171.124] by server-16.bemta-3.messagelabs.com id 1E/A9-29088-22ECB195; Wed, 17 May 2017 04:14:26 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRWlGSWpSXmKPExsWi75nTo6t4Tjr S4O1BOYvGB9PYLR49+sFkMf/+MyYHZo8pvzeyeixZ8pMpgCmKNTMvKb8igTVj/fHqgtMtjBVb l0c0MHaVdTFycQgJbGeUmH16ChOEc5hR4tnmdlYI5wijxMnVT6Eycxklrh9+BeRwcLAJ2EvM2 BPTxcjJISKgKfHxxjlmkBpmgUZGiQvPu9hBEsICgRKnHt9kgSgKk3h/fTozhK0ncXrRQbA4i4 CqxJ+pexhBbF6BUIljLQ1gvYwCshJfGleD1TMLiEvcejKfCcSWEBCQWLLnPDOELSrx8vE/Voi aPIlJC09BzRGUODnzCdh8IaD5/1YuYprAKDwLyahZSFpmIWmBiOtILNj9iQ3C1pZYtvA1M4x9 5sBjJmTxBYzsqxjVi1OLylKLdM31kooy0zNKchMzc3QNDYz1clOLixPTU3MSk4r1kvNzNzEC4 4wBCHYwNn53OsQoycGkJMrrECkdKcSXlJ9SmZFYnBFfVJqTWnyIUYaDQ0mC1+wsUE6wKDU9tS ItMwcY8TBpCQ4eJRHeVWeA0rzFBYm5xZnpEKlTjIpS4rxWIH0CIImM0jy4NliSucQoKyXMywh 0iBBPQWpRbmYJqvwrRnEORiVh3mcg43ky80rgpr8CWswEtDjspTjI4pJEhJRUA2NSvd+32xOE Lpptt1EJfPdS0mL75mNnebau6itUbFQ+k7StzCroZxLD3JmrX3ftnM8adL7jQd+vHYV974XWt KrVTnroZP9AMXX6Zx8XVq3Ed1zlj6e/D180S+Rtwg2uBPGFYkv3X1l6a6tCxdWDydZTlJTFzx f2nK19+u+Ny0+9Z4lX0idNm/dLiaU4I9FQi7moOBEAv2Ws0y0DAAA=
X-StarScan-Version: 9.4.12; banners=-,-,-
Received: (qmail 21525 invoked from network); 17 May 2017 04:14:25 -0000
Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (126.96.36.199) by server-10.tower-33.messagelabs.com with AES256-SHA256 encrypted SMTP; 17 May 2017 04:14:25 -0000
Received: from VOEXH09W.internal.vodafone.com (188.8.131.52) by edge1.vodafone.com (184.108.40.206) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 May 2017 06:14:13 +0200
Received: from VOEXC05W.internal.vodafone.com (220.127.116.11) by VOEXH09W.internal.vodafone.com (18.104.22.168) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 May 2017 06:14:13 +0200
Received: from VOEXC29W.internal.vodafone.com (22.214.171.124) by VOEXC05W.internal.vodafone.com (126.96.36.199) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 17 May 2017 06:14:13 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.69]) by voexc29w ([188.8.131.52]) with mapi id 14.03.0294.000; Wed, 17 May 2017 06:14:12 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "email@example.com" <firstname.lastname@example.org>
CC: "email@example.com" <firstname.lastname@example.org>, "Arun Arunachalam (carunach) (email@example.com)" <firstname.lastname@example.org>
Thread-Topic: draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"
Date: Wed, 17 May 2017 04:14:11 +0000
Accept-Language: en-GB, en-US
Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E157BFA3VOEXM31Winterna_"
Subject: [Insipid] draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2017 04:17:43 -0000
Hello All, To follow up on the logme requirements being published as RFC 8123, the corresponding solution draft https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ has been revised and uploaded as -07. Changes in this version are from a few sources. The requirements draft contained some detailed solution-related text that has been moved to the solution draft. The IESG review of the requirements draft highlighted a number of corrections and concerns including privacy. A review that Paul Giralt sent to this list a while back identified some changes. Also, the authors restructured and clarified the descriptions throughout. The changes are all summarized below. We have tried to be comprehensive in describing procedures and answering review concerns in this version and it would be good to hear if issues remain. Thanks! Peter and Arun (co-authors) **Changes as a result of review of requirements draft by Dan Romascanu and moving text from the requirements to the solution draft** In "2. Conventions Used in this Document added text to expand the applicability of requirements language. Added a new high-level clause "Marking Related Dialogs" to describe "log me" marking related dialogs. Defined the SIP CLF format for logs in "Format of Logged Signaling". Restructured "Security Considerations". Trust domain behavior described in end-to-end marking clause. Restructured with high-level "Stateful and Stateless SIP Entities" clause. End-to-end marking section clarifies that "log me" marking does not contain any user or device specific information. "Authorizing logme Marking" section added to Security Considerations **Changes resulting from review of requirements draft by Stephen Farrell, Kathleen Moriarty Moved "Trust Domain" sub-clause from "Security Considerations" to the body of the draft and re-named it "End-to-End Marking" Added a "Privacy" sub-clause in "Security Considerations". Did a privacy analysis as described in RFC 6973 and as a result completely restructured and revised the Privacy section. **Changes as a result of review by Paul Giralt Section 5.1 on configuration removed. Configuration does not need to be described in any detail as it is out of scope of the document. Example of calling/called party number added to section "Starting and Stopping logme Marking". Text revised to "log me" marking MUST be copied into forked requests. Section 184.108.40.206.1 describes B2BUA terminating behaviour (since according to RFC 7092, a signaling only B2BUA can manipulate SIP in any way it likes.) References to RFC 7206 changed to references to RFC 7989. In section 6.5, text revised to "A SIP entity that has logged information MUST protect the logs, such that the logs can only be read by a person authorized to do so." Text added to introduction stating that session identity must be implemented for this document. RFC7989 added to normative references. logme-reqs moved to informative references. Syntax of all references revised. Revised section "Identifying Test Cases" to align with description in the requirements draft. **Authors updates Text in 5.1 moved to clause 4 and revised to clarify that the example of using XML to show configuration is only an example. The draft does not formalize how configuration is done. Text revised to say that it is operator knowledge that some user agents do not support "log me" and that a SIP entity must act on behalf of the user agent Revised text for both originating and terminating proxies to say that they MUST log signaling. Replaced text and figure in 5.4 with a list of 4 cases for maintaining state and 4 figures that illustrate each one. Replaced figure with four figures based on a call flow example from RFC 3665. The new figures are simpler and have a single proxy in originating and terminating networks. Currently the signaling B2BUA is subject to the same rules as a user's UA, i.e. it cannot invoke "log me" marking on dialogs that it creates without configuration to do so. Text is revised to clarify why this restriction exists, and perhaps this rule can be re-visited if cases for breaking the rule emerge. debug parameter renamed logme. Split the "Maintaining State" clause into sub-clauses that describe stateless and stateful behavior. Restructured the entire draft into a more natural order of describing the "log me" marker, SIP entity behavior, error cases, and security. Consistent use of "log me" term. Referenced RFC8123 instead of I-D.ietf-insipid-logme-reqs Updated ABNF definition (Figure 7) to define header field parameter as "logme"
- [Insipid] draft-ietf-insipid-logme-marking-07 "Ma… Dawes, Peter, Vodafone Group
- Re: [Insipid] draft-ietf-insipid-logme-marking-07… Dawes, Peter, Vodafone Group