Source address validation
Paul Vixie
vixie at vix.com
Sun Mar 7 21:22:17 UTC 2004
[two responses here]
-------- 1 of 2
fingers at 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 at 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
More information about the NANOG
mailing list