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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Wed, 11 January 2017 10:39 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 35AE412960C for <insipid@ietfa.amsl.com>; Wed, 11 Jan 2017 02:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 APW1HmElJqId for <insipid@ietfa.amsl.com>; Wed, 11 Jan 2017 02:39:39 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) (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 A5FE11294D7 for <insipid@ietf.org>; Wed, 11 Jan 2017 02:39:38 -0800 (PST)
Received: from [195.245.230.51] by server-4.bemta-3.messagelabs.com id 88/A6-01392-86B06785; Wed, 11 Jan 2017 10:39:36 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRWlGSWpSXmKPExsWi75nTqZvBXRZ hsP0dl8X8+8+YLB786GVzYPKY/HgOo8eSJT+ZApiiWDPzkvIrElgzVk6YwVxwX6Li7eynbA2M c0W6GLk4hAS2M0r0NdxkhXAOM0pM+/+KCcLZxChx4fF0oAwHB5uAvcSMPTFdjJwcIgLBElseL mUHsYUFHCV2HznMAhF3klh0ZBs7jL361VlGEJtFQFWi59oNsBpegVCJvg3v2SDmn2GU+NJzjx kkwQk0/+rLB2BFjAKyEl8aV4PFmQXEJW49mc8EYksICEgs2XOeGcIWlXj5+B8rRI2OxILdn9g gbG2JZQtfM0MsE5Q4OfMJ2EwhoCP+rVzENIFRZBaSsbOQtM9C0j4LSfsCRpZVjBrFqUVlqUW6 hsZ6SUWZ6RkluYmZObqGBsZ6uanFxYnpqTmJScV6yfm5mxiB8cIABDsYt233PMQoycGkJMp75 nVphBBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3mCusgghwaLU9NSKtMwcYOTCpCU4eJREeKNB0r zFBYm5xZnpEKlTjIpS4rz9IAkBkERGaR5cGyxZXGKUlRLmZQQ6RIinILUoN7MEVf4VozgHo5I wbzLIFJ7MvBK46a+AFjMBLY60KwZZXJKIkJJqYFw8K4wveY9Zl9mbfz8XHT2mqLFve/2yWPMf Etz8NSI3476n5p9KLlMrXFD/T73oAfsKiSsTdrYzXZyQOW9LvFOiivMPqzDPVsszF9cfFGif7 mjUti3u/+ad1xZnhLzicpB789xq48ZT/ZcfJjrlK7wW+mnFffXIxUOqkvreCo7qf19wZRy706 nEUpyRaKjFXFScCABs8GmKEQMAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-13.tower-33.messagelabs.com!1484131175!84030576!1
X-Originating-IP: [47.73.108.137]
X-StarScan-Received:
X-StarScan-Version: 9.1.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8900 invoked from network); 11 Jan 2017 10:39:36 -0000
Received: from vgdpm11vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.137) by server-13.tower-33.messagelabs.com with AES256-SHA encrypted SMTP; 11 Jan 2017 10:39:36 -0000
Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 11 Jan 2017 11:39:33 +0100
Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH07W.internal.vodafone.com (47.73.211.211) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 11 Jan 2017 11:39:32 +0100
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0294.000; Wed, 11 Jan 2017 11:39:30 +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: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0AgAAen4CAASfu4A==
Date: Wed, 11 Jan 2017 10:39:30 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com>
References: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4D0D0@VOEXM31W.internal.vodafone.com> <327a9ba3-a587-b87e-a3b8-f2d0055f733e@comcast.net>
In-Reply-To: <327a9ba3-a587-b87e-a3b8-f2d0055f733e@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/ybGSTMU_yUGJw9jIFhRhlIRQ5Ps>
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: Wed, 11 Jan 2017 10:39:41 -0000

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. 

> 
> >> 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)."

> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid