DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:date:message-id:subject:from:to:content-type;
 b=CRtlxF4pvb+FbsI4pnYGn6UON8d5hj+sUDeFNqDYkX4kycD8fV5ALBIU3IeB7mjCkD
 BYHHONXAcSWuFYMnSKHj6Cm3Q/f1Xe4S7Kwb303sYUAV1Mz9JIIlYf7/PikORX/4w3lT
 Xo/P/Tdq5NLuHo/cQoMpOr4AHC9tTKvTTzBKg=
MIME-Version: 1.0
Date: Wed, 28 Apr 2010 20:38:25 -0700
Message-ID: <r2z2f57b9e61004282038h92e98433m618c47c04edeb703@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: draft-ietf-mpls-tp-framework@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Content-Type: multipart/alternative; boundary=0016368e33a6eeab93048557db46
Subject: [secdir] Secdir review of draft-ietf-mpls-tp-framework-11
Precedence: list

--0016368e33a6eeab93048557db46
Content-Type: text/plain; charset=ISO-8859-1

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 describes the architectural framework for applying MPLS to
transport networks. It is joint work with the ITU-T.

The document does not contain any normative statements in the RFC 2119
sense; presumably this is because the framework nature of the document
and/or the coupling to ITU-T, but it is a little concerning as there are a
number of "must", "should" and "may" statements in the document that do look
normative to me (e.g. "In cases where a MAC address is needed, the sending
node must set the destination MAC address to an address that ensures
delivery to the adjacent node.").

The security considerations section is very brief and consists mainly of
references to other, related documents' security considerations sections. I
think it could have been beneficial if it had covered security aspects
stemming from the architectural framework and not only force the reader to
turn to the component documents. For example, since G-ACh traffic is
indistinguishable at the server layer from data traffic, is it possible to
craft data traffic messages that confuse a server to believe it is G-ACh?
Or, does the bandwidth sharing between control traffic and user data traffic
have any security implications? Also, the NNI traffic may involve signaling
over the same channel as user data traverse which may cause similar concerns
(I am not an expert on MPLS or TP so these threats may well not be
realistic, however they serve only as examples).

(A minor editorial suggestion: Perhaps better if the list of acronyms in
Section 1.3 would be in alphabetical order?)

-- Magnus

--0016368e33a6eeab93048557db46
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I have reviewed this document as part of the security=20
directorate&#39;s
ongoing effort to review all IETF documents being processed by the
IESG. =A0These comments were written primarily for the benefit of the
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments.<br>
<br>
</div>This document describes the architectural framework for applying MPLS=
 to transport networks. It is joint work with the ITU-T.<br><br>The documen=
t does not contain any normative statements in the RFC 2119 sense; presumab=
ly this is because the framework nature of the document and/or the coupling=
 to ITU-T, but it is a little concerning as there are a number of &quot;mus=
t&quot;, &quot;should&quot; and &quot;may&quot; statements in the document =
that do look normative to me (e.g. &quot;In cases   where a MAC address is =
needed, the sending node must set the   destination MAC address to an addre=
ss that ensures delivery to the   adjacent node.&quot;).<br>
<br>The security considerations section is very brief and consists mainly o=
f references to other, related documents&#39; security considerations secti=
ons. I think it could have been beneficial if it had covered security aspec=
ts stemming from the architectural framework and not only force the reader =
to turn to the component documents. For example, since G-ACh traffic is ind=
istinguishable at the server layer from data traffic, is it possible to cra=
ft data traffic messages that confuse a server to believe it is G-ACh? Or, =
does the bandwidth sharing between control traffic and user data traffic ha=
ve any security implications? Also, the NNI traffic may involve signaling o=
ver the same channel as user data traverse which may cause similar concerns=
 (I am not an expert on MPLS or TP so these threats may well not be realist=
ic,=20
however they serve only as examples).<br><br>(A minor editorial suggestion:=
 Perhaps better if the list of acronyms in Section 1.3 would be in alphabet=
ical order?)<br><br>-- Magnus<br>

--0016368e33a6eeab93048557db46--