Sandy

Something that may help you understand this is that although
RFC6374 defines the return address object, there is nothing
in  RFC6374 that defines how you use it. You also need to
remember that this type of system operates in a world where
a lot of the operational  parameters are configured rather
than signalled.

The operation of the protocol extension that needs to be
written in such a way as to permit the existing modes
of operation to continue.


On 16/12/2015 18:27, Sandra Murphy wrote:
> 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
> "expected"?
>
> 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?
Expected covers all cases where the responder was expecting a URO.

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

That is return address - I will update the text.
>
> "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?

I think that should be SHOULD.

There is only one error code that we can respond with in the protocol
so SHOULD allows for the case where some other more important
error code needs to be sent.

Whilst the protocol would be harder to manage if the error was
not reported this way, omission would not lead to interoperability
issues and thus "send unless you have a good reason not to send"
makes more sense than "send under all circumstances". Hence
should or SHOULD.

>
> 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?
You could be configured with the address, but not the UDP port.

>
> 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?
In these circumstances the URO would not be expected and thus
there would be no error.

>
> 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?
This is a world where we need to permit flexibility.

One example where you would find a configured address and
a return address would be where configured address was the
default, but for some measurements you wanted to use a
different collector.

>
> ---------
>
> 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
> querier.
>
> 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!)
You need to read more books on radar :)
> 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?
That is out of scope.

Remember that RFC6374 is a stateless system so the messages can
be configured to contain all of the necessary information.
> 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?

The session identifier is scoped on the source. If the source is not
implicitly known, it would need to be explicitly indicated through
the source address TLV.


> ---------
>
> 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".
Remember that to create such an attack you first have to get
an MPLS packet into the systems. MPLS networks are designed,
indeed fundamentally require, that to be a hard problem.

I would expect that most systems would be configured to only
respond to the first address, except in the case of Ipv4/6 migration.

>
> 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?
I will look at adding some text, although the assumption is that
MPLS networks are well managed, and there are many other ways
they would break if they were not.

>
> ---------
>
>
> nits
>
> 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.
This is an oversight that results from the development of the protocol.
You have to remember there are three types of query, loss, delay and 
loss+delay.
I will fix it.

>
> 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-
>   CPU LSR.
>
> "to a particular node"
yes.
>
> 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
>   querier.
>
> 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?
Yes, you could have config override the object.
>
> 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
>   [RFC5654].
>
> 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.

The MPLS-TP references explain these cases.
>
> 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
yes
>
>
> page 5 section 4.3
>
>                             The source IP address and the source UDP Port
>   of Response packet
>
> of the Response packet
>
yes.

- Stewart