[MMUSIC] Lawful intercept - don't (Re: IETF#89: First version of CLUE Data Channel slide set.)

Harald Alvestrand <harald@alvestrand.no> Mon, 03 March 2014 08:41 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798EE1A0AF2 for <mmusic@ietfa.amsl.com>; Mon, 3 Mar 2014 00:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.344
X-Spam-Level:
X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] autolearn=no
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 8Y0C2sAiXCoB for <mmusic@ietfa.amsl.com>; Mon, 3 Mar 2014 00:41:54 -0800 (PST)
Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id E4D4A1A0958 for <mmusic@ietf.org>; Mon, 3 Mar 2014 00:41:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BDD037C4F60 for <mmusic@ietf.org>; Mon, 3 Mar 2014 09:41:50 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msKXEAKuEqkR for <mmusic@ietf.org>; Mon, 3 Mar 2014 09:41:50 +0100 (CET)
Received: from [31.133.161.198] (dhcp-a1c6.meeting.ietf.org [31.133.161.198]) by mork.alvestrand.no (Postfix) with ESMTPSA id EB2B17C4F5F for <mmusic@ietf.org>; Mon, 3 Mar 2014 09:41:49 +0100 (CET)
Message-ID: <5314404D.5070500@alvestrand.no>
Date: Mon, 03 Mar 2014 09:41:49 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D1C0E03@ESESSMB209.ericsson.se> <CAHBDyN75R1Wr5BODSQ9RNmNP9G7QZdOjZ9Lw+Vz3DCEUUYh4-Q@mail.gmail.com> <CAHBDyN5aDiJHy0fZ3=A8bLyCGAEhSojxu0_kAdLvOTykykE36Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1C2DF7@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826E003463@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1C3A97@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826E003836@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1C4C1F@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826E003961@US70UWXCHMBA02.zam.alcatel-lucent.com> <53139A10.1040502@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826E003DC8@US70UWXCHMBA02.zam.alcatel-lucent.com>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17826E003DC8@US70UWXCHMBA02.zam.alcatel-lucent.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tQT6IthvX4_-CrO671hO5PiV2VY
Subject: [MMUSIC] Lawful intercept - don't (Re: IETF#89: First version of CLUE Data Channel slide set.)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 08:41:57 -0000

On 03/03/2014 12:00 AM, Makaraju, Maridi Raju (Raju) wrote:
>>> > > */1./*Lawful intercept (LI): A CLUE channel may have to be reported to
>>> > > LI agents per regulatory requirements. For various reasons such
>>> > > reporting may have to be interworked with non-data channel SCTP/dTLS
>>> > > transport (e.g. TCP).
>> > 
>> > By explicit policy we don't consider lawful intercept in IETF.
>> > The same issue exists for the RTP.
> [Raju] I understand LI is a very sensitive subject and by no means I am making any statements about it. My comment was providing one use case to which a service provider may be legally obligated to oblige.
>
> There are other cases that may require interworking at gateways.
>

When stating the use case, just say that one of the participants in a
CLUE channel (including the gateway) may choose to share the content (or
the existence of the channel - I can't tell which you mean by "report"
here) with a third party.

There are lots of reasons why someone may choose to do that, including,
for instance, the requirement for recording financial advice given over
the phone in many countries, and calling out legal intercept is just
going to generate lots of heat but little light.

-- 
Surveillance is pervasive. Go Dark.