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

["Ben Campbell" <[e-mail]>]

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.