Re: [Insipid] draft-ietf-insipid-logme-marking-07

Jörgen Axell <jorgen.axell@ericsson.com> Fri, 09 June 2017 15:07 UTC

Return-Path: <jorgen.axell@ericsson.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3887129442 for <insipid@ietfa.amsl.com>; Fri, 9 Jun 2017 08:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPKXyl5sMl4L for <insipid@ietfa.amsl.com>; Fri, 9 Jun 2017 08:07:17 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5AE127076 for <insipid@ietf.org>; Fri, 9 Jun 2017 08:07:17 -0700 (PDT)
X-AuditID: c1b4fb30-4a9ff70000003fda-57-593ab9a37a16
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.21.16346.3A9BA395; Fri, 9 Jun 2017 17:07:15 +0200 (CEST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 9 Jun 2017 17:07:19 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xynFaAp8JOhjzdZxVI78Vh2ATeZE8O+zT5TYoNsIzRc=; b=A+EasTadCZNDEkSdGBMP9U/5YxTu+whV+GuBJyHaITD3bTkhUhAjf7/jr5icHNdVmIQNTU5FllbAYHLPCGDsuF7nD+yQ80VihAPptorpmuXvVY7PHlOcYiNe0OF/HHmJf4zkJbIfWxy4kLZG46HYlbTWS864rvhlaeYP0BiudG8=
Received: from DB5PR07MB0949.eurprd07.prod.outlook.com (10.161.200.144) by DB5PR07MB0808.eurprd07.prod.outlook.com (10.161.196.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Fri, 9 Jun 2017 15:07:13 +0000
Received: from DB5PR07MB0949.eurprd07.prod.outlook.com ([fe80::b5f3:e92f:5f19:54de]) by DB5PR07MB0949.eurprd07.prod.outlook.com ([fe80::b5f3:e92f:5f19:54de%17]) with mapi id 15.01.1157.014; Fri, 9 Jun 2017 15:07:13 +0000
From: =?iso-8859-1?Q?J=F6rgen_Axell?= <jorgen.axell@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] draft-ietf-insipid-logme-marking-07
Thread-Index: AQHS3kSNOfynA3pNy0mnFAelZjVtTKIcMp/A
Date: Fri, 9 Jun 2017 15:07:13 +0000
Message-ID: <DB5PR07MB0949EFAA5430320D5019DB54E0CE0@DB5PR07MB0949.eurprd07.prod.outlook.com>
References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15977A9@VOEXM31W.internal.vodafone.com> <19bd71c8-e74c-4e71-f5ed-a3fd77ffb9b0@alum.mit.edu>
In-Reply-To: <19bd71c8-e74c-4e71-f5ed-a3fd77ffb9b0@alum.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.85]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR07MB0808; 7:AziFSJXIX+ZG9g+JzCtSGazlcGSeA23fU88YmGGSqNd8TehR3wSLGlt8+vCSjDQICLgnsnMhNFbMw3Fi0y+JdFkBg3lf/3gFxdgS/sijU9sQ4ZWJz8pTQdvE0rb5/Q/xiSHTZe81Ur+jlu/4a6h5VsibILn4Ww6w4gDtSVmNerJEESCQXEUgiaFgNNXTs4kPuY5aD+ZqjJpDdjSffxr8ZMZft7B9n/pacZnbrpSvi7cPWoG3kygKwtk69GFcGD7QXY/d484nm5XQzqFaFZUxdcK+GGTX5f5MQOR7CrmZiu0y3t9haFkG5qUMqlUKBYR/9HYd8etdzhjQvrRpmtrgNQ==
x-ms-traffictypediagnostic: DB5PR07MB0808:
x-ms-office365-filtering-correlation-id: fffa2adf-242f-48fd-164f-08d4af493606
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB5PR07MB0808;
x-microsoft-antispam-prvs: <DB5PR07MB0808B50CA6C0B55F422C199EE0CE0@DB5PR07MB0808.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0808; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0808;
x-forefront-prvs: 03333C607F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(39400400002)(13464003)(55016002)(99286003)(2906002)(54356999)(2501003)(6436002)(33656002)(478600001)(6506006)(76176999)(3846002)(102836003)(50986999)(53936002)(6306002)(966005)(5250100002)(14454004)(189998001)(7696004)(9686003)(53546009)(25786009)(86362001)(8676002)(7736002)(3660700001)(6246003)(2171002)(2950100002)(38730400002)(81166006)(3280700002)(2900100001)(8936002)(5660300001)(74316002)(229853002)(230783001)(305945005)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0808; H:DB5PR07MB0949.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 15:07:13.8003 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0808
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7LvBstHtfE00qQJQQTzaQPNiWUAgXTEio1olp6U1GnbNNS IVQydCbYq07QKYrZFqaptZqlLctS0Sw1rczalrIslSjCTMntLujb7zn/c/7nhYchRSW0hElT aliVUpEh5QkoXcK92IDG+/LEoAX79hD9zCwR0tLWS4cTUauLS0RUU9MycZA4KghLZjPSclnV jj0nBam1Sy1E9pPAs23GXlSIlrdpEcMA3gXNxgAtEjAi3Ifgeaud0CL++qMfQbWtwClQuIKE iu8NJCdUEdBfKucqrAjqdaM8p8DDETC+9sfDyWIcB6+f1rvim7AcBvrGKS4eCgb7JXdOMLyv nHQxhf1gddbhyhHiY6DvMCKuQTkCU5HJZcTH4TAxWk07GWEf+FFkdE1EYm94a9e7xgaMoal7 hOTYCxy2NdpphPAVBKX6MZrb2Rc+dcVyOT7wSl/uagb4IgnT1suIE2Qw1F3swXEMGFpn3Kbn wNQzRXGcDu0312iOQ8ExbKY5IwsNhsZFd/FW6JmqdgstNNRNlrjvIoHpsTJUiWQ1/23BcSBM XrvK49gfmhvmyRrXaTzhhc5O1SPKgLzUrPpUZkpwcCCrSktSq7OUgUpWcwetf47HnStBJuSY i7AgzCDpBqG5RJ4oohW56rxMCwKGlIqFX+6uh4TJirx8VpV1QpWTwaotaAtDSb2FEY9eJohw ikLDprNsNqv6pxIMX1KItA8TzJFiy5EueXztwnyKw9eSP+IxwS9yRB+IFs/pIg/X3Xp2/g35 4dvcyuePmqH9pvqC22HzVttQTfzwmc7jvxr2bTTlKGVdLWZJSFP1BVXH1yRJ3Gl2sOL65t97 q3RlqflSh8EyNeB3w1Y8mz24+93P9hhs9X8gOwSeMjHMSCl1qmKnjFSpFX8B2hfvMRgDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/LanUOni-7-5yEyTOb0oZwdbyNxo>
Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Fri, 09 Jun 2017 15:07:21 -0000

