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

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2005 10:22:43 +0200 (EET)

Folks --

There has been no discussion on this.  Please send your comments on 
it.

On Mon, 24 Jan 2005, Pekka Savola wrote:
> The analysis/conclusions document on tunnel end-point discovery has been 
> re-focused and summarized to try to capture the critical discussions better.
>
> It would be extremely useful if folks, especially those ones which have not 
> participated in the discussions before, would take a look and send comments 
> on the list.  The document should reflect most of the discussion on discovery 
> that have taken place both on- and off-list.
>
> ---------- Forwarded message ----------
> Date: Mon, 24 Jan 2005 15:39:12 -0500
> From: [email-masked]
> To: [email-masked]
> Subject: I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Analysis of IPv6 Tunnel End-point Discovery 
> Mechanisms
> 	Author(s)	: J. Palet, et al.
> 	Filename	: draft-palet-v6ops-tun-auto-disc-03.txt
> 	Pages		: 17
> 	Date		: 2005-1-24
>
> To be able to automate setting up IPv6-in-IPv4 tunnels, it is
>   important to be able to automatically determine the tunnel end-point
>   for the tunneling mechanism.  This memo presents a short analysis and
>   conclusions on the different approaches for discovering the IPv6
>   tunnel endpoint on a node.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the 
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-palet-v6ops-tun-auto-disc-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-palet-v6ops-tun-auto-disc-03.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> v6tc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/v6tc
>

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

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

---

From: Alain Durand <[email-masked]>
Date: Wed, 09 Feb 2005 08:39:50 -0800

On Feb 9, 2005, at 12:22 AM, Pekka Savola wrote:

> Folks --
>
> There has been no discussion on this.  Please send your comments on it.
>

Ok, to get the ball rolling

Section 1.1.
I think the justification why we even need an automatic discovery 
mechanism
is very weak. If no one can come with a better justification, it will 
be hard to justify
working on this.

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 25 Feb 2005 21:47:27 +0100

>There has been no discussion on this.  Please send your comments on 

I'd suggest you remove "Appendix B.  Centralized Broker-based Solutions"
completely, because that basically says that a setup like SixXS could
not exist ("A global centralized broker is completely unfeasible.")

I guess we've proven quite well that it works perfectly fine...

And as it (trying to throw out of the window solutions that already
work) is totally unrelated to the subject there really is no need to
have it in there anyway.

Btw, I'd like to again hint the authors of the document to well known
and two tools used on the large scale: TSP & AICCU.

Then some other nits:

page 6:
8<--------
   The drawbacks are:

   o  Setting up an internal anycast route advertisement (e.g., in an
      enterprise) is likely a little bit more difficult than adding a
      name in the DNS or configuring DHCP.
-------->8

If someone can't administer a network, they can't, that is logical.
But that does not make it a drawback

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

Ever ran a 'dig +trace <hostname>' ? Gee, how many packets are that?
And remember that there are a lot of DNS servers, especially root and
cctld that are anycasted already, now that leaves to wonder why the
above is named as a drawback. See also Randy Bush's recent very early
results on his anycast data gathering experiment.

Why doesn't the DNS section have a 'advantages/drawbacks' section?
Drawbacks:
 - see anycast, as it uses anycast with most DNS servers
 - Unpredictable that the ISP is able to configure it (same silly thing as with the anycast one :)

"3.4  PPP-based Solutions", I hope you do realize that many DSL
providers already offer this solution to their paying customers?
In general the client will make two PPP sessions: one for IPv4, the
other for IPv6. And this works(tm).

8<--------
SLP has a number of drawbacks:
*  SLP is not really widely implemented or deployed.
--------->8

Please speak to Novell and quite a number of other users of this very nice protocol.
Ever used a storage tank ? :)

"Centralized brokers are a non-starter."..... see my note above.
Also, as it is moved by to the Appendix it would need at least a reference if you
want to keep it in.

Nevertheless Anycast is a clear winner, but I guess everybody already figured that out
even before somebody started putting his name in the above draft.
You might have simply copied the text from the 6to4 anycast RFC...

The security section should simply include the well known items:
 - networks are insecure
 - do ingress filtering
 - use SSL/TLS where possible

