[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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