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

[Eric Rescorla <[e-mail]>]

On Fri, Jul 6, 2018 at 11:31 PM, Kerry Meyer <[e-mail]> wrote:

> Eric,
>
> Please see inline below.
>
>           Kerry
>
>
> On Thu, Jul 5, 2018 at 6:07 AM, Hitoshi Asaeda <[e-mail]>
> <[e-mail]&gt>; wrote:
>
> >
> >
> > > On 2018/07/05, at 21:22, Eric Rescorla <[e-mail]> <[e-mail]&gt>; wrote:
> > >
> > >
> > >
> > > On Wed, Jul 4, 2018 at 10:27 PM, Hitoshi Asaeda <[e-mail]> <[e-mail]&gt>; wrote:
> > > Eric,
> > >
> > > Please see inline.
> > >
> > > > On 2018/07/05, at 5:16, Eric Rescorla <[e-mail]> <[e-mail]&gt>; wrote:
> > > >
> > > >
> > > >
> > > > On Fri, Jun 29, 2018 at 11:34 PM, Hitoshi Asaeda <[e-mail]> <[e-mail]&gt>;
> > wrote:
> > > > Hi Eric,
> > > >
> > > > > On 2018/06/30, at 6:45, Eric Rescorla <[e-mail]> <[e-mail]&gt>; 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.
> > >
> > > No, we don't prevent you from sending such Query since (we assume) you
> > are valid user.
> > > Since you are valid user, your query is accepted by the router and the
> > router forwards it as the valid request. However, the request cannot be
> > forwarded to its upstreams without splitting the original query because of
> > the limitation of packet size (e.g., MTU limitation), etc. As the result,
> > you will receive multiple replies *with NO_SPACE error code*. We think this
> > is a correct behavior and should not be categorized as DoS.
> > > On the other hand, although you are a legitimate user, if you repeat
> > this type of query many times and after all traffic is amplified, routers
> > can warn you. Even so, if you ignore the warnings and repeat such
> > amplification, the router consider this is a type of DoS and rate limit (or
> > filter out) such query based on the ACL explained above paragraph you
> > copied from the document.
> > >
> > > But this just says it "MAY" do that. Which means it won't.
> >
> > So, is the problem for you here is the wording? If so, please see the
> > modified paragraph I mentioned below.
> >
> > > BTW, above paragraph you copied explains the situation in which
> > unauthorized users initiate queries. The paragraph corresponding to your
> > example is the following one;
> > >    o  A malicious application running on a trusted server or router
> > >       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 same host that is the target of the
> > >       attack or from another "on path" host, but this is not a likely
> > >       threat scenario.  In addition, routers on the path MAY rate-limit
> > >       the packets as specified in Section 9.5 and Section 9.6.
> > >
> > > I think you're misunderstanding me. What I do here is I generate
> > something which appears to be a Request from someone else (with their IP)
> > and is so big it will produce amplification. I then forward it to the
> > upstream router (as permitted by ACL even though I'm a client and should
> > only be sending Queries). This doesn't cause responses to me but to some
> > other person. And as above there's no requirement that there be any actual
> > rate limitation.
> >
> > I thought you talked about amplification caused by multiple
> > requests/replies initiated by a legal querier.
> >
> For address spoofing, we mentioned in the document 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 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.  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.
> >
>
> It *is* a legal querier. It's just sending a *request* rather than a query.
> The point is that you need a different ACL for queries and requests, and
> not to accept requests from queriers.
>
> As this language isn't a normative description of the ACL functionality,
> it's not clear what's being mandated.
>
> An ACL can only specify restrictions down to the granularity of allowed IP
> addresses and IP address ranges for a given protocol port number. ACLs
> don’t provide a way of separately authorizing a specific message type sent
> for a given protocol port.
>

This may be true of the particular ACLs you are using, but it's not a
general property of ACLs.


Section 4.2.1, however (see below), prohibits processing of a Request that
> is not sent from an adjacent router
>


