Subject: Re: mboned: address discovery and allocation

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Nov 2005 10:48:50 -0800

Well, ...

Priority check ?

-> Unless someone tells me how to operate ASM securely in a large
   scope  like the Internet (attack from unwanted sources), i think
   we should not try to solve any secondary issues like address
   allocation.

-> I think it would be beneficial to explicitly concentrate on
   address allocation only within a "well managed" scope, eg:
   one that can have a single administration. This would not
   only explicitly exclude the Internet scope, but it would also
   allow to build easier solutions scoped specifically to Enterprise
   level - remember, we already have a solution that could scope up
   to the Internet level, and it was too complex. And i don't think
   it was made to be too complex because of *uhmm* it's inventors
   preference for complexity ;-), but rather because trying to solve
   the address allocation up to and including the Internet scope
   is difficult.

Short term recommend: Let's work only on address allocation for 239/8 ;-))
(without making a statement about IPv6 ;-)

Cheers
	Toerless

On Fri, Nov 11, 2005 at 01:27:06PM -0500, Marshall Eubanks wrote:
> I agree with Hans, and told Beau so after the session.
> 
> Regards
> Marshall Eubanks
> 
> On Nov 11, 2005, at 12:00 PM, Hans Kuhn wrote:
> 
> >I was glad to see Beau present this draft for two reasons. First,  
> >MADP fills a real need for near-zero-conf address discovery. An  
> >assumption Beau made that was frequently overlooked during the  
> >floor discussion, is that you can't expect the presence of dhcp or  
> >dns in many cases.
> >
> >Second, although Beau's proposal didn't deal with it, mboned should  
> >take on the address allocation issue because there still isn't a  
> >good solution for this. Dave Meyer has talked about this problem  
> >many times, but the problem continues to worsen. Joel is right that  
> >we need to start addressing the problems we have, not the ones that  
> >we thought we might have 10 years ago.
> >
> >-- 
> >Hans Kuhn 	Academic User Services	     office +1 (541) 346-1714
> >PGP Key fingerprint =  8D66 51A8 E120 B781 C298  2C38 031A BFB5  
> >67FC ABE5
> >_______________________________________________________________
> >user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> >web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
> 
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

-- 
Thanks
   Toerless Eckert
   
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Nov 2005 13:59:15 -0500

Hello Toerless;

>    we should not try to solve any secondary issues like address

I think that the various filters and rate limits that people have  
applied have largely
removed this problem, and I feel much better about it than I did.

There do not seem to have been any packet storms in at least the last  
6 months.

BTW, Lenny put together a pretty good description of this, and I  
liked John Kristoff's presentation.

> Short term recommend: Let's work only on address allocation for  

I thought that was basically what Beau was recommending. Scoping is a  
lot more detailed for
IPv6, and I don't think that there is any problem getting as much  
local scope as you want.

> 	Toerless

Regards
Marshall

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 11 Nov 2005 11:00:16 -0800 (PST)

>   we should not try to solve any secondary issues like address

What's your point? ASM is never going to be secure.

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       [email-masked]
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: John Zwiebel <[email-masked]>
Date: Fri, 11 Nov 2005 11:24:32 -0800

> What's your point? ASM is never going to be secure.

Which makes one wonder why ASM is needed.

Its time to figure out how to move to just SSM and Bidir.
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: John Kristoff <[email-masked]>
Date: Fri, 11 Nov 2005 13:39:48 -0600

On Fri, 11 Nov 2005 10:48:50 -0800

>    we should not try to solve any secondary issues like address

Is that possible?  The only approximation of doing that I've seen
that can make that happen is to effectively turn ASM into an SSM-like
service, which supports only a select group of sources for content
you want receivers to get at.  That is, filter the sending of 224/4
using any IP protocol by anyone but those trusted sources, setup your
static joins for those groups on the interfaces where you want the
traffic to go and then use any layer 2 magic do the rest.  Of course,
that isn't ASM anymore, but I'm willing to bet ASM across the Internet
is about as widely deployed as it is going to get.

>    the address allocation up to and including the Internet scope

I would tend to agree with this, but I didn't catch Beau's presentation
so I'll withhold judgment for now.

John

---

From: John Kristoff <[email-masked]>
Date: Fri, 11 Nov 2005 14:05:04 -0600

