Marking SIP Messages to Be Logged
RFC 8497

Received changes through RFC Editor sync (changed abstract to 'SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.

This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.')

Received changes through RFC Editor sync (created alias RFC 8497, changed title to 'Marking SIP Messages to Be Logged', changed abstract to 'SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.', changed pages to 46, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-11-27, changed IESG state to RFC Published)

[Ballot comment]
Thanks for adding some text here. I'm still concerned that there are headers that are sensitive and will still be logged, and I think it's unwise not to have a real analysis.  However, I also recognize that this analysis isn't going to happen.

[Ballot comment]
Similar to Benjamin, I am uneasy about this document and dual use of this mechanism. I think the advice it gives for an attacker is to inject the "log me" attribute at the beginning of a session that is of interest, closer to the originator ;-).

Also one small nit:

In Section 1:

  This document defines a new header field parameter "logme" for the
  "Session-ID" header field [RFC7989].  Implementations of this
  document MUST implement session identity.

Is "session identity" defined in RFC 7989? RFC 7989 doesn't use the term "session identity" anywhere.
If you mean that in order to support this extension one needs to implement support for the Session-ID header field
I suggest you rephrase the 2nd sentence to say something like this:

  Implementations of this document MUST implement [RFC7989].

[Ballot comment]
S 3.7:
"As described
  in [RFC7989] section 6, related dialogs can occur when an endpoint
  receives a 3xx message, a REFER that directs the endpoint to a
  different peer, or an INVITE request with Replaces that also
  potentially results in communicating with a new peer."

To avoid help discourage overbroad logging, this would be better if it normatively limited the set of what may be considered "related dialogs" to what is listed here, rather than saying "can occur."

S 4.3:
If intermediaries are going to be authorized to insert "log me" on behalf of UAs, was any consideration given to providing support for UAs to be able to insert "do not log me"? I realize this is a different use case -- not where the UA isn't adding new functionality specified in this document, but rather where it is -- but it seems like it might be warranted if having intermediaries insert "log me" is going to be a sanctioned practice.

Note that there could be multiple plausible semantics of "do not log me" worth supporting: telling intermediaries not to turn on "log me" or telling the terminating user agent not to log.

S 4.6:
"Any previously logged messages SHOULD be
  retained and not deleted."

I think this needs to say "in accordance with the limitations set out in Section 8.4.5."

[Ballot comment]
Thanks to everyone who has contributed work towards this document. I have
several comments of varying importance, and believe that this document requires
significant changes before publication.

---------------------------------------------------------------------------

General:

All of the examples in this document use IPv4 addresses. Please use either a mix
of IPv4 and IPv6, or IPv6 only. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for additional guidance.

---------------------------------------------------------------------------

Abstract:

>  SIP networks use signaling monitoring tools to diagnose user reported

Nit: "...user-reported..."

---------------------------------------------------------------------------

§3.2:

>  "User-Agent" header value, or for a specific set of called party

Nit: "...header field value..."

---------------------------------------------------------------------------

§3.6:

>  The entire SIP message (SIP headers and message body) SHOULD be

Nit: Choose either "SIP header fields and message body" or "SIP header and
message body". See the definitions of "Header" and "Header Field" in RFC 3261
at the bottom of page 21 for assistance.

More substantive comment: it is probably useful to also log the request line
(method, request-URI, and SIP version) or response line (SIP version, response
code, and reason phrase), as applicable, in addition to the header and body.

---------------------------------------------------------------------------

§3.7:

This scenario is hard to follow. These points seem contradictory:

  - "[Alice's] terminal is configured to log signaling for calls from the
    network administrator Bob"

  - Bob's terminal is presumably *not* configured to add "log me" marking, since
    the document doesn't mention this, and implies that the configuration at
    Alice's terminal is sufficient

  - "Logging by Alice's terminal begins when it receives and echoes the
    "logme" marker in INVITE F1"

Why does INVITE F1 have a "logme" marker in it?

  - "Logging by Bob's terminal begins when it sends INVITE F1, which
    includes the "logme" marker"

Again: why does this happen? The scenario doesn't include any special
configuration at Bob's terminal.

>  F1 - Bob's UA inserts the "logme" parameter in the Session-ID header
>  of the INVITE request that creates dialog1.

Same question.

Nit: "...header field..."

>  F3 - Alice's UA inserts the "logme" parameter in the Session-ID
>  header of the REFER request that creates dialog2 which is related to
>  dialog1.

Nit: "...header field..."

---------------------------------------------------------------------------

§3.7:

>                  |  REFER F3 (Target-Dialog:1)            |
>          dialog2 |------------------->|                    |
>                  |  202 Accepted      |                    |
>          dialog2 |<-------------------|                    |

The use of 202 in this context is deprecated. See RFC 7647 §5.

---------------------------------------------------------------------------

§3.8:

>  A SIP intermediary MUST copy the "log me" marker into forked requests
>  (see sections 4, 16.6 in [RFC3261]).

