[secdir] secdir review of draft-ietf-mpls-tp-on-demand-cv

Sandra Murphy <Sandra.Murphy@sparta.com> Thu, 25 August 2011 23:31 UTC

Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298AE21F8B62; Thu, 25 Aug 2011 16:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.213
X-Spam-Level:
X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ary7MYR0QkC; Thu, 25 Aug 2011 16:31:35 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2321F8B5D; Thu, 25 Aug 2011 16:31:34 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p7PNWjBl009300; Thu, 25 Aug 2011 18:32:45 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p7PNWcKA027916; Thu, 25 Aug 2011 18:32:39 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.112]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 19:32:36 -0400
Date: Thu, 25 Aug 2011 19:32:35 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: secdir@ietf.org, iesg@ietf.org
Message-ID: <Pine.WNT.4.64.1108251917420.7464@SMURPHY-LT.columbia.ads.sparta.com>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 25 Aug 2011 23:32:36.0101 (UTC) FILETIME=[45446B50:01CC637F]
Cc: draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-mpls-tp-on-demand-cv
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 25 Aug 2011 23:31:36 -0000

I reviewed draft-ietf-mpls-tp-on-demand-cv 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 draft extends LSP-PING to provide ping/traceroute for MPLS-TP LSPs 
and PWs, using G-ACh when the intermediate nodes would not be able to 
provide the IP service LSP-PING requires.

Background: LSP-PING (RFC4379) was defined to provide connectivity checks 
(like ping) and route tracing checks (like traceroute) for MPLS LSPs. 
LSP-PING uses an IP packet format to be carried as payload under the MPLS 
labels (RFC4379).  Each node is presumed to have an IP host stack to 
process the IP packet format.  Pseudowires (PW - RFC 3985) are constructed 
over varying packet switched nodes types, including MPLS as well as IP, so 
could not count on the IP capability being present in any PW node.  PWE3 
defined their own connection verification (VCCV - RFC5085) function, which 
uses a PW control channel feature, identified in MPLS networks by a ACH - 
Associated Channel Header (RFC4385).  A generic version (G-ACh) of the PW 
control channel ACH was defined for use with LSPs (and "Sections", haven't 
quite grasped that yet) - RFC5586.  MPLS-TP (RFC5921) is a "profile" of 
MPLS for providing a transport service and this draft was needed to 
provide MPLS-TP its own ping/traceroute capability using the G-ACh.

Security comments

This draft defines a new Channel Type for the G-ACh control channel 
defined in RFC5586.  The Channel Type indicates the particular protocol 
using the generic G-ACh.   The security considerations section of RFC5586 
says that:

    The security considerations for the associated control channel are
    described in RFC 4385 [RFC4385].  Further security considerations
    MUST be described in the relevant associated channel type
    specification.

And RFC4385 makes a stronger warning:

    An application using a PW Associated Channel must be aware that the
    channel can potentially be misused.  Any application using the
    Associated Channel MUST therefore fully consider the resultant
    security issues, and provide mechanisms to prevent an attacker from
    using this as a mechanism to disrupt the operation of the PW or the
    PE, and to stop this channel from being used as a conduit to deliver
    packets elsewhere.  The selection of a suitable security mechanism
    for an application using a PW Associated Channel is outside the scope
    of this document.

Finally, RFC5921 (MPLS-TP) reiterates that:

    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 measures.

This draft's security considerations section is brief and only points to 
the security considerations of LSP-PING:

    The draft does not introduce any new security considerations.  Those
    discussed in [RFC4379] are also applicable to this document.

Perhaps the authors considered this adequate to satisfy the requirements 
from 5586 and 4385 and 5921 for consideration of the security issues.  But 
I am not sure that all the security discussion of RFC4379 apply to this 
new CV protocol.

