On Mon, 8 Sep 2003, Brian E Carpenter wrote: > There is no defence against misconfigured routers, except for well > configured routers elsewhere.
Sure.. be sure to implement filtering at multiple levels, and by different set of folks so the chance of mistakes is minimized. For example, for some services I maintain, I have: - TCP wrappers configuration in the host/service itself, using /etc/hosts.allow - The local host firewall settings, doing similar restrictions as above - Missing default route on the host, only some selected routes used - The first hop router/firewall settings - A configuration at the site border router Five layers of security should be enough, you'd think? Even a couple of them might be OK. This is no different than checking externally (e.g. with nmap or some other network scanning tool) that some of your services you've firewalled away are, in fact, unreachable. > I bet there are routers today capable > of announcing FEC0::/10 in BGP4+ if a user tells them to do so. If there are routers which are not capable of that, I'd certainly never buy them. There is nothing magic in the prefix wrt. BGP. > Whatever we define, misconfiguration (at the factory or by the user) > will occur. So I don't see where your rant takes us. > > You're correct of course that proper security is needed, but security > is not a serious argument for these addresses anyway. > > Brian > > Pekka Savola wrote: > > > > On Fri, 29 Aug 2003, Christian Huitema wrote: > > > > Unless I have missed some essential clause in your description above, > > > we > > > > appear to have a failure mode, with a root cause of user neglect or > > > user > > > > error, in which the non-propagation requirement for unique-local > > > prefixes > > > > to the global routing table is likely to be violated. > > > > > > Stuff happens. However, one ISP making a mistake does not have to > > > endanger the whole Internet. Any good ISP is suppose to filter routes in > > > the FC00::/7 prefix from its own BGP announcements, and to ignore prefix > > > in the FC00::/7 range that peer ISP might mistakenly advertise. > > > > I've stated this a number of times, but it seems to me that any model > > which presupposes ISPs (or routers) filtering (or not) something by > > default is just plain wrong. > > > > Why wrong? > > > > Because the end-site can't trust on such filters being in place. The > > end-site MUST NOT trust in having such filters in place. If the end-site > > wishes to use some form of communications restricted to its local range, > > it must itself ensure a sufficient level of safeguards (even defence in > > depth, using multiple mechanisms). If the users are not capable of that, > > or have no tools capable of achieving that, they should use better > > security mechanisms which do not depend on such filters in the first > > place. > > > > My concern? > > > > <mode rant=on> > > > > AFAIK, some have shipped services which restrict themselves to site-local > > addresses, in the hope of someone out there (the first-hop router?) will > > filter these site-local addresses, thus making the site protectetion > > "someone else's problem". Wrong, wrong, wrong, WRONG! > > > > <mode rant=off> > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
