Subject: Re: mboned: WGLC on draft-ietf-mboned-mroutesec-00.txt

From: Stig Venaas <[email-masked]>
Date: Mon, 3 May 2004 15:52:14 +0200

I have some comments.

I think a host can easily make PIM routers on the link stop forwarding
multicast by sending assert messages. You don't say anything about
assert.

3.1.1 says something about joining non-existent RPs. With the new
PIM spec ([1]) a (*,G) join will be ignored if the RP is not
correct, see section 4.5.2 in [1].

In 3.2.2 you say:

   With ASM this "source control" is distributed across all the PIM
   domains, which decreases its applicability.  Embedded-RP enables
   easier control because source discovery is done through single RP per
   group.

I think that even with multiple RPs and MSDP, each RP (MSDP peer) can
have restrictions on which sources it accepts.

In 5.3.4 you talk about unicast-decapsulation rate-limiter. It limits
the amount of new groups per second. However, you would need to
decapsulate the packet to know the group it is for, and the
decapsulation might be the hardest part. Isn't it better to have a
limit on the amount of register messages per second from a given source
(I'm talking about source of PIM register message, not data source).
Perhaps both are needed? I guess it depends on what resources you're
trying to protect.

BSR is intentionally left out, right? There are some issues, but I'm
not sure they belong here.

Stig
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Mon, 3 May 2004 07:47:19 -0700

Stig,

	Thanks for the comments.

>> multicast by sending assert messages. You don't say anything about

	True. We'll talk this one over and somehow address it.

>> correct, see section 4.5.2 in [1].

	Thanks.

>> have restrictions on which sources it accepts.

	It is however, still distributed. I'm not sure I
	understand your point. Can you try again?

>> Perhaps both are needed? I guess it depends on what resources you're

	Another good point. 

	Thanks,

	Dave

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 May 2004 11:27:21 +0300 (EEST)

Thanks for feedback -- some thoughts below...

> multicast by sending assert messages. You don't say anything about

Yes, because on-link threats (i.e., a misbehaving host on a stub link, 
causing problems for other hosts on the link) were considered out of 
scope, as noted in section 3.3:

   There are multiple threats relating to the use of host-to-router
   signalling protocols -- such as Internet Group Management Protocol
   (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside
   the scope of this memo.
                                                                                             
   PIM-SM can also be abused in the cases where RPF checks are not
   applicable, in particular, in the stub LAN networks -- as spoofing
   the on-link traffic is very simple.  For example, a host would get
   elected to become DR for the subnet, but not perform any of its
   functions.  These are described at some length in [1], but are also
   considered out of scope of this memo.

... maybe this should be stated in a more prominent place in the 
draft?

> correct, see section 4.5.2 in [1].

I don't see this anywhere in 3.1.1 -- could you clarify what you mean?

Do you refer to this:

   o  Embedded-RP: a (*,G) join is sent towards an inter/intra-domain RP
      embedded in the group G, causing state on that path. If the RP
      does not exist, the join goes to the closest router to the RP as
      possible. Similarly, an explicit (S,G) join goes to the DR, as
      with SSM above.

?

The problem is that the RP is _topology-wise_ correct, so every router 
on the path (up to a point) thinks the join is correct, but at some 
point, there is no route to the RP, or the RP is not serving.

(For example, if you advertise 2001:700::/32 route, and I'd send an 
embedded-RP join which would use 2001:700::e as the RP, but you would 
not even have that address assigned on any of your routers..)

This is pretty analogous to right now issuing an (S,G) join to some
bogus source which does not exist, but something that a
multicast-enabled ISP advertises an aggregate for.  The routers on the
path think it's valid..
 
> have restrictions on which sources it accepts.

Yes, but that is "distributed".  Let's take an example: if we use 
embedded-RP group A with sources 1, 2, and 3 in different 
administrative domains; with MSDP if you want to protect from bogus 
sources you have to:

1) filter at administrative domains of 1, 2, and 3 would have to 
perform precise (to prevent outsiders from sending to the group), 
and/or

2) filter at _every_ domain in the internet, to prevent illegitimate 
sources from sending to a group (obviously impossible).

With embedded-RP, you only one RP has to do this filtering, so the 
source-based control is much easier.

Maybe this should be reworded to be clearer.  Suggestions?
 
> Perhaps both are needed? I guess it depends on what resources you're

These are difficult tradeoffs.  Limiting the number of new groups per
second protects against things such as this Sasser worm, where the
transmissions come from multiple sources (and then source-specific
rate-limiters may only help to an extent).  Further, the source
address of register messages can be spoofed, so using the source may 
not be the best idea.

