From nobody Sun Aug 6 11:31:04 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 2E94D13204C; Sun, 6 Aug 2017 11:30:56 -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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150204425614.15206.1148577475961550048@ietfa.amsl.com> Date: Sun, 06 Aug 2017 11:30:56 -0700 Archived-At: Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-marking-08.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: Sun, 06 Aug 2017 18:30:56 -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 WG of the IETF. Title : Marking SIP Messages to be Logged Authors : Peter Dawes Chidambaram Arunachalam Filename : draft-ietf-insipid-logme-marking-08.txt Pages : 34 Date : 2017-08-06 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 being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in normal 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-insipid-logme-marking-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-marking-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 6 11:42:32 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 7DF8D131ECE; Sun, 6 Aug 2017 11:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=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 WnySbHSxGaGB; Sun, 6 Aug 2017 11:42:28 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) (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 0BF7C127058; Sun, 6 Aug 2017 11:42:27 -0700 (PDT) Received: from [193.109.255.99] by server-2.bemta-6.messagelabs.com id AB/07-27137-21367895; Sun, 06 Aug 2017 18:42:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleJIrShJLcpLzFFi42LR98zp0RVMbo8 0WDrB2KLxwTR2i0ePfjBZzL//jMmB2WPK742sHkuW/GQKYIpizcxLyq9IYM24uuUva8FSp4qj k1+yNDC+M+hi5OIQEtjGKHFq1w12COcQo8SWI3eZIJzDjBLf5s5lhnA2M0r8uziDtYuRg4NNw F5ixp6YLkZODhEBTYmPN84xg9jMAtkSn392gNnCAi4S/058Z4Wo8ZS49uw7E4StJ/H1zG8wm0 VAReLO8wlg9bwCoRInHnwBq2cUkJX40rgaaqa4xK0n88HqJQQEJJbsOc8MYYtKvHz8jxWiRkd iwe5PbBC2tsSyha+hZgpKnJz5hAXEFhJQlfi3chHTBEaRWUjGzkLSPgtJ+ywk7QsYWVYxahSn FpWlFukameklFWWmZ5TkJmbm6BoamOnlphYXJ6an5iQmFesl5+duYgRGDgMQ7GA8syDwEKMkB 5OSKG/8irZIIb6k/JTKjMTijPii0pzU4kOMMhwcShK8pxPbI4UEi1LTUyvSMnOAMQyTluDgUR LhFU0CSvMWFyTmFmemQ6ROMepyHJrx8xuTEEtefl6qlDivEUiRAEhRRmke3AhYOrnEKCslzMs IdJQQT0FqUW5mCar8K0ZxDkYlYd59IJfwZOaVwG16BXQEE9ARbxJbQY4oSURISTUwmn2a53ZA XYzvbvNT268PzuvYbhGpuzRJSChnxbrgm+bts1S6g4zSYypSlxhZs7Dx9oubLeuo43j3bYp76 VTj+HSrOzUtG5Yydnyzdimepzeh+PpKS88wi9LSqotmS+028X2f2Fvy4sXsxkdLntz/tWzKlM IqD/3I1S9X1NrO73gUL1yQ2ByqxFKckWioxVxUnAgAM/2fgSIDAAA= X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-13.tower-48.messagelabs.com!1502044941!130242575!10 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.4.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28365 invoked from network); 6 Aug 2017 18:42:25 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.140) by server-13.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Aug 2017 18:42:25 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 6 Aug 2017 20:42:23 +0200 Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH10W.internal.vodafone.com (47.73.211.214) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 6 Aug 2017 20:42:22 +0200 Received: from AVOEXC04W.internal.vodafone.com (145.230.15.142) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 6 Aug 2017 20:42:22 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.167]) by AVOEXC04W.internal.vodafone.com ([145.230.15.142]) with mapi id 14.03.0361.001; Sun, 6 Aug 2017 20:42:21 +0200 From: "Dawes, Peter, Vodafone Group" To: "insipid@ietf.org" CC: "Arun Arunachalam (carunach" , "insipid-chairs@ietf.org" Thread-Topic: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 Thread-Index: AdMO40NqLP76QTneR5qXtNkpE/eQyg== Date: Sun, 6 Aug 2017 18:42:20 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E1640610@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 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: Sun, 06 Aug 2017 18:42:31 -0000 Hello All, Thanks again for the in-depth reviews of the log me marking draft, and for = helpfully suggesting how to resolve the issues raised for nearly all commen= ts. Below is a summary of changes in -08 (https://www.ietf.org/id/draft-iet= f-insipid-logme-marking-08.txt) listed under the corresponding review. We b= elieve that all issues raised have been covered except for one question, wh= ich is whether a "log me" marker can legitimately appear mid-dialog in thir= d party call control. The log me-marking draft section 5.2 says that markin= g appearing mid-dialog is an error:=20 5.2. "Log Me" Marker Appears Mid-Dialog "log me" marking that begins mid-dialog is an error case and the terminating user agent or edge proxy MUST NOT "log me" mark responses to the marked request, responses to subsequent requests in the dialog, or in-dialog requests from the terminating side. For a case where a B2BUA re-directs a call attempt not to the called party= but to a third party, it was questioned whether that third party might leg= itimately initiate "log me" marking. We considered as an example section 3.= 6 of RFC 3665 copied below. In this case, Alice would have to initiate logg= ing in F4 to troubleshoot any problem reported by Bob so we believe that th= e answer is no and section 5.2 is still correct. Section 4 of the logme-mar= king draft says ""Log me" marking is initiated on a dialog creating side co= ntrolled by configuration. The dialog terminating side detects an incoming= "log me" marker and reacts accordingly." which is consistent with Alice ne= eding to initiate marking. We are happy to further discuss if someone has a= different view.=20 3.6. Session via Redirect and Proxy Servers with SDP in ACK Alice Redirect Server Proxy 3 Bob | | | | | INVITE F1 | | | |--------------->| | | | 302 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | |-------------------------------->| INVITE F5 | | 100 F6 |--------------->| |<--------------------------------| 180 F7 | | 180 F8 |<---------------| |<--------------------------------| | | | 200 F9 | | 200 F10 |<---------------| |<--------------------------------| | | ACK F11 | | |-------------------------------->| ACK F12 | | |--------------->| | Both Way RTP Media | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D>| | | BYE F13 | | BYE F14 |<---------------| |<--------------------------------| | | 200 F15 | | |-------------------------------->| 200 F16 | | |--------------->| | | | Summary of changes in revision -08 per review: https://mailarchive.ietf.org/arch/msg/insipid/FnXbZzJsWaMp9xoLFigVDu23CZg=20 Revised section 3.2 as suggested by the reviewer to make the role of config= uration and of the start and end of a dialog on log me marking clear. Added= called party number as an example of a use case for logging.=20 Section 3.4.1 mixed two points, firstly that only authorized devices are a= llowed to perform marking and secondly that such marking should be passed u= nchanged. Revised this section to separate these points. Ensuring that only= authorized devices perform "log me" marking is covered by the ""Authorizat= ion"" sub-clause of the ""Security"" section and does not need to be repeat= ed here. Adopted the suggested text except that log me marking is in the se= ssion-ID header not To and From.=20 Section 3.1 says that B2BUAs and other intermediaries MUST pass the log me= marker unchanged and yet section 3.4.2 says that if no agreement exists be= tween peer networks then the "log me" marker MUST be removed at a network b= oundary. Adopted the reviewer's suggested text to allow the case of removin= g the marker.=20 =09 Revised section 4.2.2.2.1 to describe more of the messages and also show lo= g me marking in the figure itself.=20 Similarly revised sections 4.2.2.2.2 and 4.2.2.2.3 to describe more of the= messages and also show log me marking in the figure itself. =09 In section 3.5 added that the local UUID in Session-ID is the test case id= entifier as suggested.=20 =09 Made the wording and editorial changes suggested at the end of the review. https://mailarchive.ietf.org/arch/msg/insipid/LanUOni-7-5yEyTOb0oZwdbyNxo=20 Section 4.1, corrected inconsistency of using term "log me" header in one p= lace and "log me" marker in another =09 Section 4.2, reworded the final bullet for both SIP endpoints and intermedi= aries to make it clear how a user agent or intermediary echoes the marker. = Rewrote the third sentence (starting with 'The "log me" marker...') to expl= icitly state that the text deals with the case where the terminating user a= gent does not echo the marker. Sentence added to describe the logging behav= ior of the terminating SIP intermediary.=20 =09 Corrected the editorial errors identified. https://mailarchive.ietf.org/arch/msg/insipid/sZzybE-cgF7McXsYEjuy0xJH9NY=20 Changed occurrences of "test identifier" to "test case identifier" =20 Figure 1 domain names changed from "foocorp.com" to ""example.com" =20 Re-wrote the example in section 3.7 based on call transfer in RFC 5589 but = not identical. Included the details of key SIP requests and responses. =09 In section 4.1, revised the list of principles so that each bullet states a= single principle. Added a bullet that the terminating UA itself logs any i= n-dialog SIP requests that it sends if allowed by policy. Made parallel the= lists of principles for user agents and for intermediaries acting on behal= f of user agents. =09 In section 4.2, same as above. =09 Simplified section 4.2.1, which describes the behaviour of B2BUAs. Replaced= the example with a more common example of a contact center call controller= element.=20 =09 In section 4.2.2.2.1 Fig. 3, which shows "log me" marking not supported by = the originating UA, corrected the numbering of requests and responses. Also= added descriptions of other requests and responses to clarify operation, i= ncluding the comment on proxies inserting "log me" marking in responses to = the UA that does not support "log me" marking. Described the logging behavi= or of Proxy 1. =09 In section 4.2.2.2.3 inserted text for message F8. Also updated 4.2.2.2.2 t= o state that Proxy 1 doesn't log requests and responses of the dialog betwe= en itself and Proxy 2 and in 4.2.2.2.3. added logging behavior of Proxy 2=20 =09 In section 4.2.2.2.4, corrected the wording above Fig. 6 which shows "log m= e" marking being removed by the terminating network. It was commented that = the text above Fig. 6 is in conflict with section 5.1 which says that a mar= ker missing from a dialog subject to marking is an error. Section 5.1 has b= een expanded to define and illustrate error and non-error cases." Also, add= ed labels to Fig. 6 to show log me marking.=20 =09 Section 5.2 says that a "log me" marker appearing mid-dialog is an error, b= ut this was questioned e.g. in a 3PCC case - Alice calls Bob via a B2BUA, t= hen the B2BUA reconnects Alice to Charlie. It may turn out that Charlie has= logme marking enabled. So this will appear during the dialog establishment= with Charlie, but it will appear to be mid-dialog to Alice. However, are t= hese not simply separate dialogs like the 3 separate dialogs in Section 3.7= ? It would help to see the signalling details so that we can analyse this c= ase.=20 ABNF simplified as suggested. Best regards, Peter and Arun (authors)