Date: Wed, 19 Dec 2001 23:40:13 -0500 (EST) From: Krzysztof Adamski <kadamski@netsurf.net> To: Jim Flowers <jflowers@ezo.net> Cc: portmaster-users@portmasters.com, freebsd-isp@freebsd.org Subject: Re: (PM) Infrastructure Design with Portmasters and FreeBSD/Zebra (long) Message-ID: <Pine.LNX.4.21.0112192326030.14020-100000@white.netsurf.net> In-Reply-To: <002b01c1890a$7d553920$22b197ce@ezo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Dec 2001, Jim Flowers wrote: > OK, thanks for the heads up. I think that what you are cautioning against > is that the `ICMP can't fragment' message will not be returned over the > Internet to a sender with an RFC1918 address (particularly as I deny them at > the edge router). OTOH, in my proposed layout one of the basic concepts is > that hosts with RFC1918 addresses are never allowed to exchange packets with > hosts on the Internet so this situation should never arise. All the working > system hosts and customer hosts have public addresses and in this case the > Internet sourced ICMP messages should be routed over the RFC1918 network > correctly - er, right? :-) Shouldn't this work equally well for the PM3 > dialups (who all have public addresses) as long as their host/router > supports pathMTU discovery? Exactly. Except with the PM3, if the customers MTU is smaller then 1500, and a large packet comes, the PM3 will have to fragment it, but if it can't then the PM3 will send the `ICMP can't fragment' with the PM3s IP address. > Also, the inter-pop routers don't involve the Internet and as they are under > my administration I will advertise the RFC1918 addresses with ospf for any > inter-pop transmissions. This is fine, the only thing that will break is a traceroute done from the outside of your network for this routers. It will show '*' for the hop that has the RFC1918 addresses. Unless you allow icmp ttl-exceeded for this addresses to leave your network. A second nuisance is the reverse DNS for this addresses, you can set up your DNS server to be authorative for 10.x.x.x so the traceroutes inside your network give you useful info. > > I am more interested in the security aspects than reclaiming the addresses > but it is also appealing to not have to justify the usage each time we (or a > customer) want another block (It has been a hassle). Currently, we have > about 100 subnets on the 5 Class Cs with about 55% still available as we NAT > most of our commercial users. There is really no security gained from using RFC1918 addresses, at first glance, it looks like it would be secured, but as soon as a single host on the inside of you network is compromised, it has full access to all routers with RFC1918 addresses. Also there is no protection from your own customers. You should secure your routers with access lists, both from outside and inside. Don't get me wrong, I use RFC1918 addresses in my network, for instance the two DNS server IPs that are hard coded in my customer setups (where needed) are from RFC1918. This way when I renumber I will not need to change this. K > Thanks again for your reply. > > Jim Flowers - EZNets, Inc. <jflowers@ezo.net> > ----- Original Message ----- > From: "Krzysztof Adamski" <kadamski@netsurf.net> > To: "Jim Flowers" <jflowers@ezo.net> > Subject: Re: (PM) Infrastructure Design with Portmasters and FreeBSD/Zebra > (long) > > > > Replacing routable IPs with RFC1918 on a PM will work just fine, but there > > is one problem with it. It breaks Path-MTU-discovery protocol. This would > > be a problem for routers that can have different MTU size of different > > interfaces, like a PM with dial in users. > > If you are efficiently using your address space you should not have a > > problem with getting more addresses. > > > > K > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0112192326030.14020-100000>