Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Joe Touch <[e-mail]>]

On 11/1/2012 4:55 AM, Lorenzo Colitti wrote:
> On Thu, Nov 1, 2012 at 8:16 PM, Ole Trøan <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     I don't see how we can build protocols to accommodate middle boxes,
>     and we have already done RFC3514.
>
>
> I'm sorry, but there are real operational needs here.
>
> Here's an example: suppose I am under attack by a TCP SYN flood and want
> to rate-limit it or filter it out so I can process legitimate traffic.
 >
> It would be reasonable for me to want to do this on a peering router,
> because it's as close as possible to the source, and it's a
> high-capacity, scalable box that needs to process each packet anyway.
 >
> I don't want to carry tens of gigabits of useless attack packets all the
> way the way through the network to the end host, and overwhelm it, so I
> can drop them there. And I also don't want to put stateful firewalls at
> each peering connection, because the firewalls cost a lot of money, take
> up space in POPs and connecting them wastes expensive ports on peering
> routers.
>
> The right way to deal with this is to rate-limit or drop on the
> routers. You're saying the architecture doesn't allow this? Then I'm
> sorry, but we need a better architecture.

The "right way" is to drop them at the offending source, but I hope we 
all agree we cannot do that because there's no viable solution.

The architecture already allows the router to shed load by dropping 
packets either arbitrarily or per-destination. However, you want to 
preferentially drop these at your ingress router, but there's no viable 
solution there that doesn't require stateful firewalls.

So your conclusion is that the architecture is broken.

If you have a better architecture - one that also supports tunnels, 
which are ubiquitous now too - it might be useful to disclose it.

Otherwise, it might be time to admit that you can't always get what you 
want.

Joe