RE: Source address validation

["Lumenello, Jason" <jlumenello () xo com>]

I think the argument taken up for or against uRPF-loose deployment
depends largely on the ability of the provider to implement it without
1) performance impact or 2) network upgrades. Argument against it on the
grounds of "I can't accurately measure its value" is a smoke screen.

We have implemented SAV on our customer edge routers for some time, with
no ill effects, and have filtered rfc1918 on our core router interfaces
facing our peering routers since early last year. We are currently
discussing loose-mode application in the core as the suspenders to these
two techniques. It really comes down to performance capability on a
given platform, as implementation itself does not cost anything but
maybe a nights sleep in a maintenance window. Can you guess what routers
I have in my network? :)

I fail to see how people can spend all day discussing its measurable or
theoretical value, yet claim they are too busy or resource constrained
to actually deploy it. So what's my excuse for waiting until now for
uRPF-loose in my core? I have been happy (up until now) with just my
belt. I am now reaching for the suspenders to deal with those few pieces
of hardware in my network not up to the task of uRPF, and that minority
percentage of attack traffic that can slip under the radar. :)

Just my $.02. Back to our regularly scheduled program.

Jason Lumenello
IP Engineering
XO Communications 



> -----Original Message-----
> From: owner-nanog () merit edu [mailto:owner-nanog () merit edu] On Behalf
Of
> Paul Vixie
> Sent: Sunday, March 07, 2004 3:22 PM
> To: nanog () merit edu
> Subject: Re: Source address validation
>
>
> [two responses here]
>
> -------- 1 of 2
>
> fingers () fingers co za (fingers) writes:
>
> > why is DDoS the only issue mentioned wrt source address validation?
> >
> > i'm sure there's other reasons to make sure your customers can't
send
> > spoofed packets. ...
>
> yes.  for example, most forms of dns cache pollution rely on the
ability
> to forge a udp source address on a well-timed response.  several of
you
> have pointed out that as long as at least one edge network is free
from
> uPRF, then something like dnssec will still be vitally necessary --
and
> that's true.  but, if the places where forged-source were possible
could
> be enumerated, then the fact of the forgery would be useful to a
victim.
> right now those places are innumerable, and so, anonymity is complete.
>
> -------- 2 of 2
>
> hackerwacker () cybermesa com (James Edwards) writes:
>
> > uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking
private
> > address space via broken NAT. ...
>
> so what you're saying is, these packets (captured on one of the f-root
> servers just now) wasn't from your network?  THANKS!  (anybody else
here
> want to claim this slackage?)
>
> tcpdump: listening on fxp0
> 21:06:42.331994 192.168.15.3.1053 > 192.5.5.241.53:  15396 A?
> wustat.windows.com. (36)
> 21:06:42.349184 10.1.0.15.1025 > 192.5.5.241.53:  6182 NS? . (17)
> 21:06:42.427980 10.10.1.1.1041 > 192.5.5.241.53:  53830 NS? . (17)
> 21:06:42.559860 10.19.1.101.1032 > 192.5.5.241.53:  8434 [1au] A?
> SPPOLCD01.POL. (42)
> 21:06:42.688972 192.168.7.76.1036 > 192.5.5.241.53:  14986 A?
> rsthost2.ods.org. (34)
> 21:06:43.793914 192.168.160.252.1024 > 192.5.5.241.53:  28233 MX?
> jimaz.cz. (26) (DF)
> 21:06:44.048702 10.10.10.250.53 > 192.5.5.241.53:  2051 A?
> tock.usno.navy.mil. (36)
> 21:06:44.123787 10.101.58.16.1120 > 192.5.5.241.53:  9741 PTR?
> 169.16.187.208.in-addr.arpa. (45)
> 21:06:44.394578 10.8.0.22.1036 > 192.5.5.241.53:  15001 A?
> mail.inf101.net. (33)
> 21:06:44.578893 10.8.0.22.1036 > 192.5.5.241.53:  15002 MX? ezrs.com.
(26)
> 2027 packets received by filter
>
> note that this particular box has dropped a fair amount of this crud
since
> its last reboot:
>
> rule#    packets       octets ----------------rule-----------------
>
> 00400   27149821   1707500202 deny ip from 10.0.0.0/8 to any in
> 00500    1710989    109992242 deny ip from 172.16.0.0/12 to any in
> 00600    6144955    392168290 deny ip from 192.168.0.0/16 to any in
>
>  9:16PM  up 37 days, 15:55, 1 user, load averages: 0.04, 0.01, 0.00
>
> also note that it's only one of about fifty similar servers.  i don't
have
> an easy way to aggregate the slackage numbers yet, but i sure would
like
> them to be zero or at least lower.  (and, for my part in rfc 1918, i
now
> beg
> forgiveness.)
>
> > Based on my limited experience with all of this it seems the place
for
> > uRPF is not at the core (core in the context of the Internet
backbone)
> > but at the customer edge, where the problem starts.
>
> that's sort of what
http://www.icann.org/committees/security/sac004.txt
> says.
> --
> Paul Vixie