Re: [Insipid] draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Mon, 05 June 2017 14:13 UTC

Return-Path: <Peter.Dawes@vodafone.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2990F1298BA; Mon, 5 Jun 2017 07:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eVd-6nMhPZ6; Mon, 5 Jun 2017 07:13:22 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (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 4A724129A8F; Mon, 5 Jun 2017 07:13:21 -0700 (PDT)
Received: from [85.158.139.163] by server-9.bemta-5.messagelabs.com id 1B/F9-01999-FF665395; Mon, 05 Jun 2017 14:13:19 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleJIrShJLcpLzFFi42LR98zp1P2XZhp psOiAvkXjg2nsFo8e/WCymH//GZMDs8eU3xtZPZYs+ckUwBTFmpmXlF+RwJrx8e5vloJHCxkr Fn07x9rAOHkCYxcjF4eQwDZGiXs925ghnEOMEj/uTGWBcDYxSjR1XAByODjYBOwlZuyJ6WLk5 BAR0JT4eOMcWAOzQCOjxIXnXewgCWGBUImtHx4yQxSFSby/Ph3KNpJYuPAWK4jNIqAisW3uYj YQmxeovn/9QbAaRgFZiS+Nq8FsZgFxiVtP5jOB2BICAhJL9pxnhrBFJV4+/scKcg+zQJ7EykZ FiDGCEidnPmEBsYUEVCX+rVzENIFRaBaSSbMQOmYh6YAo0ZFYsPsTG4StLbFs4WtmGPvMgcdM yOILGNlXMaoXpxaVpRbpmuglFWWmZ5TkJmbm6BoamOrlphYXJ6an5iQmFesl5+duYgTGEwMQ7 GC81ed8iFGSg0lJlHe1ommkEF9SfkplRmJxRnxRaU5q8SFGGQ4OJQne3FSgnGBRanpqRVpmDj CyYdISHDxKIrzOIGne4oLE3OLMdIjUKUZFKXHefSAJAZBERmkeXBssmVxilJUS5mUEOkSIpyC 1KDezBFX+FaM4B6OSMO+ZFKApPJl5JXDTXwEtZgJazHfJBGRxSSJCSqqBccLWpYyN/ns7PF3X 3IjVNNlz84djZcCKmhtO3azWaz6UsKV47r7WNcUi4Ea6zGSuyyG5U5cUvUp7xPFcyapF/Y5Ds WPmi+Z9ujwPnohuORosxO+2TtY988JbzYdrXNc9/qiSJSxfXnFk07EJbEqVSiEre7o1JXb1NR vM89r19cvie5XOSxevVmIpzkg01GIuKk4EAOcCynohAwAA
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-15.tower-188.messagelabs.com!1496671996!111626197!3
X-Originating-IP: [47.73.108.137]
X-StarScan-Received:
X-StarScan-Version: 9.4.19; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26575 invoked from network); 5 Jun 2017 14:13:18 -0000
Received: from vgdpm11vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.137) by server-15.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 5 Jun 2017 14:13:18 -0000
Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 16:13:03 +0200
Received: from VOEXC06W.internal.vodafone.com (145.230.101.26) by VOEXH06W.internal.vodafone.com (47.73.211.204) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 16:13:02 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.246]) by VOEXC06W.internal.vodafone.com ([192.168.89.204]) with mapi id 14.03.0352.000; Mon, 5 Jun 2017 16:13:02 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "insipid@ietf.org" <insipid@ietf.org>
CC: "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>
Thread-Topic: draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"
Thread-Index: AdLOtx1nlsqbvQXKTMWmLjT3ATquTQPTn0YA
Date: Mon, 05 Jun 2017 14:13:02 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785F@VOEXM31W.internal.vodafone.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785FVOEXM31Winterna_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/c0vR4cVVhCsPda0BBSOvW3-_WUk>
Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jun 2017 14:13:25 -0000

Hi All,
Just a kind reminder that a significantly revised logme-marking solution draft (-07) was uploaded a few weeks ago. The revised text aims to pair with the now published requirements draft as a complete description of problem and solution, and to answer some comments and concerns raised during the review of the requirements draft.

The authors are hoping we can progress this draft as a follow-up to the requirements discussion as the issues are similar and some of the text in this solution draft was moved from the requirements draft.

Comments and reviews are welcome!

Best regards,
Peter (co-author)



From: Dawes, Peter, Vodafone Group
Sent: 17 May 2017 05:14
To: insipid@ietf.org
Cc: insipid-chairs@ietf.org; Arun Arunachalam (carunach) (carunach@cisco.com)
Subject: draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged"

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 4.2.1.2.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"