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

["Bound, Jim" <jim.bound@hp.com>]

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:pekkas@netcore.fi] 
> Sent: Saturday, May 01, 2004 4:03 PM
> To: Bound, Jim
> Cc: Liu Min; v6ops@ops.ietf.org
> 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
> 
> 
>