Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Thu, 12 January 2017 13:21 UTC

Return-Path: <Peter.Dawes@vodafone.com>
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 DEF371293E3 for <insipid@ietfa.amsl.com>; Thu, 12 Jan 2017 05:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.056
X-Spam-Level:
X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 tpnF_ixoFU6R for <insipid@ietfa.amsl.com>; Thu, 12 Jan 2017 05:21:13 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F59D128874 for <insipid@ietf.org>; Thu, 12 Jan 2017 05:21:13 -0800 (PST)
Received: from [85.158.138.179] by server-16.bemta-3.messagelabs.com id 6E/25-03637-7C287785; Thu, 12 Jan 2017 13:21:11 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleJIrShJLcpLzFFi42LR98zp0T3eVB5 h0LeVx2L+/WdMFg9+9LI5MHlMfjyH0WPJkp9MAUxRrJl5SfkVCawZF1o1CyYqVXy4t4O1gfGi dBcjF4eQwHZGiRWtM1khnMOMElOmX2aBcI4wSrzqvMUE4cxllPizciZ7FyMHB5uAvcSMPTFdj JwcIgLBElseLmUHsYUFHCV2HznMAhF3klh0ZBs7hO0ncXHCdzCbRUBVYsX8yWwgY3gFQiW6Tj pCjD/NJLH73SM2kBpOoPGfZp1gBbEZBWQlvjSuZgaxmQXEJW49mc8EYksICEgs2XOeGcIWlXj 5+B8rRI2OxILdn9ggbG2JZQtfg9XwCghKnJz5BOw2IaAb/q1cxDSBUXQWkrGzkLTPQtI+C0n7 AkaWVYzqxalFZalFuoZ6SUWZ6RkluYmZObqGBsZ6uanFxYnpqTmJScV6yfm5mxiBMcQABDsYl 390OsQoycGkJMq7yqM8QogvKT+lMiOxOCO+qDQntfgQowwHh5IE77RGoJxgUWp6akVaZg4wmm HSEhw8SiK82iBp3uKCxNzizHSI1ClGRSlx3jUgCQGQREZpHlwbLIFcYpSVEuZlBDpEiKcgtSg 3swRV/hWjOAejkjDvBpApPJl5JXDTXwEtZgJafNEGbHFJIkJKqoEx8vfhizI6d40r11jyLF73 r+q9qe50LybOA4sVEyaLX9dY/ivqwS199qIrguvjZi67d+6OZKhQbeQFrT5W30eV9dxSIcFLu ZWkX1/fJbaJL+7LsuxbM3YeV35YMCfCv/mcV43r/DMLC8IWT5snmFsUkWjvoWqRPtclUTDUzy +Aedv3OG5HzddKLMUZiYZazEXFiQBTkZRGGwMAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-9.tower-169.messagelabs.com!1484227270!90055598!2
X-Originating-IP: [47.73.108.140]
X-StarScan-Received:
X-StarScan-Version: 9.1.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23441 invoked from network); 12 Jan 2017 13:21:11 -0000
Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.140) by server-9.tower-169.messagelabs.com with AES256-SHA encrypted SMTP; 12 Jan 2017 13:21:11 -0000
Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 12 Jan 2017 13:41:14 +0100
Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH06W.internal.vodafone.com (47.73.211.210) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 12 Jan 2017 13:41:11 +0100
Received: from VOEXC27W.internal.vodafone.com (145.230.103.199) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 12 Jan 2017 13:41:11 +0100
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc27w ([145.230.103.199]) with mapi id 14.03.0294.000; Thu, 12 Jan 2017 13:41:10 +0100
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Paul Kyzivat <paul.kyzivat@comcast.net>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
Thread-Index: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0AgAAen4CAASfu4IAAQi0AgAF0fZA=
Date: Thu, 12 Jan 2017 12:41:09 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com>
References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com> <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net>
In-Reply-To: <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/koJU23dIp59eLT1dcNJd3VlZsPM>
Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
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: Thu, 12 Jan 2017 13:21:16 -0000

