[secdir] Secdir review of draft-ietf-p2psip-drr-11

Brian Weis <bew@cisco.com> Fri, 31 January 2014 22:20 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2B3C01A0574; Fri, 31 Jan 2014 14:20:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Status: No, score=-15.036 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.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o7OMlrVV_9GO; Fri, 31 Jan 2014 14:20:05 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 68D3E1A04E8; Fri, 31 Jan 2014 14:20:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1796; q=dns/txt; s=iport; t=1391206802; x=1392416402; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=qK6eYXw1WIGKFbEUApWxK3TPdtlwG6+N4FJktpa5Cs0=; b=fRqk7WkDxbhkmceEnwFjlzHWL4X0nfVE04+o/tvhU83iXmiKuf/WuvGE jMmTceVWmEdb5cRRuyaPGqeYx+f8DJ0X1sXKD/i+cykX3gDDR16jaD2Yq stUp6qFLScCDMc6JzzRoewnubjtzMx/mh5UuwdTkm0C9mjBDYnhd56d/z 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMGAOog7FKrRDoJ/2dsb2JhbABZgwypDpVagQ8WdIJmP4E+AYgWzS4XjwKDK4EUBIlJjmGGSItZg04b
X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="104502416"
Received: from mtv-core-4.cisco.com ([]) by mtv-iport-4.cisco.com with ESMTP; 31 Jan 2014 22:19:59 +0000
Received: from [] ([]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0VMJxLY016883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jan 2014 22:19:59 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Jan 2014 14:19:59 -0800
Message-Id: <A71C179D-F981-40A0-8E3B-0A810FD79CC1@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Cc: "draft-ietf-p2psip-drr.all@tools.ietf.org" <draft-ietf-p2psip-drr.all@tools.ietf.org>
Subject: [secdir] Secdir review of draft-ietf-p2psip-drr-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 22:20:07 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes a routing mechanism for Peer-to-Peer Session Initiation Protocol (P2PSIP). The routing mechanism in the base P2PSIP protocol specifies an initiator sending a request message hop by hop through a DHT to a responder, with the responder returning a reply using the reverse path. The alternative routing method defined in this I-D describes a shortcut for the response message. The response is returned directly to the initiator using an IP address provided by the initiator. This shortcut method is described as an optimization that is useful in private networks where a self-reported IP address is likely to be reliable (i.e., no NAT).

I previously reviewed draft-ietf-p2psip-drr-10 and had some clarification questions and minor comments. This version adequately addressed those comments, and I have no additional concerns.

The only thing that I wish could be clarified in the draft is that the "DRR(DTLS)" values for "No. of Msgs" values in Table 1 and Table 2 assume that the DTLS session had been setup previously, so the cost of those messages is thus not included in this table. That's fine, but the cost of setting up that session might not be obvious to someone looking at the tables and it would be worth pointing it out explicitly in the text. But this is not a security consideration concern, only a suggestion to make the draft easier to understand.