[Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

Adam Roach <adam@nostrum.com> Thu, 16 August 2018 00:19 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: insipid@ietf.org
Delivered-To: insipid@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266D130EB3; Wed, 15 Aug 2018 17:19:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-insipid-logme-marking@ietf.org, insipid-chairs@ietf.org, gsalguei@cisco.com, insipid@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153437875319.3073.15951759162383331116.idtracker@ietfa.amsl.com>
Date: Wed, 15 Aug 2018 17:19:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/CTpv4NwTdzNPi9iwZyAe7_9B35U>
Subject: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 00:19:13 -0000

Adam Roach has entered the following ballot position for
draft-ietf-insipid-logme-marking-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/



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