Subject: Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd)

From: Jeroen Massar <[email-masked]>
Date: Tue, 01 Mar 2005 09:23:15 +0100

On Mon, 2005-02-28 at 16:14 -0800, Alain Durand wrote:

>It is still not clear to me if that box need to be fully automatically 
>configured and why good old manual configuration of a DNS name pointing
>to the ISP TEP is not enough.

Indeed, just reconfigure tsp.conf and you are done, this can of course
be done using a nice GUI too to make it easier. The problem according to
some is 'how do we tell the user where IPv6 is' because "they do not
know where".

IMHO users who want it will find it, for the rest there is no need.
Simple example: the users who needed KaZaA (or what are the caps) and
Skype and all those other nice tools found them, so why can't they
according to some find the tool to get them IPv6 connectivity?
They apparently do want to make yet another tool that will suddenly?
appear in all OS's or something? Now I can't see the memberlist of v6tc,
but how many OS vendors are on the list ?

The funnier part comes in the fact that some people want 'security'.
They believe that NAT is 'secure', because it sort of blocks incoming
connections. When a automatic tunneling thing sets up a tunnel, all the
boxes on the internal network are suddenly wide open... hackers heaven?
Partially a good thing that you need to get access to at least one box
first and you need to find that IP then, but if you have one, you have
the rest...

Fun anecdote, the creators of the PIX still have not released a
production IPv6 firewalling version, thus for most companies there is no
firewall and thus there can't be IPv6.

Greets,
 Jeroen

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 1 Mar 2005 14:14:05 +0100

On 2005-02-28, at 17.10, Jeroen Massar wrote:

>
> There is quite a funny problem here ;)
>
> The TEP server gets automatically discovered, thus everybody who 
> deploys
> one would need to have the same cert, otherwise the client can't verify
> it being the 'correct' TEP. But with everybody having the cert,
> everybody can setup a bogus one...
>
> Maybe we should have shim6 finished before this ? Then one could use 
> the
> identifier as the verification mechanism...

...or use a DNSSEC signed reverse-zone...which is already here.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 1 Mar 2005 20:21:50 +0100

On 2005-02-28, at 20.19, Pekka Savola wrote:

> On Mon, 28 Feb 2005, Jeroen Massar wrote:
>> On Mon, 2005-02-28 at 16:21 +0100, Kurt Erik Lindqvist wrote:
>>> My concern is that you still have no idea if you are talking to the 
>>> TSP
>>> server you think you are talking to.
>>
> This issue is somewhat offtopic from _discovery_, but was mentioned 
> briefly earlier under "mutual authentication", without much 
> discussion.

Well, the problem as I see it, is that if you break the trust of the 
discovery you have also broken the trust of the forwarding chain. As 
Jeroen pointed out, you don't know you are forwarding to as you can 
have a certificate (or hash or token or whatever) before hand. The only 
trust you _can_ have is in the discovery.

> One can indeed raise a question how strongly the server should 
> authenticate the client, and how strongly the client should 
> authenticate the server.

If I trust my provider with my packets, I am doing fine until evil-Eve 
comes along and injects a route for the well-known anycast prefix into 
my ISP. evil-Eve then tells me that the tunnel end-point is a 
tunnel-proxy that she is running. She then sniffs all traffic, that 
still makes it to the destination, but with Eve having access to it.

> There can be a number of authentication methods in the _configuration 
> protocol_ (and not necessarily the endpoint discovery), but a major 
> question is how many roundtrips the clients want to waste in the 
> authentication.  At least in some scenarios, doing this may not be all 
> that interesting.

Problem is that you will not beforehand know what/who to authenticate.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 1 Mar 2005 20:23:05 +0100