Hi,

This is my review on this draft, trying to not duplicate Paul's comments:

4.1 says "log me" header in one place, change to "log me" marker
terminology "header" versus "header field" seems inconsistent

4.2:
The third sentence (starting with 'The "log me" marker...') seems a bit standalone. I think the text could have a condition e.g.: "If a "log me" marker is received by a user agent not supporting "log me" marking the user agent does not echo the "log me" marker in responses."
I think the last bullet should say that the originating SIP intermediary echoes **received** "log me" markers in responses to in-dialog requests. As the text is now I get a bit uncertain if the node always puts in a "log me" marker in the response. If so it would be against the recommendation in 5.1.

4.2.2.2.1 Editorial: Proxy-1-->Proxy 1

4.2.2.2.2 first line has in In.
Below figure 4 F6, remove "the" from "the Alice's". 

Regards,
Jörgen

-----Original Message-----
From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 05 June 2017 23:41
To: insipid@ietf.org
Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07

I have reviewed the -07 version. This time I couldn't do it just by looking at the diff, so I did read it end to end. I do have a number of
comments:

* Terminology:

Some places use "test case identifier" while others use "test identifier". Please pick one term and stick to it. Or perhaps the special term can be abandoned altogether by simply using Session-ID.

* Section 3.1:

Example needs to use domain names taken from domains example.com or example.org.

