[secdir] SECDIR Review of draft-kumaki-murai-l3vpn-rsvp-te/

Phillip Hallam-Baker <hallam@gmail.com> Fri, 21 September 2012 17:19 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6330521F8707 for <secdir@ietfa.amsl.com>; Fri, 21 Sep 2012 10:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.89
X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hvk6r-O3AZet for <secdir@ietfa.amsl.com>; Fri, 21 Sep 2012 10:19:18 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5B5FB21F86FF for <secdir@ietf.org>; Fri, 21 Sep 2012 10:19:18 -0700 (PDT)
Received: by oagn5 with SMTP id n5so3362471oag.31 for <secdir@ietf.org>; Fri, 21 Sep 2012 10:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=53jnykOMI0oIaOoZEOG6ibEFfn+pRVv9PkfXoUcWQ7E=; b=rA91hjRV+Dz9y778/B3aWlXxdYckL2vBKhE+35kaCFvIIMeS4NwnTDYKHOpmLZpCHG WwqIygRqfktON2kKbhDJm5RFwH1iYXxmRY5m1+mXp25NX0XlL2pMWxkc6DB0u76mtUn/ 9tKEmjF55XvfgzvmeH6ETbEx+59D6Th6fC41LuW5hbA+MYcwAwouz6nlVWI5+zMxNbw4 mzszAPjHcjik/3CXu0CV4xdh4lbNCVt7iMsYdHmURASjepn9mZIVRRDzlvnBBwkZkec4 LGG0VzN7GysrbiRl1C/znrc2Q9ANj0BYoS0iFJmlT81BfIw6soJ2yj2OM/hz9ziNBK3T pESw==
MIME-Version: 1.0
Received: by with SMTP id ai9mr1435942oec.36.1348247957803; Fri, 21 Sep 2012 10:19:17 -0700 (PDT)
Received: by with HTTP; Fri, 21 Sep 2012 10:19:17 -0700 (PDT)
Date: Fri, 21 Sep 2012 13:19:17 -0400
Message-ID: <CAMm+LwjU0g4YF2u56q9YpSTxMyGX9XY7gH_-jHNT4ResaU5fVQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: secdir@ietf.org, ke-kumaki@kddi.com, murai@fnsc.co.jp, dean.cheng@huawei.com, satoru.matsushima@tm.softbank.co.jp, pe-jiang@kddi.com, draft-kumaki-murai-l3vpn-rsvp-te@tools.ietf.org
Content-Type: multipart/alternative; boundary=bcaec54a3e029812f404ca397082
Subject: [secdir] SECDIR Review of draft-kumaki-murai-l3vpn-rsvp-te/
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Sep 2012 17:19:19 -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.

The specification describes a mechanism for exchanging RSVP routing
information to support multi-site VPNs in the case that a connection
supports multiple VPNs.

The document lacks a substantive security considerations section, instead
referencing RFC3209 for security considerations. I do not think this is
appropriate since that document was published in 2001 when security
considerations were still insubstantial and in the case ofd RFC 3209
consist of a reference to RFC 2205 which is also pro-forma.

rfc6437 has a much better presentation of the issues involved.

While people tend to use Security Considerations to list the problems with
a protocol there is no real reason this should be the case. The SC should
address all the considerations, positive and negative

Here we have a model where the VPN is providing authentication and
integrity checking end to end. That only leaves service and traffic
analysis as concerns with respect to routing level attacks. But there
should be discussion of the possibility that a member of the VPN network
might introduce malicious routing data to redirect traffic. Either to do
traffic analysis or to perform a DoS attack.

While this is not something members of a VPN are likely to do
intentionally, it is something an attacker might do if they own one site.
The risk here is that when you join a VPN club you may be exposing yourself
to the vulnerabilities/exploits of the weakest member of the club. And they
may be able to clobber you through them. So large scale systems might well
have rules about auditing and security policies they would need in place.
They should also sanity check the routes advertised.

Using a VPN does have a penalty as well as it means that the packet
contents are now opaque to the good guys as well as the bad. Port filtering
is no longer possible, spam filtering is hard and so on.

Website: http://hallambaker.com/