Re: [MBONED] Mail regarding draft-tissa-pim-mcastoam

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

Hi Ron

I presume you are agreeing with use case and need to have ability
perform proper multicast data-pane OAM without having to log in to or
running agents on End hosts. Which can be administratively prohibitive
in some deployments

Please see specific comments in-line

-----Original Message-----
From: Ronald Bonica [mailto:[e-mail]] 
Sent: Tuesday, March 20, 2012 7:51 AM
To: Tissa Senevirathne (tsenevir);
[e-mail]; [e-mail]
Subject: RE: Mail regarding draft-tissa-pim-mcastoam

Hi Tissa,

Comments inline.....

> 
> 1) Backwards compatibility - Hosts running legacy software will not 
> parse the new extension. They will respond to the ICMP Echo regardless

> of how it was scoped by the extension. So, the sender will not be 
> protected from a barrage of responses.
> 
> 
> [Answer] Agreed, however draft is provided as a forward looking 
> approach. Based on the progress of the draft and comments on the 
> usefulness of the mcast-oam tools we are planning to contribute to 
> Linux open source both RFC4884 extensions and extensions proposed in 
> this document.

Currently, we don't send ICMP echoes to multicast groups because we may
receive more responses than we can handle. 

[Answer] All OS and routers that I know allow to send ICMP echo requests
to multicast addresses, and happily respond to them when the multicast
group is registered.

Now assume that your draft becomes an RFC and you contribute the code to
LINUX. At some future date, multiple OS vendors will implement your
feature. At some date after that, the user community will upgrade their
systems and your feature will be widely deployed. At that time, it will
be safe to send an ICMP Echo to a multicast group.

But when will that be? The only way to be certain is to give it a try!
Since this is the case, you might want to add some text to your draft
concerning what the consequences might be if you try it too soon.

[Answer] Like you pointed out earlier this caveat is present as we type
and exchange these emails. We are not making any worst. We can make
better the situation by mandating implementations complying to this
standard to specifically implement ICMP rate limiting for both in-bound
request, and response. Most platforms today have protections against
Ping of Death attack. I honestly believe that is sufficient to protect
against.

> 
> 2) ICMP Behavior - In your draft, the ICMP Echo elicits a response 
> from all receivers and intermediate routers. Currently, routers do not

> respond unless they are also receivers. Are you recommending that the 
> router should both process the PING message (as a receiver) and 
> forward it (as a router)?
> 
> 
> [Answer] We are not expecting routers to respond to ping of receiver 
> detection. However, as indicated in section 3.3.1 of the draft, for 
> messages that need to discover routers performing different roles, we 
> generate the message with router alert bit set, hence letting each 
> router in the data plane to receive a copy of the discovery OAM 
> messages.

Please see RFC 6398 (BCP 168). Specifically, take a look at Section 4.
[Answer] RAO bit used for multicast roles discovery, this is normally
done from the devices within the trusted domain. As explained in RFC
6398 section 4.2.1 this falls in to the controlled enviorement.
Additionally Section 5 of RFC 6398 explains proposals on how to properly
utilize RAO, with dynamic rate limiting of packets with RAO set etc..
Thanks for pointing out, we can under security section mandate
implementations to comply with the requirements of Section 5.

> 
> 3) Security considerations - Could multicast PINGs be used as a DoS 
> vector? In particular, what happens if the multicast source pings a 
> group that has many, many receivers. The PING specifies a spoofed 
> source address and is scoped to 0.0.0.0/0.
> 
> In all fairness, this condition exists today.
> 
> [Answer] Like you indicated you can do the same as of today, however, 
> we strongly recommend platforms implementing this feature to rate 
> limit receipt of such multicast ICMP packet to the CPU or even in the 
> data plane itself.

Rate limiting inbound ICMP on the host that generates the ping won't
help. That host isn't the victim.
[Answer] Rate limiting can be done on both directions, in which we mean
that both at the request packets and response packets
> 
> 4) ICMP Syntax -  The ICMP Echo / Response messages are not
extensible.
> See RFC 4884, Section 4 for details.
> 
> [Answer] Yes as of RFC4884 it is not extensible, we are planning to 
> use draft-shen-traceroute-ping-ext-04, which allow to extend ICMP Echo

> request messages

That much better!

               Ron

> 
> 
> --------------------------
> Ron Bonica
> vcard:       www.bonica.org/ron/ronbonica.vcf
>