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

[Brian E Carpenter <[e-mail]>]

Nathan,

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.

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

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

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

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

    Brian