Re: [Insipid] Eric Rescorla's Discuss on draft-ietf-insipid-logme-marking-12: (with DISCUSS and COMMENT)

"Arun Arunachalam (carunach)" <> Tue, 14 August 2018 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D0F412426A; Tue, 14 Aug 2018 07:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zxZInnKTUuIj; Tue, 14 Aug 2018 07:58:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8564212F18C; Tue, 14 Aug 2018 07:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16634; q=dns/txt; s=iport; t=1534258709; x=1535468309; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kbZIVmJ+wm1wXCuV38v/y4XYkA3EpXNIrhxd3Nr1DIU=; b=dfLs6O959V5qhsuhqsulz7BfaPY6pScn/dWp2CyuC+RQyUWW8NoRW82o HihBMES7ANGa03xw3WpzSGU0pPLdtYfHeDu7aW8WsAC0BSYLB6MYfjnpq MUGMLukR++t5G25YRGSMdx3xKqfNPc7BdtuzD8IUbiIqGRqNnTPDMqYru o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAAAs7XJb/5BdJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV3hjfygKgyQ/iAqMO5JxhSkUgWYLJYRHAheDACE0GAE?= =?us-ascii?q?CAQECAQECbRwMhTgGDBdWEAIBBgIOMQMCAgIwFBECBAENBYMiAYEdZA+SaZt?= =?us-ascii?q?LgS6EKgGGJgWHU4FBF4IAgRInH4JMgUGBWgIBAgGBKgEIAwcBgyAxgiQCiAS?= =?us-ascii?q?EbYVHiC8JAoYignGGQ4FOhCuIRIsFhRSCWQIRFIEkHThhWBEIcBVlAYI+giA?= =?us-ascii?q?RHIgNO4U+bwEBiXcPF4EIgRsBAQ?=
X-IronPort-AV: E=Sophos;i="5.53,238,1531785600"; d="scan'208,217";a="438057273"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2018 14:58:28 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w7EEwSXV012005 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2018 14:58:28 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Aug 2018 09:58:27 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 14 Aug 2018 09:58:27 -0500
From: "Arun Arunachalam (carunach)" <>
To: Eric Rescorla <>, Adam Roach <>, Ben Campbell <>
CC: The IESG <>, "" <>, "" <>, "Gonzalo Salgueiro (gsalguei)" <>, "" <>, "Dawes, Peter, Vodafone Group" <>, "Arun Arunachalam (carunach)" <>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-insipid-logme-marking-12: (with DISCUSS and COMMENT)
Thread-Index: AQHUM0X8B5cM/gFFi0219JgYT2QnfKS/q8UA
Date: Tue, 14 Aug 2018 14:58:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_331AD917D4014B85AD525A6607226823ciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Tue, 14 Aug 2018 08:48:06 -0700
Subject: Re: [Insipid] Eric Rescorla's Discuss on draft-ietf-insipid-logme-marking-12: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Aug 2018 14:58:33 -0000

Hi Eric, Adam and Ben,

Thanks for your comments!

Please see inline.

On Aug 13, 2018, at 4:41 PM, Eric Rescorla <<>> wrote:

Eric Rescorla has entered the following ballot position for
draft-ietf-insipid-logme-marking-12: Discuss

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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Rich version of this review at:

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

The statement "An end user or network administrator MUST give permission….” is applicable for scenarios in which the terminal supports “log me” marking. Whereas the statement “The configuration of a SIP intermediary to perform…” is applicable when the terminal doesn’t support “log me” marking.

We can rephrase this paragraph as:

“Log me” marking MUST be disabled by default both at the endpoints and intermediaries and MUST be enabled only by authorized users. For example, an end user or network administrator must give permission for a terminal that supports “log me” marking in order to initiate marking. Similarly, a network administrator must enable a configuration at the SIP intermediary to perform "log me" marking on behalf of a terminal that doesn’t support “log me” marking. The permission MUST be limited to only specific calls of interest that are originated in a given time duration.

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.

We can add the following lines to Section 8.4.2

When the SIP SDP message body contains security descriptions in the “crypto” attribute [RFC4568], the attribute value MUST be masked with a dummy value prior to storing the message in a log file. For example, the attribute value can be replaced with a string of special characters like “X”, “*” and “#” as shown in the example below.



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?

We can use the reference provided by Adam.

Modified text:

"defined in [RFC6873] and Libpcap [application/vnd.tcpdump.pcap<>]p>].  If SIP CLF format is used, the….”

Peter & Arun