It's generally bad form to reiterate normative protocol requirements in
different language. Please rephrase to something along the lines of:

  A SIP intermediary is required to copy the "log me" marker into forked
  requests by the rules defined in sections 4 and 16.6 of [RFC3261].

---------------------------------------------------------------------------

§4.1

>  o  The mechanisms in this section limit initiation of "log me"
>    marking only in dialog creation requests (e.g.  SIP INVITE) sent
>    by an originating endpoint or an intermediary that marks on behalf
>    of the originating endpoint.  The final terminating endpoint or an
>    intermediary that marks on behalf of the terminating endpoint
>    detects an incoming "log me" marker and takes action as defined in
>    Section 4.2 and Section 4.3.

To be clear, this implies that a terminating endpoint has no means of activating
logging; only an originating endpoint (or an intermediary acting on its
behalf) is capable of doing so. If that is the intention, it needs to be stated
explicitly -- because that constraint is unclear enough that even this
document appears to have gotten it wrong (see my comments on §3.7, above).

---------------------------------------------------------------------------

§4.3:

The text in here implies, but does not state, that intermediaries acting on
behalf of endpoints generally need to understand RFC 4538 ("Target-Dialog"),
RFC 3911 ("Join"), and RFC 3819 ("Replaces").  This needs to be explicitly
noted, as intermediaries typically do not act on these header fields in any
way.

---------------------------------------------------------------------------

§4.5.2.5:

>  In Figure 6 below Proxy 2 removes "log me" marking from all SIP
>  requests and responses entering network B and Proxy 2 does not
>  support "log me" marking.

I'm on the fence about whether this is a DISCUSS. Per RFC 3261 processing
rules, proxies simply pass through header fields, unchanged, that they do not
understand -- so Proxy 2, if it does not support "log me" marking, will *NOT*
remove the header field, and will *NOT* remove the "log me" marking. One of
the only reasons that this mechanism (and the Session-ID mechanism itself)
can even be deployed is precisely because of this proxy behavior.

I'm pretty sure that this section needs to be revised to say that Proxy 2
doesn't remove the "log me" marking because it doesn't understand it, and that
Bob's UA doesn't reflect it because it doesn't understand it. The resulting call
flow would look like the following (note the changes in F4, F14, and F20):

      [ NETWORK A          ]          [ NETWORK B          ]
      Alice          Proxy 1          Proxy 2            Bob
        |                |                |                |
        |  INVITE F1    |                |                |
        |  (log me)    |                |                |
        |--------------->|                |                |
        |                |    INVITE F2  |                |
        |                |  (log me)    |                |
        |                |--------------->|                |
        |                |                |                |
        |                |                |                |
        |    100  F3    |                |                |
        |  (log me)    |                |                |
        |<---------------|                |                |
        |                |                |  INVITE F4    |
        |                |                |    (log me)    |
        |                |    100  F5    |--------------->|
        |                |  (no log me)  |                |
        |                |<---------------|                |
        |                |                |    180 F6    |
        |                |                |  (no log me)  |
        |                |                |<---------------|
        |                |    180 F7      |                |
        |                |  (no log me)  |                |
        |                |<---------------|                |
        |                |                |                |
        |                |                |                |
        |    180 F8    |                |                |
        |  (log me)    |                |                |
        |<---------------|                |    200 F9    |
        |                |                |  (no log me)  |
        |                |    200 F10    |<---------------|
        |                |  (no log me)  |                |
        |    200 F11    |<---------------|                |
        |  (log me)    |                |                |
        |<---------------|                |                |
        |    ACK F12    |                |                |
        |  (log me)    |                |                |
        |--------------->|                |                |
        |                |    ACK F13    |                |
        |                |  (log me)    |                |
        |                |--------------->|    ACK F14    |
        |                |                |    (log me)    |
        |                |                |--------------->|
        |                Both Way RTP Media                |
        |<================================================>|
        |                |                |    BYE F15    |
        |                |                |  (no log me)  |
        |                |    BYE F16    |<---------------|
        |                |  (no log me)  |                |
        |    BYE F17    |<---------------|                |
        |  (log me)    |                |                |
        |<---------------|                |                |
        |    200 F18    |                |                |
        |  (log me)    |                |                |
        |--------------->|                |                |
        |                |    200 F19    |                |
        |                |  (log me)    |                |
        |                |--------------->|    200 F20    |
        |                |                |    (log me)    |
        |                |                |--------------->|
        |                |                |                |

The prose description for "F2" also needs to be updated to instead talk about
F6, F9, and F15.

---------------------------------------------------------------------------

§4.6:

>  Two error types are defined in Section 5, a missing marker error and

Nit: "...Section 5: a missing..."
                  ^

---------------------------------------------------------------------------

§5.2:

This section needs to address what is supposed to happen when "Join" (RFC 3911)
is used to combine two dialogs, where one was started with "log me" marking, and
the other one was not.

---------------------------------------------------------------------------

§7:

>  "logme"parameter for the Session-ID header field defined in Section 5

Nit: insert space before "parameter"

---------------------------------------------------------------------------

