Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Source address validation

  • From: Paul Vixie
  • Date: Sun Mar 07 16:26:29 2004

[two responses here]

-------- 1 of 2 (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 (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 >  15396 A? (36)
21:06:42.349184 >  6182 NS? . (17)
21:06:42.427980 >  53830 NS? . (17)
21:06:42.559860 >  8434 [1au] A? SPPOLCD01.POL. (42)
21:06:42.688972 >  14986 A? (34)
21:06:43.793914 >  28233 MX? (26) (DF)
21:06:44.048702 >  2051 A? (36)
21:06:44.123787 >  9741 PTR? (45)
21:06:44.394578 >  15001 A? (33)
21:06:44.578893 >  15002 MX? (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 to any in
00500    1710989    109992242 deny ip from to any in
00600    6144955    392168290 deny ip from 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

> 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 says.
Paul Vixie

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.