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:
[...]
>        -  the IPv4 source address is a member of the Potential Router
>           List (see: section 9.1).
> 
> Neglecting for the moment the middlemost of the three checks, we see that
> the first check accepts link local IPv6 source addresses that embed the IPv4
> source address in the interface identifier. However, the third check also
> accepts link local IPv6 source addresses that *do not* embed the IPv4
> source address - so long as the IPv4 source address is in the Potential
> Router List - and this is the part that could cause trouble.
> 
> The fix suggestion is to modify the third check in the list to exclude
> packets with IPv6 link-local source addresses from the check, forcing
> IPv6 link-locals to be either verified or rejected via the first check only.
> Comments?

I see no harm in that.

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.

(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.)

> >>Well, yes - I agree with your point, and the ISATAP interface is not
> >>the only choice. I don't believe this changes the fact that one possible
> >>implementation alternative is to combine both the ISATAP and 6to4
> >>functions over a single interface, however.
> >
> >(I haven't gone through the thought exercise of looking through the
> >details, but the prospect leaves me with a fuzzy bad feeling..)
> >
> 
> Well, the good news is that this would fall under implementation details,
> and not anything necessary for protocol specification - right?

I fear I have to disagree.. leaving these unspecified seems like an
indication that we never managed to figure them out properly, and
leaving them as an "exercise for the reader".  This would tempt the
implementer to either 1) do them improperly, or 2) not do checks at
all.  We have already seen examples of both...

I.e., I think it would be very useful to try to figure out a way to
perform decapsulation processing in a sane fashion.  We don't need to
normatively *require* the specific processing rules, of course -- but
just provide them as an example (or two) for the implementers.

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