"This work has been partially funded by the European Commission under the Euro6IX project."
There went my tax money....

Appendix A:
8<-----------
   a.  A new server starts advertising the address but is refusing to
       serve the users: established tunnels continue to work, new
       tunnels cannot be established; tracerouting to the server
       identifies where the culprit is.
---------->8
Any broken setup of course breaks it.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Feb 2005 08:28:09 +0200 (EET)

Thanks for comments -- inline...

> I guess we've proven quite well that it works perfectly fine...

What works for a thousand users, informally, without any(?) service 
agreements with the main broker and PoPs does not scale up for 
hundreds of thousands of users and real usage throughout the Internet.

It's just simply operationally and administratively unfeasible to 
consider there to be a single broker like tunnel-broker.net in the 
Internet to which _all_ the users would be directed to (owned and 
managed by someone).  Nobody would want to create a serious business 
dependency on the continuity and correctness of such service.

Do you agree with this?

The draft is not saying that sixxs.net does not work.  It's just 
saying that that model cannot be scaled up for the whole Internet and 
as such is not an interesting way to discover the broker at the local 
ISP.

> and two tools used on the large scale: TSP & AICCU.

At least TSP is compatible with this model.  The point just is, how do 
you automatically discover the TSP broker?

> page 6:

I personally agree with this -- as a routing operator, I don't see 
this as an issue, but some others do..

Regular users who need to do debugging over the phone (who hardly know 
how to start a command prompt in their Windows) with their ISP don't 
:).  They can, at the advise of the helpdesk, run 'nslookup', plus 
'ping' and 'traceroute' if their firewalls don't block them.

But personally, again, I agree with you.  For expert users, this isn't 
all that difficult to debug at all.

Maybe these drawbacks need to be put in a better perspective of the 
novice usage.

> - Unpredictable that the ISP is able to configure it (same silly thing as with the anycast one :)

Because the drawbacks and advantages are listed under the subsections 
for two different DNS approaches.  If some advantages or drawbacks 
would be generic for both of them, they could be put under 3.2.

I'm not sure how relevant the anycast use with DNS is in this context. 
(The failure model with anycast DNS root and anycast, initial 
handshake TEP is a little bit different -- anycast DNS root has about 
10 alternatives if one fails, this has none.)

> other for IPv6. And this works(tm).

Sure, but as said, PPP is far from common denominator in configuring 
IPv4 connectivity, even if we could add options there (which we might 
not be able to do).

The sentence lacks context, it should have said "deployed in ISP 
networks".

> You might have simply copied the text from the 6to4 anycast RFC...

Sometimes folks have to run a full circle to arrive at the beginning. 
At least the analysis is now somewhere :)

FWIW, I was personally convinced of search-path prefixes DNS first, 
but it seems to have more drawbacks than I thought, so the only IMHO 
option seems to be doing it with anycast, or not at all (e.g., 
manually).

By the way, the use of anycast is different from 6to4 anycast RFC.  We 
propose to use it for initial handshake only.

> - use SSL/TLS where possible

The generic insecurities of the networks are probably irrelevant for 
this draft.

> There went my tax money....

Mine as well :)

> Appendix A:

Could you expand a bit?  Would you suggest a rewording?

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 27 Feb 2005 18:01:25 +0100

On 2005-01-24, at 22.33, Pekka Savola wrote:

> The analysis/conclusions document on tunnel end-point discovery has 
> been re-focused and summarized to try to capture the critical 
> discussions better.
>
> It would be extremely useful if folks, especially those ones which 
> have not participated in the discussions before, would take a look and 
> send comments on the list.  The document should reflect most of the 
> discussion on discovery that have taken place both on- and off-list.

Ok, so some comments.

o Anycast

I am far from convinced that anycast is useful for what we want to do. 
Mostly from a security POV. First of all, anyone could more or less 
insert a well-known prefix and then either snoop or spoof the traffic 
sent through it. Or it could spoof a TEP server for some advertised 
technology. Or it could effectively DoS out the service. The only way 
to protect against this is for the ISP to filter properly, or to use 
some sort of authentication in the discovery protocol. However, in 
order for the authentication to work, we would need to know who to 
authenticate to in the first place, which kind of does away with the 
automatic part.

