Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

["DOLLY, MARTIN C" <[e-mail]>]

Ben

The initial proposal was easier

UGH

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:[phone]>
Email: [e-mail]<mailto:[e-mail]>


On Nov 23, 2016, at 7:34 PM, Ben Campbell <[e-mail]<mailto:[e-mail]>> wrote:

Hi, thanks for the response. Comments inline.

Ben.

On 23 Nov 2016, at 8:59, Dawes, Peter, Vodafone Group wrote:

Hello Ben,
Thanks very much for your initial AD evaluation of draft-ietf-insipid-logme-reqs-10, below is our response. The review was long so we used some XML-style tags to structure the response according to your major and minor concerns.

Regards,
Peter and Arun (co-authors)

<major-issue-1>
- What is the archival value for this draft after the mechanism is complete? Is there really a reason to publish it as an RFC? Could the info here be stored in the working group wiki, included in the solution draft, or even allowed to expire once the mechanism is complete? I contrast this to the session-id requirements document, since that explored the details of some tricky concepts (such as "session".) It's not clear to me that this draft does the same. I also note that logme-marking already seems to replicate a good deal of this draft, and seems to dive even deeper into use cases, and in some areas seems to have moved beyond the requirements in this draft.
I ask because the question is likely to come up in IESG review, and also because the publication process creates a lot of effort for the working group, RFC editor, reviewers, etc.
</major-issue-1>

<reply-1>
The primary objective of a requirements draft is to provide clarity on the complete list of requirements that a proposed solution needs to satisfy for a given problem. In our logging and troubleshooting scenarios, the requirements list has been identified through discussions and consensus among INSIPID working group members.

That's my understanding of what a requirements draft typically does. But this draft seems to also put requirements on behavior, which seem like protocol requirements to me. So as written, it seems like protocol/behavior requirements are either spread or repeated between the requirements and solution draft. This seems to make life harder than necessary for the implementer.

There are other reasonable work divisions, for example you might have an requirements + architecture draft and a separate solution draft, or you might have a SIP element behavior draft and a data format draft, etc.



In this draft, we have clearly documented the requirements from the perspective of:
-    When the logging is started and stopped
-    Passing the log-me marker across SIP entities
-    Privacy considerations

These are all reasonable categories. My concern is how things are divided between this and the solution draft within those categories. For example, a requirement of the form of "The logging indication must be able to be sent across B2BUAs" vs "A B2BUA must copy the <foo> parameter".



The solution document will provide insights into the "how" details. These two documents help a network developer, administrator and support engineer to understand the guiding requirements upon which the solution will be built.

Once the solution _is_ built, do they still need that?

More to the point: Do you expect an implementor to have to read both this draft and the solutions draft to properly implement the mechanism? If so, then can you clarify the distinction of what would go in this draft vs that one? For example, since this draft directly states requirements on SIP network element behavior would you expect the solution draft to also do that? If not, what sorts of behavior go here?

I'm pushing on this point because I expect them to come up during the IESG review. (Please see the recent IESG statement on support documents: https://mailarchive.ietf.org/arch/msg/ietf-announce/EZi3owksw9TT6ym5ZbONHnv-Yl4


Looking at the main parts, clause 4 gives a generalized network scenario where log-me marking is needed to make testing practical, which allows an implementer to determine whether the solution is useful to them. Clause 5 summarizes the functional requirements in three categories: the logged information, the marker itself, and SIP entity behaviour to read/write/update/delete the marker, Also, clause 3 introduces definitions at a network architecture and business layer which, it seems to us, more naturally belong with a description of requirements than with protocol.
We agree that the requirements and the solution should overlap as little as possible and expect that some of the solution draft can be removed now that the requirements document is clear. The solution document can confine itself to the protocol elements and detailed procedures only.

</reply-1>


<major-issue-2>
The purpose of the draft is not clear to me. I understand it to be requirements for the creation of a protocol mechanism; that is, that it would describe the features of the mechanism, but not the details of how the mechanism works. But many of the requirements seem like requirements on the behavior of network elements (that is, mechanism details). If this draft is to be published as an RFC, I think quite a number of them will need to be rethought. Details in the minor concerns section.

