Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Sun, 08 July 2018 22:27 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 EF9E11310E3 for <mboned@ietfa.amsl.com>; Sun, 8 Jul 2018 15:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 WyzkIY7tob5B for <mboned@ietfa.amsl.com>; Sun, 8 Jul 2018 15:27:00 -0700 (PDT)
Received: from mail-yb0-x243.google.com (mail-yb0-x243.google.com [IPv6:2607:f8b0:4002:c09::243]) (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 A9357130ED7 for <mboned@ietf.org>; Sun, 8 Jul 2018 15:26:59 -0700 (PDT)
Received: by mail-yb0-x243.google.com with SMTP id k127-v6so6488794ybk.6 for <mboned@ietf.org>; Sun, 08 Jul 2018 15:26:59 -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=oOYbmaCBxY5fWVnPeFKFdIFvN/xPld3kUthtBq2o5FA=; b=Fb8kT4FORRqKLq/TzG2hZnommMPxy+AbNnBJe0H8qkFTCblj8MlIV1j5HZ49zacD8d xkn+pAfB4tmNqDPESWBqf8nVHp1zCw5PlQUWxl1Gip+o3Hy7hn3sXg/RAY/szCSYvxCR /6q4u2T0oRXZQ7TGPTucaVoHIucIxZuWnVhyZDC0tDgyLnfJLqZt+EBhF2RZkRAO64bv f8XX6vSn3XZXSZOgGoql5EpBw9yB3ewHbfC0fUIv5trweUwOW3WZtFNK6qkb5s3Dvokj o3snt6t2arC97qEDKSCa1Xd2eiC5funvedpxcxBqiVxfuX/6bFwUa8NYa8s87YQDsmZi Q6Eg==
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=oOYbmaCBxY5fWVnPeFKFdIFvN/xPld3kUthtBq2o5FA=; b=t8e7vr4hcwcOk5pqYW2mUA918wCO/yXPvNSfpY/wikBmU4nRmGwAIlKQne20vPIsDY JX6/ZfjYb/rBUACp10w5buxPHFW37HEkfl9h6PJ8e93ZwFrTdMW4FJzYDpPLMaQau6JE axosJ+ObxzRffxGMXIcSVfSdAKWUnS4uh+TsL1vu3LSd8RxqSCmE4Brqunxrhkp4eL7j gLWhR+nAP+VzUyx8IBbWM2QJRRukWrOKAwD0zTp1t4/kEikNK0SPL/fYXqz6ah4sOcBn mtlALHV+qYoPZzDcrbVputO9xzxyzV6WQeweSq+gM63fCL4iRl/kuqWz+gZzaKAOHAjw LVvQ==
X-Gm-Message-State: APt69E2zHv+868NOUpEREgc5tuHG2BIU6E50FRL+w0qKFSVWsaWlrKxr OEm7Q0OV7U5rLQ0+JFEthGhwfMiQDkthg7/a7SkW8w==
X-Google-Smtp-Source: AAOMgpcKPSguiUmkeipql4zvq6/uQU9tUjO7+SaNqs/QwPesIMYG2PbZxfYL3xJX0swMhedcMGszAST9Iyf/CYoZ0vc=
X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr10047550yba.275.1531088818535; Sun, 08 Jul 2018 15:26:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 15:26:17 -0700 (PDT)
In-Reply-To: <E54E31C9-FCD2-4D5D-9295-6BBBF15BD938@me.com>
References: <3779EE09-4481-43DB-A422-9A9FE1A4CEB4@me.com> <E54E31C9-FCD2-4D5D-9295-6BBBF15BD938@me.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 08 Jul 2018 15:26:17 -0700
Message-ID: <CABcZeBPdrfLf8ORuMQsKQ2jg1U0CyZ1jZHHqry2HwMEOf5hFyg@mail.gmail.com>
To: Kerry Meyer <kerry.meyer@me.com>
Cc: Hitoshi Asaeda <asaeda@ieee.org>, 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="00000000000026125f05708465d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/1aWWnxm29bYFKbILhRO8MEMRjJA>
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: Sun, 08 Jul 2018 22:27:06 -0000
On Fri, Jul 6, 2018 at 11:31 PM, Kerry Meyer <kerry.meyer@me.com> wrote: > Eric, > > Please see inline below. > > Kerry > > > On Thu, Jul 5, 2018 at 6:07 AM, Hitoshi Asaeda <asaeda@ieee.org> > <asaeda@ieee.org>>; wrote: > > > > > > > > On 2018/07/05, at 21:22, Eric Rescorla <ekr@rtfm.com> <ekr@rtfm.com>>; wrote: > > > > > > > > > > > > On Wed, Jul 4, 2018 at 10:27 PM, Hitoshi Asaeda <asaeda@ieee.org> <asaeda@ieee.org>>; wrote: > > > Eric, > > > > > > Please see inline. > > > > > > > On 2018/07/05, at 5:16, Eric Rescorla <ekr@rtfm.com> <ekr@rtfm.com>>; wrote: > > > > > > > > > > > > > > > > On Fri, Jun 29, 2018 at 11:34 PM, Hitoshi Asaeda <asaeda@ieee.org> <asaeda@ieee.org>>; > > wrote: > > > > Hi Eric, > > > > > > > > > On 2018/06/30, at 6:45, Eric Rescorla <ekr@rtfm.com> <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. > > > > > > 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 <asaeda@ieee.org> <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> <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> <ekr@rtfm.com>>; wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Thu, May 24, 2018 at 4:01 PM, Kerry Meyer <kerry.meyer@me.com> <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> <ekr@rtfm.com>>; wrote: > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <kerry.meyer@me.com> <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> <ekr@rtfm.com>>; wrote: > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer < > > kerry.meyer@me.com> <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> <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 > > > > > > > > > > > > > > > > > > > > > > >
- 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