[secdir] secdir review of draft-ietf-mpls-rfc6374-udp-return-path

Sandra Murphy <sandy@tislabs.com> Wed, 16 December 2015 18:29 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 738CB1A8707; Wed, 16 Dec 2015 10:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K29PyczNUM2f; Wed, 16 Dec 2015 10:29:42 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE091A8928; Wed, 16 Dec 2015 10:28:02 -0800 (PST)
Received: from nova.tislabs.com (unknown []) by walnut.tislabs.com (Postfix) with ESMTP id 73C5928B0043; Wed, 16 Dec 2015 13:28:01 -0500 (EST)
Received: from [] (localhost.localdomain []) by nova.tislabs.com (Postfix) with ESMTP id 281B81F801E; Wed, 16 Dec 2015 13:28:01 -0500 (EST)
From: Sandra Murphy <sandy@tislabs.com>
X-Pgp-Agent: GPGMail 2.5.1
Content-Type: multipart/signed; boundary="Apple-Mail=_4C40722B-18DF-465B-8F7A-C9B9D9041632"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Wed, 16 Dec 2015 13:27:52 -0500
Message-Id: <07A977A4-FD9E-4669-A8D0-7644131E06AD@tislabs.com>
To: secdir@ietf.org, The IETF <ietf@ietf.org>, draft-ietf-mpls-rfc6374-udp-return-path.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/kpM6VvS0QsK_ytZiY6ArNCoHU0o>
Subject: [secdir] secdir review of draft-ietf-mpls-rfc6374-udp-return-path
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2015 18:29:44 -0000

I have reviewed this document 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 document draft-ietf-mpls-rfc6374-udp-return-path-04 describes the
procedure and TLV format for a URO (UDP Return Object).  The URO is
used in the Packet Loss and Delay Measurement for MPLS Networks
protocol to indicate the out-of-band response destination when sent
over a IP/UDP return path.

I am not well versed in the MPLS document set, but I did review
RFC6374.  However, my comments could be based on a lack of thorough
knowledge or understanding.

I do have some comments.  Three major comments and some nits.


page 4 section 4 vs page 5 section 4.2 vs page 6 section 5.

There's some confusion to me about the necessity to include a URO, to
include either a URO or an Address object (and what Address object),
or to configure an out-of-band response without signalling.

