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

On Fri, 2004-12-17 at 12:35 +0200, Pekka Savola wrote:
> From Alain:
> > 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.
> 
> 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.

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

> On Fri, 17 Dec 2004, Jeroen Massar wrote:
> > 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 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.

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 ;)

> > Why is there a checksum in that newly proposed protocol anyway?
> > 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.

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

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

Attachment: signature.asc