Re: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT)

Hello Stephen,
Thanks for the in-depth review of the draft. Some responses below.

Best regards,
Peter and Arun (co-authors)

> -----Original Message-----
> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: 01 February 2017 14:22
> To: The IESG
> Cc: insipid@ietf.org; insipid-chairs@ietf.org; draft-ietf-insipid-logme-
> reqs@ietf.org; gsalguei@cisco.com
> Subject: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-
> reqs-12: (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-insipid-logme-reqs-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> Note that I'm balloting no-objection here. If some of these things weren't
> fixed, I'd be a DISCUSS ballot when the protocol spec turned up, should I still
> be on the IESG at that point (which I guess is unlikely:-)
> 
> - 3.2: I think "trust domain" isn't a great term, and doesn't really match the
> definition offered well. You're including the entire "source" operator plus the
> bits of any other operator that have agreed to help the source-operator with
> logging. I don't think that set of things is really a domain. Nor are the things in
> that set "trusted" except to do this logging stuff properly. It's also not clear to
> me if the relevant set is meant to differ per-call, or to be the same for all calls
> that a source-operator might originate.
> 

The term "trust domain" appears in RFC 3324 (referred to by RFC 3325, RFC 7316) and RFC 6404. In the 3GPP profile of SIP, it appears in TS 24.229. RFC 3324 concerns network asserted identities and defines a trust domain as a collection of nodes with secure connections that have configuration information on which connected nodes to trust. 

RFC 6404 concerns security threats related to the interconnection of service providers. SIP service providers (SSPs) who have a peering or transit contract are in the trust domain, others are not: "Each SSP may have connections to one or more remote SSPs through peering or transit contracts.  A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs.".

The TS 24.229 description of  the trust domain (clause 4.4) includes the following excerpts "For the IM CN subsystem, this trust domain consists of the functional entities that belong to the same operator's network " and " Additionally, other nodes within the IM CN subsystem that are not part of the same operator's domain may or may not be part of the trust domain, depending on whether an interconnect agreement exists with the remote network. " and " Within the IM CN subsystem trust domains will be applied to a number of header fields. These trust domains do not necessarily contain the same functional entities or cover the same operator domains."

The use of trust domain in logme-reqs is similar to its use in RFC 6404 and TS 24.229. The trust domain needs a wide scope in terms of included networks because one of the reasons for the logme mechanism is the unpredictability in advance of SIP routing through multiple connected service providers, transit networks, etc. It is also important to define trust domain as it applies specifically to "logme marking" as a protocol element because trust domain does not always impact all parts of SIP equally. 

logme marking is expected to be applied for regression testing and troubleshooting. It will often be pre-arranged and involve a SIP client specifically for testing owned and operated by a service provider. The trust domain is not expected to change from call to call but only a very small subset of calls will be used for testing.

> - 5.1: REQ1 seems to me to ignore privacy in one bad respect - isn't the right
> thing to log the entire message
> *except* bits that are considered sensitive by the logging entity concerned?
> E.g. any secrets or PII in the SIP message may be best not logged. Forcing
> everyone to log the entire thing would seem brittle to me - it may cause
> operators to not co-operate with one another esp if data privacy laws differ
> between them. (Or maybe more likely, the logs will not have the sensitive
> bits, or will eventually have them XXXX'd out.)
> 

Specifying logging the entire message means that troubleshooting tools will know they have all fields. Privacy might require that one service provider remove some protocol elements before passing a SIP message to a peer service provider, logme marking won't be able to bring them back. Within a service provider, logging must obey data protection laws regardless of any RFC.

If the user needs privacy, their user agent should follow the procedures documented in RFC 3323. This way we can avoid imposing privacy related requirements on SIP entities that log messages.

> - REQ9: Not quite sure, but I wonder are there additional requirements for
> intermediaries inserting this that aren't covered. For example, that that not
> be (ab)used for other than diagnostics and hence ought not be on by default
> and maybe more. I think the thing to do is to get someone to do a privacy
> analysis of this situation before the protocol spec is done - some minor
> changes might make a biggish difference there.

We can do a privacy analysis as part of the solution.

> 
> - 6.1: See above wrt 3.2. I'm not convinced that there is such a thing as a
> "trust domain boundary" as you use the term. I think (not sure) that may
> mean that logme stuff is either dropped on ingress or else never dropped
> which'd seem like a bad outcome.

Logme marking of a SIP request will be present until a SIP message is passed to a peer service provider that is not part of the prior logging agreement, and then it will be removed. Note that a response to that request might be logme marked as it re-enters the service provider that removed it from the request.

> 
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid