Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments

[Marc Blanchet <Marc.Blanchet@hexago.com>]

-- Sunday, February 29, 2004 07:57:53 +0200 Pekka Savola
<pekkas@netcore.fi> wrote/a ecrit:

> Thanks for updating the spec -- it has been a long time :).

(well, v6ops was not supposed to work on protocols... ;-)))

>  A few 
> comments below.

thanks, appreciated.

> 
> I'm commenting on the spec itself only, not the deployment model (at this
> point).
> 
> very substantial
> ----------------
> 
> 1) The specification is rather intuitive and easy to read and get a grasp
> on, but as it is, I don't think it is has enough details to build an
> interoperable implementation.  For example:
> 
>  - the heartbeat mechanism which is mentioned, appears to be non-specified
>  - a lot of error codes are listed in the end, but there is no
> specification except about the first couple of them when they are to be
> returned, etc. -- I think you're able to guess that, though.
>  - there are some references to UDP as a control plane mechanism, but no
> real specification.  There was also a mention of 
> "UDP-reliable", which was not elaborated further..

all agreed that they were not enough specified. This initial submission was
mostly a merge of the 4 old drafts altogether. I will submit a new version
with this info (it was already on my todo)

> 
> 2) There seems to be something fishy about mobility. 

not intended!

> The user is expected
> to give an IP address, which (supposedly) is used to identify the user.

no. IP address is used to create the tunnel on both end. User
authentication is used to identify the user. 

> But if the IP address of the user changes, how can such identification be
> done? 

if user have used authentication, the broker stores that information and
then can be resend to the user the next time he comes, even with a new v4
address.

> All in all, it seems like the mobility was not really described at
> length either...

ok. sorry. will do better in the next version.

> 
> 3) TSP specifies a lot of custom ways of signalling.  Maybe this is more
> of a philosophical argument of building from pieces vs. designing the
> whole system, but I think some might have preferred using existing
> heartbeat (ND), prefix delegation, DNS resolving and delegation etc.
> mechanisms.  And if those are not sufficient (e.g., prefix delegation is
> too complex), shouldn't we specify a simpler version?

tsp was based on users input and requests, starting from early 1999. Still
now, basic requirements for users are similar. 
- an important requirement was that these days (because of IPv6... ;-))),
users have a network instead of a host. A network means prefix delegation,
etc...

- for the provider perspective (provider in the sense of the tsp tunnel
broker provider: it could be ISP, enterprise, ...), tsp tunnel broker
enables fast deployment. By having these additional functions, it enables
the provider to offer a full set of services while not have to upgrade
right away its infrastructure (eg. including DNS).

- the user is authenticated in the TSP session (in non-anonymous mode):
this enables the assignments of prefixes and dns stuff, since they need
some kind of authentication. If we do it out of TSP (which is possible
today with TSP: just don't request/use these TSP functions), then another
authentication infrastructure must be put in place.

> 
> While I don't have a really strong opinion here, some consideration wrt.
> "reuse" vs "redesign to fit" will undoubtedly come up.
> 
> 4) SASL doesn't work with UDP, so my guess is that the whole UDP 
> signalling must have been some kind of glitch in the spec.

I will improve in next version. (it works, I'm using it every day...)

> 
> semi-substantial/semi-editorial
> -------------------------------
> 
> Abstract
> 
> ==> it is maybe a bit too long; fitting on the "cover page" would be very
> preferable.

ok.

> ==> no references in the abstract.
> 
>    to have up to 4 parties involved: 1- the tsp client, 2- controlling
>    the requesting tunnel end-point, 3- the tsp server, 4- controlling
>    the receiving tunnel end-point.  1,3 and 4 is the Tunnel Broker
>    model.  1 and 2 can be on the same node, as well as 3 and 4 can be on
>    the same node.
> 
> ==> s/tsp/TSP/
> ==> I think you should reword this to make clearer what 2) and 4) meant. I
> only (think I) understood this after reading the whole spec.

ok.

> 
> 3. Advantages of TSP
> 
>    o  A signaling protocol to establish the tunnel: no need to change
>       kernels, routing...
> 
> ==> I do not understand what you mean by this advantage.  Perhaps you
> should elaborate or reword.

ok. what was meant is that it is "just" a signaling protocol: it is on the
control plane. No modifications needed elsewhere.

> 
>    o  routing negociation
> 
> ==> again, it is not clear what you mean by this; perhaps needs to be
> expanded.

ok.

> 
>    o  two to four tier tunnel broker model
> 
> ==> is this an advantage?  I'd maybe count this as a drawback :-)

say an option.

> 
>    C: Content-length: 234 CR LF
>       <tunnel action="create" type="v6v4">
>        <client>
>         <address type="ipv4">1.1.1.1</address>
>         <router>
>          <prefix length="48"/>
>          <dns_server>
>           <address type="ipv4">2.3.4.5</address>
>           <address type="ipv4">2.3.4.6</address>
>           <address type="ipv6">3ffe:0c00::1</address>
>          </dns_server>
>         </router>
>        </client>
> 
> ==> umm.. why is the client requesting DNS server addresses like this --
> doesn't seem to make sense!

might not have been clear enough. He was sending _his_ dns server addresses
for the inverse tree delegation. Will add.

> 
>         <router>
>          <prefix length="48">3ffe:0b00:c18:1234::</prefix>
> 
> ==> the prefix length is 48, but the prefix is 64 -- glitch or
> intentional?


sorry. typo.

> 
>                       <address
>    type="ipv6">fe80:0000:0000:0000:0000:0000:0000:0001</address>
> 
> ==> why advertise its own link-local address?
> 
>      C:Content-length: ... CR LF
>        <tunnel action="create" type="v6anyv4">
> 
> ==> it appears that the other examples wouldn't have worked through NAT.

these are many variations or examples.

> 
>    Automation of the prefix assignment and DNS delegation, done by TSP,
>    is a very important feature for a provider in order to substantially
>    decrease support costs.  The provider can use the same authentication
>    database that is used to authenticate the IPv4 users.
> 
> ==> there is not even a hint how TSP could use the same databases as with
> v4 authentication :-)

ok. answer was "radius"... Will add.

> 
> 5.5 Applicability of TSP in Unmanaged networks
> 
> 
> ==> many of these are actually the same scenarios as identifier earlier,
> this one is pretty close to 5.2.  There's some other overlap as well --
> might be worth compressing these a bit...
> 
>    Static tunnels are created when the TSP negociation is terminated.
>    Static tunnels are not open gateways and exhibit less security issues
>    than automated tunnels.  Static IPv6 in IPv4 tunnels security
>    considerations are described in [RFC2893].
> 
> ==> there's some very important stuff in the mech-v2 document as well.
> 
> References
> 
> ==> split the references to Normative and Informative
> 
>    [5]  Hagino, J., "Possible abuse against IPv6 transition
>         technologies", July 2000.
> 
> ==> this wasn't refererred to in the draft, so remove?
> 
>     <!ATTLIST tunnel lifetime CDATA              "1440"    >
> 
> ==> is that "1440" here intentional ???

yes. default lifetime.

> 
>    <!ELEMENT router        (prefix?,dns_server?,as?)>
> 
> ==> I don't think there's need for "as", nor is it mentioned elsewhere in
> the document.

from old versions. will cut.


> 
> Full Copyright Statement
> 
> ==> please add IPR section prior to this section


humm. automation. I probably need to update my version xml2rfc, which would
do it... ;-)))

> 
> 
> editorial
> ---------

will do these.



Marc.