Re: [secdir] Secdir review of draft-ietf-mpls-tp-framework-11
Magnus Nyström <magnusn@gmail.com> Wed, 05 May 2010 04:49 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 D15703A6A99; Tue, 4 May 2010 21:49:07 -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 SsScQBvKPxKJ; Tue, 4 May 2010 21:49:06 -0700 (PDT)
Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id E23C83A6A8A; Tue, 4 May 2010 21:49:05 -0700 (PDT)
Received: by yxe9 with SMTP id 9so1685560yxe.29 for <multiple recipients>; Tue, 04 May 2010 21:48:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XzcKMHgq/Ev8tM2GYU4ZETl8r2S+WtACapEs2TeDvxQ=; b=k4uLZCumsMfC0OrKW+BwKmjKl8kZ+s8AxnWoL5+pNcNPIPnMXOhJdDiXbzZzb5V1vQ FDKU1mbtnA9xOl7u0A+y0wD5EFm2OmLDgH7BzyFX5Vs6vSwmDP9RhnlBnqCtlH09UpWT ph0/9udikN4FCfHsIjPXn2uEscfc2oy6F8B1U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BnWI1nQDg8wf0Ad5hyLLAPA+B2m6b7rQezd2kFyYp+5MXwrdf47Ssg566CYzzqf+iZ g+KOBQAuG0Q5sPQeQOjtVmO32aEBQ2wOMpSNCLAjUKN5E372LEjsEVXj46iZO6RgVKZA tmbSUyOtDnDSA6kEXUgcLoCuRXFSPNsct/yT4=
MIME-Version: 1.0
Received: by 10.101.172.1 with SMTP id z1mr5134859ano.20.1273034928378; Tue, 04 May 2010 21:48:48 -0700 (PDT)
Received: by 10.100.124.16 with HTTP; Tue, 4 May 2010 21:48:48 -0700 (PDT)
In-Reply-To: <030F37126795E34DB4796609C4FEAA4A127EA83AD1@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com>
References: <r2z2f57b9e61004282038h92e98433m618c47c04edeb703@mail.gmail.com> <030F37126795E34DB4796609C4FEAA4A127EA83AD1@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com>
Date: Tue, 04 May 2010 21:48:48 -0700
Message-ID: <i2x2f57b9e61005042148sbfd09e8evfcf54006b31f2e9b@mail.gmail.com>
From: Magnus Nyström <magnusn@gmail.com>
To: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="001636c92539b155c70485d18ab1"
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mpls-tp-framework@tools.ietf.org" <draft-ietf-mpls-tp-framework@tools.ietf.org>
Subject: Re: [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: Wed, 05 May 2010 04:49:07 -0000
Thanks for your prompt response, Matt (and all). Your suggestions make sense to me and look good to me (perhaps I would suggest that you change " It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security considerations" to " It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security measures" ) Best, -- Magnus On Tue, May 4, 2010 at 3:44 AM, Bocci, Matthew (Matthew) < matthew.bocci@alcatel-lucent.com> wrote: > Magnus, > > Many thanks for your review. Please see below for some responses. > > Best regards, > > Matthew, Stewart and Dan > > ----- Original Message ----- > From: "Magnus Nyström" <magnusn@gmail.com> > To: <draft-ietf-mpls-tp-framework@tools.ietf.org>; <iesg@ietf.org>; < > secdir@ietf.org> > Sent: Thursday, April 29, 2010 4:38 AM > Subject: Secdir review of draft-ietf-mpls-tp-framework-11 > > > >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 draft is informational, and therefore should not really include > statements > that look like normative instructions. However, the document has had > extensive review > in the ITU and they need some guidance as to some of the normative > characteristics > of MPLS-TP. Therefore there are some cases where we have quoted the > relevant requirements > documents and thereofre 'must' appears. In other cases we propose to change > 'must' to > a statement such as 'needs to'. > > > > 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? > > These sorts of security considerations are covered by the data plane > security discussion referenced from RFC5586->RFC5085 (VCCV). > Since this is rather an indirect reference, we propose to add the following > text, which is based on that in RFC5085: > > " MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) > associated > with a pseudowire, LSP or section. This control channel can be signaled > or > statically configured. Over this control channel, control channel > messages related > to network maintenance functions such as OAM, signaling or network > management are sent. > Therefore, three different areas are of concern from a security > standpoint. > > The first area of concern relates to control plane parameter and > status message attacks, that is, attacks that concern the signaling > of G-ACh capabilities. MPLS-TP Control Plane security is discussed in > [I-D.ietf-mpls-gmpls-security-framework]. > > A second area of concern centers on data-plane attacks, that is, > attacks on the G-ACh itself. MPLS-TP nodes that implement the > G-ACh mechanisms are subject to additional data-plane denial-of- > service attacks as follows: > > An intruder could intercept or inject G-ACh packets effectively > disrupting the protocols carried over the G-ACh. > > An intruder could deliberately flood a peer MPLS-TP node with G-ACh > messages to deny services to others. > > A misconfigured or misbehaving device could inadvertently flood a > peer MPLS-TP node with G-ACh messages which could result in denial of > services. In particular, if a node has either implicitly or > explicitly indicated that it cannot support one or all of the > types of G-ACh protocol, but is sent those messages in sufficient > quantity, > it could result in a denial of service. > > To protect against these potential (deliberate or unintentional) > attacks, multiple mitigation techniques can be employed: > > G-ACh message throttling mechanisms can be used, especially in > distributed implementations which have a centralized control-plane > processor with various line cards attached by some control-plane > data path. In these architectures, G-ACh messages may be processed > on the central processor after being forwarded there by the > receiving line card. In this case, the path between the line card > and the control processor may become saturated if appropriate G-ACh > traffic throttling is not employed, which could lead to a complete > denial of service to users of the particular line card. Such > filtering is also useful for preventing the processing of unwanted > G-ACh messages, such as those which are sent on unwanted (and > perhaps unadvertised) control channel types. > > A third and last area of concern relates to the processing of the > actual contents of G-ACh messages. It is necessary that the definition > of the protocols using these messages carried over a G-ACh include > appropriate security considerations." > > > > > > Or, does the bandwidth sharing between control traffic and user data > > traffic have any security implications? > > We have a warning in section 3.6 that sufficient bandwidth needs to be > provisioned to cope with the expected G-ACh traffic on an LSP or PW. > However, this could of > course be abused. For example, a malicious or faulty node could inject > sufficient traffic > into A G-Ach to cause a DoS on the control processor of a receiving node. > This is > covered in the data plane portion of the security considerations text that > we propose to insert > (see above). > > > 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). > > > > I think that the specific issue of isolation between user and control > channel traffic is addressed by > the proposed text above and by existing RFCs dealing with NNI-like > applications of MPLS (e.g. RFC5659). > I think we need to make it clear that when a particular architecture or > protocol belonging to MPLS is profiled for transport, > the profile inherits the security considerations applicable to MPLS today. > I propose that we add a statement describing this > to the start of the security considerations section: > "When an MPLS function is included in the MPLS transport profile, the > security considerations pertinent to > that function apply to MPLS-TP." > > > > (A minor editorial suggestion: Perhaps better if the list of acronyms > > in Section 1.3 would be in alphabetical order?) > > Thanks. We will reorder the acronyms. > > > > > > > -- Magnus > > > > > -- -- 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