3 ms·

Spammers make many fiber to copper to fiber connections. Every call essentially comes from a black box and every carrier is complicit. So if you make a "last m

Spammers make many fiber to copper to fiber connections. Every call essentially comes from a black box and every carrier is complicit. So if you make a "last mile" fine, basically every carrier will be charged "evenly". This plan wouldn't have the incentive structure needed to change carrier behavior. This video explains it nicely . [1] [1] https://youtu.be/WOAapu-XJl8?list=LLfTvbJseqag4h_gPkk1q58g&t=82 https://youtu.be/WOAapu-XJl8?list=LLfTvbJseqag4h_gPkk1q58g&t...

heartbeats 7y ago
Well, carriers would have to block the black boxes and only allow the good networks on. AT&T can peer with Sprint or T-Mobile, but the shady carriers that lets fiber terminate into copper without asking questions have to do due diligence or get cut off. It wouldn't be evenly distributed. Your carrier could pass on the fine at least a few hops deep, until it reaches whoever connected the shady VoIP company to the real network. In the video's example, it would be Google Voice, the owner of the hacked VoIP systems' uplink provider, or the anonymous online call services. It's rare that the spammers use payphones or prepaid cards. Even if it's the same situation as with e-mail spam, this would also be a workable solution for that problem. Say I have a G-Mail account. I get spam from X@hotmail.com. Now G-Mail have to pay me the fine, and Hotmail have to pay GMail the fine, and X has to pay Hotmail the fine. Sure, they can't track down X, but Hotmail have to pay up for letting bad actors on their network. We could also generalize this to BGP, of course. I get a port 22 brute-force attempt to my server, I contact my ISP, they pay me. They contact whoever peered them, who pays, until we get to China, where some local ISP says that a PC on their network was hacked. Too bad. Either the Chinese ISP pays up, or they get depeered by their CN <-> HK ISP, or they get depeered by their uplink, and so on. Here is an example traceroute to the Chinese ecommerce site taobao.com from Cogent. In my example, the fine would travel down this list until it finds someone unwilling to pay up, who then gets depeered. traceroute to 140.205.220.96 (140.205.220.96), 30 hops max, 60 byte packets 1 gi0-1-1-19.5.agr21.jfk02.atlas.cogentco.com (66.28.3.113) 0.693 ms 0.702 ms 2 be2605.ccr41.jfk02.atlas.cogentco.com (154.54.1.153) 0.741 ms 0.759 ms 3 be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106) 6.397 ms be2807.ccr42.dca01.atlas.cogentco.com (154.54.40.110) 6.538 ms 4 be2113.ccr42.atl01.atlas.cogentco.com (154.54.24.222) 17.340 ms be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 17.461 ms 5 be2687.ccr41.iah01.atlas.cogentco.com (154.54.28.70) 31.636 ms 31.606 ms 6 be2928.ccr21.elp01.atlas.cogentco.com (154.54.30.162) 47.240 ms be2927.ccr21.elp01.atlas.cogentco.com (154.54.29.222) 47.095 ms 7 be2930.ccr32.phx01.atlas.cogentco.com (154.54.42.77) 55.345 ms be2929.ccr31.phx01.atlas.cogentco.com (154.54.42.65) 55.417 ms 8 be2931.ccr41.lax01.atlas.cogentco.com (154.54.44.86) 66.946 ms 67.307 ms 9 be3271.ccr41.lax04.atlas.cogentco.com (154.54.42.102) 67.073 ms 67.072 ms 10 38.142.238.34 (38.142.238.34) 69.608 ms 69.608 ms 11 202.97.50.29 (202.97.50.29) 73.785 ms 73.790 ms 12 202.97.71.193 (202.97.71.193) 206.204 ms 206.594 ms 13 202.97.12.193 (202.97.12.193) 200.253 ms * 14 202.97.24.249 (202.97.24.249) 206.719 ms 202.97.62.61 (202.97.62.61) 202.714 ms 15 101.95.120.105 (101.95.120.105) 224.543 ms 101.95.120.233 (101.95.120.233) 219.260 ms 16 124.74.166.18 (124.74.166.18) 222.636 ms 101.95.206.14 (101.95.206.14) 230.753 ms 17 101.95.208.10 (101.95.208.10) 233.093 ms * 18 114.80.58.82 (114.80.58.82) 237.192 ms 180.163.38.82 (180.163.38.82) 213.441 ms 19 116.251.88.134 (116.251.88.134) 204.868 ms 116.251.88.154 (116.251.88.154) 220.342 ms 20 140.205.58.9 (140.205.58.9) 213.268 ms 116.251.106.190 (116.251.106.190) 197.170 ms 21 * * 22 * * 23 * * 24 * * 25 * * 26 * * 27 * * 28 * * 29 * * 30 * *
- AdrianEGraphene 7y ago
  sadly, it is not that simple to determine who is a "good network". Every carrier lets fiber route into copper. Your logic would work, but it is a lot of work for many entities to perform. The simple fact is that neither you nor I can control what the carriers choose to do. You'd have to design a network from the bottom up if you wanted to enact these kinds of changes. You're clearly interested in solving this spam problem and I admire the thought you've put into it. I'd advise that you focus on solutions that can be scaled more simply. If you think of all of the "spam calls" that happen, you'd come to the conclusion that your traceroute would happen 10s of billions of times a year. My advice is to think of ways that don't require the cooperation of multiple entities.
  - heartbeats 7y ago
    > Every carrier lets fiber route into copper. Indeed, they'd have to stop doing that or require them to put up a security deposit. > Your logic would work, but it is a lot of work for many entities to perform. The simple fact is that neither you nor I can control what the carriers choose to do. No, this should be required by law. The only one who has to be bound by it is the last mile carrier - the rest is done as a voluntary agreement. If they don't sign it, they can't route calls into the US. It could be trivially automated. Carrier A sends the message "pay us $X or we depeer you" to carrier B whenever they do not like what they got from carrier B. Their computer system evaluates whether the fine is worth continued peering with A. If it is, they pay, else they don't. This takes milliseconds. There is no need for a human to evaluate the evidence because there is no evidence needed. Naive implementation: def accept_fine(this_fine, value_of_continued_peering, tot_fines): return (value_of_continued_peering > (tot_fines + this_fine))
    - AdrianEGraphene 7y ago
      The US infrastructure is partially made of copper. It would be very expensive (but doable) to change that. Laws, carriers, whatever. Doesn't make a difference, we still have no say over enacting your suggestions. We can sit here and theorize all day about what may work, but if you cannot implement or test your solutions in the real world, what's the point? That's why I suggested coming up with solutions that do not require the participation of large entities. Although I am HIGHLY biased, since I'm working on a peer to peer solution.

