Last Call Review of draft-ietf-mpls-tp-on-demand-cv-

Request Review of draft-ietf-mpls-tp-on-demand-cv
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-08-23
Requested 2011-08-15
Authors Rahul Aggarwal, Eric Gray, Nitin Bahadur, Sami Boutros
Draft last updated 2011-08-26
Completed reviews Secdir Last Call review of -?? by Sandra Murphy
Assignment Reviewer Sandra Murphy
State Completed
Review review-ietf-mpls-tp-on-demand-cv-secdir-lc-murphy-2011-08-26
Review completed: 2011-08-26


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

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

(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

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.


   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

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 


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.