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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> 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) <[e-mail]>
>> Sent: 01 June 2018 08:43
>> To: Ben Campbell <[e-mail]>
>> Cc: [e-mail]; Arun Arunachalam
>> (carunach) <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>> 
>