On Fri, 11 Nov 2005 13:59:15 -0500

> There do not seem to have been any packet storms in at least the last 

I still find it difficult to implement some of those knobs though
and we have recently gotten bitten by a storm that we wouldn't have
gotten hit by if we didn't implement some hardening features.

Between bugs and the complex configuration required to get things
locked down pretty tight, it's not easy.  So if this list will allow,
let me share one very recent example that illustrates failure on
multiple fronts (I'm as much to blame here as anyone or any vendor
btw).

I have a version of code on an inter-AS MSDP speaking router that has
a number of "hardening" knobs applied.  The one knob I don't have applied
is the per-source MSDP SA limit.  Because of a bug in the running version
of code, I cannot turn this on otherwise valid SAs will be dropped.  I
do have a per peer limit though, but I obviously have to set this pretty
high and I really only have one peer where I get most of the SAs from
so I don't have any additional rate limiting granularity at the moment
and that really is needed, otherwise a single source can starve out others.

Some multicast routers behind this border are caching the SDPs sent to
224.2.127.254, which is probably not a good idea generally by the way.
I recommend you only enable this when you need it for troubleshooting.
In case any of you have seen me mention the 2500+ number elsewhere,
this was the group I'm talking about and it is a bit scary.

We have applied a number of control plane hardening features on internal
routers.  This works great, except when this is misconfigured.  On some
routers, things like OSPF messages between neighbor routers, PIM hellos
and other things were incorrectly put into a default rate class that is
in essence the "swamp", that can easily fill.

Along comes a host in .cz last week that is sending us 14K SAs or more,
not enough to hit the per-peer limit at the MSDP border.  Lots of internal
routers are joined to this group and begin processing these messages, but
these messages fall into that "swamp" class, which then starves out basic
network control protocols that weren't correctly put into their control
plane hardening class.  Can you say "routing flaps"?

So this was largely our own fault in configuration management.  However
I reckon that this sort of experience would seem familiar to anyone who
tends to enable all the hardening knobs.  It can be a challenge.  In
addition, there is very little in the way of even simple multicast
monitoring/management tools.  I created one very crude script to give
me mcast state summary across my routers, but it doesn't help me if that
isn't the problem.  :-/  ...and since this example did not look like a
multicast problem, it took that much longer to figure out.  If the per
source limiter was working, I wouldn't have had a problem, if I hadn't
deployed control plane policing on internal routers (or changed how I
did it I suppose) I wouldn't have had a problem, if my vendor could log
dropped packets at the control plane I might have seen this earlier,
and so on and so on.

This is how things work in the real world for those who try turning a
lot of this stuff on and I'm pretty sure we tend to turn on a lot more
of these things than almost everyone else based on feedback I've gotten
or not gotten from bother users and vendors.

John

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Nov 2005 12:33:32 -0800

> What's your point? ASM is never going to be secure.

exactly. Which means that we should only consider further work
into ASM for scopes where the security is not an issue or can
operationally be provided at the network level outside of the
application. Constraints the scope of applicability of whatever
address allocation mechanism we want to come up with.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Nov 2005 12:34:48 -0800

> There do not seem to have been any packet storms in at least the last  

COuld be argued as well as if Internet scope ASM is dying anyhow today,
but that could just be a current wave.j

> liked John Kristoff's presentation.

URL ?

Cheers
	TOerless

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Nov 2005 16:06:32 -0500

Of course, there is no real security on the Internet. Some protocols  
just approach it
closer than others :)

ASM is (largely) what is in use, and I would be really surprised if the
embedded application writers this is aimed at use anything else, and  
I bet the
same can be said about the mission critical
enterprise network applications  they collide with. This is no
reason not to do something to help resolve this problem.

Regards
Marshall

---

From: John Kristoff <[email-masked]>
Date: Fri, 11 Nov 2005 16:54:40 -0600

On Fri, 11 Nov 2005 12:34:48 -0800

> > liked John Kristoff's presentation.

I think Marshall is referring to these:

  <http://www.juniper.net/solutions/literature/app_note/350051.pdf>
  <http://www.nanog.org/mtg-0510/kristoff.html>

John

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sat, 12 Nov 2005 00:20:20 -0500

Yes, thanks, I was on the plane back.

Marshall

On Fri, 11 Nov 2005 16:54:40 -0600