On 2005-03-01, at 01.14, Alain Durand wrote:
> On Feb 27, 2005, at 9:44 AM, Kurt Erik Lindqvist wrote:
>>
>> We will need code deployed for any solution anyway. So we are now
>> debating if it is more likely users upgrade their Windows boxes or
>> their DSL routers. And we all know the majority updates neither, so
>> then let's stick to manual configuration :-)
>
> The scenario here is a customer, behind a v4 NAT that will not be 
> upgraded,
> add a $10 additional box to his home network. That box dig the tunnel
> to the ISP using TEPD and then advertise locally an IPv6 global prefix
> so all the other devices in the home get connectivity.

That the NAT box is v4 is clear. That it won't be upgraded is less 
clear to me. I think that is a requirement. But that is just me.

> configured
> and why good old manual configuration of a DNS name pointing to the 
> ISP TEP
> is not enough.

Maybe it would be..

- - kurtis -

---

From: Alain Durand <[email-masked]>
Date: Tue, 1 Mar 2005 11:54:28 -0800

> clear to me. I think that is a requirement. But that is just me.

Life would be simpler if the v4 NAT was upgraded. Fact of life is that 
I may,
or may not.

We can very well build tons of products that have this 
tunneling/NAT-traversal
additional functionality build in, and one of them will be activated in 
home/soho network.
This could be implemented into wireless bridges, VCR, PCs,.... anywhere 
even NAT boxes!

This way, we de-couple the problem of getting IPv6 into the home 
network from
the one of upgrading the NAT box.

	- Alain.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 1 Mar 2005 21:45:14 +0100

Alain,

> Life would be simpler if the v4 NAT was upgraded. Fact of life is that 

I understand that. But we are implicitly assuming that users will be 
more willing to upgrade their PC OS than their DSL-router OS. That 
might be true, or it might not. I have no idea.

But I can see advantages with both.

> additional functionality build in, and one of them will be activated 
> in home/soho network.
> This could be implemented into wireless bridges, VCR, PCs,.... 
> anywhere even NAT boxes!
>

Would that be a bad thing per se? Note that you are actually also 
de-coupling ISP IPv6 deployment at edge from consumer deployment 
(need). Which I thought was the most important issue...

- - kurtis -

---

From: Alain Durand <[email-masked]>
Date: Tue, 1 Mar 2005 13:21:19 -0800

Kurt,

I heard you saying: customer may be willing to upgrade their NAT box.
This made me re-think about a recent experience:

I went on a extended journey over Christmas and i visited many people 
in a couple countries,
some who already had DSL installed and others I helped installing it. 
Some observations:

	- many home customers right now just have 1 PC connected with PPPoE
	- this is changing with Wifi, and all the new installs I did was with 
a Wifi/NAT/Router box
	- those boxes are still expensive in Europe, about 150 euros. In the 
US, I was able
	  to find several for about $40. Do not know about other countries.

Before that trip, when I was looking at my own wifi set-up I build 5 
years ago
(it was expensive back then), I was thinking that upgrading all this 
would be prohibitively
expensive. Now, looking at the new integrated router/NAT/wifi going for 
$40,
this cost argument may no longer be valid... However, there might still 
be tons
of non financial reasons why this upgrade may or may not be possible.

So maybe we need to revisit the the assumption on the (un)upgradability 
of the NAT box after all...
A good topic for the Bof!

Btw, this does not change the main rationale for TC, that is, 
decoupling the upgrade
of the ISP core from the one of the access network.

	- Alain.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 1 Mar 2005 22:26:09 +0100

Alain,

On 2005-03-01, at 22.21, Alain Durand wrote:
> expensive. Now, looking at the new integrated router/NAT/wifi going 
> for $40,
> this cost argument may no longer be valid... However, there might 
> still be tons

I read this as if you are thinking of hardware upgrades. I was thinking 
firmeware upgrades.

> So maybe we need to revisit the the assumption on the 
> (un)upgradability of the NAT box after all...

Indeed!

> of the ISP core from the one of the access network.

Agreed.

- - kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Mar 2005 08:44:59 +0200 (EET)

> I read this as if you are thinking of hardware upgrades. I was thinking

