Subject: Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Mar 2018 17:32:52 -0400

It has been basically 2 weeks since the last update - can you let me
know when I can expect progress? Will this be discussed in London?

W

On Wed, Feb 28, 2018 at 3:57 AM, Hitoshi Asaeda <[email-masked]> wrote:
> Hi again,
>
>> 2018/02/27 8:56, Warren Kumari <[email-masked]> wrote:
>>
>> [ - IESG for clutter ]
>>
>> On Fri, Jan 26, 2018 at 4:58 PM, Eric Rescorla <[email-masked]> wrote:
>>> Hi Toerless,
>>>
>>> I appreciate the solution thinking, but I don't want to overrotate on these
>>> specific threats (though of course we must address them). My concern is that
>>> if there are threats this obvious then we need a more complete threat
>>> analysis. I.e., what are the avenues for attack with this protocol and then
>>> what mechanisms prevent those things. The purpose of the security
>>> considerations section is to make sure that that happens. Has someone done
>>> that somewhere and it just didn't make it into the document?
>>
>>
>> Toerless / authors,
>>
>> It has been around a month since this reply -- I'm hoping that the
>> there has been more discussion and that I just fell off the thread and
>> / or that my search foo has failed me.
>>
>> EKR makes good points (and holds a DISCUSS) - we need to figure out
>> how to address them. Was there more discussions on the thread
>> analysis? Clue bat appreciated.
>
> We may have to do some sort of security threat analysis and document the results,
> along with possible remedies to address the existing threats.
> We’ll seek comments in the ML after the authors agree on the idea.
>
> Best regards,
>
> Hitoshi
>
>
>>
>>>
>>> -Ekr
>>>
>>>
>>> On Thu, Jan 25, 2018 at 5:31 PM, Toerless Eckert <[email-masked]> wrote:
>>>>
>>>> On Thu, Jan 25, 2018 at 03:08:58PM -0800, Eric Rescorla wrote:
>>>>>> My point B.1) explicitly disables lying about the requesting address,
>>>>>> so
>>>>>> it is explicitly meant to prohibit amplification attacks.
>>>>>>
>>>>>
>>>>> I don't see how that's true. The attack I am concerned about is that you
>>>>> forge a *Request*, not a *Query*. And because the request indicates the
>>>>> original
>>>>> requester.
>>>>
>>>> Ah, sorry. I thought to remember that the text from you said query.
>>>> I just replied for query messages so far.
>>>>
>>>>> (give or take the subnet local limitations and/or additional L2 security
>>>>>> required to prohibit intra-l2-lying that i mentioned in my original
>>>>>> mail).
>>>>>
>>>>> Sorry, I'm not seeing this. The point is that you pretend to be a router
>>>>> that is forwarding a Request and fill in a bogus Client Address field.
>>>>> Waht
>>>>> stops that.
>>>>
>>>> In practical deployments IMHO we can only reasonable get similar solutions
>>>> to
>>>> what customer are also willing to deploy with PIM. For 99% deployments
>>>> that
>>>> is configured classificatio of interfaces as trusted/inside-clamshell or
>>>> untrusted/user-facing, and on the untrusted interfaces you don't accept
>>>> requests, just queries. And apply the suggested B.1 policy (Mtracev2
>>>> Client
>>>> Address must be connected on receiving interface).
>>>>
>>>> It might still be useful to have mtrace prepared for customers protecting
>>>> it
>>>> with IPsec - without requiring special features in mtrace or IPsec for it.
>>>>
>>>> IMHO for that, we need to have one UDP port for mtrace NNI messages
>>>> (requests), and another for UNI messages (query, response).
>>>> That would allow customers to take a vanilla IPsec implementation and
>>>> protect
>>>> the mtrace NNI messages and therefore eleiminate interface clamshell
>>>> classification.  In multicast signaling we got this for free: PIM is NNI,
>>>> IGMP/MLD UNI. Easy to distinguish for IPsec.
>>>>
>>>>>> My points B.1, B.2, B.3) provide solid access control mechanisms for
>>>>>> mtrace using mechanisms that are the most widely adopted form of
>>>>>> security
>>>>>> in ISPs
>>>>>> and that this option of security in mtrace should not be dismissed
>>>>>> just
>>>>>> because
>>>>>> it took us so long to bring the protocol in front of IESG review even
>>>>>> if
>>>>>> we agree
>>>>>> that we should have better options beyond that.
>>>>>
>>>>> The question is whether those options are in fact adequate. For the
>>>>> reasons
>>>>> above I don't believe that.
>>>>>
>>>>> -Ekr
>>>>
>>>> Cheers
>>>>    Toerless
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> The other point was that better security options are something we
>>>>>> should
>>>>>> not
>>>>>> invent as one-off protocol hack sinto mtrace (even if some mtrace none
>>>>>> request/reply
>>>>>> messages might be fun to define) but instead we should adopt solutions
>>>>>> that are more
>>>>>> likely in-line with existing network OAM security strategies. TLS
>>>>>> connections,
>>>>>> netconf/yang etc. pp. As i described in my email.
>>>>>>
>>>>>> Cheers
>>>>>>    toerless
>>>>>>
>>>>>>> -Ekr
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The most likely next step to overcome the trusted path issue between
>>>>>>>> query initiator to query responder is to make an mtrace yang model
>>>>>> where
>>>>>>>> you can actually initiate an mtrace via netconf/yang, aka: replace
>>>>>>>> the query with netconf. Like you would today just ssh into the
>>>>>>>> LHR and run a local mtrace client there.
>>>>>>>>
>>>>>>>> Alas, i see no easy way to get back to support A) in a lightweight
>>>>>>>> fashion ;-(
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>    Toerless
>>>>>>>>
>>>>>>>> On Thu, Jan 18, 2018 at 07:34:59AM -0800, Eric Rescorla wrote:
>>>>>>>>> Eric Rescorla has entered the following ballot position for
>>>>>>>>> draft-ietf-mboned-mtrace-v2-22: Discuss
>>>>>>>>>
>>>>>>>>> When responding, please keep the subject line intact and reply
>>>>>>>>> to all
>>>>>>>>> email addresses included in the To and CC lines. (Feel free to
>>>>>>>>> cut
>>>>>> this
>>>>>>>>> introductory paragraph, however.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please refer to https://www.ietf.org/iesg/stat
>>>>>>>> ement/discuss-criteria.html
>>>>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The document, along with other ballot positions, can be found
>>>>>>>>> here:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>>>>> DISCUSS:
>>>>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>>>>>
>>>>>>>>> The security considerations of this document are inadequate. My
>>>>>> review
>>>>>>>>> turns up at least the following potential issues which do
>>>>>>>>> not seem to be addressed or even discussed:
>>>>>>>>>
>>>>>>>>> - Amplification: this protocol does not appear to verify that
>>>>>>>>> the
>>>>>>>>>  sender of the query actually owns the IP it claims. Because
>>>>>>>>>  responses are much larger than queries, this allows for an
>>>>>>>> amplification
>>>>>>>>>  attack, especially if the client is able to send a query that
>>>>>> elicits
>>>>>>>>>  multiple replies. One defense here would be to fill the rest
>>>>>>>>> of the
>>>>>>>> packet
>>>>>>>>>  with zeroes, thus somewhat reducing the amplification factor.
>>>>>> Access
>>>>>>>>>  control would also help.
>>>>>>>>>
>>>>>>>>> - Forgery of responses: because the query id is so short, an
>>>>>>>>> attacker
>>>>>>>>>  can generally produce a message which has a nontrivial chance
>>>>>>>>> of
>>>>>>>>>  corresponding to an extant query. This could be addressed by
>>>>>>>>> having
>>>>>>>>>  a query ID that was large and random.
>>>>>>>>>
>>>>>>>>> - Anyone on-path can forge responses.
>>>>>>>>>
>>>>>>>>> In addition, Section 9.4 seems inadequate. Isn't it generally
>>>>>>>>> the
>>>>>> case
>>>>>>>> that
>>>>>>>>> who is sending to who is sensitive? This seems like a fairly
>>>>>>>>> serious
>>>>>>>> privacy
>>>>>>>>> obstacle to using this protocol at all.
>>>>>>>>>
>>>>>>>>> It seems like many of the issues I raise above would be fixed or
>>>>>>>>> at
>>>>>>>>> least mitigated by having some sort of access control mechanism.
>>>>>>>>> I
>>>>>>>>> understand why it might be the case that it's not practical to
>>>>>>>>> have
>>>>>>>>> full communication security between the links (though it would
>>>>>>>>> of
>>>>>>>>> course be desirable), but it's not clear to me why arbitrary
>>>>>>>>> people
>>>>>>>>> should be allowed to instantiate queries.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>>>>> COMMENT:
>>>>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>>>>>
>>>>>>>>> S 1.
>>>>>>>>>   When an Mtrace2 client initiates a multicast trace, it sends
>>>>>>>>> an
>>>>>>>>>   Mtrace2 Query packet to the LHR or RP for a multicast group
>>>>>>>>> and,
>>>>>>>>>
>>>>>>>>> This seems a bit confusing as there are multiple LHRs for the
>>>>>>>>> group.
>>>>>>>>> Can you rephrase?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 2.1.
>>>>>>>>>   ALL-[protocol]-ROUTERS group
>>>>>>>>>      It is a link-local multicast address for multicast routers
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> This is grammatically funny. Perhaps remove "It is"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.
>>>>>>>>>   additional information associated with the message.  If an
>>>>>>>>>   implementation receives an unknown TLV type for the first TLV
>>>>>>>>> in a
>>>>>>>>>   message (i.e., the header TLV), it SHOULD ignore and silently
>>>>>> discard
>>>>>>>>>   the entire packet.  If an implementation receives an unknown
>>>>>>>>> TLV
>>>>>> type
>>>>>>>>>   for a subsequent TLV within a message, it SHOULD ignore and
>>>>>> silently
>>>>>>>>>   discard the entire packet.
>>>>>>>>>
>>>>>>>>> ISTM that these cases are handled identically so is there a
>>>>>>>>> reason
>>>>>>>>> not just to remove the first sentence and change the second one
>>>>>>>>> to
>>>>>>>>> "for any TLV"/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.2.1
>>>>>>>>>   An Mtrace2 Query is usually originated by an Mtrace2 client
>>>>>>>>> which
>>>>>>>>>   sends an Mtrace2 Query message to the LHR.  When tracing
>>>>>>>>> towards
>>>>>> the
>>>>>>>>>   source or the RP, the intermediate routers MUST NOT modify
>>>>>>>>> the
>>>>>> Query
>>>>>>>>>   message except the Type field.
>>>>>>>>>
>>>>>>>>> I'm not sure I follow this. Don't routers either (a) not touch
>>>>>>>>> this
>>>>>> at
>>>>>>>> all
>>>>>>>>> or (b) if they are the LHR, change Type from Query -> Request
>>>>>>>>> and
>>>>>> then
>>>>>>>>> add a response block? This text seems to not really capture
>>>>>>>>> either
>>>>>> case.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.2.4.
>>>>>>>>>      Note that Mtrace2 does not require all the routers on the
>>>>>>>>> path
>>>>>> to
>>>>>>>>>      have synchronized clocks in order to measure one-way
>>>>>>>>> latency.
>>>>>>>>>
>>>>>>>>> It's not clear to me how one does this. Can you expand?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.2.6.
>>>>>>>>>
>>>>>>>>>          0x01    # of the returned Standard Response Blocks
>>>>>>>>>
>>>>>>>>> Nit: Do you want to say 0x0001
>>>>>>>>>
>>>>>>>>> Also, an example of the case covered by this section would help,
>>>>>>>>> I
>>>>>> think.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 4.4.
>>>>>>>>> It might be clearer to move this up a bit in the text as it sort
>>>>>>>>> of
>>>>>>>>> summarizes some cases you already covered before. It would be
>>>>>>>>> easier
>>>>>>>>> if it provided an overview instead.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 5.9.
>>>>>>>>>
>>>>>>>>>   In this case, the Mtrace2
>>>>>>>>>   client may receive multiple Mtrace2 Replies from different
>>>>>>>>> routers
>>>>>>>>>   along the path.  When this happens, the client MUST treat
>>>>>>>>> them as
>>>>>> a
>>>>>>>>>   single Mtrace2 Reply message.
>>>>>>>>>
>>>>>>>>> Can you please describe how the client reassembles multiple
>>>>>>>>> messages
>>>>>>>>> into one. I think I may know how to do this, but the document
>>>>>>>>> should
>>>>>>>>> tell me.
>>>>>>>>>
>>>>>>>>> S 8.
>>>>>>>>>   The following new registries are to be created and maintained
>>>>>> under
>>>>>>>>>   the "RFC Required" registry policy as specified in [4].
>>>>>>>>>
>>>>>>>>> Why did you choose RFC Required rather than Specification
>>>>>>>>> Required?
>>>>>>>>> This just seems to unduly put load on the ISE.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> MBONED mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mboned
>>>>>>>>
>>>>>>>> --
>>>>>>>> ---
>>>>>>>> [email-masked]
>>>
>>>
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>   ---maf
>>
>> _______________________________________________
>> MBONED mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mboned
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 14 Mar 2018 10:53:11 +0900

Hi Warren,

I have been working on the security threat analysis with Kerry but
not completed the documentation.
We will post our thoughts on the ml asap.
I’m sorry that I cannot attend this meeting at London locally, but
will try to attend via jabber.

Regards,

Hitoshi

> 2018/03/14 6:32, Warren Kumari <[email-masked]> wrote:
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 15 Mar 2018 16:51:43 +0900

Hi Warren, Eric, and folks,

Kerry and I have been working on the security threat analysis initiated by
Eric’s comments.
Kerry is now doing double check for our thoughts and will post the story
tomorrow, I guess.

Sorry for the long delay, but please wait for a while.

Thanks for your cooperation.

Regards,

Hitoshi

> 2018/03/14 10:53, Hitoshi Asaeda <[email-masked]> wrote:
> 
> Hi Warren,
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Mar 2018 07:55:01 +0000

Thanks. I am happy to meet in person in London if that would be useful

---

From: Kerry Meyer <[email-masked]>
Date: Thu, 15 Mar 2018 23:23:04 -0700

Hi Eric and others,

We are sorry for the long delay. We have been carefully considering the points you have raised and how best to address them. We hope that the proposed resolutions of those points will satisfy your concerns.

          Kerry

> On Jan 18, 2018, at 7:34 AM, Eric Rescorla <[email-masked]> wrote:
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The security considerations of this document are inadequate. My review
> - Amplification: this protocol does not appear to verify that the
>  responses are much larger than queries, this allows for an amplification
>  attack, especially if the client is able to send a query that elicits
>  multiple replies. One defense here would be to fill the rest of the packet
>  with zeroes, thus somewhat reducing the amplification factor. Access
>  control would also help.
> 
We understand that access control is required to protect against this and other threats from malicious senders. This will be specified in section 9.2 as follows;

"A router MUST support a mechanism to filter out queries from clients
and “requests” from peer router addresses that are unauthorized or
that are beyond a specified administrative boundary.  This filtering
could, for example, be specified via a list of allowed/disallowed client
and peer addresses or subnets for the Mtrace2 protocol port. If a query
or request is received from an unauthorized address or one beyond the
specified administrative boundary, the Query/Request MUST NOT be
processed. The router MAY, however, perform rate limited logging of such
events."

Additional text has been added to section 9.7 (see later in this mail) to explicitly map this and other concerns to the recommended prevention mechanism.

> - Forgery of responses: because the query id is so short, an attacker
>  can generally produce a message which has a nontrivial chance of
>  corresponding to an extant query. This could be addressed by having

Because there are 2**16 possible query ID values, an average of 2**15 forged response attempts would be required to “hit” the actual query ID for a given extant query. The amount of time to do this would far exceed the lifetime of an extant query/response. Even assuming that a targeted client has multiple extant queries at a given time, the chance of matching one is still quite small. More importantly, the required access control for the Mtrace protocol port (section 9.2, aforementioned) provides protection against an unauthorized malicious sender injecting bogus request packets.

> - Anyone on-path can forge responses.
The forger would need to match the query ID and the dynamically allocated client (source) port (REF: section 3.2.1) to create a valid reply message that would pass validity checks at the client.

> In addition, Section 9.4 seems inadequate. Isn't it generally the case that
> who is sending to who is sensitive? This seems like a fairly serious privacy
The requirement to specify a list of “trusted” clients (section 9.2) provides a mechanism to avoid the dissemination of this information to unauthorized hosts.

> It seems like many of the issues I raise above would be fixed or at
> least mitigated by having some sort of access control mechanism.  I
> understand why it might be the case that it's not practical to have
> full communication security between the links (though it would of
> course be desirable), but it's not clear to me why arbitrary people
Agreed. The requirement to restrict the addresses permitted to send Mtrace messages to a given router is specified in an expanded version of section 9.2.
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> S 1.
>   When an Mtrace2 client initiates a multicast trace, it sends an
>   Mtrace2 Query packet to the LHR or RP for a multicast group and,
> 
> This seems a bit confusing as there are multiple LHRs for the group.
> Can you rephrase?
> 
The word “the” preceding “LHR ...” has been changed to “an”.
>      It is a link-local multicast address for multicast routers to
> 
> This is grammatically funny. Perhaps remove "It is”
> 
The words “It is” have been removed from the cited paragraph and other similar adjacent paragraphs.
>   implementation receives an unknown TLV type for the first TLV in a
>   message (i.e., the header TLV), it SHOULD ignore and silently discard
>   the entire packet.  If an implementation receives an unknown TLV type
>   for a subsequent TLV within a message, it SHOULD ignore and silently
> ISTM that these cases are handled identically so is there a reason
> not just to remove the first sentence and change the second one to
> "for any TLV"/
> 
> 
These two cases have been combined to reflect the fact that there is no difference in handling.

“If an implementation receives an unknown TLV type for any TLV in a
message, it SHOULD ignore and silently discard the entire packet.”

> 
> S 3.2.1
>   An Mtrace2 Query is usually originated by an Mtrace2 client which
>   sends an Mtrace2 Query message to the LHR.  When tracing towards the
>   source or the RP, the intermediate routers MUST NOT modify the Query
> I'm not sure I follow this. Don't routers either (a) not touch this at all
> or (b) if they are the LHR, change Type from Query -> Request and then
> add a response block? This text seems to not really capture either case.
> 
The paragraph has been modified based on this comment as follows;

“An Mtrace2 Query is originated by an Mtrace2 client which
sends an Mtrace2 Query message to the LHR.  The LHR modifies only
the Type field of the Query TLV (to turn it into a “Request”)
before appending a Standard Response Block and forwarding it upstream.
The LHR and intermediate routers handling the Mtrace2 message when
tracing upstream MUST NOT modify any other fields within the
Query/Request TLV. Additionally, intermediate routers handling
the message after the LHR has converted the Query into a Request
MUST NOT modify the type field of the Request TLV. If the actual number
of hops is not known, an Mtrace2 client could send an initial Query
message with a large # Hops (e.g., 0xff), in order to try to trace the
full path.”
> 
> S 3.2.4.
>      Note that Mtrace2 does not require all the routers on the path to
>      have synchronized clocks in order to measure one-way latency.
> 
The paragraph has been modified to clarify this point.

> Nit: Do you want to say 0x0001
Done, thanks.

> Also, an example of the case covered by this section would help, I think.
> 
> 
> 
> S 4.4.
> It might be clearer to move this up a bit in the text as it sort of
> summarizes some cases you already covered before. It would be easier
This section is located where it is because of the sequence of operations: Query->Request->Reply.
>   client may receive multiple Mtrace2 Replies from different routers
>   along the path.  When this happens, the client MUST treat them as a
> Can you please describe how the client reassembles multiple messages
> into one. I think I may know how to do this, but the document should
> tell me.
> 
The paragraph has been expanded based on this comment as follows;

"When the NO_SPACE error occurs, as described in Section 4.2, a router
 will send back an Mtrace2 Reply to the Mtrace2 client, and continue
 with a new Request (see Section 4.3.3).  In this case, the Mtrace2
 client may receive multiple Mtrace2 Replies from different routers
 along the path.  When this happens, the client MUST treat them as a
 single Mtrace2 Reply message by collating the augmented response
 blocks of subsequent replies sharing the same query ID, sequencing
 each cluster of augmented response blocks based on the order in
 which they are received."
> S 8.
>   The following new registries are to be created and maintained under
> Why did you choose RFC Required rather than Specification Required?
Agreed. The sentence has been modified based on this comment.

******
Addtional Note:

According to above considerations, we added a new section 9.7 as shown below;
===
9.7 Specific Security Concerns

  This subsection describes some of the specific security concerns and
  exposures that have been considered during the design of the Mtrace2
  protocol. Where applicable, the exposures are mapped to the
  corresponding remedy listed in the previous subsections.

9.7.1 Request and Response bombardment

  A malicious sender could generate invalid and undesirable Mtrace
  traffic to hosts and/or routers on a network by eliciting responses to
  spoofed or multicast client addresses. This could be done via forged
  or multicast client/source addresses in Mtrace Query or Request
  messages. The recommended protections against this type of attack are
  described in sections 9.1, 9.2, 9.5, and 9.6 above.

9.7.2 Amplification attack

  Because an Mtrace Query results in Mtrace Request and Mtrace Reply
  messages that are larger than the original message, the potential
  exists for an amplification attack from a malicious sender. This
  threat is minimized by restricting the set of addresses from which
  Mtrace messages can be received on a given router as specified in
  section 9.2.

9.7.3 Leaking of confidential topology details

  Mtrace queries are a potential mechanism for obtaining confidential
  topology information for a targeted network. Sections 9.2 and 9.4
  describe required and optional methods for ensuring that Mtrace
  information is not disseminated to unauthorized hosts.

9.7.4 Delivery of false mtrace information

   Forged “Reply” messages could potentially provide a host with
   invalid or incorrect topology information. This threat is mitigated
   by the following factors:

     - The required filtering of permissible source addresses specified
       in section 9.2 eliminates the origination of forged replies from
       addresses that have not been authorized to send Mtrace messages
       to routers on a given network.

     - To forge a Reply, the sender would need to somehow know the
       associated two byte query ID for an extant Query and the
       dynamically allocated source port number.
===