[Gen-art] Gen-ART review of draft-ietf-l3vpn-ipsec-2547-05

Harald Tveit Alvestrand <harald@alvestrand.no> Mon, 06 February 2006 14:56 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F67nC-0004VF-9S; Mon, 06 Feb 2006 09:56:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F67nA-0004Ui-1u for gen-art@megatron.ietf.org; Mon, 06 Feb 2006 09:56:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24756 for <gen-art@ietf.org>; Mon, 6 Feb 2006 09:54:54 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F67zL-00006F-Vt for gen-art@ietf.org; Mon, 06 Feb 2006 10:09:13 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF6F7259726; Mon, 6 Feb 2006 15:55:08 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02529-06; Mon, 6 Feb 2006 15:55:03 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A80EE259727; Mon, 6 Feb 2006 15:55:01 +0100 (CET)
Date: Mon, 06 Feb 2006 15:48:50 +0100
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: gen-art@ietf.org, erosen@cisco.com, jeremy.de_clercq@alcatel.be, olivier.paridaens@alcatel.be, yves.tjoens@alcatel.be, Mark Townsley <townsley@cisco.com>
Message-ID: <9FD414239DCA406D08829318@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc:
Subject: [Gen-art] Gen-ART review of draft-ietf-l3vpn-ipsec-2547-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0282638451=="
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org

For background on gen-ART, see 
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>

Document: draft-ietf-l3vpn-ipsec-2547-05
Reviewer: Harald Tveit Alvestrand
Summary: Incomplete specification

The document can be summarized as follows:

- If you don't trust everyone who can inject a packet into your MPLS, 
security is a problem.
- Multiprovider BGP-MPLS VPNs require mutually untrusting SPs to exchange 
MPLS packets
- PE-PE links can be created using IPSec transport mode tunnels. This is 
useful in the above case.
- The desire to have such links can be signalled by the egress PE using BGP 
extended attributes.

This isn't exactly controversial stuff, and sounds like a fairly simple 
thing to document so that one can have interoperable experimentation to 
identify problems with the approach. But this document is not a good basis 
for such an experiment.

The document has a number of problems:

- The document jumps back and forth between considering the security 
implications of various ways of doing multiprovider VPNs and specifying the 
mechanisms for this particular proposal.
- The document is very incomplete, lacking the specification of the exact 
BGP attributes to be used to negotiate the connections, and the details of 
the certificate structures and IPSec parameters that are needed for 
interoperability - this makes it very hard to participate in the experiment 
implied by "experimental" status.
- The document uses unusual terminology for IPSec operations ("packet 
removed from IPsec SAs"), which makes the document hard to follow.
- The document jumps around between specifying the principles and protocols 
and discussing implementation details; this makes it very hard to see which 
is which.
- The document's security considerations section is a cop-out.

Nevertheless, I find it hard to get terribly excited about an Experimental 
document - at least if I take its aiming at Experimental seriously, rather 
than as an excuse to get an RFC number without a standards-track review.

My big issue with the document is that it's incomplete - you can't 
participate in the experiment unless you know more than what's here.

And that's, in my opinion, not a Good Thing.


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art