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

Alberto Llamas <albertollamaso@gmail.com> Thu, 06 October 2016 12:46 UTC

Return-Path: <albertollamaso@gmail.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 DA1B1129637 for <insipid@ietfa.amsl.com>; Thu, 6 Oct 2016 05:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FzsyH0fJYJW4 for <insipid@ietfa.amsl.com>; Thu, 6 Oct 2016 05:46:17 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F1A127A90 for <insipid@ietf.org>; Thu, 6 Oct 2016 05:46:17 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id g192so12070605ywh.1 for <insipid@ietf.org>; Thu, 06 Oct 2016 05:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tp7Ve4UXI311iyMHirQgHptPSqrOzEd3zwMUKGlROdM=; b=BT6+PWvh+nOdl2uYJQ1la0PG1F7rLCqiotE0HFqQO8nN+DMO+6tWD5q2TZyRoqKqKp rEHAwQZA54vi2uGubZbEFuTQEshARPDb4fj+uu5PPqb+WzEdyJZhuD9mS12jnI/qynp+ //irkIbSn0Ywq19iqDdvqrO5W50hICzUzkIG5OmbyT0aGGuD1HMAx9MTQKTqjwdhDb// yH5iToNAtirSYRhpbSRzxSEPkqBKpZ/zDBzejhYgDEYKXeDufuv4cy5byZJ439cwrSwb jYTbxbn7+VmkruFjnoPjKS8ZRcFHN2tkPOzxNDo8Gs9OdoYhV9xw/cLZboSp47A+GavL ymRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tp7Ve4UXI311iyMHirQgHptPSqrOzEd3zwMUKGlROdM=; b=DvSh8sfs8/QHgcKa+Y1eJw9drjHB73ktxYgvlN2Wgq5a+K/Nh7Z51yCbolCmg8/lEw IqkBQo1GRL3gVPZHBgYuje7QAbPAXeySWsp/yGqPEvb9VQpyquQAUlbbVlA8X4JnczcS PJzA/vVtsvKhx/lrYZpLTRSzz9EeocXIwIy/emPbhKIBBPEyvX+ASo2nwRx8iWSu5UbW sbPu3TIyx0m6qTqVhea+WL7lsiiXJMzmPuHouZJ94+Ns/kVgpp8O43ee/D530PWvMzIP uKxs8aLE/eSPN/DDtLa9k2Io1oqWk938zZR7Sgyk7X9OQNZXy9OyqLMC3//nUyd0BlrJ Rk9g==
X-Gm-Message-State: AA6/9RnvWmyWanwf1e+FJ3coPTz7/rUNwfXwh97aC8GMVjpU4x0SmWqO7bSRBJxc4LiF8Sb77i/U0KCqrAgKcg==
X-Received: by 10.129.120.74 with SMTP id t71mr10947426ywc.51.1475757976437; Thu, 06 Oct 2016 05:46:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.172.150 with HTTP; Thu, 6 Oct 2016 05:46:15 -0700 (PDT)
In-Reply-To: <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> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B72473@VOEXM31W.internal.vodafone.com>
From: Alberto Llamas <albertollamaso@gmail.com>
Date: Thu, 6 Oct 2016 14:46:15 +0200
Message-ID: <CAHH1jkMVARqfAOaABHhtOgzCE0k26reWP4f-XgaenaxbheLMCw@mail.gmail.com>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
Content-Type: multipart/alternative; boundary=94eb2c0b9808f5c9e3053e31adf9
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/xKrKRGjmXdnDlxPom2DLZniwSCI>
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>, "insipid@ietf.org" <insipid@ietf.org>, "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: Thu, 06 Oct 2016 12:46:22 -0000

Hi Peter, it looks very good. I just have couple of comments you would take
in consideration:


   - *In points 4.3 and 5.1 the sentence:*


logging on to the SIP entity that contains the logs

Maybe could be change for something like:

logging on to any or all SIP entity that contains the logs


   - *In points 4.3 and 5.3:*

You are referring to the 'stop event' that cause logging to stop. In this
draft and also in '*draft-ietf-insipid-logme-marking-05*' I don't find any
explanation about what a stop event is and/or how to detect it. There is a
short example that a stop event could be *"**typically expiry of a certain
amount of time*". From my point of view stop events should be defined
somewhere or at least define a single stop event as an end of the dialog.


Regards,



On Mon, Oct 3, 2016 at 4:09 PM, Dawes, Peter, Vodafone Group <
Peter.Dawes@vodafone.com> wrote:

> 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
>
>
>
>
>


-- 
Alberto Llamas
Phone: +1-786-805-6003
Telecommunications Engineer
Digium Certified Asterisk Professional (dCap)