Re: stable vs address-derived v6 prefix [Re: v6 deployment in general [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]]]

[Erik Nordmark <Erik.Nordmark@sun.com>]

> > You appear to be looking for a free lunch.
> > Sufficiently secure, operationally robust, direct paths, and no
> > need to "register".
> > That is an overconstrained problem IMHO.
> 
> That certainly is; but I am do not want to solve "direct paths" in 
> this kind of "tunnel server" solution -- and then I do not think the 
> problem space is over-constrained.
> 

Sorry about "direct paths" - but "stable prefix" was missing from the list.
Perhaps Jeroen's idea about a cookie which can be created when autoregistering
is a way to provide a stable prefix and sufficient security for the
anonymous case.

> As a matter of fact, Alain Durand reminded that "stable prefix"  
> scenario introduces stricter security requirements in a sense -- as
> noted in your multi6 security presentation on 3rd party bombing.  
> You'll basically have to do (at least) return routability when you're
> doing any actions associated with the v6 prefix.  If you tie the v6
> prefix to the address/port you use, there is no need for that.

Agreed.
But as you've pointed out elsewhere, it might make sense to require
an IPv4 return routability check as part of tunnel establishment
to prevent a single packet with a spoofed IPv4 source address from
creating a bogus tunnel.

> > I actually think it is a mistake to define mechanisms that are *not
> > capable* of doing registration with the same type of "tracability" that
> > is done to sign up for a free email account.
> 
> This type of traceability is available from the tunnel server logs, 
> similar to traceability of someone sending emails off such an account 
> (many of which do not show the IP address of the sender).

But that would require the operator to run an abuse line which
will go look for the IPv4 addresses (and email address if the tunnel
was not autoregistered).
An alternative might be the freenet6 approach of sticking this
information in the reverse DNS entry so that a smart complainer can bypass
the tunnel provider to more quickly get towards the offender.

  Erik