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

[Eric Gray <[e-mail]>]

 Sandy,

        I had a conversation with one of my co-authors about the
one item I had not addressed earlier.

        That item (from below) was on the subject of ACH TLVs to
be associated with new Pseudowire associated channel types.

        The Source & Destination identifier TLVs are not ACH TLVs.
They are TLVs within the LSP-Ping message payload.  So the ACH
TLV rules do not apply to them.

        We will be adding the following text to section 3 (where
we define the the new Pseudowire associated channel type):

   "ACH TLVs CANNOT be associated with this channel type."

        This should remove any ambiguity on this issue.

        Again, thanks for the thorough review!

--
Eric

-----Original Message-----
From: Eric Gray
Sent: Sunday, September 04, 2011 11:20 PM
To: 'Sandra Murphy'; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: secdir review of draft-ietf-mpls-tp-on-demand-cv

Sandra,

        Thanks for the detailed review!

        On the security issues, I agree with your points.

        I am inclined to add text somewhat along the lines of the
VCCV RFC (5085) - though VCCV is itself an unrelated protocol
(this will limit the similarity of the text).

        In a nut-shell, I do not think that this specification can
(or should) recommend that it is only used in the private MPLS
network case.  However, I think it is reasonable to suggest that
the source identifier would be required for any other case, in
order to facilitate filtering.

        This would be a deployment option, for which this protocol
specification can only require that the ability to do this is
included in compliant implementations.

        On the issue of extending RFC 4379, this draft explicitly
says exactly how it extends RFC 4379.  It is not the intention of
this specification to extend RFC 4379 in every possible way.

        The on-demand payload is everything that follows either the
IP header, or the ACH header.  This seems every bit as clear to
me as "IP payload" or any other protocol usage of the term.

        I have provided more detailed responses in-line below (look
for "Eric Gray >>" at the beginning of lines).

        Again, thanks!

--
Eric

-----Original Message-----
From: Sandra Murphy [mailto:[e-mail]]
Sent: Thursday, August 25, 2011 7:33 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: secdir 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.

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?

Eric Gray >> Yes, they are.  This specification extends LSP Ping - by
Eric Gray >> (among other things) supporting the non-IP case - so that
Eric Gray >> LSP Ping is usable for transport networks.  There is no
Eric Gray >> to limit the usage of existing LSP Ping.

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.

Eric Gray >> As stated above, there is no intention to limit the use
Eric Gray >> of existing LSP Ping.  In particular, except as explicily
Eric Gray >> stated, the echo request used in on demand CV may contain
Eric Gray >> any existing TLVs defined for LSP Ping.  It is up to the
Eric Gray >> implementors to work out when and where this might make
Eric Gray >> sense.

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

Eric Gray >> This is an artifact of making this specification about on
Eric Gray >> "on demand CV."  The "payload" is exactly the same as it
Eric Gray >> would be for LSP Ping.

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?

Eric Gray >> Yes, in this case, it does.  We should add text to clarify
Eric Gray >> this.

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.

Eric Gray >> If we had meant the latter, we would have needed to add the
Eric Gray >> "that is" which you have added in the latter case.  It takes
Eric Gray >> a bit of a stretch to make this any more ambiguous than any
Eric Gray >> English expression necessarily will be.

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.

Eric Gray >> Any implementation of this specification necessarily MUST
Eric Gray >> support reply mode 4.  This certainly seems obvious to me,
Eric Gray >> given reply mode 4 is part of what this draft specifies.

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

Eric Gray >> Yes.

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.

Eric Gray >> We will need to discuss this one amongst ourselves and get
Eric Gray >> back to you about it...

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?

Eric Gray >> Abolutely not!  That would require they intercept and process
Eric Gray >> the message rather than simply forward it.  This not like a
Eric Gray >> route recording, but merely the path the responder thinks is
Eric Gray >> the reverse path (to be verified by the requester, on getting
Eric Gray >> the response).

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.

Eric Gray >> Okay.

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

Eric Gray >> There is a forward reference currently in the third para
Eric Gray >> section 3.

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.

Eric Gray >> Okay.

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?

Eric Gray >> they would be encapsulated as specified for reply modes 2 or
Eric Gray >> 3 in RFC 4379.  One reason to use one of these modes would
Eric Gray >> be if the LSP is unidirectional.  Use of the ACh Header in
Eric Gray >> that case will not work.

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.

Eric Gray >> Perhaps we should say "primarily" instead of "only", or we
Eric Gray >> could simply leave "only" out.
Eric Gray >> The general aim is to make the extensions we add to MPLS for
Eric Gray >> the transport application usable in general, so we should
Eric Gray >> probably not have added such a limitation.  Clearly the case
Eric Gray >> we want to cover generally is the case where IP addressing
Eric Gray >> is not available.  The "only" case where this seemed likely
Eric Gray >> while we were writing this draft was the transport case.

--Sandy