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