Do you get firmware upgrades to those cheap-o DSL routers etc?

Do the users have any idea how to install them?

>> (un)upgradability of the NAT box after all...

My point is that the users are going to have to have a recent host OS 
in any case (to support IPv6, and to support the tunnel configuration 
protocol).  We assume that most of the users already _have_ a recent 
OS (and only need to get the tunnel configuration piece, if even 
that).  We cannot assume that the users have a v6-capable DSL, 
because, well.. those don't really exist in the mass market, and the 
users wouldn't want to pay 100$-50$ for the upgrade just to get v6.

But this can indeed be discussed at the BOF.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 2 Mar 2005 09:01:36 +0100

> Do you get firmware upgrades to those cheap-o DSL routers etc?

At least to the ones I have seen.

> Do the users have any idea how to install them?

Do users upgrade and patch their Windows XPs? How many bots did you 
kill in your network today?

> users wouldn't want to pay 100$-50$ for the upgrade just to get v6.

We can't assume that this tunnelling mechanism will just magically 
appear at the users end. It will have to get there, which means 
upgrading something somehow.

> But this can indeed be discussed at the BOF.

Ok.

- - kurtis -

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Wed, 02 Mar 2005 10:15:59 +0200

Everybody,

On Wed, 2005-03-02 at 10:01, ext Kurt Erik Lindqvist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

The problem is that not everybody can upgrade their DSL boxes. Some
cannot update it because of limited skills (e.g. my parents) and others
are not allowed to upgrade it (e.g. me). The box is owned by the
operator and I don't even have the setup password for it! 

> kill in your network today?

This is because the updates come automatically and the little window on
the screen says that bad things will happen to you if you don't update
your software...

> upgrading something somehow.

I think both models should be supported: in the NAT-box as a firmware or
hardware upgrade, and as software update directly to the host. 

> > But this can indeed be discussed at the BOF.

Certainly...

Cheers,

Jonne.
> 
> - - kurtis -
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
> 
> iQA/AwUBQiVy6aarNKXTPFCVEQKJFgCgki2o/rgpvGTMm7t1XqA77VEA/ggAnRdb
> HN/u+El96a3rlUG7i+PN1Iwg
> =GbuT
> -----END PGP SIGNATURE-----
> 
> 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Wed, 2 Mar 2005 09:41:54 +0100

----- Original Message ----- 
From: "Kurt Erik Lindqvist" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 02, 2005 9:01 AM
Subject: [v6tc] Re: About the (un)upgradability of the NAT box

>> Do the users have any idea how to install them?

I guess that a firmware upgrade requires more insight that upgrading my Windows XP, so only a minimal part of the portion of users that are able to upgrade their operating system will be able to upgrade their CPE firmware.

> upgrading something somehow.

Maybe it's more realistic to think that new OS/CPEs could have implemented the mechanism ready to be used by end users. Obviously, expert users should have the chance of upgrading their CPE firmware with the mechanims but I guess that it would be done only by a minimal part of users, as I said before.

Regards
Miguel

> -----END PGP SIGNATURE-----

************************************
Barcelona 2005 Global IPv6 Summit
Call for Papers and information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Wed, 2 Mar 2005 09:40:29 +0100

----- Original Message ----- 
From: "Kurt Erik Lindqvist" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 01, 2005 8:21 PM
Subject: Re: server authentication? [Re: [v6tc] I-DACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd)]

> trust you _can_ have is in the discovery.

AFAIK the mutual authentication pointed out requires that the client is authenticated by the TEP and the TEP is authenticated by the client. If the client is forwarded to a maliciosous TEP, the tunnel won't be configured because the TEP won't be authenticated by the client. In this way the security on the communications isn't threatened due to the lack of security on the discovery process

> still makes it to the destination, but with Eve having access to it.

We assume that ISPs are able to manage their own networks ;-) It's not easy that evil-Eve can injects a bad anycast route into the ISP network, but even if that happens we should assume that ISPs can detect that and filter such bad routes somehow. 

