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

Ben Campbell <ben@nostrum.com> Tue, 08 May 2018 21:36 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F234912EAE9; Tue, 8 May 2018 14:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fElBPtHVpJ9I; Tue, 8 May 2018 14:36:09 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3FA1712D574; Tue, 8 May 2018 14:36:06 -0700 (PDT)
Received: from [] (cpe-66-25-7-22.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w48La4Mt068916 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 May 2018 16:36:05 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [] claimed to be []
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_87433561-192C-4FD2-A093-13D0876C1023"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Message-Id: <FE69204E-870D-4BBF-BFBD-1BB85BD20D7A@nostrum.com>
Date: Tue, 8 May 2018 16:36:03 -0500
To: draft-ietf-insipid-logme-marking.all@ietf.org, insipid@ietf.org
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/eZumv2I53goKA7qIMmOfKY3JczY>
Subject: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.22
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, 08 May 2018 21:36:13 -0000


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.




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)

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

- “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…”

- 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

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

§ Is “Proxy 1” really a “proxy” as defined in RFC3261? Does this assume that Alice’s UA did insert Session-ID?

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