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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 01 Feb 2017 06:22:29 -0800

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.

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

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

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

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 1 Feb 2017 20:18:38 +0000

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:[email-masked]] On Behalf Of Stephen Farrell
> Sent: 01 February 2017 14:22
> To: The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-insipid-logme-
> [email-masked]; [email-masked]
> Subject: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-
> reqs-12: (with COMMENT)
> 
> 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.)
> 
> 
> 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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Feb 2017 22:12:34 +0000

Hi Peter,

I don't suggest that we get into it in detail - if needed that'd
be better done during IESG evaluation of the solution draft, but
I have to say that no matter how many other documents have the
same concept, I think it's a broken concept:-)

The "it" I mean is to consider the set of {all machines controlled
by one operator plus all the other machines needed for one or a
set of calls originated by that operator} as a "domain." That'd be
like considering the set of {routers affected by a BGP announcement
plus all the machines in the original AS} as a domain, which I
don't think makes any more sense.

Again though, I don't think we need to bottom out on this now,
but I suspect things'll work out better if the solution document
doesn't depend much on that "trust domain" (IMO non-)concept.

Cheers,
S.

On 01/02/17 20:18, Dawes, Peter, Vodafone Group wrote:
> 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:[email-masked]] On Behalf Of Stephen Farrell 
>> Sent: 01 February 2017 14:22 To: The IESG Cc: [email-masked];
>> [email-masked]; draft-ietf-insipid-logme- [email-masked];
>> [email-masked] Subject: [Insipid] Stephen Farrell's No
>> Objection on draft-ietf-insipid-logme- reqs-12: (with COMMENT)
>> 
>> 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.
>> 
>> 
>> 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.
> 
>> 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.
> 
>> - 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 [email-masked]

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Feb 2017 16:58:58 -0600

Hi,

I agree with Stephen that "trust domain" is used to mean so many 
different things that the term has become vacuous. Even if it is well 
defined in any given RFC, it inherits the baggage from all the other 
usages.

But, I am inclined to defer the push for something more rigorous to the 
solution draft. Give that the solutions draft will be standards track 
and privacy affecting, I expect it's security and privacy considerations 
will get close scrutiny :-)

Ben.