RE: Exodus / Clue problems
Why on earth would anyone let any of the following networks in to their network at the border? 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Hell, for that matter, I block anything claiming to be from our networks as well. There's no way they'll be originating from the outside unless it's spoofed. Nothing and I mean NOTHING claiming to be from any of them at your border is valid. At 09:36 PM 11/15/98 -0500, Adam Rothschild wrote:
On Sun, 15 Nov 1998, Dave Van Allen wrote:
Same here, dozens of times in a few seconds just now, to all listed nameservers... I can't imagine what "process" could do this unintentionally. Exodus??? You home?
Interesting you mention this. I've noticed the following on a FreeBSD 2.2.6 box, running BIND 8.1.2...
server# netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 server.4375 172.16.1.1.1984 SYN_SENT tcp 0 0 server.ftp server.4374 TIME_WAIT
Internal addr space... port 1984.. cute.
------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...
John Fraizer wrote:
Why on earth would anyone let any of the following networks in to their network at the border?
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
Hell, for that matter, I block anything claiming to be from our networks as well. There's no way they'll be originating from the outside unless it's spoofed.
Nothing and I mean NOTHING claiming to be from any of them at your border is valid.
Define "network border." I used to block all traffic from or to RFC1918 addresses, but my present upstream is using 10.0.0.0/8 and 172.16.0.0/16, at least, for their internal use. So, the IP address of the WAN interface on my router connecting to them has a 10.0.0.0/8 address. If I block incoming traffic to 10.0.0.0/8, they can't monitor my net. It appears this is becoming the preferred way for ISPs to limit their use of address space for internal-only functions. While this makes sense at some levels, attached corporate networks may have already used those addresses. The result is some level of confusion, though for the most part it doesn't break too many things. Mostly, it's just annoying since firewalls can't filter out stuff they'd otherwise limit. In cases where ISPs use RFC1918 addresses within their networks, they really should: - Tell their downstream customers WHICH of these blocks are in use. - Provide filters at peering points that ensure RFC1918 addresses from outside the ISP's space do not come in from outside. - Provide Ingress filtering at all downstream customer ports to ensure only valid source IP addresses come from their customers. Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
Define "network border." I used to block all traffic from or to RFC1918 addresses, but my present upstream is using 10.0.0.0/8 and 172.16.0.0/16, at least, for their internal use. So, the IP address of the WAN interface on my router connecting to them has a 10.0.0.0/8 address. If I block incoming traffic to 10.0.0.0/8, they can't monitor my net.
They are using (wasting) the whole 10.0.0.0/8 on one LAN? Sheesh! I've picked 172.30.0.0/16 to be divided up into 16384 /30's to use for numbered links. I'll probably choose another piece of address space in 172.16.0.0/12 for a LAN for a few special things like "permanent" DNS server addresses that will "never" change. My current thinking is to leave 10.0.0.0/8 workable between customers, let 172.16.0.0/12 be for special uses, and let customers do with 192.168.0.0/16 whatever they wish. There's no real ideal solution. How far from the intent of RFC1918 has that gone? -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Mon, 16 Nov 1998, Phil Howard wrote:
They are using (wasting) the whole 10.0.0.0/8 on one LAN? Sheesh!
I've picked 172.30.0.0/16 to be divided up into 16384 /30's to use for numbered links. I'll probably choose another piece of address space
If those numbered links will generate packets (eg. ICMP errors) sourced from 1918 space, then you should not be using 1918 addresses on them and it can break things like Path MTU Discovery. In general, using 1918 addresses for interface addresses when the interface routes public traffic is NOT a good idea unless there are special circumstances. Check the archives; this was discussed to death a few weeks ago.
On Mon, 16 Nov 1998, John Fraizer wrote:
Hell, for that matter, I block anything claiming to be from our networks as well. There's no way they'll be originating from the outside unless it's spoofed.
Nothing and I mean NOTHING claiming to be from any of them at your border is valid.
Actually, if you have a multihomed customer with your address space and their link to you goes down, you could legitimately receive traffic from your address block across external links if they then access hosts on your network via other connections. However, allowing that opens your network up to be spoofed and so it is commonly accepted practice to block internal address coming in over transit/peering links. If someone wants to multihome, they really need to have their own address block to take full advantage of it anyway. You have an anlogous problem if you filter inbound customer links, in that if they are multihomed and have address space from another ISP, you have to allow those addresses in your filters. If they provide transit, you either need to have everything downstream for them or just punt (perhaps only blocking your address space that you didn't assign to them). John A. Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
participants (5)
-
Daniel Senie -
John A. Tamplin -
John Fraizer -
Marc Slemko -
Phil Howard