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

On Fri, Jun 29, 2018 at 11:34 PM, Hitoshi Asaeda <[email protected]> wrote:

> Hi Eric,
>
> > On 2018/06/30, at 6:45, Eric Rescorla <[email protected]> wrote:
> >
> > This seems like an improvement, but I'm not sure the definition of ACLs
> is clear enough.
> >
> > Suppose I am a client that is a valid requestor but wants to attack
> another client. Which text stops me from doing that?
>
> The potential ways to minimize such unexpected traffic are ACLs (ref.
> section 9.2) and rate limits (ref. section 9.5 and 9.6).
>
> For ACLs, section 9.2 says;
>    The required use of ACLs on the participating routers minimizes the
>    possible methods for introduction of spoofed Query/Request packets
>    that would otherwise enable DoS amplification attacks targeting an
>    authorized "query" host.  The ACLs provide this protection by
>    allowing Query messages from an authorized host address to be
>    received only by the router(s) connected to that host, and only on
>    the interface to which that host is attached.
>
> In your example, you (valid user) can receive the corresponding reply and
> can recognize that the initial Query gave you an error (NO_SPACE). If you
> want to try query again, you may change the query type to avoid such error
> and retry with other query type or stop sending the same query many times..
>
If you try the same queries (NO_SPACE) many times and one or some of the
> upstream routers think these queries are malicious, the router(s) would
> filter out (or rate-limit) these Queries/Request/Reply as specified in
> section 9.5 (Limiting Query/Request Rates) and 9.6 (Limiting Reply Rates)..
>

This seems like the kind of thing that routers are likely not to do,
because the guidance is so vague.

For instance:

   A router MUST support an access control list (ACL) 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.

This doesn't prevent me from initiating a message (that should be a Query)
but actually is a Request, in which case I can just forge any alleged
initial
querier myself.

Also, MUST support seems pretty weak here. Shouldn't this at least be
SHOULD use?

-Ekr


Do you think these assumptions are not feasible or we need to add some more
> text to explain these assumptions?
>



> Regards,
>
> Hitoshi
>
>
> > -Ekr
> >
> >
> > On Wed, Jun 20, 2018 at 1:05 PM, Hitoshi Asaeda <[email protected]> wrote:
> > Hi Eric and folks,
> >
> > We've just submitted the revised Mtrace2 draft..
> > (https://tools.ietf.org/html/draft-ietf-mboned-mtrace-v2-24)
> >
> > We believe we addressed all comments given during the IESG review.
> > We'd like to ask you to kindly review this revision.
> >
> > Thanks.
> >
> > Regards,
> > --
> > Hitoshi Asaeda
> >
> >
> > > On 2018/06/07, at 1:14, Kerry Meyer <[email protected]> wrote:
> > >
> > > Hi Eric,
> > >
> > > Thank you for providing your description of the specific amplification
> attack scenario that you had in mind. Please see inline below regarding
> handling of this and other related types of DoS attacks.
> > >
> > > Please let us know if these additional details adequately address your
> concerns.
> > >
> > >           Kerry
> > >
> > >> On Jun 1, 2018, at 3:13 PM, Eric Rescorla <[email protected]> wrote:
> > >>
> > >>
> > >>
> > >> On Thu, May 24, 2018 at 4:01 PM, Kerry Meyer <[email protected]>
> wrote:
> > >> Hi Eric,
> > >>
> > >> Thank you for considering and responding to the most recent comments
> that I posted on this thread.
> > >>
> > >> Please see inline below for responses to the points raised in your
> 5/19 posting.
> > >>
> > >> We appreciate your help in addressing possible security exposures in
> the current version of the draft.
> > >>
> > >>             Kerry
> > >>
> > >>> On May 19, 2018, at 3:09 PM, Eric Rescorla <[email protected]> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <[email protected]>
> wrote:
> > >>> Hi Eric,
> > >>>
> > >>> Please see inline below for responses to the points raised in your
> most recent posting regarding the Mtrace V2 draft.
> > >>>
> > >>>                 Kerry
> > >>>
> > >>>> On Apr 9, 2018, at 2:07 PM, Eric Rescorla <[email protected]> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer <[email protected]>
> wrote:
> > >>>> 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 protected]> 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.
> > >>>> >
> > >>>> 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."
> > >>>>
> > >>>> This seems like an improvement, but still seems to allow
> amplification to any
> > >>>> client which is a valid requestor. So, if I have one such on my
> network, then
> > >>>> I am subject to DoS?
> > >>>>
> > >>> For valid queries/requests, we specified limiting query/request
> rates in section 9.5 as follows;
> > >>>
> > >>> "A router may limit Mtrace2 Queries and Requests by ignoring some of
> > >>> the consecutive messages.  The router MAY randomly ignore the
> > >>> received messages to minimize the processing overhead, i.e., to keep
> > >>> fairness in processing queries, or prevent traffic amplification.
> > >>> The rate limit is left to the router's implementation.”
> > >>>
> > >>> This seems like the kind of thing that's going to get ignored. As a
> comparison point,
> > >>> consider QUIC, which forbids sending >3 messages in response to an
> Initial
> > >>> packet.
> > >>>
> > >> For mtrace V2, only one response is accepted for a given query. (So
> the “response packet limit” is already rigidly set to “1”.)
> > >>
> > >> Well, it's not a matter of *accepted*. It's a matter of sent. Here's
> the specific attack I have in mind.
> > >>
> > >> Say that I have a Request that would ordinarily traverse routers R1,
> R2, ..... R_n. I construct a request that is just under the
> > >> MTU (it has a bunch of unknown T-bit set query block plus one
> Response block). I send it to R1. Per S 4.3.3., the router then
> > >> returns a Reply with NO_SPACE to the Client IP and then forwards the
> Request with an Augmented Response Block plus its own
> > >> Response Block upstream. This process repeats at R2, R3, ... RN. The
> result is N-times amplification. This is bad even without
> > >> ClientIP forgery, but can be very bad in that case.
> > >>
> > >> Am I wrong about this?
> > >>
> > >
> > > Thanks for explaining this form of attack. This clarifies your
> previously described concern that any client that is a valid requestor
> could initiate an attack. It does describe a viable scheme for an
> amplification attack.
> > >
> > > Because the granularity with which ACLs can be applied (and the
> granularity that we will recommend in our expanded section on use of ACLs
> for protection against security threats) is at the interface level, only
> clients directly connected to a given interface would be able to send
> queries over that interface. This does not prevent an attack from a
> malicious application on a trusted server, but it can prevent attacks from
> all other servers.
> > >
> > > The proposed additions to the “Security Considerations” section to
> address this type of vulnerability are as follows:
> > >
> > > ****
> > >
> > > The required use of ACLs on the participating routers minimizes the
> possible methods for introduction of spoofed query/request packets that
> would otherwise enable DoS amplification attacks targeting an authorized
> “query” host. The ACLs provide this protection by allowing queries from an
> authorized host address to be received only by the router(s) connected to
> that host, and only on the interface to which that host is attached. For
> protection against spoofed “request” messages, the ACLs allow requests only
> from a directly connected peer and allow these messages to be received only
> on the interface to which that peer is attached.
> > >
> > >
> > > Note: The following vulnerabilities can not be covered by the ACL
> methods described here. These methods can, nevertheless, prevent attacks
> launched from outside the boundaries of a given network as well as from any
> hosts within the network that are not on the same LAN as an intended
> authorized query client.
> > >
> > >   - A server “B” other than the server “A" that actually “owns” a
> given IP address could, if it is connected to the same LAN, send an mtrace
> query with the source address set to the address for server “A”. This is
> not a significant threat, however, if only trusted servers are connected to
> that LAN.
> > >
> > >   - A malicious application running on a trusted server could send
> packets that might cause an amplification problem. It is beyond the scope
> of this document to protect against a DOS attack launched from the server
> that is the target of the attack, but this is not a likely threat scenario.
> > >
> > > An additional note: While it is not practical to provide cryptographic
> protection between a client and the mtrace endpoints (destinations), it may
> be practical to prevent the types of attacks described above by devising a
> scheme to encrypt mtrace query packets via configuration of trusted servers
> and their associated first hop routers. This type of node/application
> authentication and authorization is, however, out of the scope of this
> document.
> > >
> > >>
> > >>> In addition, the required use of ACLs on the participating routers
> prevents the introduction of spoofed query/request packets that would
> otherwise enable DoS amplification attacks targeting an authorized “query”
> host. The ACLs provide this protection by allowing queries from an
> authorized host address to be received only by the router(s) connected to
> that host, and only on the interface to which that host is attached. For
> protection against spoofed “request” messages, the ACLs allow requests only
> from a directly connected peer and allow these messages to be received only
> on the interface to which that peer is attached.
> > >>>
> > >>> Don’t these provisions address your concern?"
> > >>>
> > >>> I'm not sure I follow where this is required. The text you are
> quoting here is a lot more vague than this. Why can't "authorized" be
> anyone?
> > >>>
> > >> The use of the word “authorized” is intended to allow discretion on
> the part of the network engineer. To be useful, the ACLs should use
> addresses based on the trusted hosts and peer router addresses within the
> local network. Would your concern on this point be adequately addressed if
> the wording of section 9.5 were modified to make it more specific in the
> requirements for acceptance of query and request packets (as detailed in
> the paragraph on ACL usage above)?
> > >>
> > >>
> > >> I think the security requirement here is that it not be possible to
> cause the system to send >> 1 packet to a given unverified address in
> response to a single packet in. If you require ACL checking that prevents
> address forgery, then I think that would be OK.
> > >>>
> > >>>>
> > >>>> 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
> > >>>> >  a query ID that was large and random.
> > >>>> >
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>> Why is that true? It's possible to send massively more than 2^15
> messages/sec.
> > >>>>
> > >>> A huge number of messages can be randomly ignored as specified in
> section 9.5.
> > >>>
> > >>> They can but they need not be. The text above is just a MAY.
> > >>>
> > >>> Not to put too fine a point on it, what's the problem with actually
> having an ID long enough to prevent off-path attack.
> > >>>
> > >>>
> > >> The query ID is not intended as a security protection mechanism. it
> is just a way of matching responses to queries. It isn’t clear how
> extending the query ID would provide protection against any actual attack
> scenario. is there one that you have in mind that should be considered? If
> you believe that there is a problem that would be solved or alleviated by
> extending the length of the query ID and the WG agrees on this change, we
> will modify the specification.
> > >>
> > >> The problem I am concerned with is response forgery (by ID guessing)
> by off-path attackers. If you make the ID unguessable, that goes away.
> > >>
> > >
> > > Proper use of ACLs at the granularity of allowed ingress interfaces
> can completely block off-path attacks. (See the previous response for
> details.)
> > >
> > >>
> > >>>>
> > >>>> > - 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.
> > >>>>
> > >>>> Yes, but if you are on-path you know all this stuff.
> > >>>>
> > >>>
> > >>> If a malicious sender knows the query ID and client port of an
> extant query because it is “on path”, then using a bigger query ID wouldn’t
> help. In addition, this information could only be seen by the routers and
> switches within a user’s network. Is there some practical scheme that can
> and should be implemented to protect against this type of attach
> originating from routers and switches within the network of a querying
> client?
> > >>>
> > >>> I don't know if it's practical or not, but typically we would
> cryptographically protect the values. As I said, this may be impractical,
> but at minimum your security considerations need to adequately document
> this attack and why you can't protect against it.
> > >>>
> > >> Because, by definition, the endpoint with which cryptographic
> protection would need to be established is not known to the requesting
> client, there is no immediately obvious way of doing this.
> > >> Would this concern be satisfied if, in an expanded revision of the
> “Amplification Attack” subsection (9.7.2) within the “Security
> Considerations” section, we provide a more detailed analysis of the
> possible mechanisms and associated risk, and document the fact that
> cryptographic protection of the query ID (and requesting client ID address)
> can not be provided in a way that is practical?
> > >>
> > >> Yes, I think this point would be satistified.
> > >>
> > >> -Ekr
> > >>
> > >>
> > >>
> > >>
> > >>> -Ekr
> > >>>
> > >> Thanks again for your all of your comments, Eric. We are glad to have
> a careful examination of the specification from a security perspective. We
> hope that we have now addressed your concerns (or that they can be
> addressed by the revisions we have proposed), but please let us know if
> there are still any remaining problems or open issues.
> > >>
> > >>                         Kerry
> > >>
> > >>
> > >>>> -Ekr
> > >>>>
> > >>>>
> > >>>> > 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.
> > >>>> >
> > >>>> 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
> > >>>> > should be allowed to instantiate queries.
> > >>>> >
> > >>>> 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”.
> > >>>> >
> > >>>> > 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”
> > >>>> >
> > >>>> The words “It is” have been removed from the cited paragraph and
> other similar adjacent paragraphs.
> > >>>> >
> > >>>> > 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"/
> > >>>> >
> > >>>> >
> > >>>> 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
> > >>>> >   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.
> > >>>> >
> > >>>> 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.
> > >>>> >
> > >>>> > It's not clear to me how one does this. Can you expand?
> > >>>> >
> > >>>> The paragraph has been modified to clarify this point.
> > >>>>
> > >>>> >
> > >>>> > S 3.2.6.
> > >>>> >
> > >>>> >          0x01    # of the returned Standard Response Blocks
> > >>>> >
> > >>>> > 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
> > >>>> > if it provided an overview instead.
> > >>>> >
> > >>>> This section is located where it is because of the sequence of
> operations: Query->Request->Reply.
> > >>>> >
> > >>>> > 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.
> > >>>> >
> > >>>> 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
> > >>>> >   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.
> > >>>> >
> > >>>> >
> > >>>> 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.
> > >>>> ===
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > MBONED mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/mboned
> >
> >
>
>

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned