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

Paul Kyzivat <paul.kyzivat@comcast.net> Thu, 12 January 2017 18:14 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 6F52B129410 for <insipid@ietfa.amsl.com>; Thu, 12 Jan 2017 10:14:06 -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 1I8oBcAdcJyi for <insipid@ietfa.amsl.com>; Thu, 12 Jan 2017 10:14:04 -0800 (PST)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 7BE5612953A for <insipid@ietf.org>; Thu, 12 Jan 2017 10:14:04 -0800 (PST)
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-09v.sys.comcast.net with SMTP id Rjsbc467R5lLvRjsycVqwt; Thu, 12 Jan 2017 18:14:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484244844; bh=sbV+h28ec2lkKDZ6jhpgNr8bcJOver5N9PJ/xqwwp5k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=amZ1qyTRbZJx2asdo8jfP8CyFmHsWpakHADyE5QYsGBCZ//fBf+FI8TswgGxfgXs8 OXGhCWb49ozL1DCX8conHn3WYzseMzgtrm/s8U/GMGPzuNzLbVWD+sz9x0aM3rOggy K4a/tqTLkFy6NVFir/T4QwQdjT55gwaT3qRnKHecK1MvWu3PiufhGkzKW8Hn7mcXhJ V43echLws+L6r611y6JJpIUcuVwXEyY513W5wH8SPHv9NHVZcMGFBepxOUFqNgY/IB nAUD+aD/LpcUg5GwOMUILUW6e+yC6An07hFEMVVfJOmkKIMSDBI07Hgi1s0yFlveIF 9335XQDgrJUyA==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-18v.sys.comcast.net with SMTP id RjswccI0b9HUeRjsxccpc0; Thu, 12 Jan 2017 18:14:04 +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> <72176fdd-f0da-cece-f8a9-6ee4c392f3bd@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <3ae55eb1-4de4-0d8d-8c28-d0888c59615d@comcast.net>
Date: Thu, 12 Jan 2017 13:14:02 -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: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfMyssnkxi/JuLyg/tXfyk1SD042C3DvCCcVprVMw7JPJrceo1DEkdYC3vdnd6nXaYUqVIfbyaoQXDWaQI1wGiuTiTDrswzjYXSR3koaRW9YSOez/XXqT n8sCitgTbUM5fhpG3ELRm7mx2o+BWx+CJkhky3D0vAm93koWc5+uh4i7UK21cIBlKEcAq2RBO3MhTud/iz4ipqbqOkA4fFTlhYY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/4Ol-DbImcLbKZG2lVxiprEGQTFI>
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 18:14:07 -0000

On 1/12/17 7:41 AM, Dawes, Peter, Vodafone Group wrote:
> 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.

I remain unconvinced that this requirement belongs in the document.
For one thing, there is no way to verify compliance.
For another, there could be good reasons to use another format, as long 
as CLF format can be generated if/when needed. For instance, somebody 
might find it convenient to capture in wireshark format.

But I don't consider this a big deal, so I won't press the issue further.

	Thanks,
	Paul

> 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
>>
>
>