Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Mon, 22 August 2016 19:40 UTC

Return-Path: <pgiralt@cisco.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 472CC12D1E4 for <insipid@ietfa.amsl.com>; Mon, 22 Aug 2016 12:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.068
X-Spam-Level:
X-Spam-Status: No, score=-15.068 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 noaOzmZcMoFK for <insipid@ietfa.amsl.com>; Mon, 22 Aug 2016 12:40:27 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AF112D177 for <insipid@ietf.org>; Mon, 22 Aug 2016 12:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14560; q=dns/txt; s=iport; t=1471894827; x=1473104427; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+NiCdC7yIUFjYc/9rwGX9BtTvG6jIPlUBVSfSxcwWpU=; b=dIDUZvyhKZL3Yeb720DcE6CSQQrHju1ilqxdTtw/qURQwf3fN3ALSSuk yk2tdqskd52J3DexT1qHBt9EYdVNBjBVoA2z6C9j/TSWH1KGz3gcj8t8h 0yxwJr3xAidnCS9JU/j7EjT95+aYfM8PvSCc6IOXSMsRNu7A+9pfffmqd 0=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AwARVLtX/4sNJK1dg0RWbQ8HsneFC?= =?us-ascii?q?IF9JIUvSgKBZTgUAgEBAQEBAQFeJ4ReAQEEAQEBIUsLBQsCAQgYJwMCAicLFBE?= =?us-ascii?q?CBA4FDogbCA6tbJAJAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgkFhiuBeAiCTYdBK?= =?us-ascii?q?4IvBZlIAYM9gXNviH+BbYRcgzOFVIw/g3cBHjaCEhyBTHCFfH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,561,1464652800"; d="asc'?scan'208,217";a="314053150"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2016 19:40:26 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u7MJePQL011379 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 19:40:26 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 15:40:24 -0400
Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 15:40:24 -0400
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
Thread-Topic: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
Thread-Index: AQHR/K0HPKaduKClik2Gt0Rn99/xSQ==
Date: Mon, 22 Aug 2016 19:40:24 +0000
Message-ID: <705044F6-1B62-4527-B67A-57422B1BBD6C@cisco.com>
References: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com>
In-Reply-To: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.81.96.60]
Content-Type: multipart/signed; boundary="Apple-Mail=_4A2C0F14-FFE7-46B2-9A35-3E70FB9B6A80"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/1z3zSdIAISPepcW1rrSOxWBlRCE>
Cc: "Arun Arunachalam \(carunach\)" <carunach@cisco.com>, "ben@nostrum.com" <ben@nostrum.com>, "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 22 Aug 2016 19:40:29 -0000

Some feedback on this document

Section 5.1: I didn’t quite understand the point of this section. Shouldn’t configuration be totally out of scope of the document? I didn’t feel like this section added any value to the document.

Section 5.2: Perhaps mention that another criteria a proxy or UA can use is a calling / called party number. This actually seems like the most likely scenario for troubleshooting.

Section 5.7: Should this be a normative statement? (e.g. An intermediary forking a request MUST copy log-me markings to all forked requests).

Section 5.8.3.1: I’m confused about this section. What does “controlled by explicit configuration of the originating side” mean? I would think signaling-only B2BUAs should still copy log-me markings from originating to terminating by default. I’m thinking the situation of a soft-switch in an SP network acting as a signaling-only B2BUA as opposed to a proxy or proxy-B2BUA (7092 is not very clear as to which one a soft switch falls into). In such a scenario, the desired behavior would be to always copy log-me from originator to terminator.

But then in Section 5.8.4, the reader is referred back to 5.8.2/3 for how to behave even if they are media terminating. This type of B2BUA would more likely be an SBC where a network operator might want to filter out log-me messages because they act as a trust boundary in which case the forwarding from originating to terminating should be configurable.

Section 5.9.1 and 5.9.2: The references to 7206 should be replaced with the RFC number assigned to [draft-ietf-insipid-session-id-27]/ 7206 doesn’t actually define the Session-ID header.

Section 5.9.2: A Session-ID may change within the same dialog due to protocol interworking somewhere further downstream. Is the intention really for this to generate a separate log file? How does this affect the requirement that a new logging session cannot start mid-dialog? From the perspective of the device doing the logging, the dialog may not have changed, but the Session-ID changed.

Section 6.2.1: What determines whether a marker has been “incorrectly inserted”?

Section 6.2.2: What do you mean by “it MUST NOT be readable by an unauthorized third party”? I’m not clear what “it” refers to. Seems like it refers to “activating a debug” but I’m not sure what “activating a debug MUST not be readable” means.

Section 6.3: Suggesting that logs SHOULD be encrypted seems like a stretch to me. Of course that doesn’t have to be followed, but most platforms today don’t encrypt their log files. I’d rather this say something like

   A SIP entity that has logged information MUST protect the logs, such that
   the logs can only be read by a person authorized to do so.

If others feel we should impose encryption, I’m okay with it staying a SHOULD but realistically seems unlikely most will implement it.

As far as I can tell, a device implementing log-me MUST implement [draft-ietf-insipid-session-id-27], correct? Seems like this should be called out at the beginning of the document (and of course added as a normative reference once the RFC number is assigned).

Does I-D.ietf-insipid-logme-reqs really have to be a normative reference? Seems like it should be Informative.


Nits:

s/signalling/signaling/g

I’d prefer is the references were not duplicated in the text (e.g. RFC 7206 [RFC7206] or defined in draft-ietf-insipid-logme-reqs [I-D.ietf-insipid-logme-reqs])

-Paul



> On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com> wrote:
> 
> Dear INSIPID Participants,
> 
> We have finally completed the Session-ID draft and it is now in the RFC Editor’s queue. It is now time to move forward with the completion of the pending bottlenecked milestones. The first one of these is draft-ietf-insipid-logme-reqs, which has previously received sufficient review and currently has no pending unaddressed issues.
> 
> This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07 <https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs>), to end on Friday September 9th, 2016. Please post comments and feedback to the insipid@ietf.org <mailto:insipid@ietf.org> list, including just a simple "looks good” if you have read the draft and have no material comments.
> 
> I kindly request the authors to please address any WGLC comments in a timely fashion.
> 
> It is my hope we can muster the energy for a final push to finish up the two remaining milestones and then close out this WG.
> 
> Regards,
> 
> Gonzalo (as chair)
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid