Subject: Re: mboned: draft MBONED agenda for IETF 61

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Nov 2004 19:21:59 +0200 (EET)

Hi,

On Thu, 21 Oct 2004, David Meyer wrote:
> MBONE Deployment WG (mboned)
>
> MONDAY, November 8, 2004 (1530-1730)
> =====================================

Sorry for forgetting about this, but would it be possible, time 
permitting, to have 5-10 mins to discuss the next steps after 
draft-ietf-mboned-mroutesec-04.txt?

Someone, at some WG, (PIM, MAGMA, MBONED), should do a threat analysis 
and describe fixes for IGMP/MLD and PIM on-link messaging (e.g., hello 
spoofing, assert abuse, etc.).

There are a few drafts out already, but I'd like to poll the WG and 
discuss whether it makes sense to do it here, who would be interested, 
etc.

Title: On-link IGMP/MLD/PIM threats and problems

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Tue, 2 Nov 2004 09:26:10 -0800

>> Title: On-link IGMP/MLD/PIM threats and problems

	Sure. 

	Dave

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 04 Nov 2004 09:09:46 -0500

On Tue, 2 Nov 2004 19:21:59 +0200 (EET)
> draft-ietf-mboned-mroutesec-04.txt?

Dear Pekka;

I would be interested in this. One thing I have been thinking about is attacks using coordinated
sources and receivers. I have felt for a while that the bad guys have yet to think about the
intrinsic power of group communications for causing havoc.

Example - an SSM attack. Divide some SSM address space range into two
subsets.  Attacking worms are spread by some means such that each child knows its parent's IP
address, and the parents know either the child's IP address or address range. Each attacking worm
picks randomly one of the SSM address subsets and sends data packets to each channel  address on
that subset. The data packets it sends include both its IP address, and the IP address or address
range of  any other worms it knows about (this could be encrypted). It also sends SSM joins to
every channel address in the OTHER subset using the IP addresses (or ranges) of every worm it knows
about. It decodes any received data packets, extracts the addresses therein, and adds them to its
join (S,G) list and also to the list in the data packets it sends out. This could be a state attack,
a data rate attack, a virus communication channel, a virus discovery mechanism, or any combination,
depending on what the attackers are trying to do.

While on this subject, here are some thoughts and suggestions for 
draft-ietf-mboned-mroutesec-04.txt

Anycast RP is not considered. It is in many ways similar to inter-domain MSDP
in its threat sensitivity, but it is intra-domain.

Simple protocol and TTL sanity checks should be done - the Ramen worm sent multicast TCP traffic,
which should not cause state to be created.

The core of this discussion is rate limiting.

The biggest problem with rate limiting multicast control traffic is that the dynamic range is small.
As an example, there are typically about 3 to 6 thousand entries in the Global MSDP tables. The
Saphire worm caused these table to peak at 50,000 to 100,000 entries, which caused problems all over
the place. This is not a lot of dynamic range to distinguish between attacks and usage.

This says to me (at least) that rate limiting needs to be pushed to the edge. A core router might
legitimately have to deal with 20,000 groups, but I can see no reason why a source or receiver
should create so much state.

Therefore multicast joins as well as source creation should be rate limited by the DR. You go over
this adequately, 

One idea I have had is to rate limit based on the _age_ of the state.
Most of the attacks we have seen have had very quick onsets - thousands of _new_ groups are
generated. Why should the rate limiting reject control traffic from groups existing before the
attack starts ? This can be implemented very naturally in a token bucket type scenario as long as
tokens are not removed as long as the state has not expired, i.e., as long as the tokens refer to
state, not control packets.

This is not really a standard use of a token bucket, as we are not limiting packets,
but state. (By the way, which is intended is not really clear in section 5.3 - does X_DEPTH refer to
incoming messages, or the amount of state those messages generate, which are not at all the same ?)
It would limit the damage done by rate-limiting to new traffic during the attack, which is typically
not that much due to their short duration.

Nit-picking :

Introduction

These attacks that these security mechanisms protect against
   are not discussed further in this document.

->

The attacks that these security mechanisms protect against
   are not discussed further in this document.

Section 5.2

 Whether the host is willfully maliscious, uncontrolled (e.g.,
      virus/worm), or a regular user just doing something wrong.

->

