Your IP Address is: 38.103.63.61
Re: [moonv6] RE: Vista DNS behavior
From: Jeroen Massar (jeroen@unfix.org)
Date: 09/15/06
- Next message: Chris Mitchell: "RE: [moonv6] RE: Vista DNS behavior - Re: [nav6tf] IPv6 news - weekly summary"
- Previous message: JF Tremblay: "Re: [moonv6] RE: Vista DNS behavior"
- In reply to: JF Tremblay: "Re: [moonv6] RE: Vista DNS behavior"
- Next in thread: Jeroen Massar: "Re: [moonv6] RE: Vista DNS behavior"
JF Tremblay wrote:
[..]
>> One only has to know the source & destination IPv4 address of the >> connection, which in effect is a VPN tunnel made for IPv6, and one >> can use it to inject malicious packets at wish, similar to Teredo, >> 6to4 and plain proto-41 tunnels. Sequence number guessing is trivial >> and mostly protects it for very simple replay attacks.
>
> One bemol here. If you use UDP tunneling, you are likely behind a NAT.
> You'll need the UDP port number to inject packets. This is where I
> believe Teredo has a perceived security issue: it broadcasts the NAT
> IPv4 address AND port to the world, as you get them from the address.
One could then indeed generate a spoofed Teredo packet which looks like it is coming from the Teredo relay towards the IPv4 + UDP port specified, or the other way around, thus injecting packets in both directions. This is mostly a problem with the statelessness of the protocol and the fact that it is not signed.
This is similar to the problem that proto-41 & 6to4 have, except that for Teredo one knows the endpoints, while with proto-41 one has to guess them. With 6to4 one also knows both of the endpoints, which is why 6to4 is quite vulnerable to these kind of attacks, especially when sending IPv6 packets anonymously through a 6to4 relay as what happened in July: http://lists.cluenet.de/pipermail/ipv6-ops/2006-July/000648.php Quite sad that all those operators decided to, for the time being, shutdown their public services because of that, simply because the ISP who was originating the packets didn't care less about 400mbit extra outgoing over transit; "We have enough bandwidth, upgrade your router if you can't handle it" was the response they gave. The power to de-peer helped in that event.
>> To take the list of the pdf I mentioned above, TSP is vulnerable to: >> - spoofing, just inject a lot of packets with a guessed sequence. >> - man in the middle attacks, when one is on-link/on-route one can >> easily spoof catch all the packets and insert arbitrary packets >> as one has control over the sequence numbering.
>
> Actually, the UDP tunnel is vulnerable. As you mentioned, TSP is only
> used for the tunnel setup. Using reverse path forwarding check on the
> server may mitigate this problem, although it doesn't prevent it for the
> man-in-the-middle attack.
(u)RPF is quite useless when there are other routes to inject packets into the network, which is especially the case when the packets go over the generic internet and thus the network between client and server is unprotected. Unfortunately there is no political means to get every ISP on this planet to start doing (u)RPF. Technically ISP's complain that their routers can't handle the extra load they will get from it (while actually they will be moving less bits, and usually spoofed data that flows goes very fast ;)
This also shows again the applicability domain of the various protocols. Teredo is there to automate deployment of IPv6 with as little hassle as possible, on the complete other side, AYIYA is targetted specifically for a network where the path between client and PoP is untrusted. Signing of packets could be turned off though if really wanted, but I advise against it.
In the cases of the stateless and non-signed protocols having a trusted network is important if one wants to avoid the security problems caused by man-in-the-middle attacks.
[..]
>> Next to all of this, unless Hexago made an update to the TSP tun/tap >> driver for Windows, the TSP client won't even run on Vista as the >> tun/tap driver bluescreens due to the API's having changed ;) >> So how did you test Vista + TSP in the first place, or is there a >> version out that supports Vista?
>
> Not yet. From what we heard from MS, there are also issues configuring
> proto-41 tunnels using netsh in Vista. They wouldn't fix it before RC1,
> according to the information they provided us (which is a shame).
What I know about this part is that M$ (the folks in the cc's should be able to confirm) that there is an outstanding bug for the fact that proto-41 is missing, but the priority for this problem is far from the top of the list (even though it would in effect only require the old configuration syntax in netsh to work). This won't be fixed before SP1 comes out I understood :(
As for the TSP client, the UDPv6 part, that, like AYIYA support in AICCU, tinc and OpenVPN etc, require an update to the Tun/TAP driver for it to function. I have a devel setup for Vista ready but didn't come around to looking into it deeply yet unfortunately. When the Tun/TAP is there proto-41 is not an issue either. Which is why I need some spare time somewhere to fix that up ;)
Greets,
Jeroen
- application/pgp-signature attachment: OpenPGP digital signature
This archive was generated by hypermail 2.1.7 : 12/01/06 EST