§8.4:

This section needs to also include information about using GRUUs not based on
AORs (see RFC 5627 §3.1.2).

This section should further mention that fields beyond those cited here might
contain information that can be traced to the user or a small set of users;
e.g., the "user" field in the "o=" parameter of an SDP body, and the Request
URI itself. Basically, it's going to be very difficult to ensure that the
identity of the calling and/or called users is completely removed in all
circumstances, and operators must not assume that messages are anonymized even
when the techniques in this section are applied.

---------------------------------------------------------------------------

§8.4.6:

I share some of Benjamin's concerns, and am somewhat surprised that this section
does not include guidance to ensure that the user is informed of sessions on
which "log me" marking has been activated. Although we don't deal with UI in the
IETF, it's completely fair game to require that UAs that are capable of
indicating that logging is taking place MUST do so.

[Ballot comment]
Thanks to everyone who has contributed work towards this document. I have
several comments of varying importance, and believe that this document requires
significant changes before publication. No single objection rises to the level
of a DISCUSS on its own, but I think the issues I describe below, in
aggregate, are sufficient to require a significantly updated document before
it is approved.

---------------------------------------------------------------------------

General:

All of the examples in this document use IPv4 addresses. Please use either a mix
of IPv4 and IPv6, or IPv6 only. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for additional guidance.

---------------------------------------------------------------------------

Abstract:

>  SIP networks use signaling monitoring tools to diagnose user reported

Nit: "...user-reported..."

---------------------------------------------------------------------------

§3.2:

>  "User-Agent" header value, or for a specific set of called party

Nit: "...header field value..."

---------------------------------------------------------------------------

§3.6:

>  The entire SIP message (SIP headers and message body) SHOULD be

Nit: Choose either "SIP header fields and message body" or "SIP header and
message body". See the definitions of "Header" and "Header Field" in RFC 3261
at the bottom of page 21 for assistance.

More substantive comment: it is probably useful to also log the request line
(method, request-URI, and SIP version) or response line (SIP version, response
code, and reason phrase), as applicable, in addition to the header and body.

---------------------------------------------------------------------------

§3.7:

This scenario is hard to follow. These points seem contradictory:

  - "[Alice's] terminal is configured to log signaling for calls from the
    network administrator Bob"

  - Bob's terminal is presumably *not* configured to add "log me" marking, since
    the document doesn't mention this, and implies that the configuration at
    Alice's terminal is sufficient

  - "Logging by Alice's terminal begins when it receives and echoes the
    "logme" marker in INVITE F1"

Why does INVITE F1 have a "logme" marker in it?

  - "Logging by Bob's terminal begins when it sends INVITE F1, which
    includes the "logme" marker"

Again: why does this happen? The scenario doesn't include any special
configuration at Bob's terminal.

>  F1 - Bob's UA inserts the "logme" parameter in the Session-ID header
>  of the INVITE request that creates dialog1.

Same question.

Nit: "...header field..."

>  F3 - Alice's UA inserts the "logme" parameter in the Session-ID
>  header of the REFER request that creates dialog2 which is related to
>  dialog1.

Nit: "...header field..."

---------------------------------------------------------------------------

§3.7:

>                  |  REFER F3 (Target-Dialog:1)            |
>          dialog2 |------------------->|                    |
>                  |  202 Accepted      |                    |
>          dialog2 |<-------------------|                    |

The use of 202 in this context is deprecated. See RFC 7647 §5.

---------------------------------------------------------------------------

§3.8:

>  A SIP intermediary MUST copy the "log me" marker into forked requests
>  (see sections 4, 16.6 in [RFC3261]).

It's generally bad form to reiterate normative protocol requirements in
different language. Please rephrase to something along the lines of:

  A SIP intermediary is required to copy the "log me" marker into forked
  requests by the rules defined in sections 4 and 16.6 of [RFC3261].

---------------------------------------------------------------------------

§4.1

>  o  The mechanisms in this section limit initiation of "log me"
>    marking only in dialog creation requests (e.g.  SIP INVITE) sent
>    by an originating endpoint or an intermediary that marks on behalf
>    of the originating endpoint.  The final terminating endpoint or an
>    intermediary that marks on behalf of the terminating endpoint
>    detects an incoming "log me" marker and takes action as defined in
>    Section 4.2 and Section 4.3.

To be clear, this implies that a terminating endpoint has no means of activating
logging; only an originating endpoint (or an intermediary acting on its
behalf) is capable of doing so. If that is the intention, it needs to be stated
explicitly -- because that constraint is unclear enough that even this
document appears to have gotten it wrong (see my comments on §3.7, above).

---------------------------------------------------------------------------

§4.3:

The text in here implies, but does not state, that intermediaries acting on
behalf of endpoints generally need to understand RFC 4538 ("Target-Dialog"),
RFC 3911 ("Join"), and RFC 3819 ("Replaces").  This needs to be explicitly
noted, as intermediaries typically do not act on these header fields in any
way.

---------------------------------------------------------------------------

§4.5.2.5:

