Subject: Re: [MBONED] additional thoughts on mtrace2

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 6 Jun 2016 14:19:16 +0900

Hi,

We've submitted the revised mtrace2 draft today.

I'm very sorry for our late response, but we believe the revised draft addresses the comment from John Kristoff regarding amplification of bogus responses (see below):

> There is only a brief mention of the potential for amplification of
> responses and no detailed analysis to the extent, including no mention
> of the susceptibility to it from spoofed requests.  An IPv4-based query
> will result in almost a 3:1 amplification for a single response
> minimally, more for each router or RP in the path that may respond.
> 
> In this day and age with spoofed amplification and reflection DDoS
> attacks so widespread, this mechanism may need a bit more work before
> any operator is going to be convinced to enable it.
> 
>> We described an ADMIN_PROHIB code that enables to restrict mtrace2
>> query (in section 4.2.2, 9.2 and 9.3) and the rate limit function (in
>> 9.4 and 9.5). And also as in section 4.1.1, while mtrace2 supports
>> non-local client, it is up to the implementation to filter out such
>> queries.
> 
> I think this is probably insufficient if mtrace were to become widely
> deployed.  Maybe if by default mtrace capability were to be disabled by
> default, but it would still be preferable to consider how to limit the
> amplification and reflection capability at the protocol design phase
> (sorry I realize I'm coming very late to this party).
> 
>> But if we need more sentences to protect the infrastructure from DDoS
>> attacks or consider additional situations, or if you have more
>> advanced idea, could you inform me, how can I express them in it? I
>> would very much appreciate your cooperation.
> 
> Perhaps it would be sufficient if the LHR had to ensure a client
> issuing an Mtrace2 Query can receive a response?

Section 4.1.1 (Query Packet Verification) are modified and section 9.2 (Filtering of Clients) are newly added in the document.

We’d appreciate reviewing the revised document.

Best,
--
Hitoshi Asaeda