Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 31 Mar 2004, Fred Templin wrote:
> >But it should be obvious that this doesn't really provide much of 
> >practical mitigation, as v4 addresses can be spoofed, or you could 
> >just use a real v4 address.  This check is most attractive inside a 
> >site, where it's reasonable to assume that ingress filtering is in 
> >place .. and the "everyone in PRL list" is definitely not that case.
> 
> I didn't quite catch what you meant by "a real v4 address"?

The check only protects from someone spoofing their v4 address.  If 
the use of link-locals by strangers (remember that these have TTL=255 
and are allowed to do anything Neighbor Discovery -wise) is 
categorically thought to be harmful (I certainly think so), this 
doesn't really help.

> >(The only difference, still, with 6to4 is that the similar abuse of 
> >6to4 is limited to global addresses -- not link-locals, even if the 
> >v4addr matched.)
> 
> In terms of link-locals, the first-pass filtering by the ISATAP decapsulator
> is only for the purpose of determining whether the IPv4 source address in
> the encapsulating header is acceptable for the IPv6 source address in the
> encapsualted packet. Higher layers up the stack will also likely use other
> mitigations in determining whether/not to accept link-local packets, but
> this is beyond the scope of our discussion on decapsulation.

Of course, but as LL's are treated specially e.g. by ND code, this 
makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings