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

From: Ronald Bonica <[email-masked]>
Date: Mon, 19 Mar 2012 18:02:16 -0400

Tissa,

Currently, any station sourcing traffic to a multicast group can send an ICMP Echo message to that group. The ICMP Echo message elicits a response from each receiver subscribed to the group. This may not be desirable because the number of receivers, and therefore, the number of responses, may be very large.

draft-tissa-pim-mcastoam draft attempts to remedy that problem by appending an RFC 4884 extension to the ICMP Echo. The extension specifies which stations should respond and which should not.

This raises the following questions:

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.

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

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. 

4) ICMP Syntax -  The ICMP Echo / Response messages are not extensible. See RFC 4884, Section 4 for details.

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

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 19 Mar 2012 20:22:33 -0700

Hi Ron

Thanks for the email and comments. Please see specific comments in-line.
Also I would like to highlight the motivation of this proposal, to help
appreciate the background and the need.

Please consider a scenario like below. Where network X is run by
provider. He offers Hosting services. Assume for now there is a
multicast problem. As the operator of the network he/she does not have
access to the hosting machines. What is very helpful here would be to
have standard set of tools that can be executed from R (routers) that
will allow to exercise the data plane. 

                             Network - X
                   +------------------------------+
 Hosting Apps      |                              |     Hosting App
  Customer Monitor |     Operated and Maintained  |    Customer Monitor
      H-------     R           by                 R ----------H
                   |       Provider               |
                   |                              |
                   +------------------------------+

See below more specific answers embedded.

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Monday, March 19, 2012 3:02 PM
To: [email-masked]; [email-masked]
Subject: Mail regarding draft-tissa-pim-mcastoam

Tissa,

Currently, any station sourcing traffic to a multicast group can send an
ICMP Echo message to that group. The ICMP Echo message elicits a
response from each receiver subscribed to the group. This may not be
desirable because the number of receivers, and therefore, the number of
responses, may be very large.

[Answer] Absolutely agree with the statement.

draft-tissa-pim-mcastoam draft attempts to remedy that problem by
appending an RFC 4884 extension to the ICMP Echo. The extension
specifies which stations should respond and which should not.

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.

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. 

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.

[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.

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

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 20 Mar 2012 10:50:33 -0400

Hi Tissa,

Comments inline.....

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

> router in the data plane to receive a copy of the discovery OAM

Please see RFC 6398 (BCP 168). Specifically, take a look at Section 4.

> group that has many, many receivers. The PING specifies a spoofed
> source address and is scoped to 0.0.0.0/0.
> 
> [Answer] Like you indicated you can do the same as of today, however,
> we strongly recommend platforms implementing this feature to rate limit

Rate limiting inbound ICMP on the host that generates the ping won't help. That host isn't the victim.

> draft-shen-traceroute-ping-ext-04, which allow to extend ICMP Echo

That much better!

               Ron

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 20 Mar 2012 19:50:16 -0700

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:[email-masked]] 
Sent: Tuesday, March 20, 2012 7:51 AM
To: Tissa Senevirathne (tsenevir);
[email-masked]; [email-masked]
Subject: RE: Mail regarding draft-tissa-pim-mcastoam

Hi Tissa,

Comments inline.....

> Linux open source both RFC4884 extensions and extensions proposed in 

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

> router should both process the PING message (as a receiver) and 
> forward it (as a router)?
> 
> 

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.

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

That much better!

               Ron

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Mar 2012 00:00:27 -0400

> From: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2012 10:50 PM
> To: Ronald Bonica; [email-masked];
> [email-masked]

I am not convinced of this at all. 

                           Ron

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Mar 2012 00:53:46 -0400

Tissa,

Having thought about your draft a while longer, I think that I can do a better job of articulating my objection. That is, that the tool described in 6450 is better suited to the problem at hand. 

Operators need a tool like this when a customer calls in wanting to know why he can't receive a multicast stream. In this case, it makes sense for the customer to initiate a test between himself and the server. It makes less sense for the server to blast something out to all of its clients hoping to elicit only a manageable number of responses.

One drawback of the solution described in RFC 6450 is that it requires clients and servers to be deployed on end systems. On the other hand, draft-tissa requires protocol changes on senders, receivers and intermediate routers. That seems to be a wash.

Furthermore, 6450 is fairly robust. Draft-tissa performance is subject to filters and rate limits that are imposed upon ICMP and optioned IP packets.

                                            Ron

BTW, In this email and in all previous messages on this thread, I am speaking as an individual contributor.

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 21 Mar 2012 09:00:37 -0700

Hi Ron

Rate limiting as proposed is only needed in the interim until
implementations include propose extensions. Secondly, these extensions
can be utilized to discover various roles performed by routers in
multicast forwarding, which RFC 6450 cannot do.

With RFC 6450 every end stations has to run the required servers and
need to have the clients. Routers would not be able to perform such a
thing and operators always have to log in to end devices, consider the
operational nightmare. Additionally, as pointed out earlier, sometimes
it is not even administratively possible. In short with RFC 6450, you
are leaving customers to troubleshoot their own problems.

Like I pointed out earlier, we needed to look forward, so some point to
the future we will have the required tools in place if we take right
steps today. If we do agree the problem space is important then we can
discuss during the WG what best approaches we can take.

Thanks
Tissa

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 9:54 PM
To: Tissa Senevirathne (tsenevir);

Tissa,

Having thought about your draft a while longer, I think that I can do a
better job of articulating my objection. That is, that the tool
described in 6450 is better suited to the problem at hand. 

Operators need a tool like this when a customer calls in wanting to know
why he can't receive a multicast stream. In this case, it makes sense
for the customer to initiate a test between himself and the server. It
makes less sense for the server to blast something out to all of its
clients hoping to elicit only a manageable number of responses.

One drawback of the solution described in RFC 6450 is that it requires
clients and servers to be deployed on end systems. On the other hand,
draft-tissa requires protocol changes on senders, receivers and
intermediate routers. That seems to be a wash.

Furthermore, 6450 is fairly robust. Draft-tissa performance is subject
to filters and rate limits that are imposed upon ICMP and optioned IP
packets.

                                            Ron

BTW, In this email and in all previous messages on this thread, I am
speaking as an individual contributor.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 21 Mar 2012 09:37:11 -0700

Hi

I see both benefits and some issues with your proposal. For
now I mainly want to make a few comments regarding RFC 6450,
but I have a question about your proposal too.

> need to have the clients. Routers would not be able to perform such a

One of the ideas with 6450 is that a server providing multicast content
can also run a 6450 server. Then hosts interested in receiving can check
their connectivity. Also an operator (some do) can place a few hosts at
various places in their network to check that they can receive. Of
course this does not show that the actual users can receive.

Some operators use 6450 to regularly monitor their network with various
servers and clients spread out in their network, and in some cases
getting customers to deploy clients or servers as needed.

There has been some interest in 6450 support in routers and possibly
combining it with mtrace. I can see both benefits and issues with that
as well.

> discuss during the WG what best approaches we can take.

 From an operator point of view, getting all user devices to respond in
such a way is certainly useful. My main question right now is about
security. There may be impacts related to both DoS and in identifying
end-points. Of course these are issues today with hosts responding to
regular multicast ICMP echo requests. I've often used that for
debugging, but there are some issues.

Stig

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