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

[Warren Kumari <[e-mail]>]

On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" <[e-mail]> wrote:

>> -----Original Message-----
>> From: Nick Hilliard [mailto:[e-mail]]
>> Sent: Tuesday, October 16, 2012 3:28 PM
>> To: Templin, Fred L
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
>> 
>>>>> Why not just let non-initial fragments through and then forward
>>>>> or don't forward the initial fragment depending on whether it
>>>>> contains enough information in tlv headers to permit a filtering
>>>>> decision?
>>>> 
>>>> i spot some DoSs there.
>>> 
>>> DoS'ing whom - the end systems? End systems know when to flush
>>> incomplete reassemblies.
>> 
>> The intermediate systems.  Well, maybe the end systems too, but that's a
>> different issue.
>> 
>> The problem with the intermediate systems is how you handle the packets.
>> Most fast/dumb boxes are able to process fixed-shape packets in hardware
>> because ASICs are pretty good at that sort of thing.  If you need to
>> process TLVs at line rate and make forwarding decisions on that basis,
>> then
>> you need much smarter hardware.  So the issue comes down to what happens
>> when you have a fast/dumb box forwarding ipv6 packets with interesting
>> headers, and the dumb box is expected to do some level of filtering.
> 
> Filtering near the edges is where we have stateful filters that
> are good at managing state. "Stateless" filtering near the middle
> has no choice but to pass the fragments always.
> 
>> For fragments, if your dedicated hardware doesn't handle them natively,
>> then you have a choice between:
>> 
>> - allowing them through always
>> - dropping them always
>> - dropping them after a certain rate limit
>> - punting them to a more intelligent part of the forwarding device
>> 
>> For punted packets, most vendors punt them to the management plane because
>> they don't have a dedicated path for handling packets which are difficult
>> to parse.  This creates a management plane DoS which can be mitigated by
>> rate limiting the punting process.  So you end up with either a management
>> plane DoS, or an initial fragment DoS, or both.
>> 
>> Now, you could argue that dumb fast boxes shouldn't attempt ipv6 acls in
>> the first place, but what do you do if you want to implement v6 iACLs to
>> protect your internal infrastructure from external attacks?  Do you allow
>> all fragments through and potentially compromise your network?  Or do you
>> drop all fragments because your routing iron only has the capability to
>> either accept all fragments or drop them all?
>> 
>>> For middleboxes that sit in front of
>>> "low-end" end systems, there is also still the option of
>>> Virtual Fragmentation Reassembly.
>> 
>> urgh, state.  As a general principal, the less state you have to deal with
>> in your intermediate systems, the better.
> 
> IPv6 nodes are required to reassemble at least 1500 bytes in
> any event. That is for packets explicitly addressed to the node,
> but also consider (temporary) fragment matching for packets
> passing through the node, e.g. as done by VRF. Plus, when the
> router gets a fragment, chances are very good that its brethren
> are hot on its heels and will arrive or not very quickly. So,
> its not a case of holding onto gobs of fragments indefinitely
> and can be managed by reasonably good hardware.
> At least, I
> have been informed by individuals working for major network
> equipment vendors that their implementations can handle router
> reassembly.

"can handle router reassembly" != "can handle router reassembly at line rate on multiple interfaces".

You really need this to be line rate on all interfaces, otherwise there is (obviously) a DoS vector here. Reassembly at 10G (or 100G) is distinctly non-trivial and requires A: large buffers, B: short timeouts, C: gets sad if not all bits go through the same device, D: state and E: hardware designed specifically for this. This is much more than packet comes in, packet goes out...

W
> 
>>> Plus, if we can't rely on ICMP PTB and we can't rely on IPv6
>>> fragmentation/reassembly, then all we are left with is 1280
>>> and IPv6 is the new ATM...
>> 
>> We had problems with this for years in the ipv4 world.  IPv6 has made it
>> much worse by implementing a difficult-to-parse IP Options style header
>> mechanism and expecting that this is an integral part of the protocol.  We
>> fixed it in IPv4 by universally dropping packets with options and by
>> creating an expectation that this was acceptable.
> 
> IPv6 fixes fragmentation and reassembly, whereas filtering routers
> dropping fragments breaks it. IPv6 fragmentation is a necessary
> part of the equation needed to support path MTU diversity. RFC4821
> is another part, but there is no way for the network to know when
> end systems are using it.  
> 
>> IOW, there are large parts of the internet for which there is no good
>> solution to this problem.  I.e. any part which doesn't forward packets
>> using a highly intelligent packet processing core.
> 
> Dropping fragments violates the end-to end principles, and negates
> path MTU diversity. 1280 is too small of a size for us to lock into
> "the matrix" once and for always.
> 
> Thanks - Fred
> [e-mail]
> 
>> Nick
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 

-- 
A. No
Q. Is it sensible to top-post?