Re: Source address validation

[Paul Vixie <vixie () vix com>]

[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