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

[Alain Durand <[e-mail]>]

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.


On Dec 17, 2004, at 3:11 AM, Jeroen Massar wrote:

>> 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
>
> _______________________________________________
> v6tc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/v6tc


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