Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Mon, 03 October 2016 14:09 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 E7E7912B2F2 for <insipid@ietfa.amsl.com>; Mon, 3 Oct 2016 07:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 RYz5edyjABlF for <insipid@ietfa.amsl.com>; Mon, 3 Oct 2016 07:09:14 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) (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 8671212B2E0 for <insipid@ietf.org>; Mon, 3 Oct 2016 07:09:08 -0700 (PDT)
Received: from [85.158.139.163] by server-7.bemta-5.messagelabs.com id FF/D1-05127-28662F75; Mon, 03 Oct 2016 14:09:06 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRWlGSWpSXmKPExsVy+MWXNt2mtE/ hBs+28VvMnH2YxWJ+52l2i+b5/xgtGh9MY7eYO8XPYv79Z0wWNxseM1qs2HCA1YHD4+/7D0we P24Hekz5vZHVY+esu+weS5b8ZPKYtfMJSwBbFGtmXlJ+RQJrxoIJF9gL1sZV3Jh8lr2BcUJsF yMXh5DAHkaJaY/mMEI4qxglzq5tgnJWMEms/vCLFcI5xCgx88VedghnE6PEjfVdLF2MHBxsAv YSM/bEdDFycogIaEp8vHGOGaSGWeA5k0Tj9WesIAlhASeJR9s/MYHUiwg4S9zuCocw3STWfss HMVkEVCSmdlaBFPMKhEqcWr6bDWLTLGaJey0L2EASnAK2ErOb5zOC2IwCshJfGlczg9jMAuIS t57MZwKxJQQEJJbsOc8MYYtKvHz8jxVkPjPQaet36UOUK0pM6X7IDrFLUOLkzCcsExjFZiGZN AuhYxaSjllIOhYwsqxi1ChOLSpLLdI1NtBLKspMzyjJTczM0TU0MNXLTS0uTkxPzUlMKtZLzs /dxAiM3XoGBsYdjBNW+R1ilORgUhLl9d/8MVyILyk/pTIjsTgjvqg0J7X4EKMMB4eSBG9X6qd wIcGi1PTUirTMHGASgUlLcPAoifCWgKR5iwsSc4sz0yFSpxgVpcR5/UASAiCJjNI8uDZY4rrE KCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZhXEWQKT2ZeCdz0V0CLmYAWB275ALK4JBEhJdXAm DTh+6kbjlEdq8WKGP6Wn3GsDlq09t15Z9+rh4K0L/1hqLx5qP5QZKvAog6Z1eFXVr8/udp2iv XDcyHinrd2vea5M3Hpk9QpB3cw2Bzj7Nq9eutmx0Z5icM/41leGrFJl2ZFrzDvv3Xuds4P87k +OVLZpibt/LlVR//PSes+/GjrPM8fp468W67EUpyRaKjFXFScCAATCr9mVwMAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-10.tower-188.messagelabs.com!1475503746!62999110!1
X-Originating-IP: [195.232.244.134]
X-StarScan-Received:
X-StarScan-Version: 8.84; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3962 invoked from network); 3 Oct 2016 14:09:06 -0000
Received: from mailout02.vodafone.com (HELO mailout02.vodafone.com) (195.232.244.134) by server-10.tower-188.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 3 Oct 2016 14:09:06 -0000
Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout02.vodafone.com (Postfix) with ESMTP id 3snkS14ylmzbdpw; Mon, 3 Oct 2016 16:09:05 +0200 (CEST)
Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3snkS13Rr3z16PRG; Mon, 3 Oct 2016 16:09:05 +0200 (CEST)
Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3snkS134s8z16MQR; Mon, 3 Oct 2016 16:09:05 +0200 (CEST)
Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 3 Oct 2016 16:09:04 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.113]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0224.002; Mon, 3 Oct 2016 16:09:03 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
Thread-Index: AQHSFN6RAbjNqQhgAUiQuX1dWTV2XqCQiS4AgAAl2gCAAABngIAGGcKw
Date: Mon, 3 Oct 2016 14:09:01 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B72473@VOEXM31W.internal.vodafone.com>
References: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com> <7FA11A21-D8BC-4829-B6D5-EE2B44200D8E@cisco.com> <984E4584-C850-4198-8F78-1839A027C36A@cisco.com> <79D6B8EF-4C53-40B1-A7B9-C8C8479E153B@cisco.com> <38281C26-6FDD-4755-AFBB-F6AC93D2EC48@cisco.com> <F5241F4A-B1FE-41D9-BD20-6C31B67B80A5@cisco.com> <6EE9E419-BCE8-4E5A-B0F1-2E0AE53C8BF0@cisco.com> <C0EB6615-9318-453E-B784-ECACAAC4856C@cisco.com>
In-Reply-To: <C0EB6615-9318-453E-B784-ECACAAC4856C@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/U9_4QH1fmUzk8CsUdBY1D60hqmU>
Cc: "ben@nostrum.com" <ben@nostrum.com>, "Arun Arunachalam \(carunach\)" <carunach@cisco.com>, "brett@broadsoft.com" <brett@broadsoft.com>, "Gonzalo Salgueiro \(gsalguei\)" <gsalguei@cisco.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, "Alberto Llamas \(albertollamaso@gmail.com\)" <albertollamaso@gmail.com>, "Paul Giralt \(pgiralt\)" <pgiralt@cisco.com>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Oct 2016 14:09:19 -0000