>  In Figure 6 below Proxy 2 removes "log me" marking from all SIP
>  requests and responses entering network B and Proxy 2 does not
>  support "log me" marking.

I'm on the fence about whether this is a DISCUSS. Per RFC 3261 processing
rules, proxies simply pass through header fields, unchanged, that they do not
understand -- so Proxy 2, if it does not support "log me" marking, will *NOT*
remove the header field, and will *NOT* remove the "log me" marking. One of
the only reasons that this mechanism (and the Session-ID mechanism itself)
can even be deployed is precisely because of this proxy behavior.

I'm pretty sure that this section needs to be revised to say that Proxy 2
doesn't remove the "log me" marking because it doesn't understand it, and that
Bob's UA doesn't reflect it because it doesn't understand it. The resulting call
flow would look like the following (note the changes in F4, F14, and F20):

      [ NETWORK A          ]          [ NETWORK B          ]
      Alice          Proxy 1          Proxy 2            Bob
        |                |                |                |
        |  INVITE F1    |                |                |
        |  (log me)    |                |                |
        |--------------->|                |                |
        |                |    INVITE F2  |                |
        |                |  (log me)    |                |
        |                |--------------->|                |
        |                |                |                |
        |                |                |                |
        |    100  F3    |                |                |
        |  (log me)    |                |                |
        |<---------------|                |                |
        |                |                |  INVITE F4    |
        |                |                |    (log me)    |
        |                |    100  F5    |--------------->|
        |                |  (no log me)  |                |
        |                |<---------------|                |
        |                |                |    180 F6    |
        |                |                |  (no log me)  |
        |                |                |<---------------|
        |                |    180 F7      |                |
        |                |  (no log me)  |                |
        |                |<---------------|                |
        |                |                |                |
        |                |                |                |
        |    180 F8    |                |                |
        |  (log me)    |                |                |
        |<---------------|                |    200 F9    |
        |                |                |  (no log me)  |
        |                |    200 F10    |<---------------|
        |                |  (no log me)  |                |
        |    200 F11    |<---------------|                |
        |  (log me)    |                |                |
        |<---------------|                |                |
        |    ACK F12    |                |                |
        |  (log me)    |                |                |
        |--------------->|                |                |
        |                |    ACK F13    |                |
        |                |  (log me)    |                |
        |                |--------------->|    ACK F14    |
        |                |                |    (log me)    |
        |                |                |--------------->|
        |                Both Way RTP Media                |
        |<================================================>|
        |                |                |    BYE F15    |
        |                |                |  (no log me)  |
        |                |    BYE F16    |<---------------|
        |                |  (no log me)  |                |
        |    BYE F17    |<---------------|                |
        |  (log me)    |                |                |
        |<---------------|                |                |
        |    200 F18    |                |                |
        |  (log me)    |                |                |
        |--------------->|                |                |
        |                |    200 F19    |                |
        |                |  (log me)    |                |
        |                |--------------->|    200 F20    |
        |                |                |    (log me)    |
        |                |                |--------------->|
        |                |                |                |

The prose description for "F2" also needs to be updated to instead talk about
F6, F9, and F15.

---------------------------------------------------------------------------

§4.6:

>  Two error types are defined in Section 5, a missing marker error and

Nit: "...Section 5: a missing..."
                  ^

---------------------------------------------------------------------------

§5.2:

This section needs to address what is supposed to happen when "Join" (RFC 3911)
is used to combine two dialogs, where one was started with "log me" marking, and
the other one was not.

---------------------------------------------------------------------------

§7:

>  "logme"parameter for the Session-ID header field defined in Section 5

Nit: insert space before "parameter"

---------------------------------------------------------------------------

§8.4:

This section needs to also include information about using GRUUs not based on
AORs (see RFC 5627 §3.1.2).

This section should further mention that fields beyond those cited here might
contain information that can be traced to the user or a small set of users;
e.g., the "user" field in the "o=" parameter of an SDP body, and the Request
URI itself. Basically, it's going to be very difficult to ensure that the
identity of the calling and/or called users is completely removed in all
circumstances, and operators must not assume that messages are anonymized even
when the techniques in this section are applied.

---------------------------------------------------------------------------

§8.4.6:

I share some of Benjamin's concerns, and am somewhat surprised that this section
does not include guidance to ensure that the user is informed of sessions on
which "log me" marking has been activated. Although we don't deal with UI in the
IETF, it's completely fair game to require that UAs that are capable of
indicating that logging is taking place MUST do so.

[Ballot comment]
I have a fair amount of lingering uncertainty about this document, but
I am balloting No Objection because the stated use case seems to be
a valid and unmet need and because I cannot identify any concrete issues
that would be DISCUSS-worthy.  I will try to articulate my unease as best I
can, and also have some section-by-section (mostly editorial) comments.
(I think that some of the factors causing my unease have already been noted
and are slated to be fixed in the next revision -- thank you for that!)

