Pekka Savola wrote: > > On Tue, 11 Dec 2001, Brian E Carpenter wrote: > > Pekka Savola wrote: > > ... > > > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt > > > > > > > > (by the way, comments would be welcome ;-) > > ... > > > > > > > Your discussion about what should not happen are already in RFC 3056 > > > > security issues. > > > > > > Some are, some aren't. But the main point was, that RFC 3056 rules were a > > > little abstract (and as a matter of fact, wrong in one sentence), so that > > > they were basically unimplementable and rather non-understandable. This > > > is noted in the introduction. > > > > There's no harm in an informational document making the RFC 3056 security > > rules more explicit, although the details are certainly implementation > > dependent. However, I can't find in your draft a clear reference to the > > sentence in 3056 that you believe is wrong. > > It's not noted in the draft, but it was mentioned on ngtrans list. > > In security considerations: > > A possible > plausibility check is whether the encapsulating IPv4 address is > consistent with the encapsulated 2002:: address. If this check is > applied, exceptions to it must be configured to admit traffic from > relay routers (Section 5). > > The latter sentence makes no sense and is confusing, as the only packets > coming from relay have the native source address, not 2002::/16, and > destination need not be excepted if it is checked.
Sorry, I think you are wrong. If the source of a packet is a normal 6to4 router, the outer IPv4 source address must be consistent(*) with the V4ADDR of the source address in the embedded 2002:: packet. But if the source of the packet is a 6to4 relay, the inner source address may be a native IPv6 address that would fail the consistency check, so the check must be skipped. That's what the second sentence says. (*) consistent does not mean equal. The real problem with this check is that you need to know *all* the V4ADDR values that might be valid, in multihomed cases. 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] --------------------------------------------------------------------