Second, a well-known anycast prefix is also easy to hijack. And this is 
being done with anycast prefixes today, and we rarely know of it.

So what is the difference between this and what we for example do with 
the roots? Well, first of all, DNS is inherently more robust. If one of 
the 13 servers where to time-out, we can pick the next one. As for 
spoofing, they are as vulnerable as a TEP anycast prefix as I describe 
above. And this has happened(*), and is documented. The difference is 
that the TLD and/or root-servers being anycasted are monitored closely 
(partly because of this reason), and for this we also have a solution 
in DNSSEC. Another difference is that in DNS I can't know which server 
a resolver/end-system will query beforehand (although that is a bug and 
not a feature from DNS perspective).

In general I think the security aspects of using anycast for this is 
poorly understood and documented and should be included. I actually 
worry enough about this to think this would be a show-stopper.

o DNS

I agree with the conclusions that has been discussed there that using 
forward lookups is to complex, and finding what to actually look up is 
inherently hard. Originally I was also very sceptical about the use of 
the reverse tree, but I am slowly changing my mind here. First of all, 
DNSSEC would/will actually prevent data protection and authentication 
(given the client supports it). Second, (from a selfish root-server 
perspective) it would force providers to populate the reverse tree with 
data, even for RFC118 addresses.

o The problem in general

The arguments have been brought forward that there are CPEs that run 
their own DNS-server on the CPE and that the boxes behind the CPE might 
be NATed (again) and therefor could not do the proper revers lookup. 
First of all, if the user is clever enough to run his own DNS server 
and whatnot on the CPE, he can sort out the manual configuration 
him-self. I would argue that Jeroen's home-network is out of scope. We 
can't solve everything. Second, the ISP can only reasonable be expected 
to solve the problem for resources that he can control. And I would 
also expect that the ISPs need to be able to authenticate the service 
one way or the other (but that is for the TEPD protocol), and that they 
would like to limit the number of queries they get to addresses they 
can trace. To me this means that the ISP should only reply to TEPD from 
addresses it has handed out. So how do we solve the CPEs that does NAT 
to a single ISP address? To me those boxes would have to do (in my 
preference) service discovery through reverse DNS on the ISP assigned 
address, and then act as a TEPD proxy (or server) to clients they are 
acting as NAT for. This could be as simple as populating the reverse 
tree that they have handed out to the clients and act as the resolver 
for those clients.

Again, I think the automatic configuration scenario has to be limited 
to exactly that. Automatic clients. Using this in an environment where 
there is "some" automation and some static configuration is bound to 
make it way to complex.

Perhaps I am oversimplifying.

Best regards,

- - kurtis -

(*) One example that comes to mind was the "helpful" IXP operator that 
wanted to give better performance to the connected ISPs and announced 
some of the root-server prefixes to the member ISPs pointing to a local 
server that answered as root-server. Same could be done for TEPD.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 27 Feb 2005 19:21:38 +0200 (EET)

Thanks for your comments -- some responses inline.

On Sun, 27 Feb 2005, Kurt Erik Lindqvist wrote:
> to protect against this is for the ISP to filter properly, [...]
>

Yes, a well-known anycast addresses have these issues for 
_interdomain_ routing, but there are at least two mitigating factors:

  - this is not meant to be [primarily] an _interdomain_ anycast 
address, just a well known anycast address (compare the scope to 
Masataka Ohta's well known DNS server address proposal -- not 
exactly the same but closer than e.g. 6to4 anycast address).

The expectation is that whoever would be providing this service, it 
would typically _NOT_ be advertised out to the Internet (but only to 
its own customers), and likewise the operators would filter out the 
prefix in inbound if they have a server of their own.  If they don't 
have a server of their own, they don't filter it of course -- but I 
doubt the user would get the service from anyone except close by, so 
I'm not sure if this is a big problem.

  - the anycast address is just used for initial handshake, to obtain 
the unicast address of the tunnel server.  That is, even with route 
hijacking, you would not get the existing tunnels -- only those which 
were created after the hijacking.

> worry enough about this to think this would be a show-stopper.

I agree that the security properties can be troublesome, and should 
probably be spelled out a bit better, but (in my personal opinion, at 
least), the above two factors shouldn't make this a really big 
problem.  Does that change your evaluation ?

> can't solve everything.

I've personally argued the same way myself.  Alain Durand, however, 
showed that at least some boxes (he mentioned Apple's wireless AP) 
would be, by default, advertising different names (e.g., search path 
of "lan") or doing NAT.  I'm not sure whether this is true or how 
commonplace it is...

> To me this means that the ISP should only reply to TEPD from
> addresses it has handed out.

Obviously, but clients behind NAT belong tot hat category as well.
(In Section 2.1, second point, we exclude ISPs advertising TEP to 
other ISPs from scope)

> So how do we solve the CPEs that does NAT

But that would require TEPD proxy support in the (NAT box) -- an 
upgrade.  That seems like a non-starter?

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 27 Feb 2005 18:44:28 +0100

On 2005-02-27, at 18.21, Pekka Savola wrote:
> Masataka Ohta's well known DNS server address proposal -- not exactly 
> the same but closer than e.g. 6to4 anycast address).
>

I understand this is primarily for intradomain use, but I think my 
assertion still holds. By using a well-defined prefix that could be 
hijacked I have moved the trust of the forwarding plane to a single 
instance. This is what worries me. In a native world this is much 
harder to achieve as there is more or less an entire chain you need to 
modify (although that has been done). Also, you have provided a single 
attack-point needed in order to intercept/redirect all user traffic. I 
am still scared.

> were created after the hijacking.

Agreed.

> problem.  Does that change your evaluation ?

They definitely need to be spelled out, and I don't think that a "you 
shall filter" line will cut it in this case.

> of "lan") or doing NAT.  I'm not sure whether this is true or how 

Uhm isn't the .lan for forward lookups? Still, if they would - their 
product simply doesn't support this...

> (In Section 2.1, second point, we exclude ISPs advertising TEP to 

No. It does belong to the ISP customer category, but it does not belong 
to the "equipment that has received configuration information from ISP" 
category. In Verbier I have a DSL line and a DSL router. My DSL router 
get's a single IP address from the ISP, default route, DNS-servers etc. 
That in turn will (through DHCP) provide my NATed boxes with the 
configuration information, effectively acting as an information proxy.

> upgrade.  That seems like a non-starter?

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 :-)

- - kurtis -

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Feb 2005 11:20:53 +0100

>hundreds of thousands of users and real usage throughout the Internet.

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.

Discovery should simply pick the 'best' available provider of a tunnel,
whoever that might be.
<offtopic>
Due note: I really can't care less who provides it, as long as the
enduser gets quality IPv6 connectivity :)
This is why SixXS exists, to give an ISP the ability to provide IPv6
connectivity for free, they only
have to make sure that the box is up and routing works, SixXS provisions
the config with our standard tools.
If they need SLA's and other things then we can arrange that. That is up
to the provider....
</offtopic>

>dependency on the continuity and correctness of such service.

One single source indeed can't, most likely, be done globally. Then
again the IETF is also one instance, IANA is one instance and so are
many other organization, who simply have subsections, providing the same
service around the world without any problems. It would just need a lot
of manpower and support. And as ISP's tend to be quite selfish and want
to keep everything for themselves, indeed that won't work out, it is
already a wonder that the complete IANA->RIR->LIR setup works for that
matter. Though that more has to do with age I guess.
So it really depends on the organization of such a thing if it can
work...

The internet seems to work and BGP really is without any certificates:)

>as such is not an interesting way to discover the broker at the local 

And what about the case where you discovered (initial couple of packets)
a TSP and did TSP/TIC or whatever method to build up your tunnel?
With anycast this would really scale.

>you automatically discover the TSP broker?

Anycast :) See below.

>'ping' and 'traceroute' if their firewalls don't block them.

That was not my point. The point is that a full DNS lookup of anything
will cause way more packets to be sent than the 1-2 packets to the
anycast address. Then taking into account the fact that DNS is already
anycasted, the above is quite bogos IMHO.
Anycast is just a cool hip term of saying you have multiple servers
servicing hosts on the same IP, nothing else.