. Also, it is worth considering that this problem hypothesis supposes that
> a DoS attack is launched from a trusted router address. Even for this
> scenario, however, the document does provide protection. The normative
> descriptions to which the quote above refers are:
>
> -  The previous paragraph from section 9.2 (requirement for use of ACLs;
> slightly reworded later in this email to the new proposed text):
>
> ----------
>    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.
> ----------
>
>
>  and
>
> - Section 4.2.1 (required validity checks to force rejection of a Request
> message from a source that is not an adjacent router):
>
> ----------
> 4.2.1.  Request Packet Verification
>
>    If the Mtrace2 Request does not come from an adjacent router, or if
>    the Request is not addressed to this router, or if the Request is
>    addressed to a multicast group which is not a link-scoped group
>    (i.e., 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be
>    silently ignored.  The Generalized TTL Security Mechanism (GTSM) [14]
>    SHOULD be used by the router to determine whether the router is
>    adjacent or not.
> ----------
>

Unless I'm missing something, this just restricts things to a *node* which
is adjacent. But if I'm a device that's on the same LAN as a router (which
isn't a crazy proposition, ISTM), then why can't I mount this attack?

Given that we're a week from Montreal, it might be easier to just try to
meet there. What say you?

-Ekr


> NOTE:  To protect against spoofing of Request packets by a trusted host,
> some authentication mechanism such as use of an Authentication Header (AH)
> between routing peers should be also considered. However, discussion of
> such external authentication mechanisms is out of the scope of this
> document.
>
> If this doesn't satisfy you, could you tell me which point is ambiguous or
> > how we should change this paragraph?
> >
> > >
> > > > Also, MUST support seems pretty weak here. Shouldn't this at least be
> > SHOULD use?
> > >
> > > Are you saying the statement, "A router MUST support an access control
> > list (ACL) mechanism...", should be "A router SHOULD support an access
> > control list (ACL) mechanism..."?
> > > According to the discussions during the IESG review, we believe we agree
> > ACL is MUST and
> > >
> > > BTW, I cannot understand "MUST support is pretty weak". More stronger
> > tone required here?
> > >
> > > Sorry that was badly written. I think that the router MUST implement and
> > SHOULD use. ACLs.
> >
> > That's clear.
> > Ok, I'll change the wording such as;
> >
> >    A router MUST implement and SHOULD enable 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 SHOULD, however, perform rate limited logging of such events.
> >
>
> This just seems pretty handwavy.. What I'm looking for is a specific
> description of the access control checks (not just "check the ACL") that
> you have to perform and then when performed prevents amplification attacks.
>
> Please see my previous response in this email. For the paragraph above,
> would you prefer the following rewording of the first paragraph in section
> 9.2 to more explicitly specify (require) that the ACLs filter based on the
> allowed addresses or address ranges for the interfaces on which Mtrace V2
> packet reception is to be enabled and to recommend  rate limited logging?
>
>  9.2.  Filtering of Clients and Peers
>
>    A router MUST implement and SHOULD enable 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 MUST 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 SHOULD, however,
>    perform rate limited logging of such events.
>
> -Ekr
>
>
> > This paragraph addresses your concerns?
> >
> > Regards,
> >
> > Hitoshi
> >
> >
> >
> > > -Ekr
> > >
> > >
> > > Regards,
> > >
> > > Hitoshi
> > >
> > >
> > > > -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 <[e-mail]> <[e-mail]&gt>;
> > 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]> <[e-mail]&gt>; 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]> <[e-mail]&gt>; wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Thu, May 24, 2018 at 4:01 PM, Kerry Meyer <[e-mail]> <[e-mail]&gt>;
> > 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]> <[e-mail]&gt>; wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <[e-mail]> <[e-mail]&gt>;
> > 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]> <[e-mail]&gt>; wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer <
> > [e-mail]> <[e-mail]&gt>; 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]> <[e-mail]&gt>;
> > 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
> > > > >
> > > > >
> > >
> > >
> >
> >
>
>
>