The first point that struck me is of course one that has already been
discussed quite a bit, e.g., for the requirements document -- this is a
"dual use" technology that could also be used for lawful intercept (a "pen
register") just as easily as for its stated goals.  However, this work
meets the requirements from RFC 8123 and is explicitly in charter for the
WG, so this is not grounds to object to the document.  One might in
isolation consider alternative designs with less of a "dual-use" nature,
such as those that involve cryptographic signatures over certain headers in
a way that would provide some level of tamper evidence, but (1) only
signalling is being logged here, and (2) in the context of the broader SIP
ecosystem this is hardly the biggest risk.

This design also entails a great deal of configuration that would
presumably be to large extent manual configuration.  If positive assent is
required for any "log me" at all, that is in some sense configuration, of
course, but not only are the endpoints given great flexibility as to
how/when to configure "log me", but the intermediaries can be configured to
know about individual endpoints behind them and their (non-capabilities),
to block "log me" from entering or exiting their network, to drop or
reflect incoming "log me" markings, etc..  Many of these require
dialog-level state management in addition to the configuration-state
management, which can be complicated.  How would intermediaries identify
specific endpoints to apply "log me" on the behalf of (and how are endpoint
capbilities tracked, especially when users can bring their own devices)?
This feels like the implementation will be hugely complicated, and
complication leads to increased risk of errors.

Though there are quite a few reminders sprinkled through the document that
it is intended only for testing and troubleshooting usage, and explicit
end-user or administrator action is required to enable it, parts of the
body text of the document still read as if a node might be configured to
always enable "log me".  This is essentially an editorial matter that a
good clean-up pass could readily resolved, so I also can't assign much
weight to it in my overall consideration of the document.

I think another part of why I ended up puzzled having read the draft is
that, though it goes into great detail to describe the technical mechanics
of the different scenarios that (e.g.) intermediaries can be configured
for, with dedicated ladder diagrams showing how a standard example scenario
plays out in the different cases, I didn't get a great picture of what
would *motivate* those different deployment scnarios?  As a concrete
example, why would I configure my network boundary to respond to "log me"
markers originating externally but not allow them to be used inside my
network?  The relevant session information is basically all going to get
logged *somewhere*, so the fact that I'm not logging it doesn't buy my
users any privacy.  Perhaps it relieves me from the need to worry about
whether the logged information is personally identifying in the relevant
jurisdiction, but it also serves to blind the end-user to the presence of
"log me" in the session (which would be a very desired feature for lawful
intercept cases).  I just don't know what would motivate me to use or not
use this configuration, which gives me some sense that perhaps the document
is incomplete, in a certain sense.


Section 4.1

  o  The mechanisms in this section limit initiation of "log me"
      marking only in dialog creation requests (e.g.  SIP INVITE) sent
      by an originating endpoint or an intermediary that marks on behalf
      of the originating endpoint. [...]

(nit?) What this text ("only in") actually says, is that there are some
limitations that can be applied, but these limitations are only applied in
the listed cases.  If you want it to mean that "log me" initiation is
limited to just the listed cases, you need to say something like "[...]
markint to only dialog creation requests [...]".

Section 4.2

Can these (and other similar) lists be tightened up?  For example, which
bullet point tells the originating agent to log requests that it receives,
that are logme marked?  (I see where it would log the response that it
sends, but not why it would log the request that triggers the response.)

Section 4.3

  authorizations in Section 8.1, a SIP intermediary close to the user
  agent (e.g. edge proxy, B2BUA) on the originating and terminating
  sides inserts the "log me" marker instead in order to test sessions

nit: is this "originating and/or terminating"?

  The SIP intermediary at the originating side is configured to insert
  the "log me" marker on behalf of the originating endpoint.  If the
  terminating user agent does not echo the "log me" marker in responses
  to a marked request then the the SIP intermediary closest to the
  terminating user agent inserts a "log me" marker in responses to the
  request.

Do we need to tweak the text to be "If [the intermediary] is configured to
insert", or repeat the "subject to the authorization checks from Section
8.1"?

(nit) Also, in general the text here is a little unclear about whether the
intermediaries need to be at both sides or can be at just one, etc.

  For the originating SIP intermediary:

  o  The originating SIP intermediary configured for "log me" marking
      MUST insert a "log me" marker into the dialog-creating SIP request
      and subsequent in-dialog SIP requests.

This makes it sound as if every dialog-creating SIP request would get "log
me"'d, not just the specific ones configured and authorized for.

Section 4.5.2.1 (et seq?)

  Alice's user agent does not support "log me" marking and hence Proxy
  1, which is the SIP intermediary closest to Alice, is configured to
  act on behalf of Alice's user agent to "log me" mark dialogs created
  by Alice.

Why are *all* dialogs created by Alice getting logged?  Shouldn't we say
something about how there is a troubleshooting case and the logging is only
enabled for the purposes of the corresponding diagnostics?



Section 8.3

  Maliciously configuring a large number of terminals to simultaneously
  "log me" mark dialogs will cause high processor load on SIP entities

nit: 'mark dialogs "log me"' might read better

Section 8.4.1/8.4.2

(In some jurisdictions/circumstances, IP addresses are considered
personally identifying information.)

[Ballot comment]
Thank  you for a clear and well written document.

A rich version of this review is at:

Thank you for a clear and well-written document.

An HTML version of this review is at: https://mozphab-ietf.devsvcdev.mozaws.net/D11687


Line: 124
I'm uncomfortable with the "operators need to" wording -- perhaps "operators often have to", or "operators are often expected to"?

Line: 1555
The privacy implications of all of this seem large -- I think that it would be really useful to make "Privacy" be its own section, and not a subsection of Security Considerations.

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D7386



DETAIL
S 6.1.
>  6.1.  "Log Me" Authorization
> 
>      An end user or network administrator MUST give permission for a
>      terminal to perform "log me" marking.  The configuration of a SIP
>      intermediary to perform "log me" marking on behalf of a terminal MUST
>      be authorized by the network administrator.

This seems to contradict S 4.4.2, which describes how you get logging
even when the responding UA doesn't support it (and thus presumably
doesn't give permission). Perhaps you mean "at least one end user or
administrator...?


S 6.4.2.
>      store all the SIP messages that are exchanged within a given dialog.
>      SIP messages can contain the personal identifiers listed in
>      Section 6.4.1 and additionally a user identity, calling party number,
>      IP address, hostname, and other user and device related items.  The
>      SIP message bodies describe the kind of session being set up by the
>      identified end user and device.

This seems to have extremely negative consequences when security
descriptions is used. It seems like you need to prohibit their
combination or at least call this out.

[Ballot comment]
S 3.6.
> 
>  3.6.  Format of Logged Signaling
> 
>      The entire SIP message (SIP headers and message body) MUST be logged.
>      Logging SHOULD use common standard formats such as the SIP CLF
>      defined in [RFC6873] and Libpcap.  If SIP CLF format is used, the

Reference for libpcap?

[Ballot comment]
A couple of quick comments/questions:

1) How do you know that both endpoints are "log me" enabled? I guess because of the requirement that all messages of a dialog must have the marker, you cannot just add it and see if the other end is able to apply it to its responses...?