>IPv4 connectivity, even if we could add options there (which we might 

Quite a large number of ISP's are using PPPoE to provision their DSL
users. I know from experience that this at least is done in the
Netherlands, Germany, France and Switzerland, there are bound to be more
countries using this standard.

>propose to use it for initial handshake only.

Which is also my idea ;)

My current complete idea of doing the _discovery_ is currently the
following:

<optional>
 - DNS lookup tsp.ipv6.transition.service. to get the IP address (which
could be anycasted) of the TSP/TIC whatever protocol we are going to use
server. The DNS lookup could be secured using DNSSEC to make Kurtis (and
also me) happy.
   If an ISP does not have the above zone in it's resolvers, or the user
has configured itself to use the root servers, these will return
NXDOMAIN and it will be game over here, as the service is not available
anyway. If the user configured something wrong then that is his/her/it's
mistake, can't change that in the same way that we don't want to
automatically reconfigure ones firewall.
  We could then always fallback to a well-known address.
</optional>

- Talk to the well known or just resolved IP address, which may be
anycasted.
- Get a referal to the TSP/TIC whatever service that contains the
configuration information.

We know where we have to be .... on to another document which specifies
what the, just discovered endpoint actually does, that is most likely
providing the configuration information, using eg TSP or TIC.

(Now... why can a tunnelbroker model not work? Do note that this is not
the original 'website' model anymore, it is just a configuration
service)

>Could you expand a bit?  Would you suggest a rewording?

Just like the above, if one misconfigures something, then it is broken.
If you turn off the box running your website, then indeed, the
uberstable Apache does not work ;)

>data, even for RFC118 addresses.

You missed a 9: RFC1918.  Next to that DNSSEC would indeed help a lot
here, see the above.
But if you want to be secure, one would really need SBGP or something
similar too IMHO.

Greets,
 Jeroen

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Feb 2005 11:55:26 +0100

Hi,

> other for IPv6. And this works(tm).

Please do not call this solution "in general".  Our Dialup customers 
(ISDN or DSL with PPPoE/L2TP) run *one* PPP session, with IPCP and IPv6CP 
nicely coexisting.

Of course it's possible to do DSL/PPPoE with two PPP sessions, possibly
even to two different ISPs, but that's more a "niche" solution than 
using PPP the way it's designed - multiprotocol in a single session.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  71007  (66629)

SpaceNet AG                    Mail: [email-masked]
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Feb 2005 12:00:37 +0100

>(ISDN or DSL with PPPoE/L2TP) run *one* PPP session, with IPCP and IPv6CP 

Ah, thanks for the update, but the point is that you are using PPP,
while the document says that nobody does.

BTW, there are no problems anymore with CPE's that could not handle the
IPv6 options? At least I recall something like this when doing it in the
same session, which was the reason for the two separate sessions.

Greets,
 Jeroen

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Feb 2005 12:16:58 +0100

Hi,

> while the document says that nobody does.

Yeah.  But in this specific scenario (ISP offering native v6 and PPP
access), most of the transition worries are moot anyway - you just hook
up your CPE and IPv6 works.

> same session, which was the reason for the two separate sessions.

I'm not sure.  We enable IPv6 only on customer request, because we are
worried about "confused CPEs that do not know how to handle IPv6CP" - so
in our case, the CPE always knows how to handle it (and if not, the
customer is expecting to beat it into submission).

OTOH I know of at least one other german large-scale dial/l2tp ISP who
has "just" enabled IPv6CP on all (!) dial-in sessions, and I haven't 
heard anything about large numbers of failed client sessions.  So most
PPP implementations around seem to be able to handle unknown protocol
requests correctly (send PROTREJ, go on with IPv4).

Gert Doering
        -- NetMaster

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Feb 2005 13:55:41 +0200 (EET)

>>> other for IPv6. And this works(tm).
[...]
> while the document says that nobody does.

The document says nothing ot that sort.

There are multiple reasons why PPP has been discounted.  A very 
important one is that PPP is not _sufficiently generic_ mechanism. 
There are lots of PPP users out there, yes.  But there are even more 
those users that _don't_ use PPP.  That makes the use of PPP a 
non-starter in this kind of scanario, where we want the mechanism to 
work whether or not PPP is being used.

