UDP packet spoofed LAN source address?

[Robert Bonomi]

> Date: Mon, 18 Oct 2010 13:02:53 +0200
> From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?  <freebsd-questions at pp.dyndns.biz>
> Subject: Re: UDP packet spoofed LAN source address?
>
> On 2010-10-17 19:36, Robert Bonomi wrote:
> >> From owner-freebsd-questions at freebsd.org  Sun Oct 17 09:04:59 2010
> >> Date: Sun, 17 Oct 2010 16:06:12 +0200
> >> From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?=
> >>  <freebsd-questions at pp.dyndns.biz>
> >> To: Nerius Landys <nlandys at gmail.com>
> >> Cc: FreeBSD Mailing List <freebsd-questions at freebsd.org>
> >> Subject: Re: UDP packet spoofed LAN source address?
> >>
> >> On 2010-10-17 06:56, Nerius Landys wrote:
> >>> This is really more of a networking question.
> >>> I'm wondering, in a typical scenario, for example my server is in a data
> >>> center with a typical colocation company.
> >>>
> >>> I am editing someone else's code, and this code handles incoming UDP
> >>> packets.  The code handles UDP packets that have a source address being from
> >>> the LAN differently.  It gives those packets special treatment.  To check
> >>> whether a source address is a LAN address, it does the typical checks for
> >>> 10.0.0.0, 172.16.0.0, 192.168.0.0, 127.0.0.0, and it also checks every
> >>> assinged IP address with netmask to see if the source address on the UDP
> >>> packet came from that network.
> >>>
> >>> My question is - how possible (in these typical environments) is it to send
> >>> a UDP packet from far away that claims to have a source address being a LAN
> >>> address?  Will such a packet typically make it to my server, or will a
> >>> router along the way stop it from arriving?
> >>>
> >>> Maybe, is there a simple 10 line C program that I can run and compile to
> >>> check if this scenario is possible on _my_ server?
> >>>
> >>> - Nerius
> >>
> >> Section 3 of RFC1918 (http://www.ietf.org/rfc/rfc1918.txt) states the
> >> following, and I quote:
> >>
> >> "Routers in networks not using private address space, especially those
> >> of Internet service providers, are expected to be configured to reject
> >> (filter out) routing information about private networks."
> >>
> >> This makes it _highly_ unlikely that your server will be hit by spoofed
> >> packets with a source address belonging to any of those private IP
> >> ranges. 
> > 
> > 
> > Wrong _WRONG_, *W*R*O*N*G*!!!!
> > 
> > THAT STATEMENT IS ABSOLUTELY INCORRECT.  
> > 
> > "routing information" works on _destination_ addresses *ONLY*.  The RFC
> > languate means that you cannot -reach- an RFC-1918 *destination* address
> > over the public internet. because no routing for those DESTINATION addrsses
> > ic carried in the routing tables.
> > 
> > The rest of your analysis is similarly similarly flawed.
> > 
> > As a matter of 'reality' *NOBODY* providing 'transit' services filters on
> > source addresses.
> > 
> > 'Leaf' networks -- those with 'upstream' connectivity, but no 'downstream'
> > clients -- are well advised to -themseleves- implement ingress/egress 
> > filtering at their border to block packets with 'inappropriate' _source_ 
> > addresses. 
> > 
> > This blocking has to be done with considerable care, however.  There are
> > some types of packets with 'un-routable' source addresses that *are*
> > absolutely legitimate, and tht you -have- to let through, or you will have
> > _major_ usability problems.
> > 
> > It is also a GOOD IDEA to filter traffic, in _and_ out, to certain ports 
> > that are 'meaningful' *only* in a LAN environment.
> > 
>
> Robert, I have 3 comments:
>
> 1) RFC1918 does _not_ explicitly define routing information as only
> destination address.

Of course not.  "routing information' is *not* contained in the packet 
being routed, _at_all_.  There is a source and a destination.  nothing
more.

"Routing information" is the information either hard-coded into a routing
table, or distributed by a routing protocol -- such as RIP,BGP, IGP,EGP, IS-
IS, etc. -- that let a router determine where the 'next hop' is that the
packet should be sent to, to get it closer to it's destination.

When you look at *other*than* the destination addrsess as part of the 
decision-making process for selecting a route, this is what is called
"policy-based" routing.  A "policy" used for this purpose is -not- 
'routing information' in the usual meaning of that term.  "Routing 
information" is information that allows a router to select the 'best/
shortest/cheapest' path to a destination, among multiple alternatives.
"Policy" is an explicit over-riding of the normal 'routing' decision,
forcing the packet to take  a 'non-optimum' route for an arbitrary
reason. 

