Re: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Tue, 17 November 2015 09:17 UTC
Return-Path: <rmohanr@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653631B2D4E; Tue, 17 Nov 2015 01:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.086
X-Spam-Level:
X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 yZ-p3KfLcQle; Tue, 17 Nov 2015 01:17:21 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A89F1B2D48; Tue, 17 Nov 2015 01:17:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4810; q=dns/txt; s=iport; t=1447751841; x=1448961441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c3X/EepysXxwVTkAGoeU2qOEaj1qtjIGxeDO2cSIIGA=; b=fSzD/nOltjD9cAB0mZMkPnIm5LHVItkSyZvBWNkHXJzxUq5DpUHqybMU BRYFIk6vvckc65MWt2hEqT4MmggJKp3j2Aztoi/bFeTr38fgPLpZMzPuA O5ZLeqgMP0Hehk/WEPuocx4oXgqwCt3fYggHO1W0S8GVa/RASM5p+cbhe Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALAgCs70pW/5BdJa1UCYM7U2kGBrw9ghoBDYFlI4VtAoFKOBQBAQEBAQEBgQqENAEBAQQ6PwwEAgEIEQMBAh8QMh0IAgQBDQWILggFA7s+AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZVhH2EKgcKAYR9BZZJAYUfiAqBW0mDd45kAoNSg3EBHwEBQoQEcgELAQGDOzoBgQYBAQE
X-IronPort-AV: E=Sophos;i="5.20,307,1444694400"; d="scan'208";a="47447057"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2015 09:17:20 +0000
Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tAH9HKEM016738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 09:17:20 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 04:17:19 -0500
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 04:17:19 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>, "draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org" <draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org>, "straw@ietf.org" <straw@ietf.org>
Thread-Topic: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
Thread-Index: AQHRILYtRnP8BsSoEEqoxVoa7OqN7J6goUUA
Date: Tue, 17 Nov 2015 09:17:19 +0000
Message-ID: <D270EE25.494E0%rmohanr@cisco.com>
References: <564A4B26.4020108@bell-labs.com>
In-Reply-To: <564A4B26.4020108@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.8.151023
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [173.39.64.87]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5733618F4FCF5548AED7FB15B723950A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/XSvEDT-1VYpT-mzrs0-FNsdpJhE>
X-Mailman-Approved-At: Tue, 17 Nov 2015 20:31:36 -0800
Cc: "iesg@ietf.org" <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 09:17:23 -0000
Hi Vijay, Thanks for your review and feedback. Please see inline -----Original Message----- From: "Vijay K. Gurbani" <vkg@bell-labs.com> Date: Tuesday, 17 November 2015 at 3:01 AM To: "draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org" <draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org> Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "iesg@ietf.org" <iesg@ietf.org> Subject: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt Resent-From: <vkg@bell-labs.com> Resent-To: <draft-ietf-straw-b2bua-dtls-srtp.all@ietf.org> Resent-Date: Tuesday, 17 November 2015 at 3:01 AM >I have been selected as the Applications Area Directorate early >reviewer for this draft (for background on appsdir, please see >http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate) >. > >Please resolve these comments along with any other Last Call comments >you may receive. Please wait for direction from your document shepherd >or AD before posting a new version of the draft. > >Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt >Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP) > Back-to-Back User Agents (B2BUAs) >Reviewer: Vijay K. Gurbani >Review Date: 2015-11-16 >IETF Last Call Date: 2015-11-17 >IESG Telechat Date: 2015-12-03 > >Summary: This draft has minor issues, and is ready for publication as >a Proposed Standard once these issues are resolved. > >I will also (strongly) suggest that the editors go over the draft for >grammatical touches to eliminate the sort of issues present in the Nits >section. This will make the draft more readable and provide it the >gravity it needs for a standards track document. > >Major: 0 >Minor: 3 >Nits: Many > >Minor: > >- S3.1.1, second to last paragraph (beginning with "[RFC4474] provides > ... the signature."): Isn't this only true if the originating UAC > used rfc4474 and inserted the appropriate headers. Or is the > assumption that rfc4474 is always used, and therefore, a media relay > B2BUA must be careful and not modify the fingerprints? Right. This is true only when RFC4474 is used. We have re-worded the text to say the same. Here is the proposed new text: NEW: "When <xref target="RFC4474"/> is used forDTLS-SRTP sessions, the fingerprint attributes are integrity protected. Thus, under circumstances when <xref target="RFC4474"/> is used, B2BUAs cannot terminate the DTLS-SRTP session without invalidating the signature and causing the session to fail. > >- S3.1.2, first paragraph: "The identity integrity protection > procedures described in Security Considerations section..." > > Described in the Security Consideration section of which document? > The document under review or some other one (rfc7092)? Described in section 5 (Security Consideration) of this document. I will re-word to say the same. > >- S3.1.2.2: I am not sure what your takeaway is at the end of this > section. You seem to be making the case that a B2BUA cannot > modify the RTP headers and RTCP packets. But then you go on and > say that this can be mitigated by using different keys, and that > with "such an approach" (aside: define "such an approach"), the > B2BUA is not aware of the keys used to decrypt the media payload. > Well, the B2BUA is never aware of such keys, since they are > negotiated end-to-end (over the B2BUA), so I am at a loss to see > what is the point of this section. The idea of the section is to highlight that with current mechanisms it is not possible for B2BUA modify headers with out being a DTLS endpoint. In future (with PERC) it is possible that a B2BUA can modify the headers/RTCP packets but still have no access to the RTP payload. > >Nits: > >- Abstract: s/media plane, rather than/media plane rather than > >- Abstract: s/This document describes the behavior such B2BUAs can > adhere to/This document describes the behaviour of such B2BUAs/ > >- S1.1: s/The fingerprint, identifies/The fingerprint identifies > >- S3.1.2: > s/There are two types of media-aware relay/There are two types of > media-aware relays/ > >- S3.1.2.1: (For readability) > s/This kind of media aware relay/A RTP/RTCP aware media relay/ > >- S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/ Thanks. Will fix all the above Nits Regards, Ram > > (If you want to retain "the", perhaps you may consider renaming > Bob to Donald! Sorry, bad joke, I know.) > >Thanks, > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
- [apps-discuss] APPSDIR review of draft-ietf-straw… Vijay K. Gurbani
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Ram Mohan R (rmohanr)