Subject: [MBONED] Call for MBONED Agenda items in Prague

From: Leonard Giuliano <[email-masked]>
Date: Wed, 17 Jun 2015 08:27:18 -0700

If you have something you'd like to present in Prague, please let us know 
the draft name and amount of time you'd like.  There are currently 
scheduling challenges (more WG requests than available slots), so if we do 
not have enough agenda items we are considering not having a meeting in 
Prague.  So please send your requests to the chairs by the end of the 
week.

Thanks,
Lenny and Greg

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 26 Jun 2015 11:33:32 +0900

Hi,

> If you have something you'd like to present in Prague, please let us know the draft name and amount of time you'd like.  There are currently scheduling challenges (more WG requests than available slots), so if we do not have enough agenda items we are considering not having a meeting in Prague.  So please send your requests to the chairs by the end of the week.

Sorry for late.

The mtrace2 draft was stacked on the table.

https://tools.ietf.org/html/draft-ietf-mboned-mtrace-v2-11

At this moment, I don’t plan to present this draft in Prague.
But we would like to ask WG to review the draft, and after the revision, we’ll ask the WGLC.

BTW, I think it is good to include AMT support in the revised draft as now AMT is standardized and necessary to support.
Anyone can kindly become a volunteer to specify the spec to support AMT in the revised mtrace2 draft?

Best regards,
--
Hitoshi Asaeda

> Thanks,
> Lenny and Greg
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: John Kristoff <[email-masked]>
Date: Thu, 25 Jun 2015 22:25:09 -0500

On Fri, 26 Jun 2015 11:33:32 +0900

> revision, we’ll ask the WGLC.

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.

John

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 26 Jun 2015 14:17:41 +0900

Hi John,

(I changed the subject.)

> any operator is going to be convinced to enable it.

Thank you for your comment.
I understand one of the most important discussions for multicast deployment itself and such measurement/operational tools is related to such security aspects and DDoS attacks.

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.

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.

Best regards,
--
Hitoshi Asaeda

---

From: John Kristoff <[email-masked]>
Date: Tue, 30 Jun 2015 14:56:14 -0500

On Fri, 26 Jun 2015 14:17:41 +0900
Hitoshi Asaeda <[email-masked]> wrote:

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

John