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.
> ===