Exodus / Clue problems

Mon Nov 16 22:18:22 UTC 1998

John Fraizer wrote:
> 
> >Define "network border." I used to block all traffic from or to RFC1918
> 
>         [root at Overkill /]# traceroute mae-east.fnsi.net
>         traceroute to mae-east.fnsi.net (192.41.177.11), 30 hops max, 40 byte packets
> ----->   1  border-core0-eth1.Columbus.EnterZone.Net (209.41.244.1)  0.538
> ms  0.444 ms  0.411 ms
> |        2  core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21)  0.916 ms
> 0.783 ms  0.774 ms
> | --->   3  border1-atm6.Vienna.fnsi.net (206.183.239.90)  23.132 ms  23.797
> ms  23.829 ms
> | |
> | |-- That is the network border of my provider at mae-east.
> |
> |---- That is the network border for MY network.  The DEMARC where my
> network ends and my providers begins.
> 
> I can't tell you precisely where yours is since @home has decided to block
> the traceroute.

Actually, the blocks are mine, not theirs. If you use a traceroute on a
system which uses ICMP ECHO packets to do the trace, instead of the
older Unix implementations which use random UDP ports, your traceroute
will get to my site without trouble.

> 
> [root at Overkill /]# traceroute www.senie.com
> traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0
> traceroute to fennel.senie.com (204.69.207.2), 30 hops max, 40 byte packets
>  1  border-core0-eth1.Columbus.EnterZone.Net (209.41.244.1)  0.542 ms
> 0.438 ms  0.411 ms
>  2  core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21)  0.896 ms
> 0.768 ms  0.731 ms
>  3  core1-atm0.Cleveland.fnsi.net (209.115.127.102)  12.083 ms  9.756 ms
> 9.316 ms
>  4  border1-atm6.SanJose.fnsi.net (206.183.239.94)  66.729 ms  65.678 ms
> 63.696 ms
>  5  bb2.mae-w.home.net (198.32.136.70)  67.027 ms  65.376 ms  76.126 ms
>  6  172.16.2.250 (172.16.2.250)  90.842 ms  78.524 ms *
>  7  172.16.2.58 (172.16.2.58)  146.095 ms  130.080 ms *
>  8  10.0.248.34 (10.0.248.34)  118.753 ms  125.679 ms  128.392 ms
>  9  10.252.48.218 (10.252.48.218)  156.053 ms !X * *
> 10  10.252.48.218 (10.252.48.218)  129.488 ms !X *  146.837 ms !X
> 
> Bad idea in my book.  By the way, you might want to ask them about all of
> those *'s.  Nasty, nasty, nasty.
> 
> In addition, path MTU discovery won't work on your network because of the
> RFC1918 addresses.  Don't get me wrong.  I personally use RFC1918 addresses
> within my network.  Those are NON-EXPOSED hosts however and there is no
> need for path discovery to take place.  In your case, your provider wanted
> to save 4 IP addresses, a /30.

I hadn't thought about the PMTU failure this causes. Not nice at all.

> 
> >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.
> 
> Find out from them SPECIFICALLY which machine they want to monitor your
> router from and open your router up to that IP address individually.  Block
> the rest of them.

The problem with this is I can't do traceroutes out, then, because all
the responses from the 10.x.x.x/8 and 172.16.0.0/16 machines get caught
in the filters.

> 
> >
> >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
> 
> The key phrase here is "internal-only." I would hardly consider your router
> or any router between yours and the rest of the world to be considered
> "internal-only."
> 
> >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.
> 
> I can find no good reason for joe blow fortune 1000 company to use anything
> other than RFC1918 addresses on their INTERNAL network and run NAT or set
> up a proxy or something.  I can also not find any good reason to use
> RFC1918 space between routers.  It breaks too many things.  I want to see
> you poll or for that matter, log into your router from any other network
> than your own.  I Hope nothing happens that would require your PERSONAL
> attention while you're at some convention, on vacation, etc.

Fortunately I have enough of an operation to have a direct dial-in to my
network so that I can get in even if the ISP link is down, but I agree
with your assessment.

> 
> >
> >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.
> >
> 
> ...and one last point...
> 
> - Have someone loan them a clue about why they should NOT use RFC1918 space
> in the way your isp is doing so.

Agree. Unfortunately, when selecting ISPs, this was not an aspect I
expected I'd have to worry about, and so I didn't ask. It certainly goes
on my list for the next negotiation, though.

Dan

-- 
-----------------------------------------------------------------
Daniel Senie                                        dts at senie.com
Amaranth Networks Inc.            http://www.amaranthnetworks.com