Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Mon, 09 April 2018 21:08 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 A17C512D7EC for <mboned@ietfa.amsl.com>; Mon, 9 Apr 2018 14:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Level:
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 3rgdkK-C_sZe for <mboned@ietfa.amsl.com>; Mon, 9 Apr 2018 14:08:10 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 07A7712D7E5 for <mboned@ietf.org>; Mon, 9 Apr 2018 14:08:09 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id 126-v6so9087152oig.0 for <mboned@ietf.org>; Mon, 09 Apr 2018 14:08:09 -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=IQa0e0PQnFoQ91v3vGznPMQfpCZzco1g99EcbWf6dkc=; b=u0jEazqM3LbgdlYJ6O48kncpTbgLrOChfAiYplkANT949kqhpdCAkSXbABE9q3ldkK g3L2Zdmm77L/BT0Hn3iWNAW77m/2YKkCCqdWim9bd2P1p9ZHkgjKKeaVc7ajAJHgDdUk U+OgiMX3fohWKs9vUuzS5zU1z/QINO9r6ZfTAHl2h1OW4YColTk5KffAOt9FUGHbX/Fd xvPrEqngScQjLoqn5iTVUwQH1rdClWqLN8SHSCH1WXi2sYATcCM43MRkd/80ZExP5CIH bBosqSN8VePLxapbJNEMwOXF2U4z8dy+JhzuzMzR/hsBBaC79Jod7To1nRA6XqzP4MhQ vUcQ==
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=IQa0e0PQnFoQ91v3vGznPMQfpCZzco1g99EcbWf6dkc=; b=PKU5PRazjYpVjhXQzTAwue5IJwhq7HktKSKyuZ4jb8ooD6tA85YdD5F9gEvC0lMzLR QIxaCz986qZYe6SIIhagGPL3f3a3jyS8+GZjuYnX+VgECiIc6Dkhz+sUJ0c38JlqvJLn 2mTrizcwU2sUJ6TyK7BHKtlaWCQqIUsa/Mq/E0F00Z3Nch1VNCuv4PYAvhh2hNYovsl1 U/86HZ+VEKKBUIFufkjC4/wbwzG18+MRDjwNJWaxyxnXNduVHInBx/TN6+fwOzWhDeVx PMMxHZ1bFKV3vO8a9gzkKaZgx30kB49aYKKsPsX0btd8ldns4/nAnLiWfcrQryenfgXt ZvMw==
X-Gm-Message-State: ALQs6tBVCStaM3UbUJUsMJCHDWtX195RiUbckYyVbWLb+VCwS5hEuRsx cIa1q0VpqX0wpjmTMbbmq26nptPxHlwAdnUe7usXXw==
X-Google-Smtp-Source: AIpwx48br+uKJVyKB/W1NhLGHEalJuouSnO3zLm3KMPvU0FV+BY2Gyb5fSdVf/Q6/t7TVsekM9bKucZ2jyFD/9zJGdU=
X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr376489oib.138.1523308089250; Mon, 09 Apr 2018 14:08:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Mon, 9 Apr 2018 14:07:28 -0700 (PDT)
In-Reply-To: <36B5669F-3931-4864-9225-FF42A8B9C122@me.com>
References: <151628969901.2325.7724014542086691903.idtracker@ietfa.amsl.com> <36B5669F-3931-4864-9225-FF42A8B9C122@me.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 09 Apr 2018 14:07:28 -0700
Message-ID: <CABcZeBPxQDBaKDpoMPiWodEEUW4+oDONJd980PR4cSyQPeQnNQ@mail.gmail.com>
To: Kerry Meyer <kerry.meyer@me.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mboned-mtrace-v2@ietf.org, Leonard Giuliano <lenny@juniper.net>, mboned-chairs@ietf.org, mboned@ietf.org, Warren Kumari <warren@kumari.net>, Hitoshi Asaeda <asaeda@nict.go.jp>, weesan@weesan.com
Content-Type: multipart/alternative; boundary="0000000000008b2936056970cd68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/KjVjn6jwADVmekgKvcQPOZu5120>
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.22
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: Mon, 09 Apr 2018 21:08:14 -0000
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? > 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. Even assuming that a targeted client has multiple extant queries at a given > time, the chance of matching one is still quite small. More importantly, > the required access control for the Mtrace protocol port (section 9.2, > aforementioned) provides protection against an unauthorized malicious > sender injecting bogus request packets. > How does this protect against forgery to a client. > > - 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. -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. > ===
- 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