Yes, you're right. However, there's no reason for an interior router to route all of 192.168.x.x ... it only needs to route the subnets it actually implements, such as 192.168.0.1 to .255 subnet mask 255.255.255.0 so you still have to block the rest of that address range from crossing your interior router boundaries.
Cable/DSL customers, even ones that use business class service and are permitted to use the link to route traffic to and from their LANs, should understand that if their border router isn't configured properly with respect to RFC 1918 addresses, these addresses represent a security risk. Individual nodes that don't route traffic for a LAN over the link should block all traffic to and from these addresses. Sincerely, Jason Coombs [EMAIL PROTECTED] -----Original Message----- From: Burton M. Strauss III [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 11:59 AM To: [EMAIL PROTECTED] Cc: Ian Webb; [EMAIL PROTECTED] Subject: RE: Strange traceroute output on Road Runner for an RFC 1918 address Border routers or interior routers? Border routers must - by RFC - block the reserved address spaces. But, if you're using the RFC1918 address spaces, your interior routers pretty much have to route it. For example, AT&T BI seems to use an overlay of the 10. space with the 12. space they also own. That is, my cablemodem has a 12.x.x.x address, assigned via dhcp, world accessible, etc. But it also has a 10.x.x.x address, used by AT&T for management. Do they need to pass both spaces through their interior routers - you bet - otherwise, how could the Denver call center manage my modem. But the gateway routers had better strip the 10. and only pass 12. or we're all in trouble. I've used 192.168.x.x addressing for semi-private links between sites (where I needed and was willing and able to provide more bandwidth for the link than the corporation was willing to provide). etc. -----Burton -----Original Message----- From: Jason Coombs [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 4:29 PM To: Burton M. Strauss III; [EMAIL PROTECTED] Cc: Ian Webb Subject: RE: Strange traceroute output on Road Runner for an RFC 1918 address Aloha, I've examined the issue of 10.x.x.x and 192.168.x.x local address ranges from a security basics point of view and concluded that they represent a threat when they are allowed to route by default out of your network. My routers always have manual routes configured for 10.0.0.0 netmask 255.0.0.0 and 192.168.0.0 netmask 255.255.0.0 to force any address in this range to route locally and not cross router boundaries. Unless there's a specific need to the contrary. Does anyone else do this already? Sincerely, Jason Coombs [EMAIL PROTECTED] -----Original Message----- From: Burton M. Strauss III [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 4:29 AM To: [EMAIL PROTECTED] Cc: Ian Webb Subject: RE: Strange traceroute output on Road Runner for an RFC 1918 address Actually, you are wrong. RFC 1918 doesn't say that those address spaces are LOCAL, rather it says that they can not be routed on the global internet. It does not prohibit a network from using them in ANY way they want internally, just don't export the addresses. Many sites use them for WAN links, etc. and then use egress/ingress filters to keep them out of the external net. This way you don't have to "waste" routable address space for those kinds of links. -----Burton -----Original Message----- From: Ian Webb [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 21, 2002 4:27 PM To: [EMAIL PROTECTED] Subject: Strange traceroute output on Road Runner for an RFC 1918 address I get the following output when I do a traceroute from my Windows XP machine, which is directly connected to a Road Runner cable modem (Motorola Surfboard), to 192.168.100.1: C:\>tracert 192.168.100.1 Tracing route to 192.168.100.1 over a maximum of 30 hops 1 * * * Request timed out. 2 62 ms 125 ms 66 ms 24.93.66.37 3 87 ms 220 ms * 24.93.66.150 4 * 24.93.66.177 reports: Destination host unreachable. This seems weird to me, since 192.168.100.1 is an RFC 1918 local address space. I can't think of any valid reason that a packet destined for it would go *two* hops into Road Runner's network before getting a destination host unreachable. Is there something I'm missing? Thanks, Ian
