Subject: RE: direct tunneling vs site's control [RE: POLL: Consensus for moving forward with Teredo?]

From: "Bound, Jim" <[email-masked]>
Date: Sat, 1 May 2004 12:44:59 -0400

> On Sat, 1 May 2004, Bound, Jim wrote:
> > I have heard from three different users in the ISR (Intelligence, 
> > Surveillance, and Reconnaissance) deployment community, all 
> different 
> > entities, that any transition mechanisms, which use special IPv6 
> > prefixes are a non-starter in certain cases.
> 
> I'm not fully sure if I understand the scenario, but if I 
> think this is what I think it is, the main problem is not a 
> special IPv6 prefix, but being to tunnel directly to the node 
> in a way that the host's site losts manageability.

That is the end result (loss of manageability) but the root cause was
permitting hard coded prefixes in the network.

> 
> > The two that are not
> > useful for that reason are 6to4 and Teredo.  They present a 
> potential 
> > security hole because nodes can create them ad hoc theoretically and
> > IPv6 packets could be sent to them, and they are not within the 
> > address space defined by these communities, and causes 
> permanent infrastructure.
> 
> 6to4 and Teredo have direct tunneling, of course; both can be 
> blocked easily at the border, but if the site is not aware of 
> them being used...

Blocking puts extra methods in the edge of this highly secure network,
and as you say they could be created without the site being aware of
them.

> 
> In some networks 6to4 is less of a problem if private IPv4 
> addresses are used as the internal nodes cannot use 6to4 tunneling.

In this case there are not PI or private addresses all addresses are
globally routable IPv6 and security methods are used to secure all
communications at various points.

> 
> > The two mechanisms that may work well at this time are DSTM and 
> > ISATAP, and objective is to let ISATAP phase out automatically with 
> > deployment (large advantage of ISATAP to them). Rigorous security 
> > holes for DSTM and ISATAP are being searched now.  That is all I 
> > really know at this point and it is new.
> 
> ISATAP is equally problematic as 6to4.   You can tunnel packets 
> directly to the nodes if they have public addresses using 
> fe80::<ISATAP> -addressing -- unless those have been 
> (properly) blocked at the border.

As I understand it ISATAP is restricted to extended subnets as nodes
evolve to IPv6 deployment, until IPv6 capable is turned on, but will not
be used off of the subnet. ISATAP is preferred over link-locals.  The
FE80 token is also only available on the local link and not routable
except by ISATAP relays and those will only be on extended subnet with
host attached links and not typical routing.  So your favorite server or
router is forwarding the packet but it is all still the same link.
ISATAP is a very good mechanism to begin IPv6 deployment and it goes
away without administration once all nodes are able to exist as IPv6
capable on the net.  Telcos that consult with me like ISATAP for that
reason too as a note.

> For what its worth, if this is the scenario you're worried 
> of, about everything will be problematic -- if you can 
> connect to a tunnel server outside of the site using protocol 
> 41 or UDP, you can go past the site's management controls 
> unless explicitly forbidden.

I not really worried about it :--) It is just operational input to the
list and a case where 6to4 and Teredo will not be used. I would imagine
IPv6 secure filtering would check for 41 clearly.

Regards,
/jim

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 May 2004 23:03:29 +0300 (EEST)

> permitting hard coded prefixes in the network.

No, the root cause is not hard coded prefixes themselves; it's being 
able to tunnel past the management -- that can be done either with a 
mechanism which has a special prefix, or some mechanism which does not 
have one.  Hard coded prefixes themselves do not cause this.

> and as you say they could be created without the site being aware of

True, but it's worth remembering that there will always be these
"cover channels" through the edges.  People tunnel IP even through
HTTP proxies.. 

So, the question is how much effort should be needed for the sites who
wish to block the attempts at creating IPv6 connectivity
(automatically) by their hosts.

> communications at various points.

Obviously for these methods to be worth considering, IPv6 addresses 
must be globally routable.. but the point is whether the _IPv4_ 
addresses are globally reachable or not.

In other words, if a host has enabled ISATAP interface or 6to4
pseudo-interface, is it even possible to send IPv4 proto-41 directly
to the hosts (this is obviously impossible w/ private addresses).

> be used off of the subnet. 

I'm not 100% sure what you meant precisely, but obviously ISATAP nodes 
are reachable through the ISATAP router, and you can tunnel directly 
to the ISATAP nodes if the ip-proto-41 access hasn't been blocked (as 
one should).

> The FE80 token is also only available on the local link and not
> routable except by ISATAP relays and those will only be on extended
> subnet with host attached links and not typical routing.

If ip-proto-41 packets are not dropped at the border of the site 
running ISATAP, and global addresses are used, anyone can tunnel 
directly to the ISATAP hosts w/ FE80 prefix.

That's why "just turn on ISATAP interface" is not really too secure.

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