Last Call Review of draft-ietf-mpls-tp-on-demand-cv-
review-ietf-mpls-tp-on-demand-cv-secdir-lc-murphy-2011-08-26-00

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