|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: aggregation & table entries
> > > i've never seen a dns attack that didn't have 50% or more packets coming > > from spoofed sources, though due to loose-mode uRPF, most spoofed sources > > in the last year or so have been from addresses for which a route exists. > > -- > > Paul Vixie > > reiterating a sometimes heretical idea... > > are you refering to things like 172.17.0.0/16 where > only a couple hundred of those numbers have real services, e.g. > all the services are in 172.17.22.0/24 and the spoofed addresses > are in 172.17.128.0/17 space? In that example, if the receiver uses loose-mode uRPF to filter ingress and carries within their AS only the minimal set of RFC1918 routes corresponding to their actual use of it, then spoofed-source packets "from" 172.17.22.0/24 would be allowed in by loose-mode uRPF because a route table entry exists. Packets "from" the rest of 172.17.0.0/16 would be filtered. Loose-mode uRPF does not protect you from spoofed-source packets where the source address falls within a prefix that you use internally, whether that space is RFC1918 space or not. Likewise, loose-mode uRPF does not (completely) protect you from spoofed-source packets where the source address falls within a prefix that is valid externally, not necessarily via the reverse path on which you're receiving the packet. The first can be addressed with additional filtering, as has been mentioned. The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. > or... why do people insist on injecting routes to non-existent > things? a route table entry is a route table entry, regardless > of the scope. Is this where you advocate that providers only announce the parts of their assigned blocks that are in use? Stephen
|