[secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02

Stefan Santesson <stefan@aaa-sec.com> Tue, 23 June 2009 16:51 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 852373A6B8B for <secdir@core3.amsl.com>; Tue, 23 Jun 2009 09:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.288
X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id bgQKs1zOQkBZ for <secdir@core3.amsl.com>; Tue, 23 Jun 2009 09:51:19 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se []) by core3.amsl.com (Postfix) with ESMTP id C311328C39E for <secdir@ietf.org>; Tue, 23 Jun 2009 09:51:18 -0700 (PDT)
Received: (qmail 27760 invoked from network); 23 Jun 2009 16:51:37 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([]) (envelope-sender <stefan@aaa-sec.com>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <secdir@ietf.org>; 23 Jun 2009 16:51:37 -0000
Received: (qmail 67118 invoked from network); 23 Jun 2009 16:51:30 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO []) (stefan@fiddler.nu@[]) (envelope-sender <stefan@aaa-sec.com>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <iesg@ietf.org>; 23 Jun 2009 16:51:30 -0000
User-Agent: Microsoft-Entourage/
Date: Tue, 23 Jun 2009 18:51:29 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, Bruce Davie <bsd@cisco.com>, Francois le Faucheur <flefauch@cisco.com>, Ashok Narayanan <ashokn@cisco.com>, James Polk <jmpolk@cisco.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <C666D4B1.2C65%stefan@aaa-sec.com>
Thread-Topic: SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02
Thread-Index: Acn0ItqU/YAdZG9qeEuzK09aj5lQSw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3328627890_1981279"
Subject: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Jun 2009 16:51:20 -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 specification define a set of procedures to overcome challenges with
deployment of Resource Reservation Protocols over BGP/MPLS VPNs.

The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely encryption
to ensure secrecy or message integrity. The security properties are instead
dependent on the security of the network infrastructure.

It appears that this draft makes a serious effort to describe and analyze
relevant security considerations. With my limited expertise in this
particular area I can't find any thing that is obviously missing.

However, one question that comes to my mind, which might be worth looking at
from a security perspective, is whether the procedures introduced by this
document requires the communication to be unencrypted and if so, whether
deployment of this protocol blocks or prevents legitimate use of e.g. IPsec
based VPN as discussed in RFC 4364 and RFC 4023. If this is the case, should
it be discussed in the security considerations section?

Stefan Santesson