> > This would only cause trouble, I guess, if the customer's > > system attributes some special security status to packets=20 > > that appear to come _from_ a site-local address, which would=20 > > be quite inadvisable. > > Hmm, perhaps there is some misunderstanding of how site-locals would be > used for security, because the idea is in fact to give special security > status to packets that come from a site-local address.
I still think it's naive to expect that a single "site" can be a useful trust boundary in any significantly-sized network. > Applications use site-local addresses to ensure that communication is > within the site. For example, one has a file server that is intended > only for use within the site: the file server is restricted to only > processing requests from site-local addresses. But the file server node > also has a global address for other uses. In a more extreme example, one > may have a private node that should only be accessible within the site, > so the node has a site-local address but no global addresses. > > OK, so how does one implement this functionality without site-locals? > > The most obvious alternative is to do filtering or firewalling of the > global prefix at nodes within the site. (Note - NOT filtering at the > site boundary!) So the file server node is configured with a filter rule > to block packets to the file service port with source addresses that > don't match the site's global prefix. The private site-internal node is > configured with a filter rule to block all packets with source addresses > that don't match the site's global prefix. Etc. > > Now in previous email I pointed out the inherent "defense in depth" of > the site-local prefix, because there will likely be multiple > site-boundary routers between an attacker and the site, all of which > would have to malfunction or be misconfigured to let the attacker's > site-local packets into the site. > > In contrast, the alternative approach has no defense in depth. Any > mistake in configuring the filter rules on a file server or private node > lets the attacker through. no, it's pretty much the same problem. In one case you configure the server to not accept anything that's not a site-local. It's not inherently configured this way, because trust of SLs will not be appropriate for all servers. The server should not make any assumptions about the meaning of SLs out of the box - that's a matter for site configuration. In another case you configure the server to not accept anything that's not from one of a small number of prefixes. In either case the server can be misconfigured, denying authorized traffic or permitting unauthorized traffic. And either case has the potential for defense in depth because multiple routers (in addition to the host) can filter based on source address regardless of whether the prefix is an SL prefix or a global prefix. (and of course you do want to filter SLs at the site boundary - I assume you meant that the filtering isn't only at the site boundary) SLs do have two slight advantages here - 1. the filtering rules in your servers don't have to change when the site changes prefixes 2. more routers outside your site are likely to filter packets using SLs as source or destination addresses however I'd argue that the probability of both you and your ISP failing to filter traffic with source addresses containing your prefix should be very small, so statistically speaking #2 does not seem like a huge win. #1 does seem useful in the absence of a good way for servers to learn which global prefixes are currently trusted. but we need to solve the renumbering problem anyway. I don't claim that it can be solved by handwaving, but I do think that if we had a credible solution to the renumbering problem then #1 wouldn't be a significant argument in favor of SLs either. (and no I don't think that SLs make a significant dent in the renumbering problem) furthermore if you have multiple prefixes on a net, some of which are trusted and some which are not, then you have to configure each of those apps to tell them to use the trusted prefix. (telling them to use an SL address for the server will work with some apps - but not all of them - and if you use DNS names for the servers (which gives you some flexibility) then you get back to needing to figure out how to make SL work with DNS.) at any rate, the disadvantages associated with wide use of SLs still don't seem worth these slight advantages. > And many more nodes have to be configured > properly, because all the internal applications and private nodes have > to be individually protected with filter rules, vs just configuring the > site-boundary routers. you only get defense in depth if you have mulitiple layers of defense. claiming that SLs provide defense in depth on one hand and that you don't have to have multiple layers of defense on another hand doesn't seem consistent. > Now in recent email, if I understand correctly, Keith is proposing that > non-routable global addresses replace site-locals in the above scenario. > So the site would have its normal routable global prefix and also a > non-routable global prefix. The non-routable global prefix would be > standardized so that distributed applications could recognize it. a site with a routable prefix probably wouldn't need a non-routable prefix, and there are good reasons to not have more prefixes than needed. > This sounds exactly like site-locals with the 38 bits of zero replaced > with a unique site identifier so that derived addresses are globally > unique yet not globally routable (sites could make private peering > arrangements to route them). > > (This is of course an idea that has been raised & rejected by the WG > several times previously, but never mind that for now.) > > Keith, do I understand this right?? as a first approximation, it does sound right. (I'm not deterred by the previous rejection of the idea by the WG because the WG is now stating to understand both the harm done by SLs and the other reasons why PI addresses are needed ) Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
