[secdir] Secdir review of draft-ietf-mpls-tp-framework-11
Magnus Nyström <magnusn@gmail.com> Thu, 29 April 2010 03:38 UTC
Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2CA28C18F; Wed, 28 Apr 2010 20:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.302
X-Spam-Level:
X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKke9wjpaz0k; Wed, 28 Apr 2010 20:38:42 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 969403A67B3; Wed, 28 Apr 2010 20:38:42 -0700 (PDT)
Received: by gwaa12 with SMTP id a12so4294200gwa.31 for <multiple recipients>; Wed, 28 Apr 2010 20:38:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Ec/m4dy4HeYgydqVhNfaGnBqjx3KV5//LyK52BxU3XQ=; b=CwzZeJwJoHSSdeDFRa1mnkxRevsGsaMMzoHegBjJPBwe0ENEJh85BYv+/kINrc528O 0WNWKtLSZcJb7FNuufmmRMySjxdinyFQiCjOi9KIbtQZbJ6DeziBzLpW+tUSMHESvQIN HZ26+ZxLgdcShqfsy/A2pB/f9cG7upNYs6VdM=
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
Received: by 10.101.170.38 with SMTP id x38mr4076026ano.211.1272512305343; Wed, 28 Apr 2010 20:38:25 -0700 (PDT)
Received: by 10.100.124.16 with HTTP; Wed, 28 Apr 2010 20:38:25 -0700 (PDT)
Date: Wed, 28 Apr 2010 20:38:25 -0700
Message-ID: <r2z2f57b9e61004282038h92e98433m618c47c04edeb703@mail.gmail.com>
From: Magnus Nyström <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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 29 Apr 2010 03:38:44 -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 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
- [secdir] Secdir review of draft-ietf-mpls-tp-fram… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-mpls-tp-… Bocci, Matthew (Matthew)
- Re: [secdir] Secdir review of draft-ietf-mpls-tp-… Magnus Nyström