Margaret, > [site-local addresses] > What do you need them for?
In a nutshell, to put one more obstacle in the hacker's way. I was trying to make the point that site-local addresses do provide some extra security, compared to RFC 1918 addresses that provide only the illusion of extra security. Let's look at a very common situation: IPv4 / RFC1918 : ---------------- - The network has a stateful firewall and uses NAT. - There is a web server with a public IP address in the DFZ. - There is a database server with an RFC 1918 address in the inside. - The web server needs to access the database server. - There is a hole in the firewall to let the web server access the database server. - There is a backdoor in the database server. (1) - The hacker wants the contents of the database and knows about the backdoor. How many things are necessary for the hacker to do in order to access the data? One: compromise the firewall. The hacker opens another hole in the firewall to allow backdoor access and creates a static NAT mapping and voila, data is gone. IPv6 / site-local: ------------------ - The network has a stateful firewall. - There is a web server with a public IP address in the DFZ. The web server also has a site-local address. - There is a database server with only a site-local address in the inside. - The web server needs to access the database server. - There is a hole in the firewall to let the web server access the database server. - There is a backdoor in the database server. (1) - The hacker wants the contents of the database and knows about the backdoor. How many things are necessary for the hacker to do in order to access the data? _more_ than one. If the hacker compromises the firewall and opens another hole in the firewall to allow backdoor access, it is not enough because the hacker's host does not have a route to the database server's site-local address. The odds of this are worse than winning the lottery. Even if we have occasionally seen people advertising 10.0.0.0/8 in the DFZ, this is typically filtered. Same thing applies to v6: it will quickly become standard practice to deny FEC0:: same as we deny 10.0.0.0 today. So, site-local addresses alone do not secure a network, but they do make the hacker's task more complicated, which does indeed help securing the network. In the example above, when I look at the extra annoyance for the hacker (we are talking about either installing a proxy on a third host that needs to be compromised or reconfiguring the IP stack on the database server) it appears to me that it is worth implementing it. You made a good point earlier about the consequences on default address selection, but the fact of the matter is that site-local addresses exist today; I agree with the assessment that Bob Hinden as made as chair that this working group was has been leaning towards full use of site-local addresses. The point I am trying to make is: site-local addresses do provide functionality, there are built in many documents, don't we have any better to do today but to try to remove them? Michel. (1) There are many examples of these, I remember one on Interbase that took two years to be discovered after the product became open-source. The backdoor could also have been installed by a disgruntled employee -------------------------------------------------------------------- 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] --------------------------------------------------------------------
