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>; 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 > >>> > >
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Arun Arunachalam (carunach)
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Dawes, Peter, Vodafone Group
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Dawes, Peter, Vodafone Group
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Dawes, Peter, Vodafone Group
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Dawes, Peter, Vodafone Group
- [Insipid] AD Evaluation of draft-ietf-insipid-log… Ben Campbell