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

Eric Rescorla <ekr@rtfm.com> Sat, 19 May 2018 22:10 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 1C4E512EB01 for <mboned@ietfa.amsl.com>; Sat, 19 May 2018 15:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 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_LOW=-0.7, 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 LC5iuu5uHkjj for <mboned@ietfa.amsl.com>; Sat, 19 May 2018 15:10:33 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 C9A1012EB0A for <mboned@ietf.org>; Sat, 19 May 2018 15:10:29 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id b130-v6so10081428oif.12 for <mboned@ietf.org>; Sat, 19 May 2018 15:10:29 -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=/WvYXprTq5XxEr3Wq97S/7UaMGKhScwPjzUlYwHLtpE=; b=poFcH4zjQKdhPnQmm51XiLy2w2xsI/ev+d1yScA1lj44xcy5BVN37kuGDc3iw+/HyX Z910NA4CRI8S09ZC2qhL3srOrDdFhfD4AFksSopAid9HmObrFFYoDDk7CRJvna9ov6Wh Bq0v9pphTDS2LXPrfz/2ArIF7uTqdo1IgKimrBvE24ATnh6Sy4MNXkRWAVofue/b8WW5 XZ3hHYmpBInxwiZI2xDqNPwaZK5sW5XBkSacfJPkMlDFb1bm3yGxcmLP5xD9YtL0hLZh lHc6sUi9Y9KnM70LOJQuvreoHh1gb7PNKRJ8SxzChXQKXhuTKxP4FZUKR2kLaYidJz7H k8Rg==
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=/WvYXprTq5XxEr3Wq97S/7UaMGKhScwPjzUlYwHLtpE=; b=ESTOKqTuWO0KTmGRLB6K/VQXYqREqX+6KCmL+MYGn1FhOKgVvAOFwwhAdRMKw+ULqt xQBIzmYwQfXapE9T51gLnvMcdnOSQZ5GHEBRYu+hEBDfVz4JjbLCYtCA7l/DYY/k1zHQ crWVX/qTmTCcbrFXh9TgpJI9LL2bvQT0Q/UZ3KztCd5jGHb24qdd4Dj/X1as+PoEMbVm O5788kbKAKd4vf+bar92sInZpVNahc8I8EKfp5qUmBVDTCnW3HS8BkwWL2sOGv8rF69R 8qzZc6I/kpm00pErrYeK2QLfh4MeWYTaRSse6Qo1z/8GDUHQjV8XDMQjmneqQ5QUkEhj 6nDQ==
X-Gm-Message-State: ALKqPwcxpj+V0t1MWFgGKszS9I9tuaOjHsLTbqSVS05oaC2HpWxNCYWR 1lBtgOrqGcTSPjlAscUbafLtuFIOKcJMOregsVcESA==
X-Google-Smtp-Source: AB8JxZroIab/aHpL10CgFHhwBkZl560cPZi3lqEfpJzRzPWRYITHqIm8a4WEWO2Y5b9C3bClQzS4NxK+Smptxbjtcsc=
X-Received: by 2002:aca:c589:: with SMTP id v131-v6mr9009870oif.92.1526767828975; Sat, 19 May 2018 15:10:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.118.130 with HTTP; Sat, 19 May 2018 15:09:48 -0700 (PDT)
In-Reply-To: <80A524CD-EC4B-4539-8315-9594C6173AE5@me.com>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 19 May 2018 15:09:48 -0700
Message-ID: <CABcZeBMtzsmSpeP8Ai_mBUeZq4yWjXEijE+XDnAs6W-7ukLm+g@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="00000000000019e456056c965633"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/Iof4pEyFr2jXw2MIo_n2i7pB8n0>
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: Sat, 19 May 2018 22:10:38 -0000

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.



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?


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



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.

To “guess” a query ID and client port would require a rapid burst of trial
and error packets which would be rendered harmless by the recommended use
of rate limiting.


It doesn't render it harmless, it just reduces the chance of success.



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

-Ekr

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



>