Hello All,
Thanks to everyone who reviewed and commented on the logme requirements draft, we have uploaded revision -08 (https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-08.txt) with the changes summarized below that aim to resolve the issues raised. Some of the changes are taken from e-mail exchanges here on the insipid list but some of the text (and structure) is new so it would be good to hear whether the revised draft is now OK.

(a)  Expanded REQ8 (was REQ5 in revision -07) to explicitly mention gateways and B2BUAs. (commented by Alberto Llamas and Paul Giralt)
(b)  Example debugging procedure given its own subclause and simplified to make it clear that it is only an example and does not contain any requirements. (commented by Paul Kyzivat)
(c)  Requirements split into 3 groups depending on whether they apply to SIP entities, the logging procedure, or the logme marker itself. (commented by Paul Kyzivat)
(d)  New subclause added that defines a network boundary. (commented by Paul Kyzivat)
(e)  New subclause added that defines a trust domain as it applies to logme (commented by Paul Kyzivat)
(f)  All requirements in the descriptive clause moved to the requirements clause (commented by Paul Kyzivat)
(g)  Changed "proxy" to "intermediary" in requirements related to whether SIP entities are stateful or stateless in terms of their logging behaviour. (commented by Paul Kyzivat and Paul Giralt)
(h)  Reworded requirement on form of logged message to say that messages should be logged in the form that they appear in the signaling. (commented by Brett Tate)
(i)   References to draft-insipid-session-id updated to the latest version. (commented by Brett Tate)
(j)  Added the sentence: ""log me" marking SHOULD be applied to in-dialog requests and responses in either direction. " to the requirement about per-dialog granularity. (commented by Paul Giralt)
(k)  Changed wording in introduction to use a more general description than "service providers" to include enterprises and other operators of SIP networks. (commented by Paul Giralt) 
(l)  Wording changed to "Header fields SHOULD be logged in the form in which they appear in the message, they SHOULD NOT be converted between long and compact forms..." (commented by Paul Giralt) 
(m)  Added the sentence ""log me" marking SHOULD be applied to in-dialog requests and responses in either direction." (commented by Paul Giralt) 
(n)  Section 6.2.1 revised to capitalize normative words (MUST etc.). Also text related to sending logged information to a server removed. (commented by Paul Giralt) 
(o)  Changed text in "Trust Domain" subclause of the "Security" clause to say SHOULD NOT rather than "might not": "If a prior agreement to log sessions exists with the next hop network then the "log me" marker SHOULD NOT be removed". (authors change)
(p)  Revised the 6.2.2 "Sending Logged Information" to "Logged Information" and changed the description to state that unauthorized parties should not have access to the logged information. (Related to comment by Paul Giralt on solutions draft)
(q)  Changed the format of cross references so that the reference name is not repeated. (Related to comment by Paul Giralt on solutions draft)
(r)  REQ5 (was REQ8 in revision -07) updated to have test identifier as a random value instead of human readable name due to Session-ID privacy requirements defined in REQ 4 of RFC7206. (commented by Paul Giralt)
(s)  REQ9 (was REQ6 in revision -07) updated with an additional use case in which intermediaries continue to mark logme for related sessions. (commented by Paul Giralt)
(t)  Acknowledgments updated to include reviewers who provided comments during last call.


