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

["Templin, Fred L" <[e-mail]>]

> -----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.

> > 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