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

Hitoshi Asaeda <> Mon, 09 July 2018 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE1DB130FDB for <>; Mon, 9 Jul 2018 06:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Eqy66G4q88_c for <>; Mon, 9 Jul 2018 06:51:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA6E2130FE4 for <>; Mon, 9 Jul 2018 06:51:15 -0700 (PDT)
Received: by with SMTP id e10-v6so13743029pfn.1 for <>; Mon, 09 Jul 2018 06:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xeMrI8q/zo1cXvm26itGmfTN3BBxqQM9LwFT+VTSLRo=; b=er/9yiYLjH3cF3oaLqdFkSyy8cJ6Eo3D1WIbIL7VgkqSb8ZlEgGELK+mm4UAYW4FR8 HJIVSYBe1HXOCGdpH7JdfIhqUWh8w8e/9edCWAZZlgIDrjoJrrWm1q+ckz/7mAWCYTOy ybYe3oTnxL7WWtSAQj9u+Y1tB9rZMXyF/kM00Uw8XCjxX/iK9Viw1RP8a2gljg5hKwyB 1teNgtddM37k+xN0dt+LU3aNSBcyEYDZWmunRqXIKaZXtt9xjOqil5VGkN6jvNAdPha4 YBboqSd/lzMf3JlUDCOPKhbH5Xfr2X6wWlbfdbyezwrZJAA7TdwO2nhbv1cWqKWzgUwi pf4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xeMrI8q/zo1cXvm26itGmfTN3BBxqQM9LwFT+VTSLRo=; b=TWE5cQVYkbSrjOD9PeQMaIpNQ1k8AJ0FRwIHSDzp1JMvKcYQMIZJuDovqMx6jFSlPf 0qUYRVSLkkNxQj1Wb21wky5df6neFAhdQa3FNKazs7cWlfu0LmgXo/Dx+2yfXFo5ZIGD aX2rLMAAmp4bYX+X9kGDo6v9nq42TC+Rr1jFhmsMBKdRECgwSnYfyiztZrookPiQhiaU lH8jGg4SmuEnufiUeodt6u1T4YVUAiK9r/Iua13s6DyHKAP/J6bzvRQtiSfNUG2ZsFt1 +DTa/hGitQCcChZkkTfZePOFsXxH+2M7+hD4SNii+E0xk5pYMePWW44B5djkUawM1Iil DbFg==
X-Gm-Message-State: APt69E3899X0jfrzpIW2HfMO9NNo/JS2SKIFya3ts6sdjOUuNyXKyQmH 98ViGlLq9Zrf5AuqVE9l5vntLg==
X-Google-Smtp-Source: AAOMgpfecGjclN4QTOE2EsJrg68OgRISj8O9udSpK63FCjvaedSrrMSqFOPiUSTWB9OEChEcYa/TrA==
X-Received: by 2002:a63:d704:: with SMTP id d4-v6mr5401936pgg.312.1531144275321; Mon, 09 Jul 2018 06:51:15 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o3-v6sm6404134pgv.53.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 06:51:14 -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 <>
In-Reply-To: <>
Date: Mon, 9 Jul 2018 22:51:10 +0900
Cc: Kerry Meyer <>,, The IESG <>, MBONED WG <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <>
Subject: Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Mail List for the Mboned Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Jul 2018 13:51:20 -0000


> >> 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., 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 
> But the difference between a request and a response is just some bits in the packet.

I cannot understand this comment.
It is very common to design protocol messages using the TLV format and differentiate the messages by the different type values. 

> And so what stops some other host on the LAN from sending something that claims to be a request.

We cannot stop someone from sending packets, but can ignore/drop/rate-limit the packets if something wrong.

> 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*.
> Yes, but that needs to be technically enforced, not just stated.

Right. That's why we propose a new type of ACLs as follows.

> 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?
> I think so, if you require its use.

Ok, fine. I'll explain this ACL extension in the upcoming meeting.

> 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.
> I don't follow this.

Is some point unclear for you?
Let's see PIM-SM (multicast routing protocol). PIM-SM has a way to verify/recognize a valid PIM neighbor. If you need such adjacent router verification, we can mention this routing protocol's verification mechanism. 

> > 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.
> I have to be at RTCWEB.

Hmm.. Then we won't be able to reach any consensus in the meeting... 

> But before the f2f discussions or the meeting, I need to understand and clarify problems you have been thinking.
> The point of the F2F discussion is to clarify the issue.

I'll then personally contact you to meet next week.



> -Ekr
> Regards,
> Hitoshi
> (snip a lot)