Thanks and regards,
Peter (on behalf of the co-authors)



From: Paul Giralt (pgiralt) [mailto:pgiralt@cisco.com] 
Sent: 29 September 2016 19:15
To: Arun Arunachalam (carunach)
Cc: Gonzalo Salgueiro (gsalguei); insipid@ietf.org; ben@nostrum.com; Dawes, Peter, Vodafone Group
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

Looks good to me. 

-Paul

On Sep 29, 2016, at 2:13 PM, Arun Arunachalam (carunach) <carunach@cisco.com> wrote:

Thanks Paul ! 

(1) Agree, let’s have a random test id given REQ 4 of RFC 7206.

(2) We can update REQ 6 as shown below to incorporate your comment:

 REQ6: A SIP intermediary MAY insert a "log me" marker into requests and
      responses.  The typical case for which a intermediary needs to insert a
      "log me" marker is for compatibility with UAs that have not
      implemented "logme" marking, i.e. when a UA has not marked a
      request or when responses received on a dialog of interest for
      logging do not contain an echoed "log me" marker.  Another use 
      case is when the session origination UA that inserted log me marker
      is no longer participating in the session (e.g: call transfer scenarios)
      and the intermediary adds "log me" marker in related sessions to enable
      end-to-end signaling analysis. In these cases, the entity that inserts a
      "log me" marker is stateful inasmuch as it must remember when a dialog is
      of interest for logging.  An entity that inserts a "log me" marker 
      SHOULD also log the SIP request or response as per REQ4.


Arun




On Sep 29, 2016, at 11:57 AM, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

Hi Arun,  

Sorry for not replying earlier. Inline… 


On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <carunach@cisco.com> wrote:

Hi Paul, 

Please see inline.

On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

Thanks Arun. See below…  

On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <carunach@cisco.com> wrote:

REQ8: Should update to latest session-id draft. Also, I have some concerns about using Session-ID as the test case identifier. The Session-ID can change (in fact will change for every session because the initial INVITE will have a null remote UUID). 

How about using the local UUID of the Session-ID generated by the originating UA / proxy as a test identifier (if the admin wants the system to auto-generate a test ID)?


I think using just the local UUID makes more sense because this will be consistent throughout the life of the session as long as the originating endpoint is still in the call. It’s possible that some B2BUA could remove the originator from the session (e.g. call gets transferred) but at that point, the device that requested the session be logged is no longer in an active session anyway. 

That said, what if the admin doesn’t want the system to auto-generate a test ID? Where would that go? The local UUID must be in a very specific format to comply with drafy-ietf-insipid-session-id, so you can’t put any arbitrary text in for the local UUID. I think either you need to stipulate that the test ID will always be automatically generated or find some other place to put it. 

I think there is value in giving the admin the ability to specify their own identifier.

One option would be to have a user defined test identifier as shown below:

   test-identifier = (alphanum / "_") *(alphanum "_")

If the user defined test identifier is not present, the log analysis server would use the local UUID of the originator’s Session-ID as the test identifier.



I like this in concept. The concern I have is whether it meets the privacy requirements stipulated for additional parameters in the Session-ID header. If someone puts a value of the person’s name or perhaps a ticket number, that could be considered personally identifiable information which is not allowed to be present in the Session-ID header. I’m not sure how we’d reconcile these requirements. We may have to just live with the test ID being something random. 




Also, should intermediaries be required to or at least allowed to continue indicating log me markings on other messages related to the session even if the originating device is no longer participating in the session? 

This will be useful to perform an end-to-end call flow analysis. 

The good thing about originator based log me marking is the “ability / control” to disable logging simply by disconnecting the call at the originator (the device requesting to enable logging). 

This control no longer exists if we allow the intermediaries to continue marking even after the originator is no longer in the session.

I guess this could be left up to the implementation of the intermediary. It is free to add a logme marker to whatever it wants to, so even if the originator drops off, there is no reason why it can’t add the identifier to related sessions. This is probably something worth mentioning in the draft, but might not be necessary in the requirements doc. 

-Paul