- 5.1, REQ1: This seems more like mechanism than a requirement against the mechanism, in that it states a requirement for specific network element behavior. Isn't the real requirement something along the lines of "The mechanism must allow the endpoint to indicate that it wishes the entire message to be logged"?
Also the MUST seems misplaced as stated; do elements have the option not to log? That seems to be in conflict with typical privacy requirements that suggest log minimization.
also...
- 5.3: Req6 is confusing as worded. It starts off saying things work best if the marker goes end to end, then says not to send it end to end. Please explain why the "responsible" behavior goes against the first sentence. (I think we can all infer the reasoning, but it's better to be explicit.)

-- Req7: This seems like mechanism, not requirements for a mechanism. It stated normative requirements on the behavior of a network element. It seems like that belongs in the mechanism document.

-- Req8: Same as last comment.
also...
-- Req10: Again, this seems like mechanism. I would expect a requirement to say something like "The mechanism must allow for stateless operation."

-- Req11: Mechanism again. I would expect a requirement to be of the form of " a log me indication applies for the duration of a dialog (or a session?).
</major-issue-2>

<reply-2>
If the requirements draft is thought of as a place where key decisions about the mechanism are captured then we think it is broadly consistent except for REQ1, even if some requirements look like part of the protocol solution. Looking at each requirement highlighted in "minor concerns":

REQ1 captures the decision regarding the format of logged information. We agree that it is too detailed and specific for a requirements document. We can move it to the solutions document and also describe what "logged information" looks like including such things as how the "test identifier" appears in the logged information. Also, the word MUST mandates the given format of information, it does not mandate the logging itself. We propose REQ1 be re-worded as:

"REQ1: If a SIP message is logged then the entire SIP message (SIP headers and message body) MUST be logged using standard logging format such as SIP CLF."

That seems reasonable. (And it would even be reasonable to mandate that CLF be used, as in the original version.


REQ6 could be re-worded as follows: " REQ6: A "log me" marker is most effective if all networks on the signalling path agree to pass it end-to-end. However, source networks should behave responsibly and not leave it to a downstream network to detect and remove a marker that it is not expecting. A "log me" marker SHOULD be removed at trust domain boundaries to ensure that message logging request is not passed to SIP entitles outside the trust domain. "

The first two sentences seem reasonable statements about mechanism requrements. The last sentence is a requirement on network element behavior.


We think the value of including REQ7, 8, 10, 11 in the requirements document is that it completes the picture of how SIP entities are impacted. However, we agree that REQ7, 8, 10 could be put into the solutions document. We think REQ11 belongs in the requirements documents because stating that a log begins when a dialog is created and ends when the dialog ends is an important decision that has implications on the details of the solution such as B2BUA behaviour, detecting log-me marking that should not be there (i.e. log-me marking starts to appear mid-dialog, and keeping log-me marking constrained.
</reply-2>

The first part of Req7 seems reasonable, but the last sentence seems like solution. Req 8 seems very much solution--I suspect you intend a requirement along the line of "The mechanism must correlate request and response log entries"?

Req9: Are you looking for something like "The mechanism SHOULD allow SIP intermediary to request logging on behalf of the originating endpoint"?

Req10: "The mechanism should allow stateless behavior for SIP intermediaries"?

Req11: "A logging request applies to all requests and responses in the dialog"?


<minor-issues-replies>
<RFC2119 language>
-2: The usage in this draft does not exactly match RFC2119.  That RFC is about interoperability, not compliance or requirements on a mechanism.
(That could be more clear in the definitions of the terms in 2119, but it's pretty clear in section 6.). That doesn't mean this draft cannot use 2119 terms, but please edit the boilerplate to describe how you really intend to use them. (I note that this draft does use some 2119 language as described in 2119, but that's what triggered my other comments about describing mechanism rather than requirements.

ANSWER) The point is understood, particularly for REQ9 for example. We can review these and edit the text in section 2 "Conventions Used in this Document" where necessary such as:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. They are used to describe mandatory, recommended and optional requirements to be satisfied by "log-me" marker solution.
</RFC2119 language>

How about something like the following for the last sentence": "..., except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log-me" marker solution."



<network boundary>
- 3.1, 2nd paragraph: Is this still part of the definition of network boundary?

ANSWER) no, but it follows on from the previous sentence "A network boundary is significant in this document because manipulation of signaling at the boundary could prevent end-to-end testing or troubleshooting" to explain why a network boundary is a defined concept in this requirements draft.
</network boundary>

Okay



<trust domain>
- 3.2: I assume the "trust domain" is specific to trust for logging purposes. I suggest "Logging trust domain" or "logging domain".

ANSWER) The term "trust domain" is used with the understanding that "trust domain" does not have a fixed meaning throughout all uses and 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. Before creating the term "logging trust domain" it would be good to be sure that we can't keep the term "trust domain" and define how it applies to log-me marking, it seems more elegant.
</trust domain>

On rereading the paragraph, I think it's okay.



<dialog>
- 4.3, third bullet: Is "dialog" the correct term here? Is this really limited to a dialog, or do you expect it to apply to the concept of a "session" as described in the session-ID doc?

ANSWER) Authors intend to say dialog.
</dialog>

Is there a requirement for correlating logs across related dialogs, similar to the way Session-ID does? This seems required in several places (e.g. Req9 mentions a transfer use case.) If so, it would be good to explicitly mention it. Stating the logging scope as a "dialog" without further comment on related dialogs could be construed to not require it.



<log retrieval policy>
- 5.1, third paragraph: Making policies about log retrieval out of scope seems unfortunate. This draft should have something to say about such policies in the form of privacy requirements on the mechanism. That doesn't mean this draft has to state the policies, but it can require the mechanism to discuss them. (Or can something be referenced from the CLF work?)

ANSWER) Can you please expand why it is unfortunate to not say when and how logs are retrieved. The security requirements say "Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party.", is this not enough?
</log retrieval policy>

