Last Call Review of draft-ietf-mpls-tp-on-demand-cv-
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.
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
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
VCCV has a different suggestion for protection:
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.
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
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
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
On receipt of the echo response, the requesting node MUST perform the
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?
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.
unable to identify the LSP on which the echo response would to 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
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
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.