Last Call Review of draft-ietf-mpls-in-udp-09
review-ietf-mpls-in-udp-09-secdir-lc-kaufman-2015-01-08-00

Request Review of draft-ietf-mpls-in-udp
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-01-12
Requested 2015-01-02
Authors Xiaohu Xu, Nischal Sheth, Lucy Yong, Ross Callon, David Black
Draft last updated 2015-01-08
Completed reviews Genart Last Call review of -04 by Roni Even (diff)
Genart Last Call review of -09 by Roni Even (diff)
Secdir Last Call review of -09 by Charlie Kaufman (diff)
Secdir Early review of -03 by Charlie Kaufman (diff)
Opsdir Last Call review of -04 by Nevil Brownlee (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-mpls-in-udp-09-secdir-lc-kaufman-2015-01-08
Reviewed rev. 09 (document currently at 11)
Review result Ready
Review completed: 2015-01-08

Review
review-ietf-mpls-in-udp-09-secdir-lc-kaufman-2015-01-08

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