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] ]

[Fred Templin <ftemplin@iprg.nokia.com>]

Pekka Savola wrote:

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

OK, but I am still checking my thinking on this. I'm now thinking that
my suggestion might foul things up for protocols that require a means
for detecting L2 address changes due to, e.g., a NAT in the path.

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

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

I can potentially see your point, depending on exactly which document
you think such non-normative text should appear in.

Fred
ftemplin@iprg.nokia.com