2) Sec 3.2: "firstly because it is configured to
  do so, or secondly because it has detected that a dialog is being
  "log me" marked, causing it to maintain state to ensure that all
  requests and responses in the dialog are similarly "log me" marked."
I was first quite confused by this sentence because I though the second case meant that intermediates needs to ensure that all messages are marked correctly. However, I guess the second case is when the other ends is configured to do marking, one needs to reply with the marking as well. I think I was mainly confused by the word "detects". Maybe it's worth to further clarify this sentence...?

3) Section 4.6 feels a little misplace but I not sure where it belong otherwise (maybe section 3 or 5?). Or maybe move section 4.5 in an own section later in the doc...?

4) Also Section 4.6: "It MUST NOT forward the "log me" marker"
Does it mean an intermediate MUST remove the marker if an error is detected? Is that safe given the proxy scenarios? If at all I would recommend to use MAY here, I guess...

5) Sec 8.1.:
"An end user or network administrator MUST give permission for a
  terminal to perform "log me" marking in the context of regression
  testing or troubleshooting a problem. "
and
"The configuration of a SIP intermediary to perform
  "log me" marking on behalf of a terminal MUST be authorized by the
  network administrator."
I'm actually not sure what these normative sentences mean for an implementation. Is this maybe rather "An implementation MUST provide a configuration to active logging and logging MUST be disabled by default."?

6) Section 8.2:
"If SIP requests and responses are exchanged with an external network
  with which there is no agreement to pass "log me" marking, then the
  "log me" marking is removed."
Should this be normative, maybe:
"If SIP requests and responses are exchanged with an external network
  with which there is no agreement to pass "log me" marking, then the
  "log me" marking SHOULD be removed at the network border."
Or MUST?

7) Also a related question: Should a network perform ingress filtering/removal of "log me" markers?

8) Nit:
Sec 2: I guess the following sentence was coped and pasted from RFC8123 and should be removed for this doc:
"Rather than describing interoperability
  requirements, they are used to describe requirements to be satisfied
  by the "log me" marking solution."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-insipid-logme-marking-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Header Field Parameters and Parameter Values registry on the SIP Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new header field is to be registered as follows:

Header Field: Session-ID
Parameter Name: logme
Predefined Values: No (no values are allowed)
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-07-10):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, insipid@ietf.org, gsalguei@cisco.com, insipid-chairs@ietf.org, draft-ietf-insipid-logme-marking@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Marking SIP Messages to be Logged) to Proposed Standard


