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

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

> 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