> 2) Cisco recommend themselves to filter out RFC1918 based on _source_
> address as described here:
> http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml#ex
> If you're unfamiliar with Cisco's standard ACL syntax you can find it
> described here:
> http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml#standacl
> I don't claim that every router out there is configured this way (I have
> no way to verify that) but if you were employed by me and didn't follow
> basic Cisco recommendations, you would have to look for a new employer.

Obviously you're -not- in a hire-and-fire- position for the industry.   <grin>
if you were, a good 80% of the indutry would be out of a job.

This is one of those situations where 'theory' and 'practice' ARE wildly
divergent, at least in regard to customer gateways.

> 3) Shouting does _not_ make a false statement correct, even if I'm fully
> aware that there are people that believe so.

Shouting _does_ serve to alert the rest of the world to an _egregiously_ 
false statement made by someone lacking in real-world experience on the 
matter on which they have pontificated.


>                                              Also, if you chose to argue
> in demeaning wordings like "your analysis is flawed", on a public
> mailing list, please atleast try to explain why the analysis is flawed.

I did.

The analysis is flawed _because_ it is wildly divergent from actual behavior
in the real world.  I cited the -actual- behavior: "NOBODY filters on 
source addreses"

> It's generally a very good idea to always provide references to what you
> claim if you want to be taken seriously. 

the 'references' in this case consist of what I, a router jockey (among
other things with over 25 years of experience 'on the net') have seen 
first-hand on the _inbound_ gateway router for a number of leaf networks,
analysing the traffic coming _from_ the network connectivity provider.  
_anybody_ who has done this kind of work professionally for any period
of time, and has experience with multiple providers can confirm.

I have also had "network operations" staff at several _major_ (so-called
'tier 1') providers tell me that they filter RFC-1918 source addrsses --
"incoming _only_" -- at their gateways to other 'networks', but *NOT* in 
_either_ direction at the gateway to their _customer_ networks.  
Quote: If the customer wants that traffic filtered, they need to do it 
on _their_ equipment.  Unquote.

I can climb on a gateway router at any of half a dozen 'leaf network' 
clients, with that many different major upstream providers, and see a 
minimum of 10k packets a day inbound on the external interface with 
RFC 1918 addresses.  Typically around 3% of those packets are clearly 
identifiable as 'legitimate', and need to be let through.  There are also 
the occasional RFC 1918-sourced packets that 'may' be letigimate, but 
for which there is no way to tell conclusuively whether they are or are 
not legit. 

I can also sample data from a couple of multi-homed clients with PI 
address-space and their own AS, who -rarely- see any inbound traffic 
with RFC 1918 addresses.  But even _they_ see the occasional 'burst'
(hours to days) of such traffic -- somebody fat-fingers something
somewhere and the traffic does 'leak'.  

I can't speak authoritatiely as to what the cable TV companies do in this 
regard, or the radio-based services; my experience is with 'hard-wired' 
(fractional T to FastEthernet, and the occasional DSL) connections.


'Good neighbor' (as in _being_ one) calls for egress filtering on source
addresses that should not escape your network ('most' RFC 1918, 'net zero',
the auto-config network, along with a few other specifica _and_ anything that
is 'not yours').  Basic defensive filtering calls for ingress filtering on 
source addresss that should not enter your network  (RFC 1918, 'net zero', 
auto-config, etc. _and- anything that *is* used internally).

Note: the -only- reason 'ingress' filtering is needed is that "not everybody'
(by a *LARGE* margin) does 'egress' filtering.  I'm sure there's got to be
at least one provider 'somewhere' that does 'good neighbor' egress filtering,
but _I_ don't know of any.  The receiving side has to filter 'anyway', so
"why bother" applies.  Plus, the 'cost' of egress filtering is one that
is 'avoidable', by pushing it off onto the receiving site, so why not 
'avoid' it?

UNFORTUNATLEY, many providers are -not- willing to bear the cost of doing
those things on _all_ the interfaces that connect to 'somebody elses'
equipment.  Very specifically, with regard to single-homed customers with
PA address-space from that provider -- Most providers regard that PA
sub-delegation as "internal' to their network, and, as such, it is 'ok'
to let RFC 1918 traffic flow to/from -that- address block.  This means 
that -every- other customer of your provider _can_ hit you with RFC 1918
sourced packets.