* Section 3.7:

It would be helpful to include some message detail for F1, F2 and F3. It doesn't have to be complete, but should show the Session-ID header field.

* Section 4.1:

A couple of important things seem to have been left out of the list
principles:

- the originating UA should itself log all the requests in the dialog.

- the terminating UA should also log in-dialog requests that it marks and sends, and the corresponding responses.

(This could be simplified by simply saying that both UAs should log all messages in the dialog.)

* Section 4.2:

Similar comment to that for 4.1.

* Section 4.2.1:

IMO what is written in this section and subsections is both incomplete and overly complex.

ISTM that this can be greatly simplified:

- a dialog on one "side" of the B2BUA may or may not be coupled to a related dialog on the other "side" for logme purposes.

- by default related dialogs on the two sides are coupled. In cases where the B2BUA is more complex some related dialogs might not be coupled. (You can say as much or as little as you want about this.)

- if a dialog on one side is logme marked then a coupled dialog on the other side must also be so marked. This affects all messages in both dialogs.

* Section 4.2.2.2.1:

The actions are labeled by message id (Fn), but those for F2 and F3 don't correspond to the corresponding message. Also you missed a message. I think you mean:

    F1 - Alice's UA does not insert a "log me" marker in the dialog-
    creating INVITE request F1.  Nevertheless, Proxy 1 is configured to
    detect the start of logging.  Proxy 1 logs INVITE request F1 and
    maintains state that this dialog is being logged.

    F5 - Proxy 1 inserts a "log me" marker in INVITE request F5 before
    forwarding it to Proxy 2.

    F16 - Proxy 1 inserts a "log me" marker in ACK request F16 before
    forwarding it to Proxy 2).

    F22 - Proxy 1 inserts a "log me" marker in 200 response F22 before
    forwarding it to Proxy 2.

Also, should Proxy 1 also be inserting a "log me" marker into F6, F11, F14, and F20? In this topology they will probably be ignored by Alice, but maybe there can be cases where they are not.

* Section 4.2.2.2.3:

You forgot to mention:

    F8 - Proxy 2 inserts a "log me" marker in the 100 response it
    sends to Proxy 1.

* Section 4.2.2.2.4:

This section says:

    In Figure 6 below Proxy 2 removes "log me" marking from all SIP
    requests and responses entering network B.  Proxy 1 therefore
    maintains state of which dialogs are being "log me" marked in order
    to "log me" mark all requests and responses that it receives from
    Proxy 2.

The "therefore" in this doesn't make sense. IMO you can't expect that Proxy 1 knows a priori that Proxy 2 will do that and hence maintain state. Rather, I think you need to assume that Proxy 1 maintains state in any case, and then uses it to mark things if it observes that they haven't been marked already. So I suggest:

    In Figure 6 below Proxy 2 removes "log me" marking from all SIP
    requests and responses entering network B.  Proxy 1 maintains
    the marking state of the dialog. When it observes that requests and
    responses received from Proxy 2 are not marked it adds the
    marking.

However this seems to be in conflict with section 5.1. I don't know how to reconcile those.

* Section 5.2:

I question this. Consider a 3PCC case - Alice calls Bob via a B2BUA, then the B2BUA reconnects Alice to Charlie. It may turn out that Charlie has logme marking enabled. So this will appear during the dialog establishment with Charlie, but it will appear to be mid-dialog to Alice. I think you do want to log in this case.

* Section 7:

I suggest simplifying the ABNF as follows:

         sess-id-param       =/ logme-param

         logme-param         = "logme"

I expect that issues may still be raised regarding security and privacy, but I'm not an expert on that stuff and will leave it to others.

	Thanks,
	Paul

_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid