Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns

From: Nathan Ward <[email-masked]>
Date: Fri, 9 Jan 2009 17:46:22 +1300

On 23/10/2008, at 9:19 AM, Brian E Carpenter wrote:

> As far as I can see, there's a general problem in attempting
> to detect and block Teredo packets (I mean UDP/IPv4 packets
> in Teredo format). But it seems to me that by running an
> internal Teredo server, a site is much better placed to
> track and trace Teredo users. This is important as Teredo
> users really need to be running an IPv6-savvy host firewall.

Nope, as remote Teredo relays and hosts will send traffic directly. I  
do not believe that it is not possible to restrict Teredo to a certain  
domain.

Perhaps if the local Teredo server tells the local Teredo aware  
firewall what UDP ports on each IPv4 /32 are used for an address, then  
the firewall could inspect packets, but there are no such products  
currently.

You also have to force end hosts to use that Teredo server. It's not  
immediately clear to me how you would do that.

If you're in a position to operate a Teredo server in an end site  
organisation, you are better off doing ISATAP. That is what it is  
designed for.

>>> I agree with you that there are real threats (or will be, once
>>> there is enough deployment to make IPv6 tunnels an interesting
>>> target). It's quite appropriate to document them.
>>
>>
>> I need to preface these remarks by say that I haven't read the  
>> document
>> apart from a quick skim read, so sorry if I'm saying something that's
>> already in there, or is not relevant.
>>
>> I think it's important to distinguish between tunnels that end users'
>> systems create automatically (ala 6to4, Teredo in Vista), and tunnels
>> that end users create to work around firewalls.
>>
>> The former is easy to document solutions for, in fact, it seems to me
>> that any tunnelling protocol RFC should include details as to how a
>> network administrator can prevent these protocols passing through  
>> their
>> network. For Teredo this means blocking port 3544/3545. For 6to4 this
>> means blocking protocol 41 (preferably returning ICMPv6 messages
>> encapsulated in 6to4 so the the application is told about it..).  
>> This is
>> more about blocking things that do not work or perform poorly in a
>> certain environment, rather than trying to secure a network.
>>
>> The latter is not so easy, and I think this document should simply  
>> point
>> out that the only way to really do this is to completely control  
>> the end
>> users' machines, and not allow any third party software or  
>> configuration
>> changes. Anything else is instilling a false sense of security in the
>> minds of network administrators who perhaps are not as fluent in  
>> these
>> things as we are.
>
> Yes, but there are plenty of environments where that's impossible,
> and default deny is unacceptable because it blocks legitimate usage.
> I think the document needs to steer between the extremes, and suggest
> scenarios that are reasonably safe.

This is the security trade-off, and is up to the security people of  
each organisation I suppose. I don't think we can say what is or is  
not acceptable.

Most organisations where I have been employed have used default deny,  
and required the use of an HTTP proxy. That worked fine for 99% of  
people, and the few of us who had different requirements had special  
ethernet ports, etc.

I am very concerned about the direction we're heading in with firewall  
type stuff if we're requiring security people in organisations to  
understand (fairly) complex protocols like Teredo. I have a hard  
enough time explaining this to people who have worked in IP networking  
for a long time. An excellent example of this is Brian's comments in  
the first part of this email.

Because of this, I feel that this document should list several  
options, and state that the only way to be sure is the default deny,  
option unless you *really* understand the protocols and can prove it.

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jan 2009 10:56:19 +1300

Nathan,

On 2009-01-09 17:46, Nathan Ward wrote:
> Nope, as remote Teredo relays and hosts will send traffic directly. I do
> not believe that it is not possible to restrict Teredo to a certain domain.

No, and that's not what I meant to suggest. I meant that by operating
a local Teredo server, the local management can find out who is actively
using Teredo and ensure that they are adequately protected at the host
level. It certainly isn't reasonable to expect a site firewall to be
doing the necessary deep packet inspection.

> 
> Perhaps if the local Teredo server tells the local Teredo aware firewall
> what UDP ports on each IPv4 /32 are used for an address, then the
> firewall could inspect packets, but there are no such products currently.
> 

Quoting you out of context:

"  Alternatively, a network may force customers to use its Teredo
   servers by 'spoofing' DNS names or IPv4 addresses. "

Were you planning to follow up on draft-nward-v6ops-teredo-server-selection-00?

> organisation, you are better off doing ISATAP. That is what it is

Yes, but my concern was more about users who are spontaneously using
Teredo. The above type of spoofing is a way to find them,
however unpleasant it may be.

