|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Source address validation
[two responses here] -------- 1 of 2 [email protected] (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 [email protected] (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
|