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

["Adrian Farrel" <[e-mail]>]

"CANNOT" ?

Lower case for a statement of fact.

2119 language for a directive.

A


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Eric
> Gray
> Sent: 09 September 2011 04:13
> To: Sandra Murphy; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: secdir review of draft-ietf-mpls-tp-on-demand-cv
> 
>  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