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

Hitoshi Asaeda <asaeda@ieee.org> Mon, 09 July 2018 07:51 UTC

Return-Path: <asaeda@ieee.org>
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 3A7AF130DDA for <mboned@ietfa.amsl.com>; Mon, 9 Jul 2018 00:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.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 fj_OQTgHynH2 for <mboned@ietfa.amsl.com>; Mon, 9 Jul 2018 00:51:25 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 E9CB01277CC for <mboned@ietf.org>; Mon, 9 Jul 2018 00:51:24 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id e10-v6so13085586pfn.1 for <mboned@ietf.org>; Mon, 09 Jul 2018 00:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kzKg7Q6rXJZ0+tbQJUXeI7Sx0Jfnwxz0DQbjW7UyTHI=; b=I6fZWw8m9dD/QzM7tWW88cagt5a6qqkbPGbmGFQC/CeqOLRwpbdRKR9FUkoAQe4ud1 3GcJiOm67z1S+FKafirolLhKYksqEtZu6WDH7pRrZl+Hc+7p8QdjhF4KEGeP67PNDk7k DiImv8WvXGbD/MGSi6Seq2thGbPP5tlZnRmYGazXWUg6EVirp/f7UOxTXIeqKxpIrRKJ dMPk75bOm1eieKBB6VVrol8YXQHYhH/JQ7VADQank0zdtjGrg1ko/wEltkp2OG78dDwc aiOlbc1/2WshGENPQBKt3ktg4ijxaCYHLEqHlC2DEWOe3JNgYf4nVq5ZaxUTxdEAYMny LclA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kzKg7Q6rXJZ0+tbQJUXeI7Sx0Jfnwxz0DQbjW7UyTHI=; b=UVoZ5LUbOv6Wsj+lVjNcziA+jUBP18NY9/YH20EJVWy+SSPMiofcYlYnNlWvnBHxFs ST5CrBPSjOeXjzIqk/y7RInvOTXBP19Juth3LVscJMy9w1QeZF167WbXHUwo4nel18d5 EDutqU0+0edNAiQ7N4a8PH0KyhvzFRio/2AbcfvTPSAkgZOpL6RmnYaQqPnZtI4Bcewl 6WUakga8Jb4IE/d21M4TthzaCc2ce83YXY48+WYX3Pk0qhYIG1iQum4NMn63SHOm3Uvh LW2YVH/tAGScP1d1X96zSMHc6UfripR3z6SVAtydCeNZ0E531YNaulPhYwXp0nKgJ3kA lW7g==
X-Gm-Message-State: APt69E3WCmT6bh6iGpYg+syi9pvNYKsS04F3HPg7LT1gvPJqdI4nIq2x PZjWQgrKdzMjA4yFDlL+N3dmYQ==
X-Google-Smtp-Source: AAOMgpfdz5lKxztZALJ6dy4vHZV02zyOTCxzoSLe4lXjeIwkKGqwL3piSPj2StLGvRE0az4MVmZjIA==
X-Received: by 2002:a63:6243:: with SMTP id w64-v6mr13300485pgb.179.1531122684494; Mon, 09 Jul 2018 00:51:24 -0700 (PDT)
Received: from ?IPv6:2001:200:e103:1000:19ba:96f3:ab4d:b91f? ([2001:200:e103:1000:19ba:96f3:ab4d:b91f]) by smtp.gmail.com with ESMTPSA id d23-v6sm35765574pfe.2.2018.07.09.00.51.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 00:51:23 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Hitoshi Asaeda <asaeda@ieee.org>
In-Reply-To: <CABcZeBPdrfLf8ORuMQsKQ2jg1U0CyZ1jZHHqry2HwMEOf5hFyg@mail.gmail.com>
Date: Mon, 9 Jul 2018 16:51:19 +0900
Cc: Kerry Meyer <kerry.meyer@me.com>, draft-ietf-mboned-mtrace-v2@ietf.org, The IESG <iesg@ietf.org>, MBONED WG <mboned@ietf.org>, mboned-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <780E7155-9BCB-4EB3-A777-896C57E1BA85@ieee.org>
References: <3779EE09-4481-43DB-A422-9A9FE1A4CEB4@me.com> <E54E31C9-FCD2-4D5D-9295-6BBBF15BD938@me.com> <CABcZeBPdrfLf8ORuMQsKQ2jg1U0CyZ1jZHHqry2HwMEOf5hFyg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/LguaIvlT8V_zdFAME85H9alaR8A>
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: Mon, 09 Jul 2018 07:51:29 -0000

Eric,

(snip)

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

Only an adjacent *multicast router* can send requests, because a request is transformed from a query initiated by a downstream node/device and forwarded toward the source/RP.

In your example, you are a valid *user (or device)* and send Request, and can attack someone. But in our definition, you cannot send any Requests because you are not a valid *multicast router*.
The problem you may think here is that the ACLs in general do not validate the Request is traversed from valid (or invalid) routers as the message types cannot be specified in ACLs, right?
If we define a *particular* ACL entry to specify accepted/non-accepted IP addresses (or ranges) or admin boundaries for each of three mtrace message types, Query/Request/Reply, will your concern be disappeared?

To protect against spoofing of Request packet, as Kerry said,
> > 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.

Also, router validation is in general defined in the routing protocol specifications and routers can run the authentication mechanisms. We do not provide an mtrace unique/specific authentication mechanism for routers in this document. But as the example, we can describe the PIM case to verify adjacent PIM neighbor routers, if it's helpful.

> Given that we're a week from Montreal, it might be easier to just try to meet there. What say you?

Although Kerry may not, I'll be there.
I asked a slot to report the current situation in the Mboned WG meeting. Please come to the meeting.
But before the f2f discussions or the meeting, I need to understand and clarify problems you have been thinking.

Regards,

Hitoshi

(snip a lot)