Subject: [v6tc] Issue 1: Could we live with UDP encapsulation always on?

From: Alain Durand <[email-masked]>
Date: Fri, 17 Dec 2004 01:52:56 -0800

Obviously the first thing to consider is the UDP overhead. When the 
payload is large,
there isn't much difference, but when it is small, there is a non 
negligible impact.

Another point to consider is that UDP encapsulation might force packets
to go to the slow path on the tunnel end-point unless special code is 
added
in the forwarding plane.

Also, IPv6/UDP/IPv4 has not generally been implemented so far, so we 
have
a deployment problem. Also, tons of PCs have now teredo, so there may 
be some
compatibility issues and/or some potential code to leverage.

Anything else to consider?

	- Alain.

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 17 Dec 2004 11:12:49 +0100

On Fri, 2004-12-17 at 01:52 -0800, Alain Durand wrote:
> payload is large,there isn't much difference, but when it is small, there is a non 
> negligible impact.
> 
> have a deployment problem.

Not implemented or deployed? I wonder why Freenet6 has their special NAT
traversal code and why SixXS have AYIYA then ;)

> Also, tons of PCs have now teredo, so there may 
> be some compatibility issues and/or some potential code to leverage.

Teredo basically is one of the main three (are there others?) versions
of IPv6/UDP/IPv4 protocol. The only thing being that it is more a p2p
like application in that it not uses a pre-configured or out-of-band
managed designated server. It is possible to configure that though (it
is something like: netsh set teredo <relay>...)

Byte-wise you could easily 'live' with UDP encaps btw. Especially as
proto-41 is non-authenticated and very spoof sensitive, oh hmm so is the
protocol which is proposed in the new draft. AYIYA, which looks somewhat
quite like the proposed protocol, does not have this issue btw...
With people downloading movies etc, do 3 bytes per packet extra hurt?
The target is getting IPv6 deployed and available to the masses
(Longhorn in 2006 will come default with IPv6 and you can turn of
IPv4 ;) Who does this or how does not really matter as long as it is
done and people can enjoy the freedom of enough addresses and thus
end-2-end connectivity.

Why is there a checksum in that newly proposed protocol anyway?
There was a reason why checksumming was removed from the IPv6 headers ;)

Greets,
 Jeroen

PS: The mailinglist archives don't work...

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Dec 2004 12:35:15 +0200 (EET)

>From Alain:
> payload is large, there isn't much difference, but when it is small, 
> there is a non negligible impact.

What I'd be interested in knowing here is whether the typical UDP 
header compression algorithms fix this problem automatically in those 
deployments where the extra bytes are important.

> With people downloading movies etc, do 3 bytes per packet extra hurt?

The assumption is that if you want to protect the payload, you'll want 
to use a real security mechanism -- this is not the place to 
(try to) invent one.

> There was a reason why checksumming was removed from the IPv6 headers ;)

It is the standard UDP checksum.  The first two lines are the UDP 
header.

> PS: The mailinglist archives don't work...

Thanks for pointing that out.  I'll raise it with the IETF 
secretariat.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 17 Dec 2004 12:11:52 +0100

> deployments where the extra bytes are important.

You mean eg dailup users? Do those still exist? Also G3 phones don't
have this issue either with UMTS and other goodies being deployed,
coming upto speeds of most lower DSL lines...

> to use a real security mechanism -- this is not the place to 

You mean using IPSEC, which does not (easily) work over the NAT we where
trying to cross in the first place ? :)

Also I don't mean to protect the payload, I could not care less about
crypto, use SSH/HTTPS/TLS in the cases you need to crypt something. It
is about verification that the sender really send the packet which you
are going to forward for them.

Because that is the issue here. Also expect people to abuse this
proposed protocol, just like they are abusing proto-41 by simply
spoofing packets and inserting them, causing some nice network traffic
spikes, being totally untraceable as there is no way to trace where they
are coming from and one will think it is coming from the legit user, who
is suddenly getting claims of sending a large ddos to somebody, while
that person is really only browsing the web, if using the connection at
all.

By having at least a *small* md5/MMH/UMAC signature on the packet this
problem gets solved and the packet can be quietly dropped at the
tunnelserver.

btw typo in the draft (sect 4, security):
8<---------
Creating tunnel state based on the first UDP packet ___is can___ open
the server to a DoS attack with spoofed source addresses.
--------->8

