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

["C. M. Heard" <[e-mail]>]

On Fri, 19 Oct 2012, Warren Kumari wrote:
> Ah, sorry, I guess I was unclear -- the connection from the data 
> plane to the control plane is much much smaller than the data 
> plane interfaces. This means that I need to protect the CP / CP 
> interface by classifying and filtering / policing / rate-limiting 
> traffic before it hits the CP interface. This means that I need to 
> be able to examine the traffic to classify it. If I get a 
> fragment, I have no way of knowing what it is for, and so have no 
> way of knowing which rate-limiter to apply. This means I can a: 
> just drop it, b: guess at a classification, c: have a classifier 
> for all fragments or d: just accept all frags.
> 
> This is part of a more general problem -- if I have a router with 
> a 10G interface facing "the Internet"[0] and e.g a webserver 
> connected behind it with a 1G interface I'd like to make sure that 
> only port 80/443 traffic is vying for the limited bandwidth. As I 
> cannot reassemble on the router, I cannot classify what 
> non-initial fragments are to know if they should be allowed. Yes, 
> an attacker can (obviously) still DoS me with >1Gbps of traffic on 
> port 80, but at least I can filter out the stupid attacks on other 
> ports (which works surprisingly well :-P)

Circling back to my original comments about this draft, this is 
precisely the sort of information that needs to be added to Section 
2.1 to justify the assertion that "some cases will remain where 
legitimate fragments are discarded for legitimate reasons."

(FWIW, I am not sure that I agree that the reasons for discarding 
legitimate fragments are actually legitimate, but Warren Kumari's 
analysis does explain why some people do it.  It may or may not be 
in scope for the draft to suggest less destructive ways for 
operators to solve this class of problems.)

//cmh