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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 February 2017 22:12 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA51295B7; Wed, 1 Feb 2017 14:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6iMJuCBiTSR; Wed, 1 Feb 2017 14:12:40 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7B71295A1; Wed, 1 Feb 2017 14:12:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E4A15BE38; Wed, 1 Feb 2017 22:12:37 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0ChXVfFNpGW; Wed, 1 Feb 2017 22:12:36 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E87CBE2D; Wed, 1 Feb 2017 22:12:35 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485987155; bh=AQheD7e//SEzAGwE2hAK35LWVQzZgaOvWXDH61ZHJJE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=o9ok0sVvo9I5rMGmS7Kfov0JhR9cgIbe3GKcPDF4CkeLtV4fW0XipV2BC/GIZzYHn IHIkOw5+HcxHK32Y/IOD+UzRq38srpni0e/2kF8tw/Mlq395IvaOTgjT1TMVa52H2G qkz4CtYlzMHBy1DaX2G2D+ivmBfTqrV/U4QkO1oE=
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, The IESG <iesg@ietf.org>
References: <148595894907.19146.186759558704017451.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7240A@VOEXM31W.internal.vodafone.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5b2e4d39-5646-27f2-a7c2-639404f1c70b@cs.tcd.ie>
Date: Wed, 1 Feb 2017 22:12:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7240A@VOEXM31W.internal.vodafone.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000508050904060402090207"
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/2v2aaCg5azNTjQ0BMzOul7VsLcc>
Cc: "insipid@ietf.org" <insipid@ietf.org>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "draft-ietf-insipid-logme-reqs@ietf.org" <draft-ietf-insipid-logme-reqs@ietf.org>, "gsalguei@cisco.com" <gsalguei@cisco.com>
Subject: Re: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 22:12:43 -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: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
>