On Mon, 22 Sep 2003, Brian E Carpenter wrote: > > 2 Adverse effects of site local addresses > > > > ==> I showed this draft to a believer of site-local addressing, who had had > > very little experience with IPv6. He was not convinced of the arguments. > > This may be for one of the many reasons. One fix is to also refer to some > > documents which include more verbiage than this document, e.g. Margaret > > Wasserman's SL impact document -- note that such would necessarily have to > > be a normative reference then, requiring the publication of it as an > > Informational doc. > > People who don't understand the down side of RFC 1918 are hard to convince > by more verbiage, in my experience. So I don't think this would be a > good use of our collective effort.
True, but if we wish to remain relevant, something has to be written somewhere. I fully agree that doing so in *this* document may not be worth it; it might be worth it in some other doc, e.g. sl-impact. > Are there any specific weak points? Trying to summarize: - 2.1: trying your own local addresses while visiting another site is a problem, but no news compared to RFC1918 - 2.2: the "leaking" of addresses may not be clear enough. The reader interpreted that as source/destination addresses (trivial!) and DNS. The *difficult* problems are elsewhere.. - 2.3: the reader didn't notice that the difficulty of routing lies with overlapping or adjacent sites. I'll send the exact wording off-list.. > > 5 Security Considerations > > > > The link-local unicast prefix allows for some blocking action in > > firewall rules and address selection rules, which are commonly > > viewed as a security feature since they prevent packets crossing > > administrative boundaries. However, such blocking rules can be > > configured for any prefix, including the expected future replacement > > for the site-local prefix. Thus the deprecation of the site-local > > prefix does not endanger security. > > > > ==> s/link/site/, obviously. > > > > ==> I think the security considerations considers only one, but important > > aspect of the site-locals. One should also discuss the effect of stability > > to the availability (which is part of security), and the effect of explicit > > scope to the address selection -- e.g., the case with intra-domain > > VPN's which route some traffic directly to the Internet but some to through > > the VPN to the infrastructure: how to ensure that the traffic destined to > > internal hosts over the VPN doesn't end up in the Internet by accident > > (e.g. if the VPN is down). > > I'm not disagreeing with your points, but does this document really need an > extended security analysis? That belongs in the specification for the > replacement (if any) of site locals, surely? Well, I'm not sure if the document does need it; maybe not. However, the security considerations as it is is a bit one-sided. It should be either tailed down a bit or extended. -- 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 IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