Hello Paul,
Mandating a standard logging format means that tools for analysing logs will know what to expect. I take the point that because how and when logs are retrieved is out of scope then the "log me" solution will not detail how log files are examined, nevertheless log files will be retrieved somehow. Implementations will have to use the specified format in order to claim compliance, so it seems a useful requirement. 

Regards,
Peter

> -----Original Message-----
> From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net]
> Sent: 11 January 2017 15:09
> To: Dawes, Peter, Vodafone Group; insipid@ietf.org
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
> 
> On 1/11/17 5:39 AM, Dawes, Peter, Vodafone Group wrote:
> > Hello Paul,
> > Thanks for the comments, replies inline.
> >
> > Regards,
> > Peter
> >
> >> -----Original Message-----
> >> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul
> >> Kyzivat
> >> Sent: 10 January 2017 17:33
> >> To: insipid@ietf.org
> >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
> >>
> >> I have a couple of comments:
> >>
> >> On 1/10/17 9:51 AM, Dawes, Peter, Vodafone Group wrote:
> >>
> >>>> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging
> >>>> format"?  Is there another logging format other than SIP CLF?
> >>>
> >>> We am not aware of any other SIP logging formats and SIP CLF is
> >>> expected
> >> to be used, but the logging format will be defined in the solutions draft.
> >>
> >> IIUC, the mechanism for retrieval of the logs is out of scope for
> >> this document and the corresponding mechanism document. So why is
> the
> >> format of the logs of any relevance here?
> >
> > The draft tries to distinguish the format of the logs from the mechanism for
> retrieval using the words "When and how " in s5.1 "When and how signaling
> logs are retrieved is out of scope of this
> >    document." It seems helpful to encourage a standard logging format by
> pointing to RFC 6873.
> 
> This is not a requirement that can be verified via any published protocol.
> (Because retrieval is out of scope.) Even if retrieval is subsequently
> standardized, the requirement would be that the retrieved document be in
> CLF format, not that the logging be *captured* in that format.
> 
> I have no objection to a non-normative hint that CLF defined and well suited
> for capturing the logs.
> 
> >>>> 6) Is there a missing requirement based on the security
> >>>> considerations that requires the this marker MUST be removed at the
> >>>> earliest opportunity if it has been incorrectly inserted?
> >>>
> >>> We can move the text "The presence of a "log me" marker might cause
> >> some SIP entities to log signaling.  Therefore, this marker MUST be
> >> removed at the earliest opportunity if it has been incorrectly inserted."
> >>> from s6.2.1 and add a REQ12 in s5.3.
> >>
> >> What do you mean by "incorrectly inserted"?
> >>
> >> If this is a syntax issue, then presumably it will be dealt with as a
> >> syntax error of the sip message. If the standard sip handling
> >> mechanism is "ignore", then how will it be recognized as a "log me"
> marker so that it may be removed?
> >>
> >> To act on this the marker must parse syntactically as a "log me"
> >> marker (whatever that syntax turns out to be) yet violate some semantic
> rule.
> >
> > "incorrectly inserted" means that either a "log me" marker has appeared
> for the first time mid-dialog, or that a SIP entity that is controlling the "log
> me" marking sees a "log me" marker that should not be there. For example,
> a UAC inserts (maliciously or due to mis-configuration) a "log me" marker in
> an initial dialog-creating request but for that network a SIP intermediary has
> sole responsible for "log me" marking initial dialog-creating requests and this
> SIP intermediary detects and removes the marker.
> > If you think this is unclear, perhaps we could expand a little to
> > something like " The presence of a "log me" marker might cause some SIP
> entities to
> >    log signaling.  Therefore, this marker MUST be removed at the
> >    earliest opportunity if it has been incorrectly inserted (e.g. mid-dialog or
> outside the configured start and stop of "log me" marking)."
> 
> That is much better.
> 
> 	Thanks,
> 	Paul
>