However, I agree that something else might be better.

The alternative I see is a simple decapsulation rate-limiter, limiting
to X pps, disregarding the source of the registers.  This limit should
have to be quite high, and would hamper the existing legimate sessions
as well.  Of course, this could also be an additional check to be used
before decapsulation and checking the group (as currently specified),
to throttle the worst of the decapsulation CPU consumption (if CPU is
used, that is).

> not sure they belong here.

Yes, though we could state explicitly that it's out of scope and may 
have problems of its own.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stig Venaas <[email-masked]>
Date: Tue, 4 May 2004 12:49:05 +0200

> scope, as noted in section 3.3:

Yes, but you do note that a host could become DR and not perform its
functions. I would suggest at least a line in there on assert. Well,
I wanted to bring it to your attention in case you missed it, leave
it out if you prefer.

> ... maybe this should be stated in a more prominent place in the 

Yes. Even if you don't discuss the threats in detail, I think it's
worth making the reader aware of them. Perhaps also suggest that
some authentication of Hello messages (e.g. IPsec AH) could help.
There is overlap with [1] though.

>       possible. Similarly, an explicit (S,G) join goes to the DR, as

I was refering to

   If the source or RP does not exist, the multicast routing protocol
   does not have any means to remove the distribution tree if the
   joining host remains active. Worst case attack could be a host
   remaining active to many different groups (containing either
   imaginary source or RP).

Imaginary RP would not be a problem (if RP not configured and not
embedded RP)

> not even have that address assigned on any of your routers..)

OK, For embedded RP this is a problem. You would have state all the
way to the place where the RP router would have been (or as far as
you have a route).

> multicast-enabled ISP advertises an aggregate for.  The routers on the

Yes, for Embedded RP it is, but not for other ASM use. When a router
receives (*,G)-join, it will check that the RP address is the same RP
that itself would use for G. In older specs this is not the case, but
you still have some protection. To specify an imaginary RP a host would
have to act as a router (unless using embedded RP).

So, I think you should make it clear that imaginary RP is only an
embedded-RP problem.

> Maybe this should be reworded to be clearer.  Suggestions?

Actually, I've read it a couple of times and thought a bit more about
it, and I think it's ok as it is. You're saying "decreases its 
applicability" which actually is right on. It's still possible to do
it, but it's hard to do it properly/effectively.

> to throttle the worst of the decapsulation CPU consumption (if CPU is

OK, disregarding the unicast source might be good. So, I think there are
two useful rate-limiters, depending on which resource to protect.

1. Decapsulation rate-limiter

   This would protect e.g. CPU usage in the router. Whether it's needed
   and what the limit should be, depends on the router architecture.

2. Rate-limit on number of G 

   A rate-limit on number of new G as you suggest in 5.3.4. This
   protects memory utilization in this and other routers.

> have problems of its own.

Yes, I think it's good to point out. Else people might get the
impression that BSR has no security problems (: You might perhaps
say that "RP discovery mechanisms like BSR and Auto-RP are out of
scope".

Stig

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 May 2004 15:42:43 +0300 (EEST)

I think we have understanding how to modify the document based on your 
feedback now -- thanks.

> I wanted to bring it to your attention in case you missed it, leave

Well, I guess mentioning Assert would be OK.

> There is overlap with [1] though.

In some other documents, there has been pushback from the IESG on 
vague statements -- better just to refer to some other documents 
which have the responsibility of addressing the problem :)
 
> > > correct, see section 4.5.2 in [1].
[...]
> Imaginary RP would not be a problem (if RP not configured and not

True, for RP, the problem is limited to embedded-RP; but for source, 
it's applicable to all three, so I think the above wording is correct 
but might use a bit of rewording.
 
> way to the place where the RP router would have been (or as far as

Yep.

> have to act as a router (unless using embedded RP).

Yes.
 
> So, I think you should make it clear that imaginary RP is only an

But the imaginary source is applicable to all, which makes the total
threat rather equivalent.

It's probably worth splitting the "imaginary source" and "imaginary 
RP" problems apart to separate paragraphs and explaining their 
applicability to make this clearer.

[...]
> it, but it's hard to do it properly/effectively.

Yep.  Now that I think about it, it should probably be 
"significicantly decreates its applicability"  or something similar 
:-)
 
>    and what the limit should be, depends on the router architecture.

Right.
 
>    protects memory utilization in this and other routers.

Good.  (We probably need to add some more justification which problems 
are fixed by which if these are done in series or independently.)
 
> say that "RP discovery mechanisms like BSR and Auto-RP are out of

Good -- thanks.