Tier 2 ingress filtering

Mon Apr 1 02:19:44 UTC 2013

Hi Alejandro,

Also inline.

On Sat, Mar 30, 2013 at 10:17 PM, Alejandro Acosta
<alejandroacostaalamo at gmail.com> wrote:
> Hi William,
>   Thanks for your response, my comments below:
>
> On 3/30/13, William Herrin <bill at herrin.us> wrote:
> > On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta
> > <alejandroacostaalamo at gmail.com> wrote:
> >> On 3/29/13, Patrick <nanog at haller.ws> wrote:
> >>> On 2013-03-29 14:49, William Herrin wrote:
> >>>> I've long thought router vendors should introduce a configuration
> >>>> option to specify the IP address from which ICMP errors are emitted
> >>>> rather than taking the interface address from which the packet causing
> >>>> the error was received.
> >>>
> >>> Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip
> >>> unnumbered loop0' everywhere. ;)
> >>
> >> Why do you think it will be better?, can you explain?
> >
> > Hi Alejandro,
> >
> > Consider the alternatives:
> >
> > 1. Provide a router configuration option (per router and/or per
> > interface) to emit ICMP error messages from a specified IP address
> > rather than the interface address.
>
> I imagine that and it sounds terrific. I guess at least this option
> should come disabled by default.
>
> > 2. At every border, kick packets without an Internet-legitimate source
> > address up to the slow path for network address translation to a
> > source address which is valid.
>
> IMHO this can be achieved with the current behaviour.

If you don't mind the router crashing. There's too much trash traffic
with bad source addresses, even when no one is under attack. You kick
it up to the main CPU, you overwhelm the router.

> > 3. Design your network so that any router with at least one network
> > interface whose IP address is not valid on the Internet has exactly
> > the same MTU on every interface, and at least an MTU of 1500 on all of
> > them, guaranteeing that the router will never emit a
> > fragmentation-needed message. And do this consistently. Every time.
>
> If you have pmtud enabled you won't need this every time

Clients effectively always enable path MTU discovery.  If the ICMP
error message your router generates when it discovers the MTU problem
comes from an IP address that can't leave your system without being
filtered then path MTU discovery fails absolutely. That path is a
black hole that mysteriously swallows TCP connections.

If you can't prevent mis-addressed ICMP error messages from leaving
your system then you must prevent the conditions under which path MTU
discovery would cause an ICMP error message to be generated.
Practically speaking, that means you guarantee an MTU of at least 1500
bytes on every link and no endpoint MTU over 1500 bytes.

> > 4. Redesign TCP so it doesn't rely on ICMP destination unreachable
> > messages to determine path MTU and get your new design deployed into
> > every piece of software on the Internet.
>
> You will have the same problem using only one output interface for
> ICMP error/messages. Of course based in your comments you mean you
> will need to troubleshoot this interface only once.

With #4, path mtu discovery no longer relies on ICMP error messages.
The endpoint client would have to reduce the MSS on retransmission and
use the pattern of lost packets to acknowledgements to find path MTU
on paths with an ICMP black hole.

For the sake of robustness, this is something we probably should think
seriously about adding to the TCP protocol. However, that's a long
plan, two decades at least. It isn't something that could deliver a
complete mitigation in the next release of the software, the way
option 1 does.

> > 5. Accept that TCP will break unexpectedly due to lost
> > fragmentation-needed messages, presenting as a particularly nasty and
> > intermittent failure that's hard to track and harder to fix.
>
> Same answer as in 3.

See me response to #3.

Regards,
Bill Herrin

--
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004