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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

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:[e-mail]]
> Sent: 12 January 2017 18:14
> To: Dawes, Peter, Vodafone Group; [e-mail]
> 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:[e-mail]]
> >> Sent: 11 January 2017 15:09
> >> To: Dawes, Peter, Vodafone Group; [e-mail]
> >> 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:[e-mail]] On Behalf Of Paul
> >>>> Kyzivat
> >>>> Sent: 10 January 2017 17:33
> >>>> To: [e-mail]
> >>>> 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
> >>
> >
> >