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

[Hitoshi Asaeda <[e-mail]>]

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)