Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Tue, 12 June 2018 13:46 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 410BA130EF2 for <insipid@ietfa.amsl.com>; Tue, 12 Jun 2018 06:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.694
X-Spam-Level:
X-Spam-Status: No, score=-2.694 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.795, 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 RREr1ZY6uXEX for <insipid@ietfa.amsl.com>; Tue, 12 Jun 2018 06:46:37 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.1]) (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 D95DD130E27 for <insipid@ietf.org>; Tue, 12 Jun 2018 06:46:36 -0700 (PDT)
Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.eu-central-1.aws.symcld.net id 92/0D-16147-ABECF1B5; Tue, 12 Jun 2018 13:46:34 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRWlGSWpSXmKPExsWi75nTqbvrnHy 0wcTzYhbzO0+zWzQ+mMZuMf/+MyYHZo8pvzeyeixZ8pPJY9bOJywBzFGsmXlJ+RUJrBmnJ+1n LJiyhbHi9p7brA2MLzYydjFycQgJbGeUOPVqFQuEc5hRYtnzPVDOZkaJM9d+MXUxcnCwCdhLz NgT08XIySEioCTxvHkrC4jNLBAn8fpSDxuILSzgLbF3/0kWkHIRAR+JOU+ZIcr9JBr2fGEEsV kEVCXOLngH1sorECrxYt0/qFWLmST2fjrMCNLLCbTq398QkBpGAVmJL42rmSFWiUvcejKfCcS WEBCQWLLnPDOELSrx8vE/VpBWZgFNifW79CHKFSWmdD9kh1glKHFy5hOwtUJAJ/xbuYhpAqPo LCRTZyF0z0LSPQtJ9wJGllWMFklFmekZJbmJmTm6hgYGuoaGxrrGuhYGeolVuol6qaW6yal5J UWJQEm9xPJiveLK3OScFL281JJNjMC4YwCCHYxff6YcYpTkYFIS5f3ZIx8txJeUn1KZkVicEV 9UmpNafIhRhoNDSYJ341mgnGBRanpqRVpmDjABwKQlOHiURHi3gqR5iwsSc4sz0yFSpxh1OZ5 cntbDLMSSl5+XKiXO2w5SJABSlFGaBzcClowuMcpKCfMyAh0lxFOQWpSbWYIq/4pRnINRSZj3 GMgUnsy8ErhNr4COYAI6wmyLDMgRJYkIKakGRp4mKblz7V9EhZ9KiTv+T1nc/HRabc37/LqPL 8Vu8anO5DpQLpqj8mpfmMiG1TyKSedtnf+yrC89+O70Xf3A6AuyJ6fxn5mc0W168nbj832Sic Kxa7+snSwXHCtzVSxWtu1zaO/Zq1IJr5fN+MDL/GHuCY59C3XU07Lei12MW6Z4z+7yzDl91Uo sxRmJhlrMRcWJAHhpbkFBAwAA
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-14.tower-228.messagelabs.com!1528811192!995538!8
X-Originating-IP: [47.73.108.137]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 12 Jun 2018 13:46:34 -0000
Received: from vgdpm11vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.137) by server-14.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Jun 2018 13:46:34 -0000
Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 12 Jun 2018 15:46:19 +0200
Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH10W.internal.vodafone.com (47.73.211.208) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 12 Jun 2018 15:46:18 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.229]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0361.001; Tue, 12 Jun 2018 15:46:17 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Ben Campbell <ben@nostrum.com>
CC: "Arun Arunachalam (carunach)" <carunach@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09
Thread-Index: AQHT5xSam+wp8a/gjkypmTJrVCCiwqRK1/cAgAAwnYCAC31YUIAFbl6AgADik4A=
Date: Tue, 12 Jun 2018 13:46:17 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E31F6807@VOEXM31W.internal.vodafone.com>
References: <FE69204E-870D-4BBF-BFBD-1BB85BD20D7A@nostrum.com> <F9B65551-4B5B-4B16-A2E0-59B26B11B5AA@nostrum.com> <73A4B2AE-6F27-4A4C-AED5-DCE88C275372@cisco.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99E31F1D30@VOEXM31W.internal.vodafone.com> <B2C03BF6-58C8-4934-A96A-040C07290B67@nostrum.com>
In-Reply-To: <B2C03BF6-58C8-4934-A96A-040C07290B67@nostrum.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/-1mg0lc70TXo_9QolHa8maeNJ-k>
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 12 Jun 2018 13:46:44 -0000