>>> I need to preface these remarks by say that I haven't read the document
>>> network administrator can prevent these protocols passing through their
>>> encapsulated in 6to4 so the the application is told about it..). This is
>>> The latter is not so easy, and I think this document should simply point
>>> out that the only way to really do this is to completely control the end
>>> users' machines, and not allow any third party software or configuration
>>> minds of network administrators who perhaps are not as fluent in these
>>> things as we are.
>>
> This is the security trade-off, and is up to the security people of each
> organisation I suppose. I don't think we can say what is or is not
> acceptable.
> 
> understand (fairly) complex protocols like Teredo. I have a hard enough
> time explaining this to people who have worked in IP networking for a
> long time. An excellent example of this is Brian's comments in the first
> part of this email.
> 
> Because of this, I feel that this document should list several options,
> and state that the only way to be sure is the default deny, option
> unless you *really* understand the protocols and can prove it.

That seems very reasonable, and I would prefer it to what looks
like firm recommmendations right now.

    Brian

---

From: Nathan Ward <[email-masked]>
Date: Sat, 10 Jan 2009 11:43:57 +1300

> doing the necessary deep packet inspection.

Seems feasible. The Teredo server could do some sort of look-up before  
responding. If they do not respond the interface will not come up.

>> firewall

Yes. I am at this minute looking at flights to SFO for IETF74, and if  
that is financially do-able then I'll update it and present it there.

Few people seemed to be interested when I explained electronically, in  
person has worked better with various people since then, so in person  
will do well I'm sure.

> however unpleasant it may be.

If they are spontaneously using Teredo (I assume by spontaneously, you  
mean automatically ala Vista etc. ?) then they are going to try ISATAP  
first. As ISATAP gives you unencapsulated traffic on your border  
router (or between your border and ISATAP routers if they are  
separate, etc. etc.) this seems like a better option, to me.

I suppose this depends whether you want to control security at the  
border, or at the host.

Hmm, it's probably worth noting that I'm talking about Windows hosts  
here. Linux hosts with a Teredo stack installed will not try ISATAP  
first.

Of course, if the local management have sufficient access to the host  
to secure it (as you suggest in the first part of the email), they  
have sufficient access to simply disable Teredo - either by having the  
host part of a Windows domain, or by pushing the right bits in to the  
registry. This seems to me to be a superior strategy.

--
Nathan Ward

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Jan 2009 15:08:49 -0800

>here. Linux hosts with a Teredo stack installed will not try ISATAP

I may be able to help with that. Tell me what behavior
you want out of ISATAP on linux, and I'll code it...

Fred
[email-masked]

---

From: Nathan Ward <[email-masked]>
Date: Sun, 11 Jan 2009 18:13:02 +1300

> you want out of ISATAP on linux, and I'll code it...

Support in major distributions seems like a good first step. I note  
that your code is now in 2.6.mumble though, that's a positive step.

While we're here, OS X and BSD support would be nice too.

There seems to be a bit of a lack of coherent vision for IPv6 support  
in OSes other than Windows. There are components - ie. 6to4, Teredo  
and ISATAP code - however there doesn't seem to be anything to relate  
them to one another so that 'end users' without a bunch of knowledge  
can use this stuff. A good first step would be to install+configure  
all three together as part of the "Enable IPv6" option. Along with  
that, take a DHCPv6 client, etc. etc.
"Enable IPv6" in most OSes means do stateless autoconfig for native  
IPv6, and that's it.

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jan 2009 09:35:11 +1300

On 2009-01-11 18:13, Nathan Ward wrote:
> Support in major distributions seems like a good first step. I note that
> your code is now in 2.6.mumble though, that's a positive step.
> 
> There seems to be a bit of a lack of coherent vision for IPv6 support in
> OSes other than Windows. There are components - ie. 6to4, Teredo and
> ISATAP code - however there doesn't seem to be anything to relate them
> to one another so that 'end users' without a bunch of knowledge can use
> this stuff. A good first step would be to install+configure all three
> together as part of the "Enable IPv6" option. Along with that, take a
> DHCPv6 client, etc. etc.

Because that was the ~1996 vision, and the current vision hasn't really
been articulated clearly (RFC4294 is really just a laundry list).
Kudos to Microsoft, but perhaps the IETF needs to write down what's
needed.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Jan 2009 14:09:38 -0800

Nathan,

>-----Original Message-----
>From: Nathan Ward [mailto:[email-masked]]
>Sent: Saturday, January 10, 2009 9:13 PM
>To: Templin, Fred L
>Cc: Brian E Carpenter; Suresh Krishnan; Christian Huitema; Kurt
Zeilenga; Pasi Eronen; Tim Polk;
>[email-masked]; [email-masked]; Dave Thaler;
[email-masked]
>Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns
>

I'll check and see if there is still a FBSD port. If not,
and if someone wants to port the linux implementation, that
would be fine with me. Otherwise, I'll put it on my todo list.

Thanks - Fred