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

Paul Kyzivat <paul.kyzivat@comcast.net> Wed, 11 January 2017 15:09 UTC

Return-Path: <paul.kyzivat@comcast.net>
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 A21F612940D for <insipid@ietfa.amsl.com>; Wed, 11 Jan 2017 07:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 WOqBarSwC2ow for <insipid@ietfa.amsl.com>; Wed, 11 Jan 2017 07:09:23 -0800 (PST)
Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 33CA5129468 for <insipid@ietf.org>; Wed, 11 Jan 2017 07:09:23 -0800 (PST)
Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-10v.sys.comcast.net with SMTP id RKWTcDd5MkJTyRKWfccrUf; Wed, 11 Jan 2017 15:09:21 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484147361; bh=oj5JLp11nFSdcNylfy4vDaeLTgJfwEgnXjqiTAD1/fU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=JvXxVWWtIxLuLNKkj68tMgqcWKk7dNA1B9cL3WXkz+J++4rc4JldJVLAkpoTYvhri SYHPUkQP3trMAqifmnChTsFY6bm8CtxA2VSNF7nn0g+Mkrwg7hdosasViCDEfBZ6TF S1qNhbCfpbxpJ+FE6rL3a714dzf8QvNmVSuczfY8CjiT81RxiWTrBjSDqjpA+ptZMr rEibtUwHys5qECenlbJFXRWJOfb/WsY6szpUFnNbjW/zcYfjQ5rVkgEtjst+kaN8OX pzSm8ajYiySkBPzPyhPGINlKQ6eVN4tX+aLIGnRw0rgl+VkGoB0XKpHDzu9PB/jNZ8 lXzS8xwV/Ignw==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-19v.sys.comcast.net with SMTP id RKWecz0bMYZITRKWfcLW6x; Wed, 11 Jan 2017 15:09:21 +0000
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "insipid@ietf.org" <insipid@ietf.org>
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>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net>
Date: Wed, 11 Jan 2017 10:09:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4DE76@VOEXM31W.internal.vodafone.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfFZJnkLlJkenEMoBPbGq0otGfJxugPz9nn7vLOk5TwALAb27yZOqbMNwM3BZyb/UI/zhC0TX4Ta1L6YvpYTkPN/Aq3+d5kg22rJ0fmoCTYfEIzChs/He TmBP0aTLGkfH37XPU+rpbX9zqWV0yus5DFUD9750dn2TQpGGJ3uplN6hW+doGJLk1+/gJfc5ob6PkwomLSmzBF56uzQqr2OAzFg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/UQa2rUAnW2JhCDURfIJ_kA4V4kY>
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 15:09:25 -0000

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