Regards
Miguel

> iQA/AwUBQiTA06arNKXTPFCVEQLUcgCg1w4X3Frhgg9b3XcMCU/itLqlXksAoMn9
> PnUAKAvk9lI+t0CjOnZcdtmc
> =OsCK

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 02 Mar 2005 10:09:35 +0100

[Pekka, see my comments on the TB doability at the bottom]

>At least to the ones I have seen.

Most I have seen are indeed upgradeable. Many actually advertise with
it. The question is more though if a vendor is willing to add IPv6
support to them. It would be great btw :)

The above is one of the many reasons why I put AICCU under a BSD-style
license. Only change in it is that I would like to know if people use
it, for the rest they can put it in their products.

The TSP code is afaik GPL, so in some companies that might stop them
from using it, as that would require them to open up their boxes.

>kill in your network today?

They have to basically otherwise stuff like MSN Messenger simply does
not boot anymore. MS is also opening up the SP2 upgrade, even for
illegal users of their products. Legal/paying users of their product get
the upgrades already of course. I more saw a tendency of companies not
upgrading to SP2 because they had a number of broken software
applications in use ;)

>upgrading something somehow.

That is why having a lot of variety is also sort of good sometimes.

The sole thing that the IETF should try to accomplish is the following:

Make standards for:
 1) Discovery
     Determining the local IPv6 Tunneling Mechanism to be used
 2) Tunnel Configuration
     Configuring the tunnel
 3) Tunnel Protocol
     The actual protocol for transmitting the data

For 1. most likely is that anycast is the way to go, I myself prefer the
use of a .service alike DNS domain for doing these kind of things.

For 2 and 3. there are already several methods that can be used, amongst
which TSP + IPv6UDP and TIC + AYIYA, tinc/OpenVPN/PPTP based solutions
and most likely a number of others.

The problem here is though, if you require authentication a user has to
enter details already. In that case the ISP could supply them.

Security wise we should never forget that we might be opening up a box
to be most likely unfirewalled, or better said, opening up the services
on the box and allowing the world to access them...

In the above respects, most likely the easiest solution for this is
having a discovery mechanism that looks up a URL and points the user to
the service page of that ISP.

I know of two fairly large ISP's who have that already:
http://www.xs4all.nl/uk/allediensten/experimenteel/ipv6.php
http://www.surfnet.nl/info/en/services/experimental/tunnels/tunnelbroker.jsp

Even though people have argued that "Tunnel Brokers won't scale", if you
want something to scale it will have to have many deployments and those
deployments will not be done for another ISP if it costs your ISP a lot
of money in supporting them. Setting up a Tunnel Broker with a "farm" of
Tunnel Servers thus is not such a bad idea, one only has to point it's
users to the main tunnel broker address, most likely TSP or TIC and
those protocols then can assign the user with the proper addresses.
But... that is my view on the thing ;)

[Towards Pekka and maybe other interrested parties, ignore if you don't
like to read a semi-offtopic topic and maybe, for some semi-advert talk,
that is why it is at the bottom]

Pekka Savola wrote:

> > One does not have a SLA as one does not pay, if people pay, they get a
> > SLA. Which is why not all the POPs are 'public' and open for everybody.
> > Though that SLA lies at the ISP providing the PoP.
> But in your model, the non-public ISPs will also have to depend on
> _your_ service, even if they don't pay anything for it? If _your_
> server would be down, the ISP's business would be disrupted. Correct?

