Opened 12 years ago

Closed 12 years ago

#2778 closed Bug (fixed)

IPv6 PEX accepts garbage addresses

Reported by: chris-jericho Owned by: charles
Priority: Normal Milestone: 1.90
Component: libtransmission Version: 1.80
Severity: Normal Keywords: backport-1.8x
Cc: jch@…

Description

Running Transmission 1.80 (released yesterday, but the bug did happen with previous betas), ipv6 peers found in the DHT seem to have erroneous addresses. The following is a tcpdump trace of T trying to connect to some ipv6 peers (ipv4 peers are blocked, so those adresses can't come from either peer exchange or tracker communication)

14:33:50.446322 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52098 > ::a8:8:fcc0:f008:d00.28672: S 3831686059:3831686059(0) win 65535 <mss 1420,sackOK,eol>
14:33:50.650586 IP6 2002:63e8:9080::222:41ff:fe3b:cea6.58788 > 2a01:e35:2f4c:6520:3091:acca:3930:4f04.59189: UDP, length 58
14:33:51.447287 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52113 > ::4019:100:0:989d:ed02:100:0.13056: S 831754404:831754404(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.447423 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52112 > ::1770:9:c91c:4:bec8:f008:cc0.50984: S 2992000740:2992000740(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.447482 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52111 > 0:a:fff8:0:8202:8000::.2: S 4172557221:4172557221(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.447560 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52110 > ::83:f21c:83:f208.63161: S 851019142:851019142(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.447612 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52109 > ::2:fff8:0:8206:8000:f008:d00.1024: S 747180951:747180951(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.447664 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52108 > ::2:0:ea:8:fc14:f008:cf0.38400: S 806237730:806237730(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.447714 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52107 > ::4:0:4b:8:fcc0:f008:d00.20640: S 193085883:193085883(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.547892 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52116 > ::1:0:bd:8:fcc0:f008:d00.9216: S 3611322657:3611322657(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.547997 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52115 > ::1:0:7d:8:fcc0:f008:d00.33792: S 4274082535:4274082535(0) win 65535 <mss 1420,sackOK,eol>
14:33:51.548053 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.52114 > ::216:cbff:fe04:bacb.8500: S 268454605:268454605(0) win 65535 <mss 1420,sackOK,eol>
14:33:53.713397 IP6 2002:54f5:cefb::54f5:cefb.49001 > 2a01:e35:2f4c:6520:3091:acca:3930:4f04.59189: UDP, length 140
14:33:53.713956 IP6 2a01:e35:2f4c:6520:3091:acca:3930:4f04.59189 > 2002:54f5:cefb::54f5:cefb.49001: UDP, length 56

Addresses like ::1:0:bd:8:fcc0:f008:d00.9216 are definitely not in the global scope space, and I can see tons of those. Sometimes, some teredo or 6to4 valid addresses are tried, though.

This bug totally defeats the purpose of having an ipv6 DHT : Transmission is unusable on an ipv6 only network.

Attachments (2)

trace-ipv6.patch (2.3 KB) - added by jch 12 years ago.
0001-Temporarily-reject-addresses-outside-of-2000-3.patch (1.5 KB) - added by jch 12 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 follow-up: Changed 12 years ago by jch

Can you provide a copy of the torrent, or is it indiscrete?

comment:2 Changed 12 years ago by charles

  • Cc jch@… added

CC'ing our DHT and IPv6 expert jch :)

comment:3 in reply to: ↑ 1 Changed 12 years ago by chris-jericho

Replying to jch:

Can you provide a copy of the torrent, or is it indiscrete?

PM'd you the link on the forum. But it's not specific with this one, it seems to happen with any well seeded torrent.

comment:4 Changed 12 years ago by jch

  • Summary changed from ipv6 peers found in the DHT have random/erroneous addresses to ipv6 peers learned from PEX have random/erroneous addresses

I can reproduce this, but I found that the erroneous addresses come from PEX, not from the DHT. Here's some evidence:

LTEP handshake: 2002:7623:cafa::7623:cafa
IPv6 PEX: [2001:0:cf2e:3096:20b8:fcc:c30e:a9db]:47459 [2002:3c32:cc38::3c32:cc38]:25491 [2001:0:cf2e:3096:cbe:3762:35a6:4377]:19308 
IPv6 DHT: [2001:0:5ef5:73bc:1077:21b0:a45a:2ab4]:6969 
[...]
IPv6 DHT: [2001:0:5ef5:73bc:1077:21b0:a45a:2ab4]:6969 
IPv6 PEX: [2001:0:4137:9e50:0:ca0e:b278:413c]:61906 [402a:d00:d8bd:bb0:5e83:a00:b0d3:4217]:2560 [2001:0:4137:9e50:0:21e3:2f9a:99d5]:38100 [402a:d00:d8bd:bb0:5e83:a00:b013:2e00]:2560 [3cf3:700:100:0:98ad:7c00:100:0]:31744 [402a:d00:d8bd:bb0:5e83:a00:90d7:4217]:2560 [::b:c8c4:c:2884]:37346 [78:ab01:100:0:409d:8913:100:0]:43777 [3cf3:700:100:0:98ed:f812:100:0]:63506 [2000:0:98be:bb0:a178:8091:70:1400]:2560 [2000:0:98be:bb0:4d94:800:b4a1:2800]:2048 [100::700d:c813:100:0]:51219 [100::701d:8813:100:0]:34835 [402a:d00:d8bd:bb0:5e83:a00:8026:2a00]:2560 [1de1:700:100:0:509d:5d12:100:0]:23826 [100::702d:9613:100:0]:38419 [b:83dc:b:83dc:b8:fc5c:0:a887]:48448 [402a:d00:d8bd:bb0:5e83:a00:800a:4317]:2560 [402a:d00:d8bd:bb0:5e83:a00:602a:2400]:2560 [402a:d00:d8bd:bb0:5e83:a00:40bf:2b00]:2560 [402a:d00:d8bd:bb0:5e83:a00:20bb:4714]:2560 [402a:d00:d8bd:bb0:5e83:a00:10cc:4114]:2560 [402a:d00:d8bd:bb0:5e83:a00:100d:b414]:2560 [::70bd:a13:100:0]:2579 [400c:4413:100:0:988d:eb12:100:0]:60178 [400c:4413:100:0:308d:eb12:100:0]:60178 [::706d:ac13:100:0]:44051 [70:6901:100:d71c:62:b001:100:0]:47361 [100::70bd:a13:100:0]:2579 [0:5013:100:0:98ed:f812:100:0]:14336 [100::2050:f00:100:0]:33810 [0:4:0:5d3:8:fcc0:f008:d00]:38912 [0:4:0:9f:8:fc14:f008:cf0]:35328 [22:d400:100:0:c0dd:eb12:100:0]:23064 [::704d:e912:100:0]:59666 [56:870:9000:5f3c:20f:b000:0:a887]:24304 [20:5e01:100:ce1f:6e:c001:100:0]:16153 [::9694:d6fc:83:f41c:83:f408]:52544 [100::4050:f00:100:0]:32531 [0:1:0:85:8:fcc0:f008:d00]:23040 [::fc00:0:3453:aa90:70:1400]:1280 [b:83dc:b:83dc:ba:f05c:0:a887]:48448 [b:b0b0:1b:8000:663:3d70:9b:de00]:43392 [0:4:0:87:8:fc14:f008:cf0]:2560 [b:b0b0:938c:d6fc:938c:8010:f008:cb0]:52544 [100::70ad:7c00:100:0]:31744 [::709d:5d12:100:0]:23826 [::709d:3d13:100:0]:15635 [100::709d:5d12:100:0]:23826 [::8:4ee4:0:0:f008:b20]:19848 
IPv6 PEX: [::709d:dd01:100:0]:56577 [::709d:f512:100:0]:62738 [::70ad:7e00:100:0]:32256 [::70bd:a13:100:0]:2579 [::70bd:f112:100:0]:61714 [::704d:de12:100:0]:56850 [b:b0b0:1b:8000:663:3d70:9b:de00]:43392 [::704d:2b13:100:0]:11027 [::70cd:813:100:0]:2067 [::700d:b815:100:0]:47125 [::70cd:a13:100:0]:2579 [b:b0b0:b2:2a00:b22:5180:9f:c200]:51536 [::70cd:9413:100:0]:37907 [::700d:8212:100:0]:33298 [3800::fe00:0:4000:0]:61222 [::70dd:9801:100:0]:38913 [::70ed:9413:100:0]:37907 [::70fd:a0b:100:0]:2571 [::985d:f112:100:0]:61714 [::989d:5d02:100:0]:23810 [::a000:8514:0:0]:25760 [3800::82:8e00:4000:0]:31744 [::700d:7a12:100:0]:31250 [::c8:8:fc14:f008:cf0]:9728 [::c8:8:fcc0:f008:d00]:11776 [::704d:e912:100:0]:59666 [23c7:800:100:0:1e32:224b::]:8779 [::5:a4ec:0:0:f008:b20]:42192 [::6:8a1c:a000:8514:0:0]:15684 [2002:63ef:2bc6:0:223:6cff:fe98:a0fb]:56019 [2002:62e4:4fa1::62e4:4fa1]:36785 [::8:4ee4:0:0:f008:b20]:19848 [::200:0:0:28:8b7:6bf0]:164 [::200:0:0:2a:8b7:6bf0]:172 [::200:0:0:2c:8b7:6bf0]:180 [::703d:90b:100:0]:2315 [::700d:913:100:0]:2323 [2001:0:d5c7:a2d6:1caa:1dc1:ae6c:c1a9]:18675 [2001:0:d5c7:a2d6:1c98:8d61:a60f:af46]:13161 [2001:0:d5c7:a2d6:1c96:d8e7:ad57:c6a0]:55931 [2001:0:d5c7:a2d6:1c25:ebae:3e40:f6e9]:41414 [2001:0:d5c7:a2d6:14a5:2c01:a83b:ccd3]:52421 [2001:0:d5c7:a2d6:147e:9865:a3f9:18be]:55195 [2001:0:d5c7:a2d6:1454:258a:a97d:3c60]:22077 [2001:0:d5c7:a2d6:1435:2e6:aa69:1fad]:50378 [2001:0:d5c7:a2d6:1426:1531:ac03:7377]:55280 [::9694:d6fc:83:f41c:83:f408]:52544 [::98be:bb0:4d94:800:242c:2700]:2048 [::a000:6224:a000:6224:50:cd90]:184 [::a000:6224:a000:6224:f008:b20]:42192 
IPv6 DHT: [2001:0:5ef5:73bc:1077:21b0:a45a:2ab4]:6969 

I'm attaching a patch (not to be committed) that generates this kind of debugging output.

Charles, any ideas what to do about that?

Changed 12 years ago by jch

comment:5 Changed 12 years ago by jch

  • Component changed from Transmission to libtransmission
  • Owner set to charles
  • Summary changed from ipv6 peers learned from PEX have random/erroneous addresses to ipv6 PEX accepts garbage addresses
  • Type changed from Bug to Enhancement

Changing title to reflect that this is not our bug.

comment:6 Changed 12 years ago by jch

Chris suggested (by private mail) that we should tighten the martian filter to reject anything that's not in 2000::/3.

The problem with that is that while addresses outside of 2000::/3 are currently reserved, they might not remain so in the future. Limiting the IPv6 global Internet to 2000::/3 means that when addresses outside of that prefix start being assigned, a lot of software will break.

We're having a lot of problems with old software rejecting previously reserved addresses in IPv4, I'm not going to participate in creating the same problems in IPv6.

comment:7 Changed 12 years ago by jch

  • Keywords martian added; DHT peer addresses removed
  • Summary changed from ipv6 PEX accepts garbage addresses to IPv6 PEX accepts garbage addresses

comment:8 Changed 12 years ago by chris-jericho

I don't think such a martian filter is made to stay in the long term.

The problem here is that another implementation is polluting our pool of known peers. Is it possible to know which one? so we can ask its developers to fix the bug asap. Meanwhile, we definitely need to filter those martians out, and filtering site and link local addresses won't be enough here. Then, when the bug is fixed, we can loosen the filter to avoid any problem with future IANA allocations.

comment:9 Changed 12 years ago by jch

Experience, however, shows that such filters tend to remain for ages. How do you guarantee that Transmission's martian filter won't be cut-n-pasted textually into other applications, and will end up causing problems down the line.

Search the web for 240.0.0.0/4 if you want a good example of such problems.

comment:10 Changed 12 years ago by jch

How about the following? (Completely untested.)

comment:11 Changed 12 years ago by charles

jch: your patch made me spill my drink.

comment:12 Changed 12 years ago by chris-jericho

I checked in the source, global_unicast_address is already checking against 2000::/3 to determine if we have a global unicast address or not and there might be other places where such checks are used. I would at least cache the return value of tr_time() to avoid being too resource intensive.

comment:13 Changed 12 years ago by charles

tr_time() is a free call.

Mayan calendar aside, do the both of you think this is a reasonable solution? If you think it needs more testing we can throw it into the trunk nightly builds...

comment:14 Changed 12 years ago by chris-jericho

I'm OK for a test run.

Even though I don't like the idea of checking against the current date, if jch fins it necessary, I can live with that.

comment:15 Changed 12 years ago by charles

Committed to trunk by r10049

comment:16 Changed 12 years ago by chris-jericho

Oops, i kind of missed a typo : the check should be (address[0] & 0xE0) != 0x20) instead of (address[0] & 0xC0) != 0x20)

comment:17 Changed 12 years ago by charles

typo fixed in trunk by r10051. thanks!

comment:18 Changed 12 years ago by chris-jericho

OK after multiple tests I couldn't see any connection attempt outside of 2000::/3. T connects to ipv6 peers far more quickly now.

I think this can be marked as fixed. thanx :)

comment:19 Changed 12 years ago by charles

  • Keywords backport-1.8x added; ipv6 martian removed
  • Status changed from new to assigned

comment:20 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.90
  • Resolution set to fixed
  • Status changed from assigned to closed
  • Type changed from Enhancement to Bug

marking as fixed w/milestone 1.90.

adding backport-1.8x tag. this fix should be included if/when there's another 1.8x release.

Note: See TracTickets for help on using tickets.