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

From: Sean Turner <[email-masked]>
Date: Fri, 06 Jan 2017 18:56:33 -0800

Reviewer: Sean Turner
Review result: Has Nits

After getting over my initial reaction that was something like
"srsly!? we're going to standardize the exact opposite of 'do not
track'", I realized that this is a requirements draft for an IETF
approved WG and a chartered work item of that WG :)

0) s3.2: Is the intent to define a protocol mechanism to determine if
the two or domains are part of the same trust domain?  This
requirement could be achieved by saying out-of-band bilateral
agreements are the mechanism to establish the domain.

1) s5.1: REQ1 - Did you mean to say "using SIP standard logging
format"?  Is there another logging format other than SIP CLF?

2) s5.1: Should the must be MUST in the following:

  All log retrieval mechanisms must adhere to
  authorization and privacy protection policies
  set forth by the network administrator.

3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing? 
I mean if SIP doesn't allow adding new headers then didn't somebody
sink your battleship?  But SIP does allow you to add arbitrary headers
so I think I'm missing something as to why this is needed?

4) s5.2: REQ3 - Reads a bit awkward to me how about:

  It MUST be possible to mark a SIP request or response for
  logging by inserting a "log me" marker.

i.e., remove "of interest"

5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are
there fields that SIP requires be stripped?

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?

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Tue, 10 Jan 2017 14:51:09 +0000

Hello Sean,
Thanks very much for your review, some proposals and answers from the co-authors inline below to cover the points raised.

Best regards,
Peter

> -----Original Message-----
> From: insipid [mailto:[email-masked]] On Behalf Of Sean Turner
> Sent: 07 January 2017 02:57
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
> 
> Reviewer: Sean Turner
> Review result: Has Nits
> 
> After getting over my initial reaction that was something like "srsly!? we're
> going to standardize the exact opposite of 'do not track'", I realized that this
> is a requirements draft for an IETF approved WG and a chartered work item
> of that WG :)
> 
> 0) s3.2: Is the intent to define a protocol mechanism to determine if the two
> or domains are part of the same trust domain?  This requirement could be
> achieved by saying out-of-band bilateral agreements are the mechanism to
> establish the domain.

There is no intent to define a protocol mechanism to determine if two or
more domains are part of the same trust domain. s3.2 explains the meaning
of the term "trust domain" as it is used in this draft because the term "trust
domain" does not have a fixed meaning throughout its use in RFCs. RFC 3324
section 2.3 defines "trust domain" for network asserted identity and this
definition is re-used by RFC 7316 for a private network indicator. "Trust
domain" is used without definition in RFC6404. So we define the term " trust
domain" as it applies to log-me marking.

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

>   set forth by the network administrator.

This "must" was left lower case as retrieval itself is out of scope, but we think
capitalizing MUST would be consistent with the rest of the draft so we
can do that. Although this MUST does not impact interoperability, we
extended the use of MUST beyond interoperability required to satisfy RFC
2119 as a result of a comment from area director Ben Campbell.

> I mean if SIP doesn't allow adding new headers then didn't somebody sink
> your battleship?  But SIP does allow you to add arbitrary headers so I think
> I'm missing something as to why this is needed?

The purpose of REQ3 is to make it clear that the solution needs a new
protocol element, i.e. "log me" marking cannot be done using existing SIP.
The text says: "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. "

> i.e., remove "of interest"

We can see your point. The purpose of the words "of interest" is to avoid
suggesting that marking requests and responses forces them to be logged.
The decision of whether to honour the log-me marking is largely left to the
admin policy (e.g. s6.2.1 says " The presence of a "log me" marker
might cause some SIP entities to log signaling.") but "log me" marking is not
expected to force logging in all cases.
 
The following revision of REQ3 would clarify:
REQ3: It MUST be possible to mark a SIP request or response to be considered for logging by inserting a "log me" marker.

> 
> 5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are there fields
> that SIP requires be stripped?

The purpose of REQ4 (It MUST be possible for a "log me" marker to cross
network boundaries.) is to ensure that the log me marker is not defined in a
way that will very probably cause it to be removed by real-world networks
such as described earlier in the draft in s3.1 ("A  network boundary is
significant in this document because manipulation of signaling at the
boundary could prevent end-to-end testing or troubleshooting. "). Also,
some protocol elements might change at a network boundary, for example
an outgoing network boundary may obfuscate some fields, or an incoming
network boundary might translate the request URI from a public identity to
one that is private to that network.

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

> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jan 2017 12:33:19 -0500

I have a couple of comments:

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

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

	Thanks,
	Paul

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 11 Jan 2017 10:39:30 +0000

Hello Paul,
Thanks for the comments, replies inline.

Regards,
Peter

> From: insipid [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 10 January 2017 17:33
> To: [email-masked]
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
> 
> > 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.
> 
> 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."
> 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?
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jan 2017 10:09:20 -0500

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

>    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

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 12 Jan 2017 12:41:09 +0000

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. 

Regards,
Peter

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 11 January 2017 15:09
> To: Dawes, Peter, Vodafone Group; [email-masked]
> >> IIUC, the mechanism for retrieval of the logs is out of scope for
> >> this document and the corresponding mechanism document. So why is
> the
> > 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
> 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.
> 
> >> some SIP entities to log signaling.  Therefore, this marker MUST be
> >> removed at the earliest opportunity if it has been incorrectly inserted."
> >> 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
> >    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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jan 2017 13:14:02 -0500

> 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" sol…

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

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Mon, 16 Jan 2017 19:24:30 +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)."

> Sent: 12 January 2017 18:14
> > 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.
> 
> 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.
> 
> >> 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.
> >>
> >> (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.
> >>
> >>>>>> considerations that requires the this marker MUST be removed at
> >>>>>> the earliest opportunity if it has been 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
> >> 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.