nanog mailing list archives
Re: MTU path discovery and IPSec
From: Tony Rall <trall () almaden ibm com>
Date: Thu, 4 Dec 2003 13:24:01 -0800
On Wednesday, 2003-12-03 at 09:38 PST, David Sinn <dsinn () dsinn com> wrote:
Given the nastiness of ICMP DDoS attacks of late, it might be better to
hit
the server and client admin's with the clue bat about not using PMTU discovery (which also extends to the writers of the App's and OS's).
This idea that some protocol has been used for some form of attack means that we should for now and evermore block that protocol leads clearly to a network with all protocols blocked. No, I don't buy the argument that icmp (at least most forms of it) should be blocked.
Frag. is in the fast path of just about every current version of brand C code,
so
giving the tunneling folks the OK to frag the packet might be preferred
to
forcing them to mess about with alternate options.
Fragmentation should be an ok eventuality for some traffic, but there are a couple of points that make it more painful than it might seem: 1. Encapsulated traffic (such as most vpns - GRE, IPSEC, etc.) often results in packets that subsequently need to be fragmented. That typically yields lots of 1500 byte packets followed by 80 byte packets. 2. I really don't know how NAPT routers deal with fragments. These guys depend on the port information in a packet to reliably determine the target of inbound traffic. But there is no port information in anything other than fragment 1. When they receive a frag other than 1 they don't definitely know who to deliver it to. They have to either guess or drop the packet. Ugh, in both cases. (And note that frag 1 often is not the first fragment to arrive at downstream nodes. In my example in (1), frequently frag 2 will reach places before frag 1 does (if any router along the path reorders its transmit queue based on packet size).) Tony Rall
Current thread:
- Re: MTU path discovery and IPSec, (continued)
- Re: MTU path discovery and IPSec Owen DeLong (Dec 03)
- Re: MTU path discovery and IPSec Valdis . Kletnieks (Dec 03)
- Re: MTU path discovery and IPSec Owen DeLong (Dec 03)
- RE: MTU path discovery and IPSec cproctor (Dec 03)
- Re: MTU path discovery and IPSec David Sinn (Dec 03)
- Firewall stateful handling of ICMP packets Sean Donelan (Dec 03)
- Re: Firewall stateful handling of ICMP packets Owen DeLong (Dec 03)
- Re: Firewall stateful handling of ICMP packets Valdis . Kletnieks (Dec 03)
- Re: Firewall stateful handling of ICMP packets Owen DeLong (Dec 03)
- Re: MTU path discovery and IPSec David Sinn (Dec 03)
- Re: Firewall stateful handling of ICMP packets Henry Linneweh (Dec 03)
- Re: MTU path discovery and IPSec Tony Rall (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Valdis . Kletnieks (Dec 04)
- Re: MTU path discovery and IPSec Barney Wolff (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Valdis . Kletnieks (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Crist Clark (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Laurence F. Sheldon, Jr. (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)