ietf
[Top] [All Lists]

Re: secdir review of draft-ietf-mpls-rfc6374-udp-return-path

2016-04-07 09:17:18


On 18/12/2015 09:57, Stewart Bryant wrote:

Sandy, I have looked at this discussion again. Please see inline:


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.

Looking at the text again, since we are ONLY talking about systems using the
URO, the Address object text fragment is pointless so I have deleted it.




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.


This text is only about the URO case. The only residual text on the DA obj
is in the section that is to be deleted.

- Stewart

<Prev in Thread] Current Thread [Next in Thread>
  • Re: secdir review of draft-ietf-mpls-rfc6374-udp-return-path, Stewart Bryant <=