Thanks Ben, we look forward to hearing what you think. We agreed with nearly all of your other comments and have a draft version ready with improved wording clarity, text order, corrected references etc. that we can post after resolving these bigger issues. 

Regards,
Peter and Arun

> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: 12 June 2018 03:07
> To: Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com>
> Cc: Arun Arunachalam (carunach) <carunach@cisco.com>om>; insipid@ietf.org
> Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09
> 
> Hi,
> 
> Thanks for the response. Due to a schedule conflict, it will be sometime mid
> to late this week before I can go over your response in detail.
> 
> Thanks!
> 
> Ben.
> 
> > On Jun 8, 2018, at 8:10 AM, Dawes, Peter, Vodafone Group
> <Peter.Dawes@vodafone.com> wrote:
> >
> > Dear Ben,
> > Thanks very much for the in-depth review, we authors have reviewed all of
> the points raised and drafted a new revision proposing solutions. Because
> the comment count was high (we recorded 33 in total!) we think it would be
> most efficient to resolve the 3 major review comments first. The major
> comments and our proposed resolutions are as follows:
> >
> > (1) "I think there are still privacy issues in this document. In particular,
> compliant intermediaries are normatively required to log, and to log entire
> messages. Log minimization is a common tenant of privacy, and these
> requirements effectively forbid it. IMO, the draft should avoid normative
> requirements about whether a device logs, and how much it logs.”
> >
> > Although the text is not at the beginning of the draft, section 6.4.6 “User
> Control of Logging” states the logging can be skipped if local policy doesn’t
> allow. We have drafted a new clause called “Scope of Marking” that can be
> placed as a new high-level clause 3 or as the first sub-clause of 4. “SIP Entity
> Behaviour” that refers to this text and would increase its visibility. We
> included the text of this clause in the response to your major comment (3).
> >
> > (2) "Likewise, the requirement to log entire messages without change
> effective forbids pseudonymization or anonymization. There is text in the
> privacy considerations suggesting this is the UA responsibility—I don’t think
> that’s good enough, especially in the case where an intermediary inserts the
> logme parameter on behalf of a non-supporting  endpoint. I’d like to see it
> possible for an intermediary to anonymize logs, and some guidance that it
> should do so unless there is a reason not to.”
> >
> > We would like to maintain the requirement to log the entire message
> because it gives predictable behaviour. The approach of the draft is to ensure
> that logging only happens by prior agreement, and that logged data is within
> a network that already has a relationship with the user. Would it satisfy your
> comment to accommodate anonymization if the endpoint or intermediary
> has that ability?
> >
> > (3) " I think one of the major values of this mechanism is to allow an
> operator to only log details for sessions being tested, and avoid the
> temptation to just log everything in case they need it someday. I suggest this
> be emphasized early in the document. Along those lines, I’d like to see text
> that talks about configuring endpoints and intermediaries to insert the
> parameter to include guidance about the timescale and granularity of such a
> configuration. There is text in the privacy considerations suggesting that you
> this should be configured on a per session basis with a limited timeframe, but
> If there are normative requirements to that effect, I missed them.”
> >
> > We propose to add the following “Scope of marking” section, either as a
> new high-level clause 3, or as the first sub-clause of 4. “SIP Entity Behaviour”.
> This collects together a description of the safeguards of logging only sessions
> being tested, the limits on logging granularity, and the requirements that are
> implicit in the mechanism to prevent logging beyond the boundaries of what
> is intended and has user consent.
> >
> > (3. or 4.1.)  Scope of Marking
> >
> >   "Log me" marking is intended to be limited, in time period and number
> >   of dialogs marked, to the minimum needed to troubleshoot a particular
> >   problem or perform a particular test.
> >
> >   o  SIP entities MUST be configured to "log me" mark only dialogs
> >      needed for the current testing purpose e.g. troubleshooting or
> >      regression testing.  The mechanisms in this clause ensure that
> >      "log me" marking begins at dialog creation and, other than cases
> >      of marking related dialogs or premature ending, ends when the
> >      dialog being "log me" marked ends.
> >
> >   o  SIP entities MUST be configured to initiate "log me" marking on a
> >      dialog creating side.  The mechanisms in this clause limit
> >      initiation of "log me" marking to the dialog creating side, the
> >      dialog terminating side detects an incoming "log me" marker and
> >      reacts accordingly.
> >
> >   Note that the error cases described in clauses 5.1 and 5.2 cause SIP
> >   entities to stop "log me" marking, and the requirements in Section 7
> >   also place requirements on SIP entities, including allowing SIP
> >   entities to not log signaling based on local policies (see
> >   Section 7.4.6).
> >
> > Thanks again for the review,
> > Peter and Arun
> >
> >> -----Original Message-----
> >> From: Arun Arunachalam (carunach) <carunach@cisco.com>
> >> Sent: 01 June 2018 08:43
> >> To: Ben Campbell <ben@nostrum.com>
> >> Cc: draft-ietf-insipid-logme-marking.all@ietf.org; Arun Arunachalam
> >> (carunach) <carunach@cisco.com>
> >> Subject: Re: [Insipid] AD Evaluation of
> >> draft-ietf-insipid-logme-marking-09
> >>
> >> Thanks Ben.
> >>
> >> We are working on it and will share the response by next week.
> >>
> >> Peter and Arun
> >>
> >>> On Jun 1, 2018, at 12:48 AM, Ben Campbell <ben@nostrum.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Just a reminder — I have not seen a response to my review from the
> >> authors.
> >>>
> >>> Thanks!
> >>>
> >>> Ben.
> >>>
> >>>> On May 8, 2018, at 4:36 PM, Ben Campbell <ben@nostrum.com>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This is my AD evaluation of draft-ietf-insipid-logme-marking-09. I
> >>>> have
> >> separated my comments into Major, Minor, and Editorial. I would like
> >> to at least resolve the major comments prior to IETF last call.
> >>>>
> >>>> As a preface, please remember that the related requirements
> >>>> document
> >> created controversy during the IESG review. Some of the controversial
> >> normative language was moved from that document to this one.
> >> Therefore, we can expect some of that controversy to reoccur.
> >> Hopefully if we can resolve my major comments, we can avoid much of
> that.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Ben.
> >>>>
> >>>> ----------------------------------
> >>>>
> >>>> Major Comments:
> >>>>
> >>>> 1) I think there are still privacy issues in this document. In
> >>>> particular,
> >> compliant intermediaries are normatively required to log, and to log
> >> entire messages. Log minimization is a common tenant of privacy, and
> >> these requirements effectively forbid it. IMO, the draft should avoid
> >> normative requirements about whether a device logs, and how much it
> >> logs. It is reasonable to include non-normative guidance that
> >> troubleshooting might require information than might otherwise be
> logged.
> >>>>
> >>>> Likewise, the requirement to log entire messages without change
> >>>> effective
> >> forbids pseudonymization or anonymization. There is text in the
> >> privacy considerations suggesting this is the UA responsibility—I
> >> don’t think that’s good enough, especially in the case where an
> >> intermediary inserts the logme parameter on behalf of a
> >> non-supporting  endpoint. I’d like to see it possible for an
> >> intermediary to anonymize logs, and some guidance that it should do so
> unless there is a reason not to.
> >>>>
> >>>> 2) I think one of the major values of this mechanism is to allow an
> >> operator to only log details for sessions being tested, and avoid the
> >> temptation to just log everything in case they need it someday. I
> >> suggest this be emphasized early in the document. Along those lines,
> >> I’d like to see text that talks about configuring endpoints and
> >> intermediaries to insert the parameter to include guidance about the
> >> timescale and granularity of such a configuration. There is text in
> >> the privacy considerations suggesting that you this should be
> >> configured on a per session basis with a limited timeframe, but If there
> are normative requirements to that effect, I missed them.
> >>>>
> >>>> 3) There is a normative downref to RFC7206. I don’t think that is
> >>>> necessary
> >> or appropriate. It doesn’t appear to be cited, so maybe it can just go
> away?
> >>>>
> >>>> Minor Comments:
> >>>>
> >>>> Abstract, last paragraph: "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.”: While
> >> the draft allows this when there is agreement between operators to do
> >> so, it seems like it is not the default case. Stating it this way
> >> without limitation in the abstract is likely to give the wrong idea.
> >>>>
> >>>> §2: There are instances of 2119 keywords in lower case. Unless you
> >>>> intend
> >> those to be normative, please use the boilerplate from RFC 8174 instead.
> >>>>
> >>>> §3.1, first paragraph: I think “...MUST be passed unchanged…” is
> >>>> too
> >> strong. This only allows the exception for external networks. There
> >> may be any number of local policy reasons to not pass the parameter
> >> through. I suggest making this a SHOULD, and mentioning that local
> >> policy might disallow it. (Note that this MUST is redundant to the
> >> one in §3.4.2. It seems like the normative requirement belongs there,
> >> and that the mention in §3.1 should be descriptive.
> >>>>
> >>>> §3.2, 2nd paragraph: What is expected to happen when such an error
> >> condition occurs?
> >>>>
> >>>> §3.4.1: See comment to §3.1
> >>>>
> >>>> §3.4.2: I don’t think it’s appropriate to use 2119 keywords to
> >>>> describe the
> >> agreements. between operators. It’s reasonable to say
> >> (non-normatively) that end-to-end troubleshooting will be made easier
> >> if such agreements exist.
> >>>>
> >>>> §3.6: (See major comment 1.) It’s reasonable to say that logging
> >>>> the entire
> >> message without change might make troubleshooting easier. But a SIP
> >> network element should be able to apply local policy to decide what
> >> (and
> >> whether) to log. I think a better approach would have been to define
> >> the meaning of “logme” to mean “this message is of interest for
> >> troubleshooting or testing”, and then let devices decide what to do
> >> about that based on local policy.
> >>>>
> >>>> §4 (See major comment 1): This needs some guidance not to minimize
> >> “log me” marking so that only the dialogs under test or
> >> troubleshooting get marked. Otherwise, people will be tempted to just
> mark everything.
> >>>>
> >>>> §4.1: Since the bullet points are listed as “principles”, I suggest
> >>>> using
> >> descriptive language rather than normative keywords. (Same for §4.2)
> >>>>
> >>>> §4.2:
> >>>> - This behavior will likely be a red flag to reviewers. Please
> >>>> mention the
> >> consent requirement up front.
> >>>> - Is the restriction that the intermediaries that insert logme on
> >>>> behalf of
> >> the endpoints be the first SIP hop from the endpoints intended to be
> >> normative? (How much work does it need to do to verify this? For
> >> e.g., there may be edge cases where looking at Via headers may not be
> >> sufficient to tell an endpoint from a b2bua.)
> >>>>
> >>>> §4.4.1: It seems like there are other normative requirements that
> >> effectively prevent stateless processing in many cases.
> >>>>
> >>>> §5.1, last paragraph: This needs to talk about how it interacts
> >>>> with
> >> intermediaries that add the log-me parameter on behalf of endpoints
> >> that don’t support it. It seems like they will see missing markers all the
> time.
> >>>>
> >>>> §6.1: Again, this needs some guidance to discourage an end user or
> >> administrator turning on log-me for all dialogs.
> >>>>
> >>>> §6.4.1: (See major comment 1) This seems unhelpful in the case
> >>>> where an
> >> intermediary inserts log-me on behalf of an end-point that doesn’
> support it.
> >>>>
> >>>> §6.4.4: This doesn’t seem right; the SIP privacy mechanism is about
> >> avoiding identifying the user, not avoiding fingerprinting of a UA.
> >> OTOH, as far as I can tell, log-me doesn’t make fingerprinting
> >> “worse” except in the case where it introduces full-message logging
> >> without the knowledge of the endpoint.
> >>>>
> >>>> §6.4.5: Is the need to enable logging on a per-session basis or
> >>>> specific time
> >> period stated normatively somewhere that I missed? Also, I think this
> >> can do better than making the retention period “out-of-scope”. I
> >> suggest non- normative language that log records captured for
> >> troubleshooting or test purposes should not be retained longer than
> necessary for that purpose.
> >>>>
> >>>> §6.4.6: The “MUST” in the first paragraph seems redundant to
> >>>> already
> >> stated requirements; please state it descriptively. Also, It seems
> >> like the last paragraph is incompatible with some existing MUST level
> requirements.
> >>>>
> >>>> §10.2: It seems like the reference to 3323 should be normative as
> >> currently used.
> >>>>
> >>>>
> >>>> Editorial Comments:
> >>>>
> >>>> - IDNits returns a number of issues; please check. (I see that the
> >>>> shepherd
> >> writeup also points these outs; is there a reason they were not fixed
> >> as a result of that review?)
> >>>>
> >>>> §3.1:
> >>>> - “Logging is most effective…”: I suggest “Logging for diagnostic
> >>>> purposes is
> >> most effective…”
> >>>> - “ session identifier is passed through”: I suggest  “… more
> >>>> likely to be be
> >> passed through…”
> >>>>
> >>>> §3.2:
> >>>> - First paragraph: Is “As indicated in [RFC8123] REQ111,” really
> >>>> needed? It
> >> doesn’t seem to add information to this document.
> >>>> - 2nd paragraph: I suggest s/proxy/intermediary
> >>>>
> >>>> §3.7:
> >>>> — 2nd paragraph:
> >>>> - “Figure 2 below”: Don’t assume all presentations of the RFC will
> >>>> keep the
> >> same relative positioning for the figure. Better to just say “Figure 2”.
> >>>> - "Her terminal is configured to log signalling”: That makes it
> >>>> sound like
> >> her terminal is configured to insert the logme parameter into all requests.
> >> Can this be scoped more tightly?
> >>>> - “ Alice’s terminal logs related REFER dialog2” : And inserts the
> >>>> logme
> >> parameter?
> >>>>
> >>>> —  4th paragraph: Unmatched closing parenthesis.
> >>>> — Figure 2: It would be helpful to mention that parts of the
> >>>> messages in
> >> examples are elided for clarity (e.g. no SDP, “…” for content-length).
> >>>>
> >>>> §3.8: By what? (Please consider active voice; in this case passive
> >>>> voice
> >> obscures the actor).
> >>>>
> >>>> §4.2, first paragraph: “The intermediaries that are known to be
> closest…”
> >> That’s the point of the whole section; I moving it to the beginning
> >> of the paragraph.
> >>>>
> >>>> §4.4.2.1: Is “Proxy 1” really a “proxy” as defined in RFC3261? Does
> >>>> this
> >> assume that Alice’s UA did insert Session-ID?
> >>>>
> >>>> §4.4.2.1.1: Seems like this example belongs with the text about errors.
> >>>>
> >>>> §5.1.1, figure 9: “Network B” doesn’t seem to participate in the
> >> exchange—why is it in the picture?
> >>>>
> >>>> §5.2: I don’t think the term “edge proxy” captures the idea that we
> >>>> are
> >> talking about an intermediary immediately adjacent to an endpoint.
> >>>>
> >>>> §6.4: comma splice
> >>>>
> >>>> §7: This section should come before the security considerations.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> insipid mailing list
> >>>> insipid@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/insipid
> >>>
> >