heartbeats 7y ago

Well, carriers would have to block the black boxes and only allow the good networks on. AT&T can peer with Sprint or T-Mobile, but the shady carriers that lets fiber terminate into copper without asking questions have to do due diligence or get cut off. It wouldn't be evenly distributed. Your carrier could pass on the fine at least a few hops deep, until it reaches whoever connected the shady VoIP company to the real network. In the video's example, it would be Google Voice, the owner of the hacked VoIP systems' uplink provider, or the anonymous online call services. It's rare that the spammers use payphones or prepaid cards. Even if it's the same situation as with e-mail spam, this would also be a workable solution for that problem. Say I have a G-Mail account. I get spam from X@hotmail.com. Now G-Mail have to pay me the fine, and Hotmail have to pay GMail the fine, and X has to pay Hotmail the fine. Sure, they can't track down X, but Hotmail have to pay up for letting bad actors on their network. We could also generalize this to BGP, of course. I get a port 22 brute-force attempt to my server, I contact my ISP, they pay me. They contact whoever peered them, who pays, until we get to China, where some local ISP says that a PC on their network was hacked. Too bad. Either the Chinese ISP pays up, or they get depeered by their CN <-> HK ISP, or they get depeered by their uplink, and so on. Here is an example traceroute to the Chinese ecommerce site taobao.com from Cogent. In my example, the fine would travel down this list until it finds someone unwilling to pay up, who then gets depeered. traceroute to 140.205.220.96 (140.205.220.96), 30 hops max, 60 byte packets 1 gi0-1-1-19.5.agr21.jfk02.atlas.cogentco.com (66.28.3.113) 0.693 ms 0.702 ms 2 be2605.ccr41.jfk02.atlas.cogentco.com (154.54.1.153) 0.741 ms 0.759 ms 3 be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106) 6.397 ms be2807.ccr42.dca01.atlas.cogentco.com (154.54.40.110) 6.538 ms 4 be2113.ccr42.atl01.atlas.cogentco.com (154.54.24.222) 17.340 ms be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 17.461 ms 5 be2687.ccr41.iah01.atlas.cogentco.com (154.54.28.70) 31.636 ms 31.606 ms 6 be2928.ccr21.elp01.atlas.cogentco.com (154.54.30.162) 47.240 ms be2927.ccr21.elp01.atlas.cogentco.com (154.54.29.222) 47.095 ms 7 be2930.ccr32.phx01.atlas.cogentco.com (154.54.42.77) 55.345 ms be2929.ccr31.phx01.atlas.cogentco.com (154.54.42.65) 55.417 ms 8 be2931.ccr41.lax01.atlas.cogentco.com (154.54.44.86) 66.946 ms 67.307 ms 9 be3271.ccr41.lax04.atlas.cogentco.com (154.54.42.102) 67.073 ms 67.072 ms 10 38.142.238.34 (38.142.238.34) 69.608 ms 69.608 ms 11 202.97.50.29 (202.97.50.29) 73.785 ms 73.790 ms 12 202.97.71.193 (202.97.71.193) 206.204 ms 206.594 ms 13 202.97.12.193 (202.97.12.193) 200.253 ms * 14 202.97.24.249 (202.97.24.249) 206.719 ms 202.97.62.61 (202.97.62.61) 202.714 ms 15 101.95.120.105 (101.95.120.105) 224.543 ms 101.95.120.233 (101.95.120.233) 219.260 ms 16 124.74.166.18 (124.74.166.18) 222.636 ms 101.95.206.14 (101.95.206.14) 230.753 ms 17 101.95.208.10 (101.95.208.10) 233.093 ms * 18 114.80.58.82 (114.80.58.82) 237.192 ms 180.163.38.82 (180.163.38.82) 213.441 ms 19 116.251.88.134 (116.251.88.134) 204.868 ms 116.251.88.154 (116.251.88.154) 220.342 ms 20 140.205.58.9 (140.205.58.9) 213.268 ms 116.251.106.190 (116.251.106.190) 197.170 ms 21 * * 22 * * 23 * * 24 * * 25 * * 26 * * 27 * * 28 * * 29 * * 30 * *

