Who does source address validation? (was Re: what's that smell?)
Stephen Stuart
stuart at tech.org
Wed Oct 9 17:58:30 UTC 2002
> Loss of ICMP packets generated by links with endpoints numbered in RFC1918
> space. Holes in traceroutes, broken PMTU detection.
Sherman, set the Way-Back Machine for August:
To: David Schwartz <davids at webmaster.com>
Cc: nanog at merit.edu
Subject: Re: NSPs filter?
In-reply-to: Your message of "Thu, 08 Aug 2002 17:57:35 PDT."
<20020809005740.AAA18472 at shell.webmaster.com@whenever>
Date: Thu, 08 Aug 2002 18:45:17 -0700
From: Stephen Stuart <stuart at tech.org>
In August you said it this way:
> One thing that sometimes comes up is that people do number links using
> RFC1918 address space which occasionally results in an ICMP 'fragmentation
> needed but DF bit set' packet with an RFC1918 source address. Filtering out
> this packet could result in TCP breaking.
I still say this:
That can be accomodated; behold, all the joy of PMTUD, with none of
the other crap from designated special-use address space:
firewall {
family inet {
filter external-filter {
term allow-icmp-unreach {
from {
protocol icmp;
icmp-type unreachable;
icmp-code fragmentation-needed;
}
then {
count allow-icmp-need-frag;
accept;
}
}
term allow-icmp-timxceed {
from {
protocol icmp;
icmp-type time-exceeded;
icmp-code [ ttl-eq-zero-during-transit ttl-eq-zero-during-reassembly ];
}
then {
count allow-icmp-timxceed;
accept;
}
}
term deny-rfc1918 {
from {
source-address {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
}
}
then {
count deny-rfc1918;
discard;
}
}
term deny-test {
from {
source-address {
192.0.2.0/24;
}
}
then {
count deny-test-net;
discard;
}
}
term deny-autoconfig {
from {
source-address {
169.254.0.0/16;
}
}
then {
count deny-autoconfig;
discard;
}
}
term LAST {
then accept;
}
}
}
}
Application is left as an exercise to the reader.
Stephen
More information about the NANOG
mailing list