Re: [secdir] Secdir review of draft-ietf-mpls-tp-framework-11

["Bocci, Matthew (Matthew)" <[e-mail]>]

Magnus,

Many thanks for your review. Please see below for some responses.

Best regards,

Matthew, Stewart and Dan

----- Original Message -----
From: "Magnus Nyström" <[e-mail]<mailto:[e-mail]>>
To: <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>
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
>