>From your response, I assume the authors consider the "how and when" for log retrieval not to include things like authorization policies, protections against eves droppers, etc. I don't think all readers will make that distinction.

Would it make sense to say that the log retrieval mechanism is required to support certain authorization policies and privacy protections, but that otherwise the details are out of scope?



<REQ9>
-- Req9 seems to have privacy implications that need discussion somewhere. How would a user know logging was requested? Can a user override that?

ANSWER) We propose to add a paragraph (the second paragraph below) to clause 6.2.1 to clarify this point:

6.2.1.  "Log Me" Marking
  The "log me" marker MUST NOT convey any sensitive information,
  although the "log me" marker will sometimes be inserted because a
  particular device is experiencing problems.

  The insertion of "log me" marker at the endpoint MUST be approved
  by the end user or by the network administrator. Similarly, network
  administrator authorization is required for a SIP intermediary to
  insert a "log me" marker on behalf of an UA that does not support
  "log me" marking.

  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.

  Activating a debug mode affects the operation of a terminal,
  therefore debugging configuration MUST be supplied by an authorized
  party to an authorized terminal, debugging configuration MUST NOT be
  altered in transit, and MUST NOT be readable by an unauthorized third
  party.

  Logged signaling is privacy-sensitive data, therefore signaling logs
  MUST NOT be readable by an unauthorized third party.

</REQ9>
<identify-user>

That helps, thanks.



- 6.2.1: Would it make sense to say the marker must not contain information can be used to identify the uer or endpoint device, and that it must not be possible to correlate markers across multiple sessions?
If not, why not?

ANSWER) It would be fine for us to say that the marker must not contain information can be used to identify the user or endpoint device.
</identify-user>

On reflection, can you meet the intended use cases without identifying a device or user?



<modifying the marker>
-- Does the requirement that the marker must not be modified in transit imply that it must not be possible for it to be modified, or just that participating endpoints must not modify it?

ANSWER) Section 6.2.1 says that debugging configuration MUST NOT be altered in transit, it does not say anything about modifying a log-me marker. Perhaps it would be better if the requirements draft did not say anything configuring entities for logging.
</modifying the marker>

On re-reading the paragraph, I see you are correct. But I'm not clear on what that means. Does the "in transit" part and "readable by unauthorized party" part refer to whatever config interface is in use, not something sent in the SIP signaling? Are requirements on the configuration interface in-scope for this document?



<protecting-logs>
-- The requirement that logs not be readable by an unauthorized party seems to contradict the earlier statement that how and when logs are read is out of scope.

ANSWER) Section 5.1 says "When and how signaling logs are retrieved is out of scope of this document.", which refers to the act of copying or transferring logged information from the SIP entity that wrote them after logging has finished. The requirement that these logs not be readable by an unauthorized party is slightly different, e.g. perhaps they are encrypted, or perhaps a secure account is needed to log on to the entity that wrote the logged information. We can try to make this distinction stronger.
</protecting-logs>

See my previous comment.



<section-6.2.2>
- 6.2.2: The previous section stated this more strongly, so this section seems entirely redundant.

ANSWER) Agreed. Rather than deleting 6.2.2 we propose to move the last paragraph of 6.2.1 "Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party. " to replace the existing text in 6.2.2. In this way, the security section does not lose the distinction between the log-me marker and the logged information.
</section-6.2.2>

Works for me.

_______________________________________________
insipid mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/insipid