Subject: Re: Tunnel Set-up requirements: Issue to be resolved

From: "Carl Williams" <[email-masked]>
Date: Thu, 6 May 2004 16:28:22 -0700

Alain,

  Some of the scenarios we are looking at require that
we be able to keep the same IPv6 address for both registered
and non-registered modes for each tunnel setup - this of course
should be a choice.

  I don't know if this is more of an implementation issue or not
but for registered mode I don't want to require the end customer to
manually enter settings via some web page every time
they initiate a new tunnel setup.  For example, I want to require 
registration but in a way that is automatic and transparent to the 
user. 

  Thank you for creating this requirements document and I hope
that other service providers and/or mobile network operators
can comment on the requirements as well.  

Original Message:
-----------------
From: Alain Durand [email-masked]
Date: Thu, 06 May 2004 14:49:06 -0700
To: [email-masked], [email-masked]
Subject: Re: Tunnel Set-up requirements: Issue to be resolved

On May 6, 2004, at 2:33 PM, Erik Nordmark wrote:

>> The original draft talked about two modes, authenticated and non
>> authenticated.
>> This was not a perfect terminology, and we now use registered vs non
>> registered.
>
> Question: in the non-registered mode is there an ability to have a 
> mechanism
> by which the same host gets the same IPv6 address each time it sets up
> a tunnel?

Not today. Do you want to require such a mechanism?

>> 	- The registered part of the protocol SHOULD not be too
different 
>> from
>> the non registered one,
>> 	   so as to minimize code difference between the two modes
>
> Are we assuming that the registration is done as part of the protocol
> itself, or are we assuming that the registration is external to the 
> protocol?

unspecified at this time.

> In the latter case you can the ISP that supports registered tunnels
can
> have a web site where the user types in the credentials it uses
> with the ISP (userid? contract number? whatever)
> and as a result gets some registration key/tag which will be used
> in the actual tunnel setup protocol.

That is definitively one way of doing it.

This could be a way to unify the two modes: if you are unregistered,
you provide an empty key and the system could (if desired by the ISP)
allocate you one so you would be able to retrieve the same address next 
time
by presenting that key.

In the registered mode, you provide the key that was pre-assigned to 
you.

Question: are we not already in solution space?

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Thu, 06 May 2004 21:24:18 -0700

Thank you Carl, this is exactly the kind of feedback
I'm looking for.

> registration but in a way that is automatic and transparent to the

Would a one time registration through a web page be ok?
There could be some kind of token/key exchange happening there
and that would be reuse automatically every time the user
sets up the tunnel.

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 07 May 2004 09:35:22 +0200

> and that would be reuse automatically every time the user

IMHO a protocol doing this MUST not rely on an external mechanism.

The problem is very easy to solve:
 - user start tool(tm)
 - tool discovers the closest tunnel setup protocol (*)
 - tool connects to tunnel setup protocol
 - setup server notifies client that it can handle:
    * anonymous users
    * pre-registered users
    * allowing new registrations
    all optional depending on the ISP/server deployers wishes.
    A tunnel setup protocol MUST be able to do all three.

Then the tool proceeds to either:
 [anonymous user]
  - user claims it wants to be anonymous and presents a
      'cookie' if it has that from a previous session
  - setup server either validates the cookie and finds the old
      IPv6 prefix(es) the user was using or returns a new one.
      the client MUST be able handle to handle it and a server
       MAY return a new prefix
  - setup server returns prefix information, cookie, endpoint info,
      etc....

  [registered user, aka one with an account]
   * the account can be obtained out-of-bound
       (website, phone, preexisting agreement or using below regmethod)
  - tool asks for possible authentication methods (MD5/SHA/whatever)
  - tool asks user for authentication tokens and sends to server
  - server authenticates user and:
  - setup server returns prefix information, endpoint info, etc....

  [registered user, but no account yet]
   - tool tries asks the server how to register
   - server responds with either:
       * website + http://www.example.com/register/
           - Tool either presents the user that it can register
               through a website and if it wants to do that.
               This site could also point to information how to
               do it in different ways. If the user answers yes
               to the question then the user is shown the url
                either by starting the webbrowser directly or just text.
        * direct [en|nl|de|...] (the languages supported)
           - Tool asks if the user wants to register using the tool
               when no, return to start.
           - Tool asks server for 'registration information' in 'en'
               or 'nl' or whatever depending on the language the user
wants
           - Server returns "language not available" or:
               <text name="name" short="Name">Your full name (first +
last name)</text>
               <text name="address" short="Address">The address where
you live</text>
               <text>.....</text>
               * but this is implementation*
       As registration through this protocol should be optional when
       it is implemented it SHOULD only use the 'website' method, the
       'direct' method is quite complicated and basically also presents
       the same forms as the website.... (maybe better only do website?)

(*) = I split "Tunnel Setup" & "Discovery" as the discovery should be
done seperatly IMHO and could be as simple as DNS lookups but could also
do more difficult tricks. The Discovery should only return a pointer to
the Tunnel Setup Server.

(and yes... all this is already possible using the configuration
protocol in use by SixXS, waiting for this thing to settle ;)

Greets,
 Jeroen

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 7 May 2004 09:55:40 -0700 (PDT)

> IMHO a protocol doing this MUST not rely on an external mechanism.

But later you say that referring to a website for registration is ok.
Perhaps we mean different things by "external mechanism".

I think it is find to have the tunnel set-up return a
"please register at www.example.com/register" as you suggest,
and that is what I call "external".

So I suspect we agree on this point.

I don't know if the "direct" is that useful. You effectively end
up carrying a subset of html when you do this; it is simpler just
to refer to a URL.
(And there might non-technical reasons for an ISP wanting a URL for
registration; they can have banner ads for their ADSL service etc.)

One question:
For the [registered user, aka one with an account] you are describing
something that looks like a full authentication exchange, which opens
up the door to questions like "are we encapsulating EAP over the tunnel
setup protocol? or SASL?".

Do you see this strong authentication as a requirement?
Or do you think it is sufficient to have the registration result in
some "key/tag" where presenting that key/tag in the clear in the tunnel setup
protocol is sufficient?

   Erik

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 08 May 2004 15:40:49 +0200

> So I suspect we agree on this point.

Correct.

> registration; they can have banner ads for their ADSL service etc.)

Indeed, which is why I also noted that in the message.
Most users are able to navigate through a 'register' type site.
It is up to the ISP to make it doable and this also 'lightens' the
burden on the tool as it doesn't need to be able to do checks of
validity and other things which can then be handled in a webstyle
method.

> some "key/tag" where presenting that key/tag in the clear in the tunnel setup

I personally would be more inclined to require a somewhat more strong
authentication, thus in the form of SASL at least that the key is not
passed in cleartext and that a replay attack can be avoided.
I guess that most people will not mind, but if someone has a good
argument against doing that, please mention it of course.

IMHO the best thing to go is require that a tunnel setup protocol is
able to allow multiple styles of authentication and let the deployer
pick. Thus that the server announces it's capabilities:

- SSL/TLS negotiation so that the complete protocol is crypted
   (think starttls here just like in SMTP).
- Several authentication methods:
   - cleartext (required)
   - md5/sha/sasl style (optional but recommended)

Advertisements of capabilities should be done in order of strongest to
the weakest version. Clients should then pick the first one which it can
handle and use that. It would of course be easier to just define one
single strong authenticator and a cleartext variant, which may be only
available when using SSL/TLS for instance.

Greets,
 Jeroen