Subject: Re: I-D ACTION:draft-blanchet-v6ops-tunnelbroker-tsp-01.txt

From: Florent Parent <[email-masked]>
Date: Wed, 16 Jun 2004 10:21:53 -0400

-- On Wednesday, June 16, 2004 09:52:28 AM +0200, Jeroen Massar wrote:

> On Tue, 2004-06-15 at 21:41, [email-masked] 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

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 16 Jun 2004 09:52:28 +0200

On Tue, 2004-06-15 at 21:41, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 

<SNIP>

"2.1  NAT Discovery"

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...

"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.

"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.

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-tunnel-disco.pdf

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 16 Jun 2004 18:03:45 +0200

On Wed, 2004-06-16 at 16:21, Florent Parent wrote:

<SNIP>
> 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>

> 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.

> 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.

> 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