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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Mon, 16 January 2017 19:24 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 A2BDB129413 for <insipid@ietfa.amsl.com>; Mon, 16 Jan 2017 11:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.055
X-Spam-Level:
X-Spam-Status: No, score=-3.055 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] 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 uO26S8ZiUHw9 for <insipid@ietfa.amsl.com>; Mon, 16 Jan 2017 11:24:36 -0800 (PST)
Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.114]) (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 C614812961F for <insipid@ietf.org>; Mon, 16 Jan 2017 11:24:35 -0800 (PST)
Received: from [193.109.254.3] by server-10.bemta-6.messagelabs.com id 19/DC-13192-1FD1D785; Mon, 16 Jan 2017 19:24:33 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRWlGSWpSXmKPExsVy+MUXQ92PsrU RBjdO8FnMneJnMf/+MyaLBz962RyYPab83sjqMfnxHEaPJUt+MgUwR7Fm5iXlVySwZjT3XmIp WONWMe0rSwPjFssuRi4OIYHtjBIr1m1nhHAOM0o0XLjHBOEcYZT48LyLFcKZC1R28B1bFyMHB 5uAvcSMPTFdjJwcIgLBElseLmUHsZkFHCXurfnGCGILA9m7jxxmgahxklh0ZBs7hB0l8fX7Vm aQMSwCqhK33oKV8AqESrRsA7FBVp1iluhp2A02hxNo1ePfs8BsRgFZiS+Nq5khdolL3Hoynwn ElhAQkFiy5zwzhC0q8fLxP1aIGh2JBbs/sUHY2hLLFr5mhlgmKHFy5hOwxUJAN/xbuYhpAqPY LCRjZyFpn4WkfRaS9gWMLKsY1YtTi8pSi3Qt9ZKKMtMzSnITM3N0DQ3M9HJTi4sT01NzEpOK9 ZLzczcxAqONAQh2MN7dFHCIUZKDSUmU94ZQbYQQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCd45Mk A5waLU9NSKtMwcYNzDpCU4eJREeAtA0rzFBYm5xZnpEKlTjIpS4ryvQRICIImM0jy4NliqucQ oKyXMywh0iBBPQWpRbmYJqvwrRnEORiVh3o0gU3gy80rgpr8CWswEtPi6TjXI4pJEhJRUA+Py C7UckyaY3lLz6v9pohBVd/D1HTHhqOcp55r+3zt6pSDjhv41dUFvA4Gj67k3MaherJnjvfvyZ fNMw+r0Xxt/bZa1Nv/r46h64USRBK/rgbzO0zcuu8SdNjl86cbzrI+WMlXC8vlvUldbCDcKrL 3uP8l5xgpLw3DJYx/UVZUk5jqxKjEveqTEUpyRaKjFXFScCAAgVGSFMAMAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-3.tower-184.messagelabs.com!1484594672!95993341!2
X-Originating-IP: [195.232.244.49]
X-StarScan-Received:
X-StarScan-Version: 9.1.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26468 invoked from network); 16 Jan 2017 19:24:33 -0000
Received: from msedge4.vodafone.com (HELO voxe04hw.internal.vodafone.com) (195.232.244.49) by server-3.tower-184.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 16 Jan 2017 19:24:33 -0000
Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 16 Jan 2017 20:24:32 +0100
Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 16 Jan 2017 20:24:32 +0100
Received: from VOEXC27W.internal.vodafone.com (145.230.103.199) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 16 Jan 2017 20:24:32 +0100
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc27w ([145.230.103.199]) with mapi id 14.03.0294.000; Mon, 16 Jan 2017 20:24:31 +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: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0AgAAen4CAASfu4IAAQi0AgAF0fZCAAFFyAIAGI0zw
Date: Mon, 16 Jan 2017 19:24:30 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C53766@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> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4F3C1@VOEXM31W.internal.vodafone.com> <3ae55eb1-4de4-0d8d-8c28-d0888c59615d@comcast.net>
In-Reply-To: <3ae55eb1-4de4-0d8d-8c28-d0888c59615d@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/4YM-gcLfDgj2VFF7FRTDJRGiEyc>
Cc: "Gonzalo Salgueiro \(gsalguei@cisco.com\)" <gsalguei@cisco.com>
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: Mon, 16 Jan 2017 19:24:38 -0000

Hello All,
A new version (-12) of logme-reqs is uploaded to https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/  containing the revisions listed below resulting from the latest reviews and discussion. 

For the review comment
"It seems that different implications on security and network behavior were considered, although some of them are not explicitly mentioned - such as the potential overload or DoS attacks in case of mis-configuration or malicious configuration of a big number of terminals in a SIP network leading to simultaneous activation of debug modes. It may be good to explicitly mentions these, but otherwise this document is READY from an OPS-DIR perspective." 
It seems to us that describing mitigation of any particular attacks fits better in the solutions draft (the requirements draft has the basic consideration "maliciously adding a "log me" marker MUST NOT adversely affect a network"). Our proposal is therefore to not make any related changes in this draft, but to forward this comment to be resolved as part of developing the solution.

Thanks again to the reviewers and commenters for taking time to check the draft and provide corrections and improvements,
Peter and Arun (co-authors)

-12: January 2017
   Moved the following text  from section 6.2.1 to become REQ12 in section 5.3: "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."
   Added text in brackets to clarify what "incorrectly inserted" means: "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)."
   Capitalized the word "must" in the text "All log retrieval mechanisms MUST adhere to authorization and privacy protection policies set forth by the network administrator."
   Changed "SHOULD" to "MUST" in the following text at the start of section 6.1 "Since a "log me" marker may cause a SIP entity to log the SIP header and body of a request or response, the "log me" marker MUST be removed at a trust domain boundary." 
   Revised REQ3 from 
   REQ3: It MUST be possible to mark a SIP request or response as of interest for logging by inserting a "log me" marker.  This is known as "log me" marking. 
   to 
   REQ3: It MUST be possible to mark a SIP request or response to be considered for logging by inserting a "log me" marker. This is known as "log me" marking.
   In section 3.1, expanded the first use of "SBC" to "Session Border Controller (SBC)".
   Expanded the first use of "UA" to "User Agent" (in REQ9).
   Simplified the wording of section 3.1 paragraph 2 from
   "[RFC5853] gives examples of manipulating signaling to prevent the sending network passing on sensitive information, for example topology hiding, or the receiving network protecting itself from signaling that is not under its control, for example  protocol repair. Example SIP device types (see [RFC7092]) that might manipulate signaling at a network boundary are a Session Border Controller performing protocol repair or Interconnection Border Control Function (IBCF) performing topology hiding."
   to
   "Topology hiding and protocol repair (see [RFC5853]) are two common functions that manipulate signaling at the network boundary. These functions are performed by SIP device types  (see [RFC7092]) such as Session Border Controller and Interconnection Border Control Function (IBCF)."


> -----Original Message-----
> From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net]
> Sent: 12 January 2017 18:14
> To: Dawes, Peter, Vodafone Group; insipid@ietf.org
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
> 
> 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
> >>
> >
> >