Whether the host is willfully malicious, uncontrolled (e.g.,
      virus/worm), or a regular user just doing something wrong.

Is there a reference for a "token-bucket -based rate-limiter" ?
Here is one
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a00800ca59f.html
but an RFC would be better. Again, whether a state bucket or a packet bucket is meant should be made
clear.

Marshall

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Nov 2004 06:06:56 +0200 (EET)

Hi,

On Thu, 4 Nov 2004, Marshall Eubanks wrote:
> I would be interested in this. One thing I have been thinking about 
> is attacks using coordinated sources and receivers. I have felt for 
> a while that the bad guys have yet to think about the intrinsic 
> power of group communications for causing havoc.
[...]

Do you mean interested in draft-ietf-mboned-mroutesec-04.txt? 
Unfortunately, that document is already past IESG evaluation (twice), 
so it's basically done except for editorial corrections.

(I was asking here whether folks thought doing similar with the first 
hop issues would be interesting..)

In below..

> Anycast RP is not considered. It is in many ways similar to 
> inter-domain MSDP in its threat sensitivity, but it is intra-domain.

Too late to change this, but I'm not sure if this is a problem 
because:
  - intra-domain anycast-RP problem comes when MSDP is used, or
  - when pim-anycastrp is used instead of MSDP (e.g., with 
embedded-RP?), but only for internal state.  This should be reflected 
appropriately to the pim-anycastrp draft, if it already isn't (can you 
bring it up on pim WG?)

> Simple protocol and TTL sanity checks should be done - the Ramen 
> worm sent multicast TCP traffic, which should not cause state to be 
> created.

Can you clarify, protocol and TTL checks on _what_?

> The biggest problem with rate limiting multicast control traffic is 
> that the dynamic range is small. As an example, there are typically 
> about 3 to 6 thousand entries in the Global MSDP tables. The Saphire 
> worm caused these table to peak at 50,000 to 100,000 entries, which 
> caused problems all over the place. This is not a lot of dynamic 
> range to distinguish between attacks and usage.
>
> This says to me (at least) that rate limiting needs to be pushed to 
> the edge. A core router might legitimately have to deal with 20,000 
> groups, but I can see no reason why a source or receiver should 
> create so much state.
>
> Therefore multicast joins as well as source creation should be rate 
> limited by the DR. You go over this adequately,

Agreed, I think this is already reflected: the borders should have 
stricter limitrs, but because you can't count on the borders having 
the limits, the next components (DR -> RP -> MSDP sender -> MSDP 
receiver -> etc.) must also do something.

> One idea I have had is to rate limit based on the _age_ of the 
> state. Most of the attacks we have seen have had very quick onsets - 
> thousands of _new_ groups are generated. Why should the rate 
> limiting reject control traffic from groups existing before the 
> attack starts ? This can be implemented very naturally in a token 
> bucket type scenario as long as tokens are not removed as long as 
> the state has not expired, i.e., as long as the tokens refer to 

Section 5.3.6 actually proposes this for new MSDP state entries.

> This is not really a standard use of a token bucket, as we are not 
> limiting packets, but state. (By the way, which is intended is not 
> really clear in section 5.3 - does X_DEPTH refer to incoming 
> messages, or the amount of state those messages generate, which are 
> not at all the same ?) It would limit the damage done by 
> rate-limiting to new traffic during the attack, which is typically 

X_DEPTH is the length of burst allowed, while X_RATE is the average 
rate.  I'm not sure which subsection of 5.3 you're referring to, but 
if 5.3.6, I'd interpret as "state", not messages.

>      virus/worm), or a regular user just doing something wrong.

All of these noted, and to be fixed.

> Is there a reference for a "token-bucket -based rate-limiter" ? Here 
> is one 
> but an RFC would be better. Again, whether a state bucket or a 
> packet bucket is meant should be made clear.

RFCs have used token bucket based rate-limiters in the past (e.g., 
RFC2215), but apparently without references.  Token-bucket model is 
well known especially in QoS circles but arguably, it could be not so 
well known w/ multicast folks.  I'd rather not add this here.

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 08 Nov 2004 07:36:43 -0500

On Mon, 8 Nov 2004 06:06:56 +0200 (EET)

> so it's basically done except for editorial corrections.

No, I meant the next steps...

Marshall