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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Authors: Perhaps have a look at the Security Considerations section of RFC 6872 and 6873 as preparation for questions that may arise regarding storage, transport, privacy, securing, etc of logged material.

-G


> On Dec 21, 2016, at 4:27 PM, Ben Campbell <[e-mail]> wrote:
> 
> Thanks! I think this version is ready for IETF Last Call.
> 
> One thing to consider (in parallel to the last call) is if you want to say anything about log minimization for privacy purposes. For example, is it always necessary to log the entire SIP message? are there use cases where one might log a subset, to avoid logging of information not necessary for the purpose? As written, the requirements don't seem to allow that--should they?
> 
> I mention this because I expect it to come up either during the LC or IESG evaluation. It might help to have already thought about that if it does. (Again, I don't think this need block the last call.)
> 
> Thanks!
> 
> Ben.
> 
> On 15 Dec 2016, at 7:54, Dawes, Peter, Vodafone Group wrote:
> 
> Hi Ben,
> The new version of logme-reqs is uploaded as https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-11.txt. The complete list of revisions resulting from your review and the subsequent discussion is below. Most of the changes to requirements text have been made in order to remove SIP entity behaviour descriptions from the requirements draft so that they can be moved to the solutions draft.
>  
> Thanks,
> Peter and Arun (co-authors)
>  
> -11: December 2016
>    In "2.  Conventions Used in this Document" added the following clarification: ", except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log-me" marker solution."
>    In "4.3.  Example Debugging Procedure" added the following text to the third bullet: ".  For some scenarios, such as call transfer, related dialogs may also be marked with "log me" marker."
>    Revised REQ1 from
>       "REQ1: The entire SIP message (SIP headers and message body) MUST
>       be logged using the SIP CLF format defined in [RFC6873], with
>       Vendor-ID = 00000000 and Tag = 02 in the <OptionalFields> portion
>       of the SIP CLF record (see [RFC6873] clause 4.4)."
>       to
>       "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 defined in [RFC6873]."
>    Added the following text to the end of the paragraph below REQ2: "All log retrieval mechanisms must adhere to authorization and privacy protection policies set forth by the network administrator."
>    In REQ5, deleted the words "by the debugging server to " from "The test case identifier does not have any impact on
>       session setup, it is used by the debugging server to collate all logged SIP requests and responses to the initial SIP request in a dialog or standalone transaction." because log retrieval is out of scope.
>    Revised REQ6 from
>       "REQ6: A "log me" marker is most effective if it passes 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
>       will not use.  A "log me" marker SHOULD be removed at trust domain
>       boundaries."
>    to
>       "REQ6: A "log me" marker is most effective if all networks on the
>       signaling 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."
>    Revised REQ7 from
>       "REQ7: The presence of a "log me" marker indicates that a request
>       or response is part of debugging or regression testing.  SIP
>       entities that support "log me" marking SHOULD log SIP requests or
>       responses that contain a "log me" marker."  The SIP entity checks
>       for the presence of a "log me" marker and writes any request or
>       response that contains a "log me" marker to a log file."
>    to
>       "REQ7: The presence of a "log me" marker indicates that a request
>       or response is part of debugging or regression testing."
>    Revised REQ8 from
>       "REQ8: If a UA that supports "log me" marking receives a request
>       with a "log me" marker, it MUST echo that "log me" marker in
>       responses to that request.  This requirement applies to cases
>       where the UA is the endpoint of communication, where the UA is one
>       side of a gateway such as a SIP/PSTN gateway, and where the UA is
>       one side of a B2BUA."
>    to
>       "REQ8: It MUST be possible to insert a "log me" marker in SIP
>       responses that correspond to SIP requests with a "log me" marker
>       in order to ensure that the complete SIP transaction is logged.
>       This requirement applies to endpoints, SIP/PSTN gateways and
>       B2BUAs."
>    Revised REQ9 from
>       "REQ9: A SIP intermediary MAY insert a "log me" marker into
>       requests and responses.  The typical case for which a intermediary
>       needs to insert a "log me" marker is for compatibility with UAs
>       that have not implemented "log me" marking, i.e. when a UA has not
>       marked a request or when responses received on a dialog of
>       interest for logging do not contain an echoed "log me" marker.
>       Another use case is when the session origination UA that inserted
>       log me marker is no longer participating in the session (e.g.,
>       call transfer scenarios) and the intermediary adds "log me" marker
>       in related sessions to enable end-to-end signaling analysis.  In
>       these cases, the entity that inserts a "log me" marker is stateful
>       inasmuch as it must remember when a dialog is of interest for
>       logging.  An entity that inserts a "log me" marker SHOULD also log
>       the SIP request or response as per REQ4."
>    to
>       "REQ9: The "log me" marker mechanism SHOULD allow a SIP
>       intermediary to request logging SIP requests and responses on
>       behalf of the originating endpoint.  The typical use case for this
>       requirement is for compatibility with UAs that have not
>       implemented "log me" marking, i.e. when a UA has not marked a
>       request or when responses received on a dialog of interest for
>       logging do not contain an echoed "log me" marker.  Another use
>       case is when the session origination UA that inserted log me
>       marker is no longer participating in the session (e.g., call
>       transfer scenarios) and the intermediary adds "log me" marker in
>       related sessions to enable end-to-end signaling analysis."
>    Revised REQ10 from
>       "REQ10: SIP intermediaries MAY be stateless in terms of logging of
>       SIP requests that contain a "log me" marker, i.e. they MAY base
>       the decision to log a SIP request or response solely on the
>       presence of the "log me" marker.  For example, it is OPTIONAL for
>       a SIP entity to maintain state of which SIP requests contained a
>       "log me" marker in order to log responses to those requests.
>       Echoing a "log me" marker in responses is the responsibility of
>       the UA that receives a request."
>    to
>       "REQ10: The mechanism MUST allow stateless processing of SIP
>       requests that contain a "log me" marker by SIP intermediaries.
>       This requirement enables the SIP intermediaries to base the
>       decision to log a SIP request or response solely on the presence
>       of the "log me" marker."
>    Revised REQ11 from
>       "REQ11: "log me" marking of requests and responses MUST be applied
>       on a per-dialog granularity.  If applied, "log me" marking MUST
>       begin with the dialog-creating request and SHOULD continue to the
>       dialog end. "log me" marking SHOULD be applied to in-dialog
>       requests and responses in either direction. "log me" marking MUST
>       NOT be stopped and re-started on a given dialog."
>    to
>       "REQ11: The scope of SIP message logging request includes all
>       requests and responses within a given dialog.  The scope can be
>       extended to related dialogs that correspond to an end-to-end
>       session for scenarios discussed in REQ9.  The "log me" request
>       MUST be indicated at the beginning of the dialog of interest and
>       SHOULD continue to the dialog end without any stop and restart
>       during the duration of the dialog."
>    In section 6.2.1 "Log Me" Marking, added the following text to the end of the first paragraph: "The "log me" marker MUST
>    NOT reveal any information related to any SIP user or device."
>    In section 6.2.1 "Log Me" Marking, added a new second paragraph as follows:
>       "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."
>    In section 6.2.1 "Log Me" Marking, revised the final paragraph from
>       "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."
>    to
>       "Activating a debug mode affects the operation of a terminal,
>       therefore debugging configuration MUST be supplied by an authorized
>       party to an authorized terminal through a secure communication
>       channel."
>    In section 6.2.1 "Log Me" Marking, moved the final paragraph "Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party." to replace the text in section 6.2.2 "Logged Information"
>  
>  
> From: Arun Arunachalam (carunach) [mailto:[e-mail]] 
> Sent: 13 December 2016 12:15
> To: Ben Campbell
> Cc: Dawes, Peter, Vodafone Group; [e-mail]; Gonzalo Salgueiro (gsalguei); [e-mail]; DOLLY, MARTIN C; Arun Arunachalam (carunach)
> Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
>  
> Thanks Ben !
>  
> We will submit the new version soon.
>  
> Thanks!
> Arun
>  
> On Dec 12, 2016, at 5:34 PM, Ben Campbell <[e-mail]> wrote:
>  
> Hi,
> All of your responses look reasonable, pending seeing them in the context of the document. Please submit the new version when you are ready.
> Thanks!
> Ben.
> On 9 Dec 2016, at 10:58, Dawes, Peter, Vodafone Group wrote:
> Hello Ben,
> Thanks for your comments and guidance, our responses below.
>  
> Regarding " 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."
> Below we have suggested moving some of the requirements draft text to the solutions draft, based on your feedback. With these revisions, the requirements draft covers only the requirements of the log-me mechanism. Specifically, the requirements draft will document “what” are the requirements and “why” is it a requirement. Details about “how” the requirements are implemented in the network element are moved to the solution draft.
>  
> Regarding " 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?"
> We would expect an implementor to read both. The requirements draft gives a high-level understanding of the motivating scenario, concept definitions (e.g. network boundary), and the requirements themselves. The solution draft then defines the protocol mechanism details. This top down approach of understanding the problem being solved and the concepts around it before implementing a solution seems natural to us.
> Also, the working group has been following this top down approach for quite a while as can been seen from the decisions below from 2013 and 2014. We hope that the IESG will understand that the group worked for a long time on acceptable requirements and that it is valuable to freeze them now and publish them as a reference that explains and scopes the problem and defines the target for the solution to fulfil.
> During IETF 87, Berlin, 2013 the meeting notes (https://mailarchive.ietf.org/arch/msg/insipid/08l7_9vrzRlmV0qGkgDxDrBi8Ig) say " Log-me requirements: Alternatives to LogMe draft should be submitted in following weeks. Solution draft will come later."
> Then at IETF 88, Vancouver, 2013, it is noted (https://www.ietf.org/proceedings/88/minutes/minutes-88-insipid) that "Proposal is to remove the solution text in the current version and adopt the requirements part as WG draft.- Paul K: Had a bunch of comments.  Not sure the subset of requirements is ready to be adopted. There is still a bunch of trust issues with storing the log.- Gonzalo S: Solution discussion has not even begun yet. This is purely the requirements we are talking about"
> And the working group milestones have been stable since February 2014 (https://mailarchive.ietf.org/arch/msg/insipid/vxRRrq_OxJyCWZDtHD25U32chCo):
> "Changed milestone "Requirements for marking SIP sessions for logging to IESG (Informational)", set due date to September 2014 from June 2014.
> Changed milestone "Protocol for marking SIP sessions for logging to IESG (Proposed Standard)", set due date to December 2014 from November 2014."
>  
> Regarding REQ1, REQ6, REQ7, REQ8, REQ9, REQ10, REQ11, these have been revised along the lines of your feedback and the new wording is shown below.
> REQ6: A "log me" marker is most effective if all networks on the signaling 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.
>  
> REQ7: The presence of a "log me" marker indicates that a request or response is part of debugging or regression testing.  SIP entities that support "log me" marking SHOULD log SIP requests or responses that contain a "log me" marker." 
>  
> REQ8: It MUST be possible to insert “log me” marker in SIP responses that correspond to SIP requests with “log me” marker in order to ensure that the complete SIP transaction is logged. This requirement applies to endpoints, SIP/PSTN gateways and B2BUAs.
>  
> REQ9: The “log me” marker mechanism SHOULD allow a SIP intermediary to request logging SIP requests and responses on behalf of the originating endpoint. The typical use case for this requirement is for compatibility with UAs that have not implemented "log me" marking, i.e. when a UA has not marked a request or when responses received on a dialog of interest for logging do not contain an echoed "log me" marker. Another use case is when the session origination UA that inserted log me marker is no longer participating in the session (e.g., call transfer scenarios) and the intermediary adds "log me" marker in related sessions to enable end-to-end signaling analysis.
>  
> REQ10: The mechanism MUST allow stateless processing of SIP requests that contain a “log me” marker by SIP intermediaries. This requirement enables the SIP intermediaries to base the decision to log a SIP request or response solely on the presence of the "log me" marker.
> REQ11: The scope of SIP message logging request includes all requests and responses within a given dialog. The scope can be extended to related dialogs that correspond to an end-to-end session for scenarios discussed in REQ9. The “log me” request MUST be indicated at the beginning of the dialog of interest and SHOULD continue to the dialog end without any stop and restart during the duration of the dialog.
>  
> We can revise the paragraph on RFC2119 language as per your feedback.
> “2. Conventions Used in this Document
> 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], , except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log-me" marker solution."
>  
> Regarding “4.3, third bullet: 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?”
> In 4.3 "Example Debugging Procedure", the third bullet can be extended in order to not exclude scenarios such as call transfer.
> Subsequent responses and requests in the same dialog are also marked with a "log me" marker. For some scenarios, such as call transfer, related dialogs may also be marked with "log me" marker.
>  
> Regarding "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." We propose the following additional sentence at the end of the paragraph after REQ2 in 5.1 "Message Logs":
> When and how signaling logs are retrieved is out of scope of this document.  Logs might be retrieved by logging on to the SIP entity that contains the logs, by sending logs to a central server that is co-ordinating debugging, by storing them on removable media for later manual collection, or by some other method. All log retrieval mechanisms must adhere to authorization and privacy protection policies set forth by the network administrator.
>  
> Regarding " On reflection, can you meet the intended use cases without identifying a device or user?"
> We believe that we can meet the intended use cases without using the device or user. Neither the session-ID nor the log-me marker contain any user specific or device specific information.
>  
> Regarding "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?"
> Configuration interface is not in-scope for this draft. “in-transit” was referencing to the data path through which configuration is sent. To keep things simple, we can reword the sentence to use “secure communication channel” as follows:
> Section 6.2.1
> change third paragraph from:
> "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."
> to:
> "Activating a debug mode affects the operation of a terminal, therefore debugging configuration MUST be supplied by an authorized party to an authorized terminal through a secure communication channel."
>  
> Regarding " 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."
> This should be covered in our previous e-mail response by moving the last paragraph of 6.2.1 " "Log Me" Marking" to replace the paragraph in 6.2.2 "Logged Information". In this way, the text applies only to the logged information itself, not its retrieval (in response to our last e-mail, you indicated that you are OK with removing the redundancy in 6.2.1 in this way). Section 6.2.2 then becomes:
> "6.2.2.  Logged Information
> Logged signaling is privacy-sensitive data, therefore signaling logs MUST NOT be readable by an unauthorized third party."
>  
>  
> We plan to post a new revision of the logme-reqs draft when all of your comments are resolved.
>  
> Thanks again,
> Arun and Peter (co-authors)
>  
> From: DOLLY, MARTIN C [mailto:[e-mail]] 
> Sent: 24 November 2016 02:20
> To: Ben Campbell
> Cc: Dawes, Peter, Vodafone Group; Arun Arunachalam; [e-mail]; Gonzalo Salgueiro; [e-mail]
> Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
>  
> Longer than most of my short answers 
> Initially meant in controlled deployments 
>  
> Maybe SIP or now the world version of SiP being done in 3GPP.
>  
> Not IETF. In would have been interoperable
>  
> Sorry
> Martin C. Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: +1.609.903.3360
> Email: [e-mail]
>  
> 
> On Nov 23, 2016, at 9:02 PM, Ben Campbell <[e-mail]> wrote:
> 
> I'm not sure I follow you, but I assume you either mean either that you like version 10 the way it is, or you like some component of it better than my suggestion.
> 
> Please note that my proposals on requirements language, which I think are the most material suggestions, are contingent on the answers to some of my earlier questions about how the behavior definition is divided between this and the solution draft.
> 
> Ben.
> 
> On 23 Nov 2016, at 19:08, DOLLY, MARTIN C wrote:
> 
> 
> 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
>