From nobody Mon May 15 01:55:44 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D601200E5; Mon, 15 May 2017 01:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: insipid@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149483854247.2843.357208484530510121@ietfa.amsl.com> Date: Mon, 15 May 2017 01:55:42 -0700 Archived-At: Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-marking-07.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 08:55:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID of the IETF. Title : Marking SIP Messages to be Logged Authors : Peter Dawes Chidambaram Arunachalam Filename : draft-ietf-insipid-logme-marking-07.txt Pages : 24 Date : 2017-05-15 Abstract: SIP networks use signaling monitoring tools to diagnose user reported problems and for regression testing if network or user agent software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents, and therefore impractical to monitor SIP signaling end-to-end. This document describes an indicator for the SIP protocol which can be used to mark signaling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular user agent signaling. However, such marking can be carried end-to-end including the originating and terminating SIP user agents, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-insipid-logme-marking-07 https://datatracker.ietf.org/doc/html/draft-ietf-insipid-logme-marking-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-marking-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 16 21:17:44 2017 Return-Path: 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 DCB5012EB07; Tue, 16 May 2017 21:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: 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 ([4.31.198.44]) 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 [195.245.230.176]) (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 [195.245.230.51] 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-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-10.tower-33.messagelabs.com!1494994458!71361288!10 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21525 invoked from network); 17 May 2017 04:14:25 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.140) 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 (47.73.211.207) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 May 2017 06:14:13 +0200 Received: from VOEXC05W.internal.vodafone.com (145.230.101.25) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 May 2017 06:14:13 +0200 Received: from VOEXC29W.internal.vodafone.com (145.230.103.201) by VOEXC05W.internal.vodafone.com (145.230.101.25) 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 ([145.230.103.201]) with mapi id 14.03.0294.000; Wed, 17 May 2017 06:14:12 +0200 From: "Dawes, Peter, Vodafone Group" To: "insipid@ietf.org" CC: "insipid-chairs@ietf.org" , "Arun Arunachalam (carunach) (carunach@cisco.com)" Thread-Topic: draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged" Thread-Index: AdLOtx1nlsqbvQXKTMWmLjT3ATquTQ== Date: Wed, 17 May 2017 04:14:11 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E157BFA3@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_4A4F136CBD0E0D44AE1EDE36C4CD9D99E157BFA3VOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 04:17:43 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E157BFA3VOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, To follow up on the logme requirements being published as RFC 8123, the cor= responding solution draft https://datatracker.ietf.org/doc/draft-ietf-insip= id-logme-marking/ has been revised and uploaded as -07. Changes in this version are from a few sources. The requirements draft cont= ained some detailed solution-related text that has been moved to the soluti= on 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 restr= uctured and clarified the descriptions throughout. The changes are all sum= marized below. We have tried to be comprehensive in describing procedures and answering re= view 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 applicab= ility 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, K= athleen 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 des= cribed in any detail as it is out of scope of the document. Example of calling/called party number added to section "Starting and Stopp= ing 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 M= UST protect the logs, such that the logs can only be read by a person autho= rized to do so." Text added to introduction stating that session identity must be implemente= d 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 r= equirements draft. **Authors updates Text in 5.1 moved to clause 4 and revised to clarify that the example of us= ing XML to show configuration is only an example. The draft does not formal= ize 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 a= gent 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 stat= e and 4 figures that illustrate each one. Replaced figure with four figures based on a call flow example from RFC 366= 5. The new figures are simpler and have a single proxy in originating and t= erminating 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 c= onfiguration to do so. Text is revised to clarify why this restriction exis= ts, 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 statele= ss 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 "log= me" --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E157BFA3VOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

To follow up on the logme requirements being publish= ed 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 b= een 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 lis= t 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 proc= edures and answering review concerns in this version and it would be good t= o hear if issues remain.

 

Thanks!

Peter and Arun (co-authors)

 

**Changes as a result of review of requirements draf= t by Dan Romascanu and moving text from the requirements to the solution dr= aft**

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.<= /o:p>

Defined the SIP CLF format for logs in "Format = of Logged Signaling".

Restructured “Security Considerations”. =

Trust domain behavior described in end-to-end markin= g clause.

Restructured with high-level "Stateful and Stat= eless SIP Entities" clause.

End-to-end marking section clarifies that "log = me" marking does not contain any user or device specific information.<= o:p>

"Authorizing logme Marking" section added = to Security Considerations

 

 

 

**Changes resulting from review of requirements draf= t by Stephen Farrell, Kathleen Moriarty

Moved "Trust Domain" sub-clause from "= ;Security Considerations" to the body of the draft and re-named it &qu= ot;End-to-End Marking"

Added a "Privacy" sub-clause in "Secu= rity 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<= /o:p>

Section 5.1 on configuration removed. Configuration = does not need to be described in any detail as it is out of scope of the do= cument.

Example of calling/called party number added to sect= ion "Starting and Stopping logme Marking".

Text revised to "log me" marking MUST be c= opied into forked requests.

Section 4.2.1.2.1 describes B2BUA terminating behavi= our (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 t= hat has logged information MUST protect the logs, such that the logs can on= ly be read by a person authorized to do so."

Text added to introduction stating that session iden= tity must be implemented for this document. RFC7989 added to normative refe= rences.

logme-reqs moved to informative references.

Syntax of all references revised.

Revised section "Identifying Test Cases" t= o 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. Th= e draft does not formalize how configuration is done.

Text revised to say that it is operator knowledge th= at 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 pr= oxies to say that they MUST log signaling.

Replaced text and figure in 5.4 with a list of 4 cas= es for maintaining state and 4 figures that illustrate each one.

Replaced figure with four figures based on a call fl= ow example from RFC 3665. The new figures are simpler and have a single pro= xy 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.

        &nbs= p;            &= nbsp;     

Restructured the entire draft into a more natural or= der of describing the “log me” marker, SIP entity behavior, err= or cases, and security.

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =   

Consistent use of "log me" term.

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =  

Referenced RFC8123 instead of I-D.ietf-insipid-logme= -reqs

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =  

Updated ABNF definition (Figure 7) to define header = field parameter as "logme"

 

 

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E157BFA3VOEXM31Winterna_--