[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