[secdir] secdir review of draft-ietf-mpls-in-udp-09

Charlie Kaufman <charliekaufman@outlook.com> Wed, 07 January 2015 06:34 UTC

Return-Path: <charliekaufman@outlook.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65551A895C; Tue, 6 Jan 2015 22:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ujcrev2HYdz5; Tue, 6 Jan 2015 22:34:26 -0800 (PST)
Received: from COL004-OMC4S3.hotmail.com (col004-omc4s3.hotmail.com [65.55.34.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BE71A8749; Tue, 6 Jan 2015 22:34:26 -0800 (PST)
Received: from COL401-EAS231 ([65.55.34.201]) by COL004-OMC4S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 6 Jan 2015 22:34:26 -0800
X-TMN: [65HRksx9n8HuCMNeLT9wVZSv947W5blr]
X-Originating-Email: [charliekaufman@outlook.com]
Message-ID: <COL401-EAS231323CE5CC4F49693F893ADF460@phx.gbl>
From: Charlie Kaufman <charliekaufman@outlook.com>
To: <secdir@ietf.org>
Date: Tue, 6 Jan 2015 22:34:27 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
thread-index: AdAqP+F8Wy95lMIdTFiL8C/lr4JixA==
Content-Language: en-us
X-OriginalArrivalTime: 07 Jan 2015 06:34:26.0108 (UTC) FILETIME=[FB4D7FC0:01D02A43]
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PJuwDZ8lqZh9rMKofnzKILotOYo
Cc: draft-ietf-mpls-in-udp.all@tools.ietf.org, iesg@ietf.org
Subject: [secdir] secdir review of draft-ietf-mpls-in-udp-09
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: Wed, 07 Jan 2015 06:34:28 -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 specifies a syntax for encapsulating MPLS in UDP for the
purpose of tunneling MPLS packets across a non-MPLS portion of the network.
There are already RFCs specifying the encapsulation of MPLS in IP, GRE, and
L2TPv3. The motivation to specify yet another encoding is to take advantage
of the fact that many routers know how to load balance links based on UDP
ports, and this encoding gives the encapsulator the ability to take
advantage of that.

The security considerations follow other schemes for encapsulating MPLS,
though there are some gotchas. If the tunnel is protected using IPsec, the
UDP ports are hidden and there is little to no reason to use this protocol
over the (slightly) more efficient MPLS over IP. Protecting the tunnel using
DTLS may be viable if the size of the DTLS header is not prohibitive. I
would expect that it would be common for the tunnel to be unprotected while
the tunneled connections are protected with some cryptographic protocol
(though this leaves the system open to network-overloading denial of service
attacks).

I could find nothing to take issue with.

Formatting glitch: At least on my system, Viewing the pdf version of the
document shows page 4 as being reduced to about 1/4 of its correct size
(i.e. 5 or 6 point font).

	--Charlie