On Wed, 2004-06-16 at 16:21, Florent Parent wrote: <SNIP> > > > > "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 :) There is 'is' twice in the sentence, which doesn't read smoothly IMHO. <SNIP> > > "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? Correct. But the heartbeat draft is for proto-41 tunnels. The AYIYA draft is for anything-over-anything and includes the same heartbeat trick but embedded in the data stream. > > "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). Beep indeed. But with the way you are now handling TSP-over-UDP you have added back the sequence numbers which where missing from UDP. > > 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. It is not securing the transport, it is making sure that there is no _additional_ spoofing going on. There are a number of ways that make it very easy to abuse tunnels, dossing hosts without them ever being able to trace the traffic. By authenticating the traffic, a hash is maybe only 4 bytes so that is not the issue, you can make sure that at least the traffic upto the Tunnel Server is not spoofed. The IPv4 internet is a wide open place as shown in the above doc, thus adding a bit of resilience for the small price of 4 bytes and a bit of hashing overhead is not so heavy to pay IMHO. Indeed if one wants to make sure that everything works correctly use IPsec, but one of the issues we are trying solving here is that many hosts are behind NAT's, thus they can't use IPv4-IPsec in the first place ;) Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part