As none of the following packets are verified, anybody who is able to
send a spoofed packet, which is very commonly possible with most
networks not doing RPF and other mechanisms, every packet can be spoofed
and sent out over the tunnelserver. Thus please add "can become the
source of an untraceable ddos attack in case the infrastructure between
the endpoints is not secure".

As this protocol is for endpoints behind NAT's I guess there is also a
very large assumption which can be made that the above is the case, thus
roll up your sleeves when your friendly (ahem) neighbourhood kid finds
out that he can use his 100k+ botnet* for some more 'action' in the new
world...

* these things also exist because the network administrator is either
too busy/lazy or simply doesn't care about his network.
For that matter I am waiting for them to start abusing Teredo and other
public relays, as there is normally unconfigured only a few number of
Teredo relays you don't want to imagine the effect it will have on them.
It would boost IPv6 traffic a bit of course, but this is not the kind of
traffic that people would like to see I think ;)

Next to this security issue, the proposed protocol (is there a name for
it, would make it easier to reference it) does not take care of the case
where a user gets an IP address, starts a huge video stream, thus eg
multicast udp packets at 2mbit/s, coming unacked to the endpoint. User
disconnects/changes IP, which is a common case with ISP's who also limit
their users to one IP address, they also usually have some nice change-
your-ip-every-day tricks to get you to maybe buy a more expensive
account, the next user getting this IP will then get this nice streams
of 2mbit/s tunneled IPv6 traffic. And actually she didn't want to get 1
byte, maybe she is even paying for the bandwidth and thus is paying for
a lot of unwanted traffic. Cash for the ISP, but not very nice for the
user. In short: please add a heartbeat mechanism, which also allows one
to change IP during the tunnel lifetime and thus seamlessy swap over to
another IP.

No, this is not to replace Mobile IP and no it is not intended to
replace IPSEC, but it does make certain things much better without
having to rely on two of the protocols which most OS's don't
have/support nor can't use because of the NAT which they are behind.
It has also already been proven that it is very easy to deploy the above
described protocol and I actually I wonder why there is need for yet
another one while the others are sufficient for the purposes requisted.
But that could be me of course ;)

> It is the standard UDP checksum.  The first two lines are the UDP 

Ah, I glanced over it too quickly, usually protocol descriptions don't
include the upper layer protocol again, this more looks like a
redefinition of UDP in this case...

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Fri, 17 Dec 2004 03:20:19 -0800

> coming upto speeds of most lower DSL lines...

The issue is not so much speed but money. If there is a 7-10% overhead,
this is not insignificant, regardless of bandwidth.

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 17 Dec 2004 03:22:47 -0800

Please keep this discussion for the upcoming issue 3 thread:
"Should some of this authentication mechanism "follow-on" atfer the 
tunnel set-up phase
	  as finished?"

To keep the discussion focussed, I will only introduce one issue at a 
time.

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 17 Dec 2004 12:35:53 +0100

> this is not insignificant, regardless of bandwidth.

In general for 'office/home environments' aka webbrowsing and alike, it
seems the trend is that packet length distribution is that about 40% of
the packets is between the 0-400 size. the other 60% is in between
400-1200 with only relatively few packetlengths in tehe 1200-1400 range,
one will have a peak for the 1500 size, thus completely full packets.
On average, from the couple of graphs that I have I would estimate the
packetlength to be around 600 bytes/packet.

This is based on an ethernet (mtu=1500) environment though, thus the
peek at 1500 will move downwards, relative to the mtu size of the
environment. Also, when there is a high concentration of 'downloaders'
it might well be that that the packetsize distribution shifts almost
completely to the maximum mtu. All depends on the usage of the network
and if you count packets or octets as an importance.

There will always be some sort of overhead with encapsulation. But if
you are thinking of that, make a new protocol number which would make it
proto-41 or GRE, which did not work over NAT's.

> "Should some of this authentication mechanism "follow-on" after the 
> tunnel set-up phase as finished?"

Ack, though if you want to minimize the header, you can't introduce any
of those parts anymore because the header is to small ;)

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Fri, 17 Dec 2004 05:14:15 -0800

> packetlength to be around 600 bytes/packet.

This is very good data. However, VoIP has the potential to change this 
picture a lot.
 From what I'm told, the payload is typically 44 bytes...

	- Alain.