AdrianEGraphene 7y ago
sadly, it is not that simple to determine who is a "good network". Every carrier lets fiber route into copper. Your logic would work, but it is a lot of work for many entities to perform. The simple fact is that neither you nor I can control what the carriers choose to do. You'd have to design a network from the bottom up if you wanted to enact these kinds of changes. You're clearly interested in solving this spam problem and I admire the thought you've put into it. I'd advise that you focus on solutions that can be scaled more simply. If you think of all of the "spam calls" that happen, you'd come to the conclusion that your traceroute would happen 10s of billions of times a year. My advice is to think of ways that don't require the cooperation of multiple entities.
- heartbeats 7y ago
  > Every carrier lets fiber route into copper. Indeed, they'd have to stop doing that or require them to put up a security deposit. > Your logic would work, but it is a lot of work for many entities to perform. The simple fact is that neither you nor I can control what the carriers choose to do. No, this should be required by law. The only one who has to be bound by it is the last mile carrier - the rest is done as a voluntary agreement. If they don't sign it, they can't route calls into the US. It could be trivially automated. Carrier A sends the message "pay us $X or we depeer you" to carrier B whenever they do not like what they got from carrier B. Their computer system evaluates whether the fine is worth continued peering with A. If it is, they pay, else they don't. This takes milliseconds. There is no need for a human to evaluate the evidence because there is no evidence needed. Naive implementation: def accept_fine(this_fine, value_of_continued_peering, tot_fines): return (value_of_continued_peering > (tot_fines + this_fine))
  - AdrianEGraphene 7y ago
    The US infrastructure is partially made of copper. It would be very expensive (but doable) to change that. Laws, carriers, whatever. Doesn't make a difference, we still have no say over enacting your suggestions. We can sit here and theorize all day about what may work, but if you cannot implement or test your solutions in the real world, what's the point? That's why I suggested coming up with solutions that do not require the participation of large entities. Although I am HIGHLY biased, since I'm working on a peer to peer solution.