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 Thu, 1 Apr 2004, Fred Templin wrote:
>  
>
> > > 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.
> > >      
> > Right, but this is an issue for the upper layers (e.g., ND handling code).
> >    
>
> 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

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

> > > Of course, but as LL's are treated specially e.g. by ND code, this 
> > > makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation.
> > >      
> > I'm not sure what you mean by this; ND handling code comes *after*
> > decapsulation; not during - correct? The only mitigations specified
> > by 6to4 for decapsulation are found in the second paragraph of
> > ([RFC3056], section 10) and these are optional.
> >
> > The final sentence of that paragraph says: "2002:: traffic must also
> > be excepted from checks applied to prevent spoofing of "6 over 4"
> > traffic [6OVER4]." Perhaps a similar sentence with
> > s/6over4/ISATAP is needed somewhere?
> >    
>
> 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.

Fred
ftemplin@iprg.nokia.com