The other issues w/ PPP are:
  - PPP is not good if there is a NAT box in the middle.
  - there has been procedural resistance to extending PPP with new 
options

The same considerations (except for willingness for extentions) apply 
to DHCPv4.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Feb 2005 14:39:10 +0200 (EET)

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

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

[...]
> The internet seems to work and BGP really is without any certificates:)

No, this does not work.  What you're proposing, I think, is something 
similar to DNS root servers.  Some people would be in charge of 
keeping up-to-date synchronized "tunnel broker root", to which you 
would be required to register all the other tunnel servers.

Such a model has zero practical chance of being actually deployable 
within the next 10 years or so.

This is not AFAICS comparable to BGP with or without certificates.

> With anycast this would really scale.

With anycast used to discover the tunnel endpoint, and the TSP/TIC as 
"tunnel configuration" protocol, this might (or might not) fulfill the 
requirements for the solution.

But that model is completely different from what sixxs.net and "one 
centralized broker in the Internet" models, because we don't assume 
there is a broker that knows everything about everything.

>> you automatically discover the TSP broker?

So, as anycast is already being described here, mentioning TSP or 
AICCU (whatever that is) is out of scope for this draft.  Those 
describe the _configuration protocol_, not _tunnel end-point 
discovery_ mechanism.

> anycast address.

The situation is different.  DNS (w/UDP, without fragmentation) is 
stateless.  If you send 2 DNS UDP packets to an anycast address and 
the first gets to server A and the second gets to server B, it still 
works.  This would _not_ work.

So (AFAIK) it has not been demonstrated that an anycast TEP discovery 
would simply "just work" as well as DNS roots.

In addition, as Kurtis said, the model is a bit different.  If one DNS 
root (which is anycasted) fails, there are about 12 others to try. 
Here, there would be no alternative.

(Don't get me wrong, personally I believe the anycast issues are not 
really issues at all, but just trying to express the concerns the 
others have said.)

>  We could then always fallback to a well-known address.

This kind of generic approach is probably better proposed in somewhere 
like DNSOP.  It has some .. issues.  It could be used to redirect the 
users from a well-known anycast address to a local address (at the 
cost of 1-2 roundtrips or even more), but what's the point if you're 
able to do the same by just using anycast as well? (The only 
difference would be that instead of having to configure a prefix 
advertisement, you'd have to configure a DNS server as authorative, 
and be sure all the clients actually use that server and not 
implementa a caching server of their own -- i.e., not good.)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 28 Feb 2005 16:21:28 +0100

> server. The DNS lookup could be secured using DNSSEC to make Kurtis 

My concern is that you still have no idea if you are talking to the TSP 
server you think you are talking to.

- - kurtis -

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Feb 2005 17:10:08 +0100

On Mon, 2005-02-28 at 16:21 +0100, Kurt Erik Lindqvist wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

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

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Feb 2005 21:19:40 +0200 (EET)

> identifier as the verification mechanism...

This issue is somewhat offtopic from _discovery_, but was mentioned 
briefly earlier under "mutual authentication", without much 
discussion.

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

If the discovery mechanism has potential for giving ambiguous 
responses, it can be argued that the need for the client to 
authenticate the server is greater (but probably only slightly).

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.

As an example of configuration protocol client<->server 
authentication, draft-parent-v6tc-protocol-exploration-01.txt gives an 
overview how to use SEND or DHCPv6 + authentication.  Both can 
guarantee that you are talking to the server you think you're talking 
to.

So, this does not necessarily need to be addressed in the end-point 
discovery part of the solution, though the properties of the discovery 
may affect the requirements level of the authentication.

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2005 16:14:20 -0800

On Feb 27, 2005, at 9:44 AM, Kurt Erik Lindqvist wrote:
> mation proxy.

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.

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.

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Feb 2005 17:20:02 -0800

PPP is L2 technology. If the box that wants v6 connectivity has access 
to it, great, problem solved, if not,
this is simply not an option, unless you are talking about ppp over 
TCP, which is a whole different beast.`

	- Alain.