Marking SIP Messages to Be Logged
RFC 8497

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.

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.

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

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

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

What is the implementation and interoperability status of this specification? Is there any running code?

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