> Could anyone please explain me why Livingston is smart enough
> to announce (over OSPF) a summary route for assigned block,
> but is really stupid in not installing a reject (blackhole)
> route for this block internally apparently causing a potential
> routing loop?
Yep, I agree. The fancy summarizing of assigned addresses is nice, but
I would trade it for a null device in a second: set up routes to the null
device, then export via OSPF.
> This is a serious bug and it can be easiely used to mount a DoS
> attack. If one pings an address in the assigned block which
> happens not to be active at this moment the ping results in
> 30 duplicated packets between the portmaster and the next-hop router.
> With 2ms average rtt over Ethernet you get 1500*8*1000/2=6Mbs with
> 1500 byte packets; and an attacker only needs to have only
> 1500*8*1000/30=400Kbs. Apply this 15x factor to your remote T1
> POP (the rtt will be different but the 15 ratio will remain) -
> 4 incoming 1500 packets per second will saturate your T1.
>
> I recall there had been some discussion of this matter on the list
> but apparently nothing came out - in 3.7 there's still a routing loop.
>
> Interesting thing is that if you add a static route for the assigned block
> yourself (and point it to the pormaster's ethernet interface address)
> the portmaster treats the route as a blackhole - no packets looping,
> they just die there at portmaster.
Or you can add a manual route to a non-existant address for the blocks.
> One can also install blackhole summary route on a (smart) adjancent
> router and run RIP, not OSPF (the portmaster will announce individual
> routes in case of RIP).
>
> But these are ugly workarounds of the very clear problem in ComOS.
Yep, and Livingston said it would be in the next release.
> --
> Igor V. Semenyuk Internet: iga@sovam.com
> SOVAM Teleport Phone: +7 095 258 4170
> Moscow, Russia Fax: +7 095 258 4133
>
>
Tom