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

[Nathan Ward <[e-mail]>]

On 10/01/2009, at 10:56 AM, Brian E Carpenter wrote:

> On 2009-01-09 17:46, Nathan Ward wrote:
>> 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.
>
> 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.

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.

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

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.

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

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