[c-nsp] ip virtual-reassembly drop-fragments

[Juergen Marenda]

Reassembling ipv4 pakets inside the router is only needed for fragmented
packets with the router as destination; in the ipv4 world, the target host
is responsible for reassembling the fragmented pakets,
even when this happens on a router between an not on the source host.

(for example, if an ipsec encapsulated packet got too big with the
additional infos, the destination router which will de-ipsec it must first
reassemble it. (global settable ipsec behavior)
On GRE-Tunnels, the ip fragments will be delivered to the destination host,
which must reassemble it.

To help with fragment-ddos, configuring a mechanism not involed will not
help;
so you may want to use ACLs or the IOS firewall. See for example 

http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-g
re/8014-acl-wp.html

(not special for GRE even when the name suggests it)

Juergen.

-----Ursprüngliche Nachricht-----
Von: Satish Patel [mailto:satish.txt at gmail.com] 
Gesendet: Freitag, 3. Juni 2016 03:01
An: cnsp at marenda.net
Cc: Nick Hilliard; Cisco Network Service Providers
Betreff: Re: AW: [c-nsp] ip virtual-reassembly drop-fragments

Sorry typo it was "Internet"

We are getting many IP fragment DDoS so I was planning to use on outside
interface to drop all IP fragmented packet. 

--
Sent from my iPhone

> On Jun 2, 2016, at 10:44 AM, Juergen Marenda <cnsp at marenda.net> wrote:
> 
> 
> Satish Patel wrote:
>> is it safe to put on internap facing interface?
>> 
>> ip virtual-reassembly drop-fragments
> 
> what's an "internap"?
> 
> s/ap/et/
> 
> Yes it is safe, but
> 
> "no ip virtual-reassembly"
> is the best thing you can do, on every interface, and look form time 
> to time and after reloads weather it reappears.
> 
> "virtual-reassembly" should "reassembly" fragments (in a special, 
> memory conserving way) So dropping fragments in that context must be 
> an april's first joke.
> 
> Having too few resources,
> the theoretically good idea behind "virtual-reassembly" does not work 
> very well (in practice) esp. when it should be usefull.
> 
> Using the "no" form on every interface where it appears automagically 
> When you configure nat, crypto, ... did help us to solve many problems.
> 
> Juergen.
> 
>