The IESG has received a request from the INtermediary-safe SIP session ID WG
(insipid) to consider the following document: - 'Marking SIP Messages to be
Logged'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-07-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  SIP networks use signaling monitoring tools to diagnose user reported
  problems and for regression testing if network or user agent software
  is upgraded.  As networks grow and become interconnected, including
  connection via transit networks, it becomes impractical to predict
  the path that SIP signaling will take between user agents, and
  therefore impractical to monitor SIP signaling end-to-end.

  This document describes an indicator for the SIP protocol which can
  be used to mark signaling as being of interest to logging.  Such
  marking will typically be applied as part of network testing
  controlled by the network operator and not used in normal user agent
  signaling.  Operators of all networks on the signaling path can agree
  to carry such marking end-to-end, including the originating and
  terminating SIP user agents, even if a session originates and
  terminates in different networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD evaluation of draft-ietf-insipid-logme-marking-09. I have separated my comments into Major, Minor, and Editorial. I would like to at least resolve the major comments prior to IETF last call.

As a preface, please remember that the related requirements document created controversy during the IESG review. Some of the controversial normative language was moved from that document to this one. Therefore, we can expect some of that controversy to reoccur. Hopefully if we can resolve my major comments, we can avoid much of that.

----------------------------------

Major Comments:

1) I think there are still privacy issues in this document. In particular, compliant intermediaries are normatively required to log, and to log entire messages. Log minimization is a common tenant of privacy, and these requirements effectively forbid it. IMO, the draft should avoid normative requirements about whether a device logs, and how much it logs. It is reasonable to include non-normative guidance that troubleshooting might require information than might otherwise be logged.

Likewise, the requirement to log entire messages without change effective forbids pseudonymization or anonymization. There is text in the privacy considerations suggesting this is the UA responsibility—I don’t think that’s good enough, especially in the case where an intermediary inserts the logme parameter on behalf of a non-supporting  endpoint. I’d like to see it possible for an intermediary to anonymize logs, and some guidance that it should do so unless there is a reason not to.

2) I think one of the major values of this mechanism is to allow an operator to only log details for sessions being tested, and avoid the temptation to just log everything in case they need it someday. I suggest this be emphasized early in the document. Along those lines, I’d like to see text that talks about configuring endpoints and intermediaries to insert the parameter to include guidance about the timescale and granularity of such a configuration. There is text in the privacy considerations suggesting that you this should be configured on a per session basis with a limited timeframe, but If there are normative requirements to that effect, I missed them.

3) There is a normative downref to RFC7206. I don’t think that is necessary or appropriate. It doesn’t appear to be cited, so maybe it can just go away?

Minor Comments:

Abstract, last paragraph: "However, such marking can be carried end-to-end including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.”: While the draft allows this when there is agreement between operators to do so, it seems like it is not the default case. Stating it this way without limitation in the abstract is likely to give the wrong idea.

§2: There are instances of 2119 keywords in lower case. Unless you intend those to be normative, please use the boilerplate from RFC 8174 instead.

