[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments
Thanks for updating the spec -- it has been a long time :). A few
comments below.
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..
2) There seems to be something fishy about mobility. The user is expected
to give an IP address, which (supposedly) is used to identify the user. But
if the IP address of the user changes, how can such identification be done?
All in all, it seems like the mobility was not really described at length
either...
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?
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.
semi-substantial/semi-editorial
-------------------------------
Abstract
==> it is maybe a bit too long; fitting on the "cover page" would be very
preferable.
==> 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.
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.
o routing negociation
==> again, it is not clear what you mean by this; perhaps needs to be
expanded.
o two to four tier tunnel broker model
==> is this an advantage? I'd maybe count this as a drawback :-)
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!
<router>
<prefix length="48">3ffe:0b00:c18:1234::</prefix>
==> the prefix length is 48, but the prefix is 64 -- glitch or intentional?
<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.
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 :-)
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 ???
<!ELEMENT router (prefix?,dns_server?,as?)>
==> I don't think there's need for "as", nor is it mentioned elsewhere in
the document.
Full Copyright Statement
==> please add IPR section prior to this section
editorial
---------
A tunnel broker with the Tunnel Setup Protocol(TSP) enables the
==> s/(TSP)/ (TSP)/ (multiple times)
used by the tunnel client to negociate the tunnel with the broker.
==> s/negociate/negotiate/ (also a lot of times)
networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A
==> s/he/it/
This document first describes the TSP framework as well as the
different profiles used. It then describes the applicability of TSP
in different environments, some were described in the v6ops scenario
documents.
==> s/some/some of which/ ?
o IP address allocation for the tunnel endpoints
==> s/allocation/assignment/
o IPv6 prefix assignment when the client is a router and has a
network behind
==> s/behind/behind itself/
The TSP connexion can be established between two nodes, where each
==> s/connexion/connection/ (multiple times AFAIR?)
established. On the IPv6 layer, there are no mobility seen.
==> s/there are no mobility seen/no mobility is needed/ ?
When a tunnel endpoint changes its underlying IP address (i.e.
change of its IPv4 address when doing IPv6 in IPv4 encapsulation),
the keepalive mechanism fail and the TSP client reconnects to the
==> s/fail/fails/ (there were a LOT of stuff like this..)
4.1 Terminology
Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking
==> s/TB)/TB):/ (similar later)
Clients (TC). Tunnel clients query brokers for a tunnel and the
broker find a suitable tunnel server, ask the Tunnel server to
setup the tunnel and send the tunnel information to the Tunnel
Client.
==> s/find/finds/, s/ask/asks/
service to a Tunnel Client. It can reveive the tunnel request
==> s/reveive/receive/
Authentication phase: The Authentication phase is when the Tunnel
Brokers/Servers advertises their capability to Tunnel Clients and
when Tunnel clients authenticate to the server.
==> s/advertises/advertise/
==> s|server|server/broker| (based on the picture at least...)
Response phase: The response phase is where the respond to the client
==> something missing between "the respond" ?
For each command sent by a Tunnel Client their is an expected
response by the server.
==> s/their/there/
When a TCP (or UDP-reliable) session is established to a Tunnel
==> uh-oh, the infamous UDP-reliable.. :)
adevertised mechanism. If the authentication fails the server sends
==> s/ade/ad/
If the authentication succeed, the server sends a success return code
and the protocol enter the Command phase.
[...]
Upon successful authentication the protocol enters the command phase
as described in the next section.
==> one of these is probably redundant
==> s/succeed/succeeds/, s/enter/enters/
4.6.4 broker element
==> s/broker element/Broker Element/ (similar elsewhere)
The 'broker' element will contain a series of 'address' element.
==> s/element/element(s)/ ?
In a provider network where IPv4 is dominant, a tunnelled
infrastructure can be used to provider IPv6 services to the
==> s/provider/provide/
TSP server can be put in the core, in the aggregation points or in
the pops to offer the service to the customers. IPv6 over IPv4
==> s/pop/PoP/
mobile hosts to have IPv6 connectivity wherever they are, by having
the TSP client sends updated information of the new environment to
the TSP server, when a change occur. Together with NAT discovery,
==> s/sends/send/, s/occur/occurs/
tonegociate tunnel parameters, as well as prefix assignment, dns
==> s/tonegociate/to negotiate/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings