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

Dear IESG and WG,

I've submitted the revised Mtrace2 draft;

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MBONE Deployment WG of the IETF.

       Title           : Mtrace Version 2: Traceroute Facility for IP Multicast
       Authors         : Hitoshi Asaeda
                         Kerry Meyer
                         WeeSan Lee
	Filename        : draft-ietf-mboned-mtrace-v2-25.txt
	Pages           : 40
	Date            : 2018-07-26

Abstract:
  This document describes the IP multicast traceroute facility, named
  Mtrace version 2 (Mtrace2).  Unlike unicast traceroute, Mtrace2
  requires special implementations on the part of routers.  This
  specification describes the required functionality in multicast
  routers, as well as how an Mtrace2 client invokes a query and
  receives a reply.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mboned-mtrace-v2-25
https://datatracker.ietf.org/doc/html/draft-ietf-mboned-mtrace-v2-25

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-mtrace-v2-25


The authors believe this revision addresses all comments given during the IESG review process.

Thank you for your comments.

Regards,

Hitoshi


> On 2018/07/09, at 22:54, Eric Rescorla <[email protected]> wrote:
> 
> 
> 
> On Mon, Jul 9, 2018 at 6:51 AM, Hitoshi Asaeda <[email protected]> wrote:
> Eric,
> 
> > >> 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 
> > 
> > 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. 
> 
> Yes. That's why it's important to have the receiver check.
> 
> 
> 
> > 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.
> 
> Yes.
> 
> 
> > 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.
> 
> That's fine, but if you send me proposed new text beforehand, I can also review it. 
> 
> Regards,
> 
> Hitoshi
> 
> 
> 
> > -Ekr
> > 
> > 
> > Regards,
> > 
> > Hitoshi
> > 
> > (snip a lot)

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned