Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Wed, 04 July 2018 20:16 UTC
Return-Path: <ekr@rtfm.com>
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 828D51310B4 for <mboned@ietfa.amsl.com>; Wed, 4 Jul 2018 13:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 E_c7jNgtKeQ2 for <mboned@ietfa.amsl.com>; Wed, 4 Jul 2018 13:16:49 -0700 (PDT)
Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 B09DD13108E for <mboned@ietf.org>; Wed, 4 Jul 2018 13:16:44 -0700 (PDT)
Received: by mail-yw0-x242.google.com with SMTP id w76-v6so2258569ywg.4 for <mboned@ietf.org>; Wed, 04 Jul 2018 13:16:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2+0kO/gy64Gs4dZoPMjkLAqZ+lNtCMuPRx1DS5fyJqo=; b=nEXylc8Wu09nvuqC4M9jfEbMmBqcEW1UVYAZlhatb1aiVySZSXZaY49xVGDDvlSpPl Xz1nu3Ck4Kx21wj7KgjGutBcfWyzE52FYPsJPmVyXiT4IJitU0Oqsd+JKIlTGgS8FXjF 60TK+7pN64CUtKHltHbEqccb8tuPpkPfkuCgvsREpc8Y2PjEZKTppgPJghZsPuqYOE3F XJIq/fIC7ZUI3xhGz58QOpDM1+nnUqFsxhphaChhZeEunIiZcJUaJ73mpJLm82utm46Z 4STdim3g38aGNWCkiTdtOBaoupbxVveBe9ubW1KqDa5xKEA2Z5ieoGXRraow0UwdIn3t 6eSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2+0kO/gy64Gs4dZoPMjkLAqZ+lNtCMuPRx1DS5fyJqo=; b=hwOv9HbNDa0M8+71KMiabTeFJ5ATtIVmfWsHR5Mlj5Jc0IVxb89Uco/Pzq15tKYECZ cpOETlJcMXFNgSz/6qWMnPdbvvsy0tcYtXs3XqMdxDF6aG5UDnNRYYLoWukhiJoSWmGd TNktWx/V71XdSCYPMPuPnFXKzmPCwYi4JS/+IgQr73FcyqZPf9HII4sBwTDEb5U8VHW+ hGFe9jCIzF9FXDusbllGCTj+RPXdebCVsev6eN791RWpEDdlQ/ZJ3iLM+MmsAoESvHkB OaAiGkHZySmk+PSXXIbpwYroE4zREt7WJNb75KH5WksJtLsy58EJKytY+il0OrsbqgTD 3Nbg==
X-Gm-Message-State: APt69E2vQmL4nSjo1H6eGt3ALHJS3Hwg0jon8+9lE5Nc72jBezQd7GsB fZt0e0/fcrTrHQpM5YUjIdt+YwnTYZ6iymwVnWIxMw==
X-Google-Smtp-Source: AAOMgpdn5kIxMbfLTqcng95zttBm7EKU63HtLNpFsRfzfQF9jf10uJbK9VGWxgd2qCCqKZnWnbVOz2X+jKL0glHsXWM=
X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr1648722ywk.102.1530735403644; Wed, 04 Jul 2018 13:16:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 13:16:03 -0700 (PDT)
In-Reply-To: <0A7ACC08-2808-4D71-857B-00D3E7B68FA2@ieee.org>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 04 Jul 2018 13:16:03 -0700
Message-ID: <CABcZeBN6z=iHm2V8okDhMxxaZmQHCeto0cj+bnRTv4D2cTYoKg@mail.gmail.com>
To: Hitoshi Asaeda <asaeda@ieee.org>
Cc: draft-ietf-mboned-mtrace-v2@ietf.org, The IESG <iesg@ietf.org>, MBONED WG <mboned@ietf.org>, mboned-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fad18d0570321bfa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/7MBiOz6oJgEHWlzXUwZxCT0b_ro>
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:16:54 -0000
On Fri, Jun 29, 2018 at 11:34 PM, 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). > This seems like the kind of thing that routers are likely not to do, because the guidance is so vague. For instance: A router MUST support an access control list (ACL) mechanism to filter out Queries from clients and Requests from peer router addresses that are unauthorized or that are beyond a specified administrative boundary. This filtering could, for example, be specified via a list of allowed/disallowed client and peer addresses or subnets for the Mtrace2 protocol port. If a Query or Request is received from an unauthorized address or one beyond the specified administrative boundary, the Query/Request MUST NOT be processed. The router MAY, however, perform rate limited logging of such events. This doesn't prevent me from initiating a message (that should be a Query) but actually is a Request, in which case I can just forge any alleged initial querier myself. Also, MUST support seems pretty weak here. Shouldn't this at least be SHOULD use? -Ekr Do you think these assumptions are not feasible or we need to add some more > text to explain these assumptions? > > Regards, > > Hitoshi > > > > -Ekr > > > > > > On Wed, Jun 20, 2018 at 1:05 PM, Hitoshi Asaeda <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/stat > ement/discuss-criteria.html > > >>>> > for more information about IESG DISCUSS and COMMENT positions. > > >>>> > > > >>>> > > > >>>> > The document, along with other ballot positions, can be found > here: > > >>>> > https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ > > >>>> > > > >>>> > > > >>>> > > > >>>> > ------------------------------------------------------------ > ---------- > > >>>> > DISCUSS: > > >>>> > ------------------------------------------------------------ > ---------- > > >>>> > > > >>>> > The security considerations of this document are inadequate. My > review > > >>>> > turns up at least the following potential issues which do > > >>>> > not seem to be addressed or even discussed: > > >>>> > > > >>>> > - Amplification: this protocol does not appear to verify that the > > >>>> > sender of the query actually owns the IP it claims. Because > > >>>> > responses are much larger than queries, this allows for an > amplification > > >>>> > attack, especially if the client is able to send a query that > elicits > > >>>> > multiple replies. One defense here would be to fill the rest of > the packet > > >>>> > with zeroes, thus somewhat reducing the amplification factor. > Access > > >>>> > control would also help. > > >>>> > > > >>>> We understand that access control is required to protect against > this and other threats from malicious senders. This will be specified in > section 9.2 as follows; > > >>>> > > >>>> "A router MUST support a mechanism to filter out queries from > clients > > >>>> and “requests” from peer router addresses that are unauthorized or > > >>>> that are beyond a specified administrative boundary. This filtering > > >>>> could, for example, be specified via a list of allowed/disallowed > client > > >>>> and peer addresses or subnets for the Mtrace2 protocol port. If a > query > > >>>> or request is received from an unauthorized address or one beyond > the > > >>>> specified administrative boundary, the Query/Request MUST NOT be > > >>>> processed. The router MAY, however, perform rate limited logging of > such > > >>>> events." > > >>>> > > >>>> This seems like an improvement, but still seems to allow > amplification to any > > >>>> client which is a valid requestor. So, if I have one such on my > network, then > > >>>> I am subject to DoS? > > >>>> > > >>> For valid queries/requests, we specified limiting query/request > rates in section 9.5 as follows; > > >>> > > >>> "A router may limit Mtrace2 Queries and Requests by ignoring some of > > >>> the consecutive messages. The router MAY randomly ignore the > > >>> received messages to minimize the processing overhead, i.e., to keep > > >>> fairness in processing queries, or prevent traffic amplification. > > >>> The rate limit is left to the router's implementation.” > > >>> > > >>> This seems like the kind of thing that's going to get ignored. As a > comparison point, > > >>> consider QUIC, which forbids sending >3 messages in response to an > Initial > > >>> packet. > > >>> > > >> For mtrace V2, only one response is accepted for a given query. (So > the “response packet limit” is already rigidly set to “1”.) > > >> > > >> Well, it's not a matter of *accepted*. It's a matter of sent. Here's > the specific attack I have in mind. > > >> > > >> Say that I have a Request that would ordinarily traverse routers R1, > R2, ..... R_n. I construct a request that is just under the > > >> MTU (it has a bunch of unknown T-bit set query block plus one > Response block). I send it to R1. Per S 4.3.3., the router then > > >> returns a Reply with NO_SPACE to the Client IP and then forwards the > Request with an Augmented Response Block plus its own > > >> Response Block upstream. This process repeats at R2, R3, ... RN. The > result is N-times amplification. This is bad even without > > >> ClientIP forgery, but can be very bad in that case. > > >> > > >> Am I wrong about this? > > >> > > > > > > Thanks for explaining this form of attack. This clarifies your > previously described concern that any client that is a valid requestor > could initiate an attack. It does describe a viable scheme for an > amplification attack. > > > > > > Because the granularity with which ACLs can be applied (and the > granularity that we will recommend in our expanded section on use of ACLs > for protection against security threats) is at the interface level, only > clients directly connected to a given interface would be able to send > queries over that interface. This does not prevent an attack from a > malicious application on a trusted server, but it can prevent attacks from > all other servers. > > > > > > The proposed additions to the “Security Considerations” section to > address this type of vulnerability are as follows: > > > > > > **** > > > > > > The required use of ACLs on the participating routers minimizes the > possible methods for introduction of spoofed query/request packets that > would otherwise enable DoS amplification attacks targeting an authorized > “query” host. The ACLs provide this protection by allowing queries from an > authorized host address to be received only by the router(s) connected to > that host, and only on the interface to which that host is attached. For > protection against spoofed “request” messages, the ACLs allow requests only > from a directly connected peer and allow these messages to be received only > on the interface to which that peer is attached. > > > > > > > > > Note: The following vulnerabilities can not be covered by the ACL > methods described here. These methods can, nevertheless, prevent attacks > launched from outside the boundaries of a given network as well as from any > hosts within the network that are not on the same LAN as an intended > authorized query client. > > > > > > - A server “B” other than the server “A" that actually “owns” a > given IP address could, if it is connected to the same LAN, send an mtrace > query with the source address set to the address for server “A”. This is > not a significant threat, however, if only trusted servers are connected to > that LAN. > > > > > > - A malicious application running on a trusted server could send > packets that might cause an amplification problem. It is beyond the scope > of this document to protect against a DOS attack launched from the server > that is the target of the attack, but this is not a likely threat scenario. > > > > > > An additional note: While it is not practical to provide cryptographic > protection between a client and the mtrace endpoints (destinations), it may > be practical to prevent the types of attacks described above by devising a > scheme to encrypt mtrace query packets via configuration of trusted servers > and their associated first hop routers. This type of node/application > authentication and authorization is, however, out of the scope of this > document. > > > > > >> > > >>> In addition, the required use of ACLs on the participating routers > prevents the introduction of spoofed query/request packets that would > otherwise enable DoS amplification attacks targeting an authorized “query” > host. The ACLs provide this protection by allowing queries from an > authorized host address to be received only by the router(s) connected to > that host, and only on the interface to which that host is attached. For > protection against spoofed “request” messages, the ACLs allow requests only > from a directly connected peer and allow these messages to be received only > on the interface to which that peer is attached. > > >>> > > >>> Don’t these provisions address your concern?" > > >>> > > >>> I'm not sure I follow where this is required. The text you are > quoting here is a lot more vague than this. Why can't "authorized" be > anyone? > > >>> > > >> The use of the word “authorized” is intended to allow discretion on > the part of the network engineer. To be useful, the ACLs should use > addresses based on the trusted hosts and peer router addresses within the > local network. Would your concern on this point be adequately addressed if > the wording of section 9.5 were modified to make it more specific in the > requirements for acceptance of query and request packets (as detailed in > the paragraph on ACL usage above)? > > >> > > >> > > >> I think the security requirement here is that it not be possible to > cause the system to send >> 1 packet to a given unverified address in > response to a single packet in. If you require ACL checking that prevents > address forgery, then I think that would be OK. > > >>> > > >>>> > > >>>> Additional text has been added to section 9.7 (see later in this > mail) to explicitly map this and other concerns to the recommended > prevention mechanism. > > >>>> > > >>>> > - Forgery of responses: because the query id is so short, an > attacker > > >>>> > can generally produce a message which has a nontrivial chance of > > >>>> > corresponding to an extant query. This could be addressed by > having > > >>>> > a query ID that was large and random. > > >>>> > > > >>>> > > >>>> Because there are 2**16 possible query ID values, an average of > 2**15 forged response attempts would be required to “hit” the actual query > ID for a given extant query. The amount of time to do this would far exceed > the lifetime of an extant query/response. > > >>>> > > >>>> Why is that true? It's possible to send massively more than 2^15 > messages/sec. > > >>>> > > >>> A huge number of messages can be randomly ignored as specified in > section 9.5. > > >>> > > >>> They can but they need not be. The text above is just a MAY. > > >>> > > >>> Not to put too fine a point on it, what's the problem with actually > having an ID long enough to prevent off-path attack. > > >>> > > >>> > > >> The query ID is not intended as a security protection mechanism. it > is just a way of matching responses to queries. It isn’t clear how > extending the query ID would provide protection against any actual attack > scenario. is there one that you have in mind that should be considered? If > you believe that there is a problem that would be solved or alleviated by > extending the length of the query ID and the WG agrees on this change, we > will modify the specification. > > >> > > >> The problem I am concerned with is response forgery (by ID guessing) > by off-path attackers. If you make the ID unguessable, that goes away. > > >> > > > > > > Proper use of ACLs at the granularity of allowed ingress interfaces > can completely block off-path attacks. (See the previous response for > details.) > > > > > >> > > >>>> > > >>>> > - Anyone on-path can forge responses. > > >>>> > > > >>>> The forger would need to match the query ID and the dynamically > allocated client (source) port (REF: section 3.2.1) to create a valid reply > message that would pass validity checks at the client. > > >>>> > > >>>> Yes, but if you are on-path you know all this stuff. > > >>>> > > >>> > > >>> If a malicious sender knows the query ID and client port of an > extant query because it is “on path”, then using a bigger query ID wouldn’t > help. In addition, this information could only be seen by the routers and > switches within a user’s network. Is there some practical scheme that can > and should be implemented to protect against this type of attach > originating from routers and switches within the network of a querying > client? > > >>> > > >>> I don't know if it's practical or not, but typically we would > cryptographically protect the values. As I said, this may be impractical, > but at minimum your security considerations need to adequately document > this attack and why you can't protect against it. > > >>> > > >> Because, by definition, the endpoint with which cryptographic > protection would need to be established is not known to the requesting > client, there is no immediately obvious way of doing this. > > >> Would this concern be satisfied if, in an expanded revision of the > “Amplification Attack” subsection (9.7.2) within the “Security > Considerations” section, we provide a more detailed analysis of the > possible mechanisms and associated risk, and document the fact that > cryptographic protection of the query ID (and requesting client ID address) > can not be provided in a way that is practical? > > >> > > >> Yes, I think this point would be satistified. > > >> > > >> -Ekr > > >> > > >> > > >> > > >> > > >>> -Ekr > > >>> > > >> Thanks again for your all of your comments, Eric. We are glad to have > a careful examination of the specification from a security perspective. We > hope that we have now addressed your concerns (or that they can be > addressed by the revisions we have proposed), but please let us know if > there are still any remaining problems or open issues. > > >> > > >> Kerry > > >> > > >> > > >>>> -Ekr > > >>>> > > >>>> > > >>>> > In addition, Section 9.4 seems inadequate. Isn't it generally the > case that > > >>>> > who is sending to who is sensitive? This seems like a fairly > serious privacy > > >>>> > obstacle to using this protocol at all. > > >>>> > > > >>>> The requirement to specify a list of “trusted” clients (section > 9.2) provides a mechanism to avoid the dissemination of this information to > unauthorized hosts. > > >>>> > > >>>> > It seems like many of the issues I raise above would be fixed or > at > > >>>> > least mitigated by having some sort of access control mechanism. > I > > >>>> > understand why it might be the case that it's not practical to > have > > >>>> > full communication security between the links (though it would of > > >>>> > course be desirable), but it's not clear to me why arbitrary > people > > >>>> > should be allowed to instantiate queries. > > >>>> > > > >>>> Agreed. The requirement to restrict the addresses permitted to send > Mtrace messages to a given router is specified in an expanded version of > section 9.2. > > >>>> > > > >>>> > ------------------------------------------------------------ > ---------- > > >>>> > COMMENT: > > >>>> > ------------------------------------------------------------ > ---------- > > >>>> > > > >>>> > S 1. > > >>>> > When an Mtrace2 client initiates a multicast trace, it sends an > > >>>> > Mtrace2 Query packet to the LHR or RP for a multicast group and, > > >>>> > > > >>>> > This seems a bit confusing as there are multiple LHRs for the > group. > > >>>> > Can you rephrase? > > >>>> > > > >>>> The word “the” preceding “LHR ...” has been changed to “an”. > > >>>> > > > >>>> > S 2.1. > > >>>> > ALL-[protocol]-ROUTERS group > > >>>> > It is a link-local multicast address for multicast routers to > > >>>> > > > >>>> > This is grammatically funny. Perhaps remove "It is” > > >>>> > > > >>>> The words “It is” have been removed from the cited paragraph and > other similar adjacent paragraphs. > > >>>> > > > >>>> > S 3. > > >>>> > additional information associated with the message. If an > > >>>> > implementation receives an unknown TLV type for the first TLV > in a > > >>>> > message (i.e., the header TLV), it SHOULD ignore and silently > discard > > >>>> > the entire packet. If an implementation receives an unknown > TLV type > > >>>> > for a subsequent TLV within a message, it SHOULD ignore and > silently > > >>>> > discard the entire packet. > > >>>> > > > >>>> > ISTM that these cases are handled identically so is there a reason > > >>>> > not just to remove the first sentence and change the second one to > > >>>> > "for any TLV"/ > > >>>> > > > >>>> > > > >>>> These two cases have been combined to reflect the fact that there > is no difference in handling. > > >>>> > > >>>> “If an implementation receives an unknown TLV type for any TLV in a > > >>>> message, it SHOULD ignore and silently discard the entire packet.” > > >>>> > > >>>> > > > >>>> > S 3.2.1 > > >>>> > An Mtrace2 Query is usually originated by an Mtrace2 client > which > > >>>> > sends an Mtrace2 Query message to the LHR. When tracing > towards the > > >>>> > source or the RP, the intermediate routers MUST NOT modify the > Query > > >>>> > message except the Type field. > > >>>> > > > >>>> > I'm not sure I follow this. Don't routers either (a) not touch > this at all > > >>>> > or (b) if they are the LHR, change Type from Query -> Request and > then > > >>>> > add a response block? This text seems to not really capture > either case. > > >>>> > > > >>>> The paragraph has been modified based on this comment as follows; > > >>>> > > >>>> “An Mtrace2 Query is originated by an Mtrace2 client which > > >>>> sends an Mtrace2 Query message to the LHR. The LHR modifies only > > >>>> the Type field of the Query TLV (to turn it into a “Request”) > > >>>> before appending a Standard Response Block and forwarding it > upstream. > > >>>> The LHR and intermediate routers handling the Mtrace2 message when > > >>>> tracing upstream MUST NOT modify any other fields within the > > >>>> Query/Request TLV. Additionally, intermediate routers handling > > >>>> the message after the LHR has converted the Query into a Request > > >>>> MUST NOT modify the type field of the Request TLV. If the actual > number > > >>>> of hops is not known, an Mtrace2 client could send an initial Query > > >>>> message with a large # Hops (e.g., 0xff), in order to try to trace > the > > >>>> full path.” > > >>>> > > > >>>> > S 3.2.4. > > >>>> > Note that Mtrace2 does not require all the routers on the > path to > > >>>> > have synchronized clocks in order to measure one-way latency. > > >>>> > > > >>>> > It's not clear to me how one does this. Can you expand? > > >>>> > > > >>>> The paragraph has been modified to clarify this point. > > >>>> > > >>>> > > > >>>> > S 3.2.6. > > >>>> > > > >>>> > 0x01 # of the returned Standard Response Blocks > > >>>> > > > >>>> > Nit: Do you want to say 0x0001 > > >>>> > > > >>>> Done, thanks. > > >>>> > > >>>> > Also, an example of the case covered by this section would help, > I think. > > >>>> > > > >>>> > > > >>>> > > > >>>> > S 4.4. > > >>>> > It might be clearer to move this up a bit in the text as it sort > of > > >>>> > summarizes some cases you already covered before. It would be > easier > > >>>> > if it provided an overview instead. > > >>>> > > > >>>> This section is located where it is because of the sequence of > operations: Query->Request->Reply. > > >>>> > > > >>>> > S 5.9. > > >>>> > > > >>>> > In this case, the Mtrace2 > > >>>> > client may receive multiple Mtrace2 Replies from different > routers > > >>>> > along the path. When this happens, the client MUST treat them > as a > > >>>> > single Mtrace2 Reply message. > > >>>> > > > >>>> > Can you please describe how the client reassembles multiple > messages > > >>>> > into one. I think I may know how to do this, but the document > should > > >>>> > tell me. > > >>>> > > > >>>> The paragraph has been expanded based on this comment as follows; > > >>>> > > >>>> "When the NO_SPACE error occurs, as described in Section 4.2, a > router > > >>>> will send back an Mtrace2 Reply to the Mtrace2 client, and continue > > >>>> with a new Request (see Section 4.3.3). In this case, the Mtrace2 > > >>>> client may receive multiple Mtrace2 Replies from different routers > > >>>> along the path. When this happens, the client MUST treat them as a > > >>>> single Mtrace2 Reply message by collating the augmented response > > >>>> blocks of subsequent replies sharing the same query ID, sequencing > > >>>> each cluster of augmented response blocks based on the order in > > >>>> which they are received." > > >>>> > S 8. > > >>>> > The following new registries are to be created and maintained > under > > >>>> > the "RFC Required" registry policy as specified in [4]. > > >>>> > > > >>>> > Why did you choose RFC Required rather than Specification > Required? > > >>>> > This just seems to unduly put load on the ISE. > > >>>> > > > >>>> > > > >>>> Agreed. The sentence has been modified based on this comment. > > >>>> > > >>>> ****** > > >>>> Addtional Note: > > >>>> > > >>>> According to above considerations, we added a new section 9.7 as > shown below; > > >>>> === > > >>>> 9.7 Specific Security Concerns > > >>>> > > >>>> This subsection describes some of the specific security concerns > and > > >>>> exposures that have been considered during the design of the > Mtrace2 > > >>>> protocol. Where applicable, the exposures are mapped to the > > >>>> corresponding remedy listed in the previous subsections. > > >>>> > > >>>> 9.7.1 Request and Response bombardment > > >>>> > > >>>> A malicious sender could generate invalid and undesirable Mtrace > > >>>> traffic to hosts and/or routers on a network by eliciting > responses to > > >>>> spoofed or multicast client addresses. This could be done via > forged > > >>>> or multicast client/source addresses in Mtrace Query or Request > > >>>> messages. The recommended protections against this type of attack > are > > >>>> described in sections 9.1, 9.2, 9.5, and 9.6 above. > > >>>> > > >>>> 9.7.2 Amplification attack > > >>>> > > >>>> Because an Mtrace Query results in Mtrace Request and Mtrace Reply > > >>>> messages that are larger than the original message, the potential > > >>>> exists for an amplification attack from a malicious sender. This > > >>>> threat is minimized by restricting the set of addresses from which > > >>>> Mtrace messages can be received on a given router as specified in > > >>>> section 9.2. > > >>>> > > >>>> 9.7.3 Leaking of confidential topology details > > >>>> > > >>>> Mtrace queries are a potential mechanism for obtaining > confidential > > >>>> topology information for a targeted network. Sections 9.2 and 9.4 > > >>>> describe required and optional methods for ensuring that Mtrace > > >>>> information is not disseminated to unauthorized hosts. > > >>>> > > >>>> 9.7.4 Delivery of false mtrace information > > >>>> > > >>>> Forged “Reply” messages could potentially provide a host with > > >>>> invalid or incorrect topology information. This threat is > mitigated > > >>>> by the following factors: > > >>>> > > >>>> - The required filtering of permissible source addresses > specified > > >>>> in section 9.2 eliminates the origination of forged replies > from > > >>>> addresses that have not been authorized to send Mtrace > messages > > >>>> to routers on a given network. > > >>>> > > >>>> - To forge a Reply, the sender would need to somehow know the > > >>>> associated two byte query ID for an extant Query and the > > >>>> dynamically allocated source port number. > > >>>> === > > >>>> > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > MBONED mailing list > > > MBONED@ietf.org > > > https://www.ietf.org/mailman/listinfo/mboned > > > > > >
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- [MBONED] Eric Rescorla's Discuss on draft-ietf-mb… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda