Pekka Savola wrote: > > On Fri, 21 Dec 2001, Brian E Carpenter wrote: > > Pekka Savola wrote: > > > This is getting too implementation-specific, so I guess we had better kill > > > this thread, at least from here... > > > > In fact, it would be a fundamental error to make protocol choices on the > > basis of perceived implementation glitches in today's popular operating > > systems. If we do the "right thing", one of these days the o/s will > > catch up. > > My gripe with 6to4 is that it doesn't discuss the security issues > properly. Everything about security is basically written (rather > concisely), in security considerations, like sugar coating on a cake.
Actually I think the decapsulator pseudocode indicates where checks should be made, and as far as I know that is the only place where security would come in. Yes, the description is in boundary condition terms, which the WG thought was necessary and sufficient at the time. > > IMO, this is the wrong approach. Security precautions should be discussed > and handled all the way through the specification (as with Shipworm), and > in security considerations, a summary and remainder threats discussed. > Remainder threats are not covered there. Are you aware of any except spoofing? > > A few points from along the course of this thread: > > - 6to4 does not require the checks and the threats are partially > downplayed It's very hard to attach MUST to checks which are implementation and deployment specific. > - automatic tunneling does not discuss the checks even that much > - issues with multiple use of configured/autotunnel/6to4/... on the same > box is not covered AFAIK anywhere Quite true. > - should autotunnel be deprecated in a more official fashion? Probably. That means removing it from the address architecture and from RFC 2893. > > > That doesn't deny the value of informational documents about today's > > implementation issues, especially security threats. > > This is what my draft was/is partially meant to be; from my perspective (I > looked at Linux and KAME) it appeared that the checks had been implemented > only partially or not at all. Perhaps partly because they may not have > been understood to be important, or were difficult to implement because of > the problem with multiple mechanisms. I think your draft is useful. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
