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

[Stephen Farrell <[e-mail]>]

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
>