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 22:26:51 -0400

Thanks for you views I see no point in further mail on this thread the
WG has the input.
/jim 

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Saturday, May 01, 2004 4:03 PM
> To: Bound, Jim
> Cc: Liu Min; [email-masked]
> Subject: RE: direct tunneling vs site's control [RE: POLL: 
> Consensus for moving forward with Teredo?]
> 
> On Sat, 1 May 2004, Bound, Jim wrote:
> > > 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.
> 
> 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.
> 
> > > > 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.
> 
> 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.
> 
> > > 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.
> 
> 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).
> 
> > > > 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.
> 
> 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
> 
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 1 May 2004 22:09:43 -0700

> That is the end result (loss of manageability) but the root cause was

I believe the root cause is using unmanaged hosts in a context where
secure behavior is expected. If you want to assert security properties
of the hosts, then you absolutely need to manage them and control what
kind of software they run. Otherwise, even without Teredo and 6to4, it
is pretty trivial to set up an IPv6 tunnel to some random place.

-- Christian Huitema