§3.1, first paragraph: I think “...MUST be passed unchanged…” is too strong. This only allows the exception for external networks. There may be any number of local policy reasons to not pass the parameter through. I suggest making this a SHOULD, and mentioning that local policy might disallow it. (Note that this MUST is redundant to the one in §3.4.2. It seems like the normative requirement belongs there, and that the mention in §3.1 should be descriptive.

§3.2, 2nd paragraph: What is expected to happen when such an error condition occurs?

§3.4.1: See comment to §3.1

§3.4.2: I don’t think it’s appropriate to use 2119 keywords to describe the agreements. between operators. It’s reasonable to say (non-normatively) that end-to-end troubleshooting will be made easier if such agreements exist.

§3.6: (See major comment 1.) It’s reasonable to say that logging the entire message without change might make troubleshooting easier. But a SIP network element should be able to apply local policy to decide what (and whether) to log. I think a better approach would have been to define the meaning of “logme” to mean “this message is of interest for troubleshooting or testing”, and then let devices decide what to do about that based on local policy.

§4 (See major comment 1): This needs some guidance not to minimize “log me” marking so that only the dialogs under test or troubleshooting get marked. Otherwise, people will be tempted to just mark everything.

§4.1: Since the bullet points are listed as “principles”, I suggest using descriptive language rather than normative keywords. (Same for §4.2)

§4.2:
- This behavior will likely be a red flag to reviewers. Please mention the consent requirement up front.
- Is the restriction that the intermediaries that insert logme on behalf of the endpoints be the first SIP hop from the endpoints intended to be normative? (How much work does it need to do to verify this? For e.g., there may be edge cases where looking at Via headers may not be sufficient to tell an endpoint from a b2bua.)

§4.4.1: It seems like there are other normative requirements that effectively prevent stateless processing in many cases.

§5.1, last paragraph: This needs to talk about how it interacts with intermediaries that add the log-me parameter on behalf of endpoints that don’t support it. It seems like they will see missing markers all the time.

§6.1: Again, this needs some guidance to discourage an end user or administrator turning on log-me for all dialogs.

§6.4.1: (See major comment 1) This seems unhelpful in the case where an intermediary inserts log-me on behalf of an end-point that doesn’ support it.

§6.4.4: This doesn’t seem right; the SIP privacy mechanism is about avoiding identifying the user, not avoiding fingerprinting of a UA. OTOH, as far as I can tell, log-me doesn’t make fingerprinting “worse” except in the case where it introduces full-message logging without the knowledge of the endpoint.

§6.4.5: Is the need to enable logging on a per-session basis or specific time period stated normatively somewhere that I missed? Also, I think this can do better than making the retention period “out-of-scope”. I suggest non-normative language that log records captured for troubleshooting or test purposes should not be retained longer than necessary for that purpose.

§6.4.6: The “MUST” in the first paragraph seems redundant to already stated requirements; please state it descriptively. Also, It seems like the last paragraph is incompatible with some existing MUST level requirements.

§10.2: It seems like the reference to 3323 should be normative as currently used.


Editorial Comments:

- IDNits returns a number of issues; please check. (I see that the shepherd writeup also points these outs; is there a reason they were not fixed as a result of that review?)

§3.1:
- “Logging is most effective…”: I suggest “Logging for diagnostic purposes is most effective…”
- “ session identifier is passed through”: I suggest  “… more likely to be be passed through…”

§3.2:
- First paragraph: Is “As indicated in [RFC8123] REQ111,” really needed? It doesn’t seem to add information to this document.
- 2nd paragraph: I suggest s/proxy/intermediary

§3.7:
— 2nd paragraph:
- “Figure 2 below”: Don’t assume all presentations of the RFC will keep the same relative positioning for the figure. Better to just say “Figure 2”.
- "Her terminal is configured to log signalling”: That makes it sound like her terminal is configured to insert the logme parameter into all requests. Can this be scoped more tightly?
- “ Alice’s terminal logs related REFER dialog2” : And inserts the logme parameter?

—  4th paragraph: Unmatched closing parenthesis.
— Figure 2: It would be helpful to mention that parts of the messages in examples are elided for clarity (e.g. no SDP, “…” for content-length).

§3.8: By what? (Please consider active voice; in this case passive voice obscures the actor).

§4.2, first paragraph: “The intermediaries that are known to be closest…” That’s the point of the whole section; I moving it to the beginning of the paragraph.

§4.4.2.1: Is “Proxy 1” really a “proxy” as defined in RFC3261? Does this assume that Alice’s UA did insert Session-ID?

§4.4.2.1.1: Seems like this example belongs with the text about errors.

§5.1.1, figure 9: “Network B” doesn’t seem to participate in the exchange—why is it in the picture?

§5.2: I don’t think the term “edge proxy” captures the idea that we are talking about an intermediary immediately adjacent to an endpoint. 

§6.4: comma splice

§7: This section should come before the security considerations.

Shepherd Writeup for draft-ietf-insipid-logme-marking-09:
=========================================================

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended Status: Proposed Standard. This document defines a new header field parameter "logme" for the "Session-ID" header field.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

      This document describes an indicator for the SIP protocol which can be used to mark
      signaling as being of interest to logging.  Such marking will typically be applied
      as part of network testing controlled by the network operator and not used in
      normal user agent signaling.  However, such marking can be carried end-to-end
      including the originating and terminating SIP user agents, even if a session
      originates and terminates in different networks.
     
      This document defines a new header field parameter "logme" for the "Session-ID"
      header field.  Implementations of this document MUST implement session identity
      specified in [RFC7989].


Working Group Summary

      The work on the document took a relatively long time in the WG. The reason
      was not so much related to controversies, or different opinions, but more related
      to the cycles the authors, contributors and reviewers were able to put on the work.
      There is a consensus in the INSIPID WG to publish the document as an RFC and it has
      received sufficient review to ensure document quality and technical accuracy.
     
Document Quality

      A number of vendors have indicated that they have implemented, or intend to
      implement, the document. Individuals representing the implementers were also
      involved in the work on the document.
     
      The document is also referenced by 3GPP, and support is required for certain IMS
      use-cases and functions.

Personnel

      Document Shepherd: Gonzalo Salgueiro (gsalguei@cisco.com ¬ INSIPID WG chair)

      Responsible Area Director: Ben Campbell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The Document Shepherd has no concerns or issues with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each author has confirmed that any appropriate IPR disclosure has been filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There is no IPR disclosures against this document and neither author knows of any undeclared IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understands the draft and agrees with it being published as an RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


idnits 2.15.01

/tmp/draft-ietf-insipid-logme-marking-09.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 37 pages


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 2 instances of too long lines in the document, the longest one
    being 2 characters in excess of 72.

  -- The document has examples using IPv4 documentation addresses according
    to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
    there should be IPv6 examples, too?


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  == Line 161 has weird spacing: '...ple.com  p1.ex...'

  -- The document date (December 19, 2017) is 54 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'RFCXXXX' is mentioned on line 1473, but not defined

  == Unused Reference: 'RFC7206' is defined on line 1511, but no explicit
    reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 7206


    Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--).



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Yes.  There is a normative reference to an Informational RFC (RFC 7206).  The authors
will fix this along with other comments received during AD review and/or IESG review.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no issues with the IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new IANA registries created by this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The Document Shepherd has reviewed the BNF rules. The document does not use other
types of formal languages.