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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

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 <[e-mail]>
> Sent: 12 June 2018 03:07
> To: Dawes, Peter, Vodafone Group <[e-mail]>
> Cc: Arun Arunachalam (carunach) <[e-mail]>; [e-mail]
> 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
> <[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
> >>>
> >