RFC4379 (LSP-PING) and RFC5085 (VCCV) both discuss the concerns about 
misuse of the control channel - intercepting or injecting packets, 
flooding, etc.  LSP-PING discusses potential mitigation techniques based 
on rate limiting to the UDP port, and filtering and access lists based on 
the source and destination addresses of the LSP-PING payload.  This draft 
defines source and destination ID TLVs for the non-IP use of this 
on-demand-cv, which contain identifiers (see 
draft-ietf-mpls-tp-identifiers) that sound like they could also be used 
for filters and access lists (the "global ID" is typically the ASN and the 
"node ID" is typically the IP address -- but specifically not required to 
be - for example, probably not when they are "compatible with ITU-T 
transport-based operations".). Unfortunately, the source and destination 
ID TLVs are a MAY, so they don't have to appear.  So I don't believe that 
the mitigations suggested in RFC4379 apply to this draft in a 
straightforward way.

VCCV has a different suggestion for protection:

                                                  However the
       implementation of the connectivity verification protocol expands
       the range of possible data-plane attacks.  For this reason
       implementations MUST provide a method to secure the data plane.
       This can be in the form of encryption of the data by running IPsec
       on MPLS packets encapsulated according to [RFC4023], or by
       providing the ability to architect the MPLS network in such a way
       that no external MPLS packets can be injected (private MPLS
       network).

(Note that when VCCV and MPLS-TP talk about data plane attacks they mean 
the payloads in the control channel, not the user data traffic.)

RFC4023 is encapsulating MPLS in IP or GRE, so again these techniques 
would not apply to the non-IP case that is the motivation for this draft. 
Of course, the "private MPLS network" mitigation will continue to work. 
(Probably not in inter-domain applications - perhaps inter-domain pings 
would be rare.)

So I doubt that this draft can rely completely on the security 
considerations section of LSP-PING and don't know if it needs to take the 
security considerations advice of VCCV and MPLS-TP.  I do believe that the 
needs to decide how to handle the MUST requirements in the security 
considerations of 4385/5586/5921.


Editorial comments:

This draft says it updates RFC4379.  But I was unclear about some 
sections, for example, sections 3.1 and 3.2 that talk about IP 
encapsulation.  Section 3.1 in particular does not seem to extend RFC4379 
at all, and it says:

           This form of On-demand CV OAM MUST be supported for MPLS-TP
    LSPs when IP addressing is in use.

Will LSP-PING packets be considered one "form" of On-demand CV?

The draft defines new TLVs and sub-TLVs.  But it also refers often to 
"On-demand CV payload".  It appears this means the entire LSP-PING packet 
as defined in RFC4379 section 3 but it is not clear whether this means 
those packets that include both old TLVs and/or new TLV/sub-TLVs, or those 
packets with only the new TLVs/sub-TLVs.  It wouldn't take much to make 
this clear.
As there are requirements for what happens with "On-demand CV payload", 
(e.g. in section 3.3, if the reply mode is 4 then the "On-demand CV 
payload MUST directly follow the ACH header"), it would be good to be very 
clear what is meant by "On-demand CV payload".

In section 3.3, in the following:

    If the Reply mode indicated in an On-demand CV Request is 4 (Reply
    via application level control channel), the On-demand CV reply
    message MUST be sent on the reverse path of the LSP using ACH.  The
    On-demand CV payload MUST directly follow the ACH header and IP
    and/or UDP headers MUST NOT be attached.

Does this same restriction on the placement of the On-demand CV payload 
apply to the echo request as well?

In the "MUST be sent on the reverse path of the LSP using ACH" -- is that 
"MUST (be sent on the reverse path of the LSP) (using ACH)" or "MUST be 
sent on the reverse path of (the LSP that is using ACH)".  I'm thinking 
the first is right, but I am not sure.

In the following:

    If a node receives an MPLS echo request with a reply mode other than
    4 (reply via application level control channel), and if the node
    supports that reply mode, then it MAY respond using that reply mode.
    If the node does not support the reply mode requested, or is unable
    to reply using the requested reply mode in any specific instance, the
    node MUST drop the echo request packet and not attempt to send a
    response.

The section does not say what happens if the reply mode *is* 4, but the 
node does not support reply mode 4.  I don't know if that ever could 
happen.  I believe the same response holds - drop the request.

I believe the "that reply mode" means the requested reply mode, not the 4 
reply mode.

RFC5586 discusses examples of "ACH TLVs" as source and destination 
information.  It places restrictions on the definition of ACH TLVs in any 
new Channel Type, such as this draft:

    If the G-ACh message MAY be preceded by one or more ACH TLVs, then
    this MUST be explicitly specified in the definition of an ACH Channel
    Type.  If the ACH Channel Type definition does state that one or more
    ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow
    the ACH.  If no ACH TLVs are required in a specific associated
    channel packet, but the Channel Type nevertheless defines that ACH
    TLVs MAY be used, an ACH TLV Header MUST be present but with a length
    field set to zero to indicate that no ACH TLV follow this header.

    If an ACH Channel Type specification does not explicitly specify that
    ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used.

I do not know if the Source and Destination Identifier TLVs are ACH TLVs 
or if they can precede the G-ACh.  It looks to me like different 
interpretations of whether these two paragraphs apply to the 
source/destination TLVs could change the packet ordering and content.

Section 3.4.2 and 3.4.3 (part of the Reverse Path CV discussion) say:

               The requesting node (on receipt of the response) can use
    the Reverse-path Target FEC Stack TLV to perform reverse path
    connectivity verification.

and

    On receipt of the echo response, the requesting node MUST perform the
    following checks:

    1.  Perform interface and label-stack validation to ensure that the
        packet is received on the reverse path of the bi-directional LSP
    2.  If the Reverse-Path Target FEC Stack TLV is present in the echo
        response, then perform FEC validation.

Does only the requesting node perform the FEC validation check on the 
Reverse-Path Target FEC Stack?  Don't intermediate nodes do the check?

Section 4.2.2

    The On-demand CV route tracing responses will be received on the LSP
    itself and the presence of an ACH header with channel type of On-
    demand CV is an indicator that the packet contains On-demand CV
                                                      ^an
    payload.

The "On-demand CV" Channel Type is not defined until the IANA 
considerations section.  A forward reference would be good.

Section 4.2.3

    unable to identify the LSP on which the echo response would to be
                                                          would be

                    All responses MUST always be sent on a LSP path using
    the ACH header and ACH channel type of On-demand CV.

Section 3.3 says that requests in a non-IP ACH case SHOULD be sent with 
reply mode of 4 [i.e., could be other than 4] and responses when the reply 
mode is not 4 can be sent using the requested reply mode.  Reply modes 2&3 
are IP encapsulation - does this mean that they must also use the ACH 
header?

Section 5:
5.  Applicability

    The procedures specified in this document for non-IP encapsulation
    apply only to MPLS-TP Transport paths.  This includes LSPs and PWs
    when IP encapsulation is not desired.  However, when IP addressing is
    used, as in non MPLS-TP LSPs, procedures specified in [RFC4379] MUST
    be used.

If this document applies only to MPLS-TP, why place requirements on cases 
that fall outside the scope of this document?  Is there an implication 
that the procedures in RFC4379 differ from the procedures in this draft in 
those non MPLS-TP LSPs?  What does this imply about section 3.1 "LSP-Ping 
with IP encapsulation"?  I obviously am somewhat confused about the area 
of overlap, if any, between RFC4379 and this draft.

--Sandy