On Thu, 2 Sep 1999, Ryan Russell wrote:
> NICs have nothing to do with routing. The closest thing to the scenario you're
> talking about
> is reverse name lookups. I don't expect any difficulty there. ISPs are
> responsible for not leaking
> RFC1918 addresses into the Internet, and would be even if DNS didn't exist.
It shouldn't really matter if they do though. People should filter them
on their boarders, and only *destination* addresses affect routing, so
unless you're accepting them and processing them as legitimate, there
should be no issues.
> >and if that responsibility expands past these few entities (especially seeing
> as
> >how aquisitions are occurring right and left), there is obvious room for
> mistakes or confusion. We've all
> >seen what happens when upstream ISPs fudge the routing tables, but I wonder
> what the impact
> >would be if one of the newcomers decided to route 10.0.1.X at the same time
> another one did.
>
> If ISPs screw up and start sending RFC1918 addresses into the Internet (which
> happens often
> enough), it shouldn't really matter. If more than one does it, too bad for them,
> since they're not
> supposed to be there in the first place.
It's no different than any other address space that gets advertised by
multiple entities. Tier-1 providers should be filtering their ingress
routes anyway, not that it should matter unless you're the destination.
Sourced packets from any source address will reach you, the IANA reserved
blocks shouldn't mean anything different than any other spoofed packet to
a network.
> >I believe
> >it's possible that packets could end up on someone else's private net given the
> appropriate fudging
You shouldn't leak such packets to the world. If you do, you should deal
with the brokeness of your networks. That's true for any traffic that
isn't part of your legal address space. It'd be a better world if
everyone initiated oubound filtering on their border routers for packets
not legitimately sourced (not that I'm holding my breath.) Outbound
rules on a Cisco are still fast-switched (not sure if inbound packets are
still process switched, but outbound definitely is fast switched.)
> >scenario. So what I'm wondering is ... among the firewall list folks, has
> anyone seen any anomalies
> >of this nature, and if so, what are the responses that stateful inspection vs.
> packet filtering give on
> >unexpected WAN behavior?
If you're not filtering invalid sources at your border, then you're not
doing a very good job. If you're leaking packets from invalid addresses,
you're doing a worse job. Address blocks are just that- attempting to
assign some special value to a set of addresses leaked by you or someone
else to a subset of the address range doesn't address the full problem,
you shouldn't leak invalid packets, and you should be able to handle
obvious spoof attempts- incomplete as it may be - as well as real spoof
attempts on any exposed servers.
People have announced routes to the 1918 netblocks before. Broken load
balancing and NAT equipment has leaked before, it'll happen again, but it
shouldn't be a big deal on a well-run network. If you don't trust the
equipment, switch to proxy servers, you're not going to leak then.
> As a matter of course, firewall admins should implement anti-spoofing rules that
> block (source)
> addresses for their inside nets, any RFC1918 addresses, and anything above
> 223.255.255.255
> (minus anything they wish to explicitly allow for MBONE, routing protocols,
> etc..)
As well as 127.0.0.0/8 and 0.0.0.0/32. You'd be surprised the number of
networks that allow loopback, 0.0.0.0, 255.255.255.255 and
my.net.addr.broadcast packets in. Some of them even have UDP echo open
on multiple machines.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
