North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Who does source address validation? (was Re: what's that smell?)

  • From: Stephen J. Wilcox
  • Date: Tue Oct 08 17:31:48 2002 
On Tue, 8 Oct 2002, Sean Donelan wrote:

> 
> On Tue, 8 Oct 2002, Jared Mauch wrote:
> > 	install this on all your internal, upstream, downstream
> > interfaces (cisco router) [cef required]:
> >
> > "ip verify unicast source reachable-via any"
> >
> > 	This will drop all packets on the interface that do not
> > have a way to return them in your routing table.
> 
> Once again, which providers do this?
> 
> If c.root-servers.net provider did this, they wouldn't see any RFC1918
> traffic because it would be dropped at their provider's border routers.
> If c.root-servers.net provider's peer did this, again c.root-servers.net
> provider wouldn't see the rfc1918 packets.
> 
> So why doesn't c.root-servers.net provider or its peers implement this
> "simple" solution?  Its not a rhetorical question.  If it was so simple,
> I assume they would have done it already.  PSI wrote one of the original
> peering agreements that almost everyone else copied.  If it was a
> concern, I imagine PSI could have included the requirement,  most of
> their peers would have signed it 10 years ago.  But they didn't.

If you do it on ingress from customers then this is probably a good thing and
makes your network compliant to RfC1918.

But you need to accept the internet isnt RFC1918 compliant in the same way that
we implement hacks in all kinds of applications to enable compatibility with
other non-RFC compliant implementations. You try running an RFC822 compliant
mail server as an example and see how many microsoft users complain they cant
send email!

Not all IP packets require a return, indeed only TCP requires it. It is quite
possible to send data over the internet on UDP or ICMP with RFC1918 source
addresses and for their to be no issue. Examples of this might be icmp fragments
or UDP syslog which altho shouldnt according to RFC1918 be on these source
addresses might be and if you block these on major backbone routes you may break
something.

So I guess you may argue block RFC1918 tcp inbound but icmp and udp .. you start
to break things, perhaps that is why large providers dont do this on backbone
links.

Steve

> 
> Does AT&T? Yes
> Does UUNET? ?
> Does Cable & Wireless? ?
> Does Level 3? ?
> Does Qwest? ?
> Does Genuity? ?
> Does Sprint? ?
> 
> 
>