Re: New I-D: Teredo Security Concerns Beyond What Is In RFC 4380

[Rémi Denis-Courmont <rdenis@simphalempin.com>]

Le vendredi 1 juin 2007, Jim Hoagland a écrit :
> Does the return routability check ensure that the sender listed in a
> Teredo packet is from the specified side of a network boundry?
>
> Ingress filtering can also be used to filter IPv6 addresses that are
> associated with, say, a denial of service attack.
>
> Egress filtering makes sure that (perhaps compromised) hosts inside
> your network do not pretend to be somewhere else on the Internet.  A
> gateway device would have to look inside the Teredo tunnel to do
> egress filtering for Teredo clients.

There is something terribly wrong if one tries to use Teredo in a 
typical controlled corporate network. Teredo is not an "internal" 
transition mechanism; IETF has specified ISATAP for that purpose.

Teredo is only suitable for hosts in unmanaged networks. Much of the 
concerns in your draft seems to come from a misunderstanding or a 
disagreement as to where/when Teredo is suitable.

There is something seriously wrong if a corporate network relies on a 
NAT for security purposes, precisely because Teredo or any other hole 
punching system will break it easily.

(...)
> I'm not aware of any RFC 4380 requirement that Teredo clients
> voluntarily give up their Teredo qualification when they stop being
> able to contact the server.

5.2.5.  Maintenance

   The Teredo client must ensure that the mappings that it uses remain
   valid.  It does so by checking that packets are regularly received
   from the Teredo server.

You may argue that it does not strictly require that the client stops 
the tunnel when it receives no response, but this is common sense when 
implementing any NAT traversal and hole punching mechanism. Indeed, all 
of the, err... two publicly available Teredo client implementations do 
that.

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