Re: [dispatch] Proposed charter for work on logging

"Vijay K. Gurbani" <vkg@bell-labs.com> Thu, 13 June 2013 21:19 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9C21F9ACD for <dispatch@ietfa.amsl.com>; Thu, 13 Jun 2013 14:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiqupan-ol2y for <dispatch@ietfa.amsl.com>; Thu, 13 Jun 2013 14:19:16 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0FD21F9A39 for <dispatch@ietf.org>; Thu, 13 Jun 2013 14:19:15 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5DLJ4tl017188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dispatch@ietf.org>; Thu, 13 Jun 2013 16:19:04 -0500 (CDT)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r5DLJ3DX000793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <dispatch@ietf.org>; Thu, 13 Jun 2013 16:19:04 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r5DLJ38P010320 for <dispatch@ietf.org>; Thu, 13 Jun 2013 16:19:03 -0500 (CDT)
Message-ID: <51BA382E.4040605@bell-labs.com>
Date: Thu, 13 Jun 2013 16:22:54 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: dispatch@ietf.org
References: <EDC0A1AE77C57744B664A310A0B23AE210701601FC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com>
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [dispatch] Proposed charter for work on logging
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 21:19:21 -0000

On 06/13/2013 06:17 AM, Dawes, Peter, Vodafone Group wrote:
> Hello All, Following on from the comments at IETF#86
> (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch),
> where there was mild support for working on logging, I have updated
> the log me requirements draft with 3 potential solutions (in clause
> 7) which can meet the requirements
> (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.txt).
> Opinions and comments on these or any other potential solutions would
> be very welcome.

Peter: I am not being a contrarian, just being curious.

What is the utility of a log-me marker if all traffic is logged
through a mechanism such as SIP CLF?

> It was commented at IETF#86 that a security analysis is needed so I
> would like to understand if any scenarios exist with potential
> security threats in order to add them to requirements. In many cases,
> a network simply logs the signalling that passes through it so no new
> security issues are created. Collecting end-to-end logging for
> signalling that crosses multiple networks must not compromise
> security or privacy, but I would expect networks to remove any
> security sensitive fields before forwarding signalling regardless of
> whether that signalling is of interest to logging.

We went through discussions related to all of the above points during
the SIP CLF work.  See the Security Consideration section of [1]; it
may provide you some answers.

[1] http://tools.ietf.org/html/rfc6872

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq