[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-01.txt
-- On Wednesday, June 16, 2004 09:52:28 AM +0200, Jeroen Massar wrote:
On Tue, 2004-06-15 at 21:41, Internet-Drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)
<SNIP>
Things I am wondering about(tm):
"2.1 NAT Discovery"
It mentions to choose UDP over IPv4, is there a spec of this protocol?
Also it mentions that it will pick 'the most effective protocol even in
dynamic situations when the clients moves', which one is that?
If no NAT is in the path, IPv6-over-IPv4 is selected. Otherwise, IPv6 over
UDP.
In: "On the IPv6 layer, if the client uses user authentication, the same
IPv6 address and prefix are kept and re-established. On the IPv6 layer,
there is no change of address."
The last sentence is a duplicate or clarification I assume?
Yes, they mean the same thing. Could be merged into the same sentence.
"If there is no IPv4 NAT is detected in the path by
the TSP server, then IPv6 over IPv4 encapsulation is used."
Reprase to "If no IPv4 is detected in the path..."
I think the original sentence is ok, or I lost you here :)
Note that there are *many* ISP/transits that blindly filter proto-41 and
then the tunnel will not work. Of course they could also filter UDP for
that matter...
Correct. You can let the broker pick the 'best' encapsulation for you, or
if you know that ip-proto41 is filtered, one can always explicitly specify
IPv6 over UDP encapsulation (or vice-versa).
"2.3 Mobility", would it not be easier and more effective to use
heartbeats here? Renegotiating all the parameters would cause a delay and
cause packets to be dropped.
Well, keep-alives do help out here in detecting if you have "moved" *and*
keeping the NAT state valid.
The delay involved in renegotiating is negligible compared to the time to
detect and have the OS adjust to the fact that you have "moved".
But yes, the 'heartbeats' would be faster since you send authentication
material in every packets. The 'heartbeats' are sent out-of-band, as I
recall (w.r.t. the established tunnel), so this doesn't help to keep the
NAT state active. We would need to send 'heartbeats' and keep-alives in
such a configuration, right?
"3. Advantages of TSP" Advantages over what? There is no other Tunnel
Setup Protocol defined :)
For 4.x: What was actually the reason for not picking a full HTTP/1.1 or
SOAP protocol? Implementing clients would then be much easier as many
HTTP clients already exist also that could allow Apache (or IIS ;) for
instance to be used as a server.
Good point. I will need to think a bit more on this one. A point that comes
to mind is the fact that we require UDP for NAT traversal (not sure we want
to do HTTP over UDP?). My knowledge on SOAP is limited, I'll have to readup
a bit. My take is that TSP is much closer to BEEP (RFC3080).
The Security Considerations should note that due to the many spoof-open
networks it is very easy to inject a packet into the network stream of
v6udpv4 packets and pose as the original sender. One could thus easily
disrupt the tunnel. Same for proto-41 tunnels. Also see
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunne
l-disco.pdf
True. But as you state, no different from IPv6-over-IPv4. If securing the
transport is important, IPsec seems like the way to go.
Thanks for the comments Jeroen!
Florent