Subject: RE: POLL: Consensus for moving forward with Teredo?

From: "Bound, Jim" <[email-masked]>
Date: Sat, 1 May 2004 09:13:55 -0400

This made me think of something to relay to the WG (thanks Liu Min).  

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.  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.
These nets use stateless and dominant IPv6 nets reducing IPv4
immedidately when possible, and using mechanisms to connect to legacy
IPv4.  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.  

/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Liu Min
> Sent: Saturday, May 01, 2004 1:19 AM
> To: 'Pekka Savola'; [email-masked]
> Subject: RE: POLL: Consensus for moving forward with Teredo?
> 
> I think NAT traversal in IPv6 transition is a very important 
> issue and should be solved. Although Teredo needs special 
> IPv6 address prefix and need Teredo relay in every IPv6 
> network, it is reasonably secure and already out there. There 
> are also other mechanisms for this issue and each of them has 
> different properties and applying scenarios. We should go 
> forward with these transition mechanisms and let the market 
> to make the final decision.
> 
>  
>  
> 
> Best Wishes,
>  
> Liu Min
> Institute of Computing Technology
> Chinese Academy of Sciences
> Tel: (86-10) 6256 5533-9240
> E-mail: [email-masked]
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Pekka Savola
> > Sent: Saturday, May 01, 2004 1:32 AM
> > To: [email-masked]
> > Subject: POLL: Consensus for moving forward with Teredo?
> > 
> > Hi,
> > 
> > (co-chair hat on)
> > 
> > As identified in the scenarios analysis at IETF59 and in
> > draft-savola-v6ops-tunneling-01.txt, there appears to a need which
> > cannot be filled by another mechanism for Teredo at least 
> in one major
> > Unmanaged scenario.
> > 
> > Is there rough consensus to move forward with Teredo? 
> (i.e., to adopt
> > it as WG document in this WG or elsewhere, for Proposed Standard.)
> > 
> > The main issue raised has been to call for a more extensive analysis
> > for the deployment implications of native, 6to4, and 
> Teredo.  There is
> > already discussion of this in the Unmanaged Analysis 
> document.  There
> > seemed to be very little energy or interest in the WG to drive this
> > much further.
> > 
> > The options regarrding Teredo at this stage seem to be:
> > 
> >  a) Go forward with Teredo, hone the deployment implications in the
> >     unmanaged analysis in parallel (if and as appropriate),
> > 
> >  b) Conclude that there is no sufficiently strong need for 
> Teredo, and
> >     not support its advancement (for PS) at this stage, or
> > 
> >  c) Decide that we need to analyze the scenarios or deployment more
> >     before being able to make a decision.
> > 
> >     If so, please state where you believe more analysis is needed..
> >     and volunteer if possible :)
> > 
> > If you have an opinion, please state it within a week, i.e., by next
> > Friday, 7th May.
> > 
> > Thanks!
> > 
> > (co-chair hat off)
> > 
> > 
> 
> 
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 May 2004 18:04:14 +0300 (EEST)

On Sat, 1 May 2004, Bound, Jim wrote:
> 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.

> The two that are not

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

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

> The two mechanisms that may work well at this time are DSTM and

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.

...

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.

-- 
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: "Tony Hain" <[email-masked]>
Date: Mon, 3 May 2004 09:04:37 -0700

Changing the subject to make counting the poll easier ...

There is no permanent infrastructure component in either 6to4 or teredo, and
they are no less secure than any other approach. Every node is supposed to
prefer a non-tunneled prefix over a tunneled one, so these mechanisms stop
being used when there is a non-tunneled path to the other end. Also, they
are not arbitrary prefixes, they are based on the 'controlled' IPv4 address.
If organizations want more absolute control over their IPv6 packet headers,
they will need to deploy a dual-stack native path first. When they really
want a single protocol routing infrastructure, DSTM makes sense. The only
time ISATAP makes sense for people with these concerns is when they want
'controlled' prefixes (see note above about control of IPv4), but don't want
to upgrade the routing infrastructure at the same time. 

Note: this is just another example where the complexity of various
requirements is outside the scope of the IETF. All of these mechanisms have
value to some environments, and will raise concerns in others. The IETF
needs to point out where the design value is, and any significant issues
when used outside the design point, and stop trying to make everyone deploy
an identical network. 

Tony 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bound, Jim
> Sent: Saturday, May 01, 2004 6:14 AM
> To: Liu Min; Pekka Savola; [email-masked]