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

["Ben Campbell" <[e-mail]>]

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.

On 1 Feb 2017, at 16:12, Stephen Farrell wrote:

> 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:[e-mail]] On Behalf Of Stephen Farrell
>>> Sent: 01 February 2017 14:22 To: The IESG Cc: [e-mail];
>>> [e-mail]; draft-ietf-insipid-logme- [e-mail];
>>> [e-mail] 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 [e-mail]
>>> https://www.ietf.org/mailman/listinfo/insipid
>>
>
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid