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

[Eric Rescorla <[e-mail]>]

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?

-Ekr


On Wed, Jun 20, 2018 at 1:05 PM, Hitoshi Asaeda <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
> >>
> >>
> >>
> >> On Thu, May 24, 2018 at 4:01 PM, Kerry Meyer <[e-mail]>
> 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 <[e-mail]> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <[e-mail]>
> 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 <[e-mail]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer <[e-mail]>
> 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 <[e-mail]> 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/
> statement/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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
>
>