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 Fri, 2 Apr 2004, Fred Templin wrote:
> >I have to disagree with that.  ND operates with very specific security
> >assumptions (TTL=255, link-local messages is considered "reasonably
> >safe").  Those assumptions are valid for typical links (physical,
> >local point-to-point tunnels, etc.).
> >
> >Making it possible to send TTL=255 + LL packets from everywhere in the 
> >Internet breaks this assumption.
> 
> Well, we have made specific mention this assumption in past versions of
> the draft, e.g, see Security considerations in:
>   
> http://www.join.uni-muenster.de/Dokumente/drafts/draft-ietf-ngtrans-isatap-03.txt

Too bad this was removed and apparently forgotten by many WG 
participatents :-(

> >So, my argument is that while that assumption has not been
> >sufficiently well spelled out, you must avoid breaking that assumption
> >rather than say, "whoops -- we broke the assumption.  Well, figure out
> >a new means to secure ND, deploy it everywhere where this mechanism is 
> >deployable -- and make sure it interoperates with current ND 
> >specifications."
> 
> I think there may be other efforts in progress in regard to securing ND,
> so for the time being I am fine with looking at a domain of applicability
> that might be more constrained than including the entire Internet and
> allowing other mechanisms to come online as they become mature.

Good.  Note that for e.g. SEND to work, there has to be a trust 
anchor.  That's communicated using the routers.  If would not be 
routers (but everyone just on link), applying something like SEND to 
ISATAP would be very difficult or impossible.  So, while there is work 
in progress for ND, that work migth also be applicable only in the 
specific scenario it is designed for.

> >Link-locals can be discarded by the 6to4 pseudo-interface, as they are
> >not used for anything.  The spec does not say anything about that.  
> >(Obviously, discarding is not possible with ISATAP so they aren't
> >equivalent in that regard.)  draft-ietf-v6ops-6to4-security-02.txt
> >does mention this though, under "Attacks with ND Messages".
> >
> 
> Well, section 3.1 of RFC 3056 has something to say about (non)use of
> link-locals for 6to4, but that text seems to me to be only a
> snapshot in time and not to be taken as precluding the possibility
> of future scenarios requiring link-locals.

Agree.  As a matter of fact, long-since-expired 6to4 multicast
extensions used (AFAIR) link-local MLD messages on the
pseudo-interface.  But (more or less) luckily enough, that has not
materialized, and there is no current use for link-locals.  As a
matter of fact, the 6to4 security document recommends dropping them
(for what it's worth).

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