Only new signups and config changes won't work, the rest, thus
heartbeats etc, keeps on running perfectly as has been demonstrated a
couple of times already due to some nice people thinking that it is nice
to DDoS servers... :(

> This would be simply an unacceptable operational and administrative
> model for _real_ use. I hope you can see that.

I am not saying that everybody should join for instance our main box,
but having a local installment of the SixXS software, which is what we
offer, if the ISP wants that, works fully well. That at the moment this
still scales very well and that we have not got a need for multiple
central boxes doesn't mean this is not possible, it actually was one of
the many reasons why we redid the complete codebase 
The code is not available to everybody, but if you are a 'real' ISP it
sure is and of course for free. Why not open? -> To avoid the growth of
suddenly a large number of "ISP"'s who will not properly handle abuse,
and thus give IPv6 a bad name. Most people only use it for IRC anyway
and there is enough badness coming with that already.

Due note that for instance XS4ALL runs a, by now most likely quite
heavily modified, version of the our former IPng software. They have
been providing IPv6 to their customers using the tunnelbroker model and
their users are very happy with it, even though it is just experimental
as you can see from the URL above. Similar installations can be made
using the above setup. Do note that there is at least one company
selling these solutions and according to their marketing campaign they
are doing quite good in it, which is great for them ;)

Still such a setup would be easier if there is a discovery procedure or
a open well defined standard for doing it. Organizations providing these
solutions can then conform to it and the world can pick what to use,
switch easily etc. And afaik that is sort of what the IETF and open
standards are about, freedom of choice ;)

I really can't care if somebody sells such a solution, earns a lot of
money of off it or whatever they do, as long as they do it correctly,
provide quality and keep it in control, certainly on points of abuse.

Greets,
 Jeroen

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 2 Mar 2005 10:55:16 +0100

On 2005-03-02, at 09.40, Miguel Angel Diaz wrote:

> AFAIK the mutual authentication pointed out requires that the client 
> is authenticated by the TEP and the TEP is authenticated by the 
> client. If the client is forwarded to a maliciosous TEP, the tunnel 
> won't be configured because the TEP won't be authenticated by the 
> client. In this way the security on the communications isn't 
> threatened due to the lack of security on the discovery process

But how can the client authenticate the TEP? And the other way around? 
Either the client blindly trust the TEPD or it must have a pre-shared 
secret. If have a pre-shared secret, we might as well have static 
configuration. For trusting TEPD I am arguing that anycast is to weak 
to be used.

> We assume that ISPs are able to manage their own networks ;-) It's not 
> easy that evil-Eve can injects a bad anycast route into the ISP 
> network, but even if that happens we should assume that ISPs can 
> detect that and filter such bad routes somehow.

I think it's a lot easier to inject false routes than you think...

But let's leave this for the BOF...

- - kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Mar 2005 12:29:36 +0200 (EET)

> configuration. For trusting TEPD I am arguing that anycast is to weak

E.g., SEND does allow this.  If the Tunnel server would advertise 
2001:db1:1::/48, the node could check that the tunnel server has a 
certificate for advertising 2001:db1:1::/48.  This does not require 
pre-shared secrets.

There are probably other models as well.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 02 Mar 2005 11:40:06 +0100

>certificate for advertising 2001:db1:1::/48.  This does not require 

With certs it could work sort of indeed.

But I thought one of the main things that was suggested was to 'minimize
the number of packets' being send to communicate.

page 6/7 of the palet-v6ops-tun-auto-disc-03 draft:

8<-------------------------
The advantages of the anycast approach are:
<SNIP>
The drawbacks are:
   o  The failure modes are a bit more complex than, e.g., just looking
      up a domain name, as one will have to send 1-2 packets to the
      anycast address to see if a working tunnel server is found or not.
------------------------->8

Thus many packets is apparently a 'drawback'. Just if DNS does not
require a lot of packets.

Also the certs for 2001:db8:1::/48 could also be added to a DNSSEC'd
reverse for that zone and managed. This works for the 6to4 anycast
routes etc... (Why again didn't cooperation, eg tunnelbrokers, work?
there are a number of examples that seem to work quite well already...)

Greets,
 Jeroen

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 2 Mar 2005 11:46:26 +0100

> There are probably other models as well.

I am missing how this would work with anycasting but let's do that over 
a beer and a notepad in Minneapolis then...

- - kurtis -