Subject: Edits to Teredo Security concerns

From: Suresh Krishnan <[email-masked]>
Date: Thu, 05 Jul 2007 14:34:41 -0400

Hi Remi/James/Christian/Jordi/Fred,
   From what I understood from your comments about the teredo security 
concerns draft, these are the issues you raised

   * Teredo should not be recommended for use in a managed network.
   Action: I will add some text to strongly caution against the use of 
Teredo in a managed network.

   * It is easy to identify and filter Teredo packets
   Action: I will replace section 3 with a simple way of identifying and 
filtering Teredo as follows
      Inbound traffic
      ===============
      src_port==3544 identifies Teredo packets

      Outbound traffic
      ================
      dest_port==3544 identifies Teredo packets

Am I missing any issues? Are the suggested actions acceptable to you? I 
will try to make these edits before the Jul 9 .

Cheers
Suresh

---

From: Jim Hoagland <[email-masked]>
Date: Thu, 05 Jul 2007 19:21:53 -0700

> filtering Teredo as follows

This would only cover 3.2 (filtering).  As this does not find content
packets (only Teredo overhead packets), this cannot cover 3.1 (inspection).

-- Jim

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 6 Jul 2007 09:13:34 +0200

On Thu, 05 Jul 2007 19:21:53 -0700, Jim Hoagland

<[email-masked]> wrote:

> On 7/5/07 11:34 AM, "Suresh Krishnan" <[email-masked]>

> wrote:

> packets (only Teredo overhead packets), this cannot cover 3.1

> (inspection).

True. But that matters only if inspection is aimed at monitoring rather

than

filtering. If port 3544 is blocked, no conforming client will ever send

outgoing or process incoming content packet.

And if that is not satisfactory, then it's all about "You cannot rely on

stateful firewalling to block tunnels", and it's not a Teredo protocol

issue.

-- 

Rémi Denis-Courmont

http://www.remlab.net/

---

From: Jim Hoagland <[email-masked]>
Date: Fri, 06 Jul 2007 09:34:34 -0700

> stateful firewalling to block tunnels", and it's not a Teredo protocol

I think perhaps I should say what the goal is with inspection:  to be able
to apply the same content inspection as is done for native IPv4 or IPv6 to
Teredo.  This content inspection could be done in a firewall, IDS, router,
etc.  Content in this case meaning the layer 3+ part of the communication
(as opposed to tunnel overhead).

This inspection requires the ability to find the content.  That is
straightforward for native IPv4 or IPv6, but is expensive to do for Teredo
tunneled content.

-- Jim

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 8 Jul 2007 12:03:34 +0300

Le vendredi 6 juillet 2007, vous avez écrit :
> I think perhaps I should say what the goal is with inspection:  to be
> able to apply the same content inspection as is done for native IPv4
> or IPv6 to Teredo.  This content inspection could be done in a
> firewall, IDS, router, etc.  Content in this case meaning the layer
> 3+ part of the communication (as opposed to tunnel overhead).
>
> straightforward for native IPv4 or IPv6, but is expensive to do for
> Teredo tunneled content.

Thanks for the clarification. I think my confusion is a testimony to the 
need to clarify the document anyway.

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Christian Huitema <[email-masked]>
Date: Sun, 8 Jul 2007 17:07:18 -0700

> Thanks for the clarification. I think my confusion is a testimony to
> the need to clarify the document anyway.

If an organization wants to provide IPv6 connectivity while monitoring the IPv6 traffic, then Teredo is definitely not the right tool. As you note, the best way to achieve that is to provide native IPv6 connectivity. If the organization's internal network cannot be upgraded to support native IPv6, then it should consider other transition technologies like ISATAP, rather than Teredo. 

-- Christian Huitema

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jul 2007 13:13:37 -0700

I have been away from e-mail for the past week, but my
initial reaction is that perhaps some of the concerns are
already address in scenario/analysis documents published
by this wg, e.g, RFCs 3750, 3904, 4057, and 4852. (Also,
RFC4864 - Local Network Protection for IPv6.) I was under
the impression that these documents already clarify use
cases and address security concerns?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Sunday, July 08, 2007 5:07 PM
> To: Rémi Denis-Courmont; JimHoagland; Suresh Krishnan; 
> [email-masked]
> Subject: RE: Edits to Teredo Security concerns
> 
> If an organization wants to provide IPv6 connectivity while 
> monitoring the IPv6 traffic, then Teredo is definitely not 
> the right tool. As you note, the best way to achieve that is 
> to provide native IPv6 connectivity. If the organization's 
> internal network cannot be upgraded to support native IPv6, 
> then it should consider other transition technologies like 
> ISATAP, rather than Teredo. 
> 
> -- Christian Huitema
> 
> 
> 
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 17 Jul 2007 21:44:07 +0300

> cases and address security concerns?

RFC4057 does not explicitly states that automatic tunneling should not 
be used. I'd say it's probably obvious to us v6ops crowd. It might not 
be obvious to every IT requirements or security manager.

Worst yet, RFC4852 reads:

   Having IPv6 applications on a Dual-IP host on a v4-only network
   requires some form of tunneling.  Where configured tunnels are not
   sufficient, a more automatic solution may be appropriate.  Available
   solutions include the Intra-Site Automatic Tunnel Addressing Protocol
   (ISATAP) [ISTP] or Teredo [TRDO] to tunnel to a v6 end service.
   ISATAP [ISTP] can be used to provide end-node IPv6 connectivity from
   nodes on an isolated IPv4 network, through the use of automatic
   tunneling of IPv6 in IPv4.  Teredo [TRDO] can be used when the
   enterprise network is behind a NAT.

and further:

   The first stage begins with an IPv4-only network and IPv4 customers.
   This is the most common case today and the natural starting point for
   the introduction of IPv6.  During this stage, the enterprise begins
   to connect individual IPv6 applications run on dual-stacked hosts
   through host-based tunneling using Tunnel Broker, ISATAP, or Teredo.
   Some early adopter networks are created for pilot studies and
   networked together through configured tunnels and 6to4.

-- 
Rémi Denis-Courmont
http://www.remlab.net/