[v6ops] Missing features of Tunnel Brokers (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs)

[Jeroen Massar <[e-mail]>]

Setting Subject so that people know that this is clearly not about the
draft anymore and that subject can then be closed.

On 2014-11-14 00:03, Alexandru Petrescu wrote:
> Le 13/11/2014 23:46, Jeroen Massar a écrit :
>> [Replies to multiple mails in this thread compressed into one]
>>
>> On 2014-11-13 23:17, Alexandru Petrescu wrote: [..]
>>>>> Do not deprecate until you offer a solution satisfying a
>>>>> number of requirements (currently unsatisfied by eg tunnel
>>>>> brokers).
>>>>
>>>> Which requirements are these?
>>>
>>> Ones one would have to lay down and agree on before engaging in
>>> new work.
>>>
>>> For example -1- must allow for reverse DNS ok,
>>
>> That is a business decision. Most (all?) TBs provide this.
>>
>> Note that a normal ISP does not do this, hence bit silly to require
>> it for a free tunnel...
> 
> Home ISP may not do it, but business ISP does.

Then consider Tunnel Brokers Business ISPs :)

>>> -2- must be secureable by existing e2e IPsec,
>>
>> The tunnel or the packets that flow within it? What is the problem
>> you are trying to solve?
> 
> I need to trust enough the other endpoint, not send something in the wild.

The whole point of the Tunnel Broker model is that there is a fixed IP
and thus likely a stable path to send packets to and get them back from...

>> The packets in the tunnel are 1280+ hence, go IPSec away as much as
>> you want.
>>
>> For securing the tunnel it would require distributing keying
>> material.
>>
>> As IPsec is horrible to configure and does not work through NATs
>> happily (yes, you can patch crap) nobody ever bothered with this.
>>
>> For AYIYA packets are signed btw, hence, no spoofing of those. There
>> is no crypto though there either.
> 
> The questions I have about these are numerous but mostly administrative
> as such are hard to formulate here in a public forum.  It has to do with
> what kind of business is it, etc.

[e-mail] or [e-mail] are there to answer such questions ;)



>>> -3- to the extent of possible be easy to set up for Clients
>>
>> TSP (gogoclient) and TIC (AICCU) solve that problem. CPEs incorporate
>> these tools or have their own implementations (eg Fritz!Box).
>>
>> How much 'easier' do you want it?
> 
> Easy in the sense of as easy as opening a Google account.

I am not sure about HE, but for SixXS you don't have to fill in some
extremely unreadable recaptcha thing.

Hence that makes it for those EASIER than opening a Google account.


>>> and not involve intervention of another party (like when
>>> requesting an IPv6 address from an administrator, delayed paper
>>> forms, etc).
>>
>> Gogo's "anonymous" TSP tunnels do this. They get a lot of abuse.
> 
> For example, do they spy on you?

You might want to define "spy". You will never know what the three
letter agencies of the world do with data flowing around the world.

My advise always: use SSL, or develop your own crypto and stuff packets
in that.

A tunnel does not restrict you from any of that.


>> Other Tunnel Brokers and Gogo TSP in "authenticated" mode require
>> that one signs up, just as you would with a IPv4 ISP.
> 
> For example, what kind of private data should I share with them?

At most the same as you would signup to a normal ISP:
 Your valid contact details (name, address, phone)

At minimum a random username.


>> This is a "business" decision though. Nothing a technical thing can
>> solve.
> 
> There is no such aspect in 6to4...

Yes there is. As the providers running the relays can and will shut them
down. That would also be a business decision.

History has shown that this already happened when Hetzner allowed a
customer of theirs to send spoofed 6to4 packets (src-ipv4 their IP,
dst-ipv4 the 6to4-anycast-addr, src-IPv6 spoofed, dst-IPv6 some target).
That caused quite a few 6to4 relays to shut them down as they did not
want to carry that crap traffic.


>>> From another mail:
>>
>>> For example, the current tunnel brokers are very good but (1) are
>>> not trustful,
>>
>> What do you mean with "trustful"?
> 
> HArd to say, who do _you_ trust?

Nobody? :)


> Trustful in the sense of accountable.  I dont want them to spy my
> traffic, at least.  I want them to anwser questions when asked.

You will never know if somebody is snooping along with your data.

I can state though that SixXS does not peek along, unless we need to
debug or there is some weird traffic pattern etc.

I have no idea if the ISP providing the PoP peeks, or if some national
agency is doing so though on the fiber level or just tapping away.


As you love 6to4: as your packets go to an anycast you don't even know
which path they will take the next moment... note that the 'anycast' is
in four directions: IPv4 you->6to4-anycast, IPv6 6to4-anycast -> dest,
IPv6 dest -> 6to4-anycast (could be different from original), IPv4
6to4->anycast to you.

Hence, on the return path you won't even see it anyway...

If you are paranoid about this: use Tor.

Though that might not solve those problems either.

There are lots of VPN providers you can pay for a service that might
help you though.

This will never be something that anybody will vouch for though.
(At least, I cannot vouch for it because I don't control all the factors)

>>> (2) force into later efforts to renumber when going native,
>>
>> Changing ISPs typically require that.
> 
> Whereas we can require the destinationISP to set up routing such that I
> keep the same prefix I got from the first.  Or update other databases.

That does not scale.

Please check the GROW WG for more details.

>> Only way to avoid that is to get your own PI space.
> 
> Another administrative effort?

Only once.

It seems you want for free what lots of people just do...

>> At that point you will be able to arrange your own connectivity too
>> though.
> 
> Only to those ISPs who accept it?

Everybody you pay transit (or buy a crate of beer & a sack of onions ;)

These are not technical requirements, but business (read: money/policy)
problems.

>>> (3) require filling in forms.  6to4 has the advantage of not
>>> requiring 3.
>>
>> And 6to4 is unreliable as no ISP can 100% support it.
> 
> Its mostly a matter of 6to4 Relays uptime and IP routing finding right
> paths.  Up to now I didnt experience 6to4 Relay not responding.

Then you where lucky.

>> With Tunnel Brokers you are signing up for a service. Signing up
>> requires forms.
> 
> Are the Tunnel Brokers ready to fill in forms that I request conceive?

I really do not understand that sentence, please rephrase.

>> Though those forms are there primarily to limit abuse too and to
>> enable contacting people when they problems with their tunnel so
>> that it can be resolved.
> 
> What about the potential abuse from the Tunnel Brokers?

What kind of abuse would the Tunnel Broker cause?

Unless you mean the users. That is simple: depending on the problem
report to authorities and the IPv4 ISP, or just close their account.

>> And another mail:
>>> 6to4 is not alowing for reverse DNS either, if I am not terribly
>>> wrong.
>>
>> https://6to4.nro.net
> 
> Thanks, I didnt know that.

"There is a RFC for that": http://www.ietf.org/rfc/rfc5158.txt

> Does it require filling in forms for each IP address?  I am easier at
> vi-ing a config file in my local DNS and then DNS takes care of rest.

Afaik it goes per /48. Hence once per IPv4 address you'll have to fill
something in.


I have never bothered with 6to4 as configured tunnels simply work and do
not have any unreliable properties.

Oh another trip own memory lane: in something like 1997 I had a address
our of 5f04:b000::/32 (rfc1897) thank you Surfnet (Wim Biemolt in
particular) for that tunnel. Thus no, I did not always control the tunnel :)

Greets,
 Jeroen