Section 4:

 If the URO is expected but is not present in a query message and an
 MPLS-PLDM Response is requested out-of-band, the query message MUST
 NOT be processed further, and if possible an "Error - Invalid
 Message" ([RFC6374] Section 3.1) SHOULD be send to the querier and
 the operator notified via the management system (see Section 4.2 for
 further details.

Not sure what "expected" means here.  oob response request is
specifically mentioned, so does "expected" mean something more than
presence of a oob control code?  And section 4.2 indicates that an
error is sent if both the URO and an Address object are missing, not
just a missing URO.  Does this paragraph indicate just a missing URO
might induce an error message, in those cases when a URO was

Section 5 indicates that some systems rely on configuration, not
signalling, to determine the return path, and that the URO may be
omitted.  What does this paragraph mean in that case?  Does "expected"
have to do with configuration rather than packet contents?

Section 4.2

 If an Out-of-band response is requested and the Address object or the
 URO is missing, the query SHOULD be dropped in the case of a
 unidirectional LSP.  If both these TLVs are missing on a
 bidirectional LSP, the control code of Response message should set to
 0x1C indicating "Error - Invalid Message" ([RFC6374] Section 3.1) and
 the response SHOULD be sent over the reverse LSP.  The receipt of
 such a mal-formed request SHOULD be notified to the operator through
 the management system, taking the normal precautions with respect to
 the prevention of overload of the error reporting system.

The first sentence says that both the Address object and the URO must
be present or the query is dropped - right?  I'm reading this as

     (if not(Address) OR not(URO)) then drop.

What Address object - there are three - Return, Source and
Destination.  I'm betting on Return, but the text should be clear.

"should be set" - is that a SHOULD?  As always with "should" - when
would it not be?  When it is not, is it set to something different?
or not sent? or not set at all?

Section 4 says just the absense of an "expected" URO might induce the
error report.  Is that a mis-wording or a separate case that should be
noted here?

Section 5 says that some systems rely on configuration, not
signalling, to determine the return path, and that the URO may be
omitted.  Does this paragraph mean that such a system should be
configured with a (Return) Address object, to avoid the error code in
the response as noted here?

Section 5

 Nothing in this document precludes the use of a configured UDP/IP
 return path in a deployment in which configuration is preferred to
 signalling.  In these circumstances the URO MAY be omitted from the
 MPLS-PLDM messages.

In light of section 4.2, what about the (Return) Address object?  If
configuration is preferred, is signalling the Return Address
acceptable (to avoid the error code noted in section 4.2.)?  Or would
such a system avoid requesting an oob response?


page 5 section 4.3 and page 6 section 4.4

I was confused about handling a response at a recipient collector
other than the querier. That is mentioned in the introduction, but
later text seems to presume that the recipient of a response is the

page 5 section 4.3

 As shown in Figure 1 the Associate Channel Header (ACH)
 [RFC5586] is not included.  The information provided by the ACH is
 not needed since the correct binding between the query and response
 messages is achieved though the UDP Port and the session indentifier
 contained in the RFC6374 message.

page 6 section 4.4

 If the Response was received over UDP/IP and an out-of-band response
 was not requested,

The idea here is to allow "bistatic" (a new word for me, woohoo!)
collection, the receiver of a response might be a collector other than
the querier.  Right?  So is there a way for a collector know that a
query was made, much less whether the query requested an oob response?
Does section 4.4 apply only when the receiver of the response was the
querier?  Is that noted by the session identifier mentioned in section
4.3?  If the recipient is a collector other than the querier, is there
a way to detect duplicate session identifiers across queriers?


Security Considerations section

The security considerations section refers to the section in RFC6374
and the assumption that MPLS and MPLS-PLDM are deployed in well
managed private and service provider networks.  One presumes there's
an underlying assumption there that all nodes are trustworthy and
error free.

Be that as it may, this draft presents a feature that sure looks to me
like a reflection attack vector.  I am not sure if the size of the
response makes the reflection into an amplification attack, except
that multiple response destination addresses could be requested -
could they all be the same address?  The design note in section
3.1. indicates that "the combined size of the two objects [ed: an
Address object and a UDP object] was large".

The RFC6374 out-of-band response feature and the "Return Address"
object seem to indicate the potential exists in RFC6374 as well.
RFC6374's security consideration section does not mention the
reflection attack possibility, only the integrity of the return
out-of-band path and the possibility of affecting the validity of the
measurements.  But even if the assumptions of well-managed, private,
service provider networks are met, I believe that the potential and
increased need for careful configuration should be mentioned.  "Note:
the feature can be misused, so take care".  Perhaps a manageability
section caution about checking the Return Address or URO to ensure
addresses are within the private or service provider network.
something?  Or presume all will be well, because this is to be used in
well managed private and service provider networks?



MPLS-PM occurs in section headings (and in the file name of a related
draft draft-ietf-mpls-pm-udp-return-00) but the text always says
MPLS-PLDM.  Are they different?  If not a typo, there should be an
expansion somewhere.

page 2 section 1

 Currently the MPLS-PLDM protocol does not have any mechanism to
 deliver the PLDM Response message to particular node within a multi-

"to a particular node"

page 2 section 3

 This document specifies that, unless configured otherwise, if a UDP
 Return Object (URO) is present in a MPLS-PLDM Query, the responder
 MUST use the IP address and UDP port in the URO to reply back to the

Not sure how the responder would be configured otherwise.  Is the
otherwise configuration: "ignore any URO and always send to this
address" or "ignore URO (always send response to the querier)"?  could
be either?

page 2-3 section 3

                                     In this document, the term
 bidirectional LSP includes the co-routed bidirectional LSP defined in
 [RFC3945] and the associated bidirectional LSP that is constructed
 from a pair of unidirectional LSPs (one for each direction) that are
 associated with one another at the LSP's ingress/egress points

On first read, I thought "the associated bidirectional LSP" meant the
previously mentioned "co-routed bi-directional LSP", but further down
in the sentence it looks like it means the bidirectional LSP
associated with a pair of LSPs.  No biggie, and a wordsmithing quibble,
but "includes both the ... and also the...." would help.

page 5 section 4.2

                                    If both these TLVs are missing on a
 bidirectional LSP, the control code of Response message should set to

of the Response message

should be set to

page 5 section 4.3

                           The source IP address and the source UDP Port
 of Response packet

of the Response packet