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

From: Fred Templin <[email-masked]>
Date: Thu, 01 Apr 2004 12:16:42 -0800

Pekka Savola wrote:

>On Wed, 31 Mar 2004, Fred Templin wrote:
>  
>
>>>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 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).

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

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Apr 2004 09:58:49 +0300 (EEST)

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

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

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

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

---

From: Fred Templin <[email-masked]>
Date: Fri, 02 Apr 2004 09:54:38 -0800

>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

>deployable -- and make sure it interoperates with current ND 

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.

>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
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 5 Apr 2004 09:32:53 +0300 (EEST)

> 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 :-(

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