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

Warren Kumari <warren@kumari.net> Wed, 04 July 2018 20:07 UTC

Return-Path: <warren@kumari.net>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640E41310AE for <mboned@ietfa.amsl.com>; Wed, 4 Jul 2018 13:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb7rII8u08IL for <mboned@ietfa.amsl.com>; Wed, 4 Jul 2018 13:07:04 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9E1130DD6 for <mboned@ietf.org>; Wed, 4 Jul 2018 13:07:04 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id w16-v6so7734480wmc.2 for <mboned@ietf.org>; Wed, 04 Jul 2018 13:07:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mc1Y9LjkUf6XIcZPijR7wxZWDW86GW+QrASE8yxEKq4=; b=vR9WcR5VPRYUMYi9GqCmmFZ9H+caHOaz4q52lnrDiQvzZ8h6GdXSnBiMIftERmjzwh rLkuotWoVj3FcwyDpzTd+UeLZkjWfAkvVIhykkLb6TKb8EcB6lE0yr0L7oW8ERDXE/tP DNrOzA8GYG59nSpqcGNxY86KqLmv+LpeC4oO77CdZD3uA0rTXy7phqffMlbooDtub+XL XQxvGQhtiwQp0Mg73eE6u56lKegVBypRjy5qflThV9uqogyMWvUda+IUfrfpuAgquAAx 3768HvsIZC8tNKf46FjAVzTfo47e5ak99BBUac/n5oQFQHkhlZna7xAdljNNNjWJdVWO MP/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mc1Y9LjkUf6XIcZPijR7wxZWDW86GW+QrASE8yxEKq4=; b=RwKpvyHpbAoIGsnwpIeBgYO/TaH7dC3gp2dTxjFilMtnFgOxpW9lRS9Kq21brchqEs 5rGdmLIXxlTMJoP+XjNMMjcOPtpwlFz6vk0cXv7pyrvrATtTdmvmYWFWduRhhnQcdc43 VYflBv9X9SofnXl1RryO2UjYF3mYkhDFLATg6qmfJwnCthx9dEx1UiACVuFCfJS+W/Ld EsBEdtnK1VdA8Q8WEqSaim+U9VpfpI12/0lqb145PLhdhwzAGdC+rJQ0bYpLW3fwPFwP 94WXRM5YlU7OqPnZJztJz9zyCELT7a4/9eo0cWM3qSAx8v2KWdXu0BZ0x/OVaIWoJU5T uQ1A==
X-Gm-Message-State: APt69E2UMeYa+QUg44/DE2EWH4BaMULJRM1g5MvjRS04d8KcOz05StDm bJosJVq7VdX2PxHHU1tq3MADQtb0yLjT2hWA467qLA==
X-Google-Smtp-Source: AAOMgpc3jbeK+c4RMUT+R1HFpfFsCzB0l7SY8wx7+Xb3wGEtONxPhw/PHdqpdB5nr61GFzkdhL3irAnVn/9Kk++59mc=
X-Received: by 2002:a1c:8b0d:: with SMTP id n13-v6mr2221237wmd.46.1530734822166; Wed, 04 Jul 2018 13:07:02 -0700 (PDT)
MIME-Version: 1.0
References: <151628969901.2325.7724014542086691903.idtracker@ietfa.amsl.com> <36B5669F-3931-4864-9225-FF42A8B9C122@me.com> <CABcZeBPxQDBaKDpoMPiWodEEUW4+oDONJd980PR4cSyQPeQnNQ@mail.gmail.com> <80A524CD-EC4B-4539-8315-9594C6173AE5@me.com> <CABcZeBMtzsmSpeP8Ai_mBUeZq4yWjXEijE+XDnAs6W-7ukLm+g@mail.gmail.com> <A741347D-72DD-4C32-B01D-A3B8A220446D@me.com> <CABcZeBMVQ2PauprdjmCW8qzo1MrT87G7bxehyknb_JKNTOqbwQ@mail.gmail.com> <B3DCB9C5-50F8-469E-BFB9-8B2F0580BD1A@me.com> <BE71F679-A350-494A-877F-B54F17AAE9A1@ieee.org> <CABcZeBPJ-+s5srnr5AMd4feC8vN9gpgagRxBfgK92AkLMe0yQQ@mail.gmail.com> <0A7ACC08-2808-4D71-857B-00D3E7B68FA2@ieee.org>
In-Reply-To: <0A7ACC08-2808-4D71-857B-00D3E7B68FA2@ieee.org>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 04 Jul 2018 16:06:25 -0400
Message-ID: <CAHw9_iLsE=KnUXP6uEex_sSSPXW-YT8-4mwnv+E06Evt=yrn3A@mail.gmail.com>
To: Hitoshi Asaeda <asaeda@ieee.org>
Cc: Eric Rescorla <ekr@rtfm.com>, draft-ietf-mboned-mtrace-v2@ietf.org, MBONED WG <mboned@ietf.org>, mboned-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005231d9057031f956"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/esSacy9nW54niJKpqPJEWHkHeOs>
Subject: Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 20:07:12 -0000

On Sat, Jun 30, 2018 at 2:34 AM Hitoshi Asaeda <asaeda@ieee.org> wrote:

> Hi Eric,
>
> > On 2018/06/30, at 6:45, Eric Rescorla <ekr@rtfm.com> 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).
>
> Do you think these assumptions are not feasible or we need to add some
> more text to explain these assumptions?
>
>
​... and if not OK, should we try and schedule some ​time to sit down in
Montreal and discuss how we get this unstuck?
W



> Regards,
>
> Hitoshi
>
>
> > -Ekr
> >
> >
> > On Wed, Jun 20, 2018 at 1:05 PM, Hitoshi Asaeda <asaeda@ieee.org> 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 <kerry.meyer@me.com> 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 <ekr@rtfm.com> wrote:
> > >>
> > >>
> > >>
> > >> On Thu, May 24, 2018 at 4:01 PM, Kerry Meyer <kerry.meyer@me.com>
> 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 <ekr@rtfm.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <kerry.meyer@me.com>
> 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 <ekr@rtfm.com> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer <kerry.meyer@me.com>
> 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 <ekr@rtfm.com> 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
> > > MBONED@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mboned
> >
> >
>
>

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