Port 2323/tcp
I've been seeing a lot of rejections in my logs for 2323/tcp. According to the Storm Center, this is what the Mirai botnet scanner uses to look for other target devices. Is it worthwhile to report sightings to the appropriate abuse addresses? (That assumes there *is* an abuse address associated with the IPv4 address that is the source.) Would administrations receiving these notices do anything with them? Alternatively, is there anyone collecting this information from people like me to expose the IP addresses of possible infections? I am toying with the idea of setting up a honey-pot, but I'm so far behind with $DAYJOB that such a project will have to wait a bit. I want to be a good net citizen. I also want to make sure I'm not wasting my time. Today's crop: > 1.34.169.183 > 12.221.236.2 > 14.138.22.12 > 14.169.142.30 > 14.174.71.158 > 14.177.197.101 > 31.168.146.33 > 31.168.212.174 > 36.71.224.179 > 36.72.253.206 > 37.106.18.86 > 42.115.187.189 > 42.117.254.248 > 42.119.228.222 > 43.225.195.180 > 46.59.6.249 > 49.114.192.91 > 58.11.238.146 > 58.186.231.59 > 59.8.136.21 > 59.49.191.4 > 59.57.68.56 > 59.126.35.47 > 59.126.242.70 > 59.127.104.67 > 59.127.242.8 > 60.251.125.125 > 61.219.165.38 > 73.84.152.194 > 78.179.113.148 > 78.186.61.30 > 78.189.169.142 > 78.226.222.234 > 79.119.74.255 > 81.16.8.193 > 81.101.233.14 > 81.214.121.43 > 81.214.134.133 > 81.214.137.197 > 82.77.68.189 > 83.233.40.141 > 85.96.202.199 > 85.99.121.41 > 85.238.103.111 > 86.121.225.48 > 87.251.252.22 > 88.249.224.167 > 89.122.87.239 > 89.151.128.198 > 90.177.91.201 > 92.53.52.235 > 92.55.231.90 > 94.31.239.178 > 94.254.41.152 > 94.255.162.90 > 95.78.245.54 > 95.106.34.92 > 95.161.236.182 > 96.57.103.19 > 101.0.43.13 > 108.203.68.245 > 110.55.108.215 > 110.136.233.10 > 112.133.69.176 > 112.165.93.130 > 112.186.42.216 > 113.5.224.110 > 113.161.64.11 > 113.169.18.153 > 113.171.98.158 > 113.172.4.204 > 113.183.204.112 > 113.188.44.246 > 114.32.28.219 > 114.32.87.32 > 114.32.189.5 > 114.34.29.167 > 114.34.170.10 > 114.35.153.123 > 114.226.53.133 > 115.76.127.118 > 116.73.65.248 > 116.100.170.92 > 117.0.7.77 > 117.1.26.234 > 117.195.254.3 > 118.32.44.99 > 118.42.15.21 > 118.43.112.120 > 118.100.64.159 > 118.163.191.208 > 119.199.160.207 > 119.202.78.47 > 120.71.215.81 > 121.129.203.22 > 121.178.104.129 > 121.180.53.143 > 122.117.245.28 > 123.9.72.86 > 123.16.78.77 > 123.23.49.149 > 123.24.108.10 > 123.24.250.187 > 123.25.74.209 > 123.27.159.13 > 123.240.245.72 > 124.66.99.251 > 124.131.28.38 > 125.166.193.206 > 125.227.138.132 > 138.204.203.66 > 171.97.245.221 > 171.224.7.147 > 171.226.20.220 > 171.232.118.93 > 171.248.210.120 > 171.249.223.213 > 171.250.26.209 > 173.56.21.67 > 175.138.81.130 > 175.203.202.232 > 175.207.137.139 > 175.211.251.156 > 177.207.49.108 > 177.207.67.170 > 177.223.52.193 > 178.222.246.96 > 179.4.140.63 > 179.235.55.39 > 179.253.163.107 > 180.73.117.62 > 180.254.224.10 > 182.37.156.98 > 182.180.80.75 > 182.180.123.43 > 183.46.49.216 > 183.144.245.235 > 186.19.48.158 > 186.69.170.130 > 186.219.1.156 > 187.104.248.17 > 187.211.63.51 > 188.209.153.15 > 189.101.220.244 > 189.234.9.147 > 191.103.35.250 > 191.180.198.31 > 191.249.21.41 > 196.207.83.23 > 197.224.37.108 > 201.243.225.103 > 210.178.250.121 > 211.7.146.51 > 211.216.202.191 > 213.5.216.213 > 213.14.195.100 > 213.170.76.149 > 217.129.243.48 > 218.161.121.178 > 218.186.43.224 > 220.85.169.133 > 220.132.111.124 > 220.133.24.142 > 220.133.198.71 > 220.133.234.229 > 220.134.132.200 > 220.134.193.133 > 220.135.64.43 > 221.145.147.78 > 221.159.105.17 > 221.167.64.53 > 222.254.238.188 > 223.154.223.159
Re: Port 2323/tcp
It's pretty much part of the IBR now. And what can a provider do, really? It's not likely he will expend much effort blocking customers. Maybe we should all start filtering 2323? -mel via cell > On Nov 16, 2016, at 11:53 AM, Stephen Satchell wrote: > > I've been seeing a lot of rejections in my logs for 2323/tcp. According > to the Storm Center, this is what the Mirai botnet scanner uses to look > for other target devices. > > Is it worthwhile to report sightings to the appropriate abuse addresses? > (That assumes there *is* an abuse address associated with the IPv4 > address that is the source.) Would administrations receiving these > notices do anything with them? > > Alternatively, is there anyone collecting this information from people > like me to expose the IP addresses of possible infections? > > I am toying with the idea of setting up a honey-pot, but I'm so far > behind with $DAYJOB that such a project will have to wait a bit. > > I want to be a good net citizen. I also want to make sure I'm not > wasting my time. > > Today's crop: > >> 1.34.169.183 >> 12.221.236.2 >> 14.138.22.12 >> 14.169.142.30 >> 14.174.71.158 >> 14.177.197.101 >> 31.168.146.33 >> 31.168.212.174 >> 36.71.224.179 >> 36.72.253.206 >> 37.106.18.86 >> 42.115.187.189 >> 42.117.254.248 >> 42.119.228.222 >> 43.225.195.180 >> 46.59.6.249 >> 49.114.192.91 >> 58.11.238.146 >> 58.186.231.59 >> 59.8.136.21 >> 59.49.191.4 >> 59.57.68.56 >> 59.126.35.47 >> 59.126.242.70 >> 59.127.104.67 >> 59.127.242.8 >> 60.251.125.125 >> 61.219.165.38 >> 73.84.152.194 >> 78.179.113.148 >> 78.186.61.30 >> 78.189.169.142 >> 78.226.222.234 >> 79.119.74.255 >> 81.16.8.193 >> 81.101.233.14 >> 81.214.121.43 >> 81.214.134.133 >> 81.214.137.197 >> 82.77.68.189 >> 83.233.40.141 >> 85.96.202.199 >> 85.99.121.41 >> 85.238.103.111 >> 86.121.225.48 >> 87.251.252.22 >> 88.249.224.167 >> 89.122.87.239 >> 89.151.128.198 >> 90.177.91.201 >> 92.53.52.235 >> 92.55.231.90 >> 94.31.239.178 >> 94.254.41.152 >> 94.255.162.90 >> 95.78.245.54 >> 95.106.34.92 >> 95.161.236.182 >> 96.57.103.19 >> 101.0.43.13 >> 108.203.68.245 >> 110.55.108.215 >> 110.136.233.10 >> 112.133.69.176 >> 112.165.93.130 >> 112.186.42.216 >> 113.5.224.110 >> 113.161.64.11 >> 113.169.18.153 >> 113.171.98.158 >> 113.172.4.204 >> 113.183.204.112 >> 113.188.44.246 >> 114.32.28.219 >> 114.32.87.32 >> 114.32.189.5 >> 114.34.29.167 >> 114.34.170.10 >> 114.35.153.123 >> 114.226.53.133 >> 115.76.127.118 >> 116.73.65.248 >> 116.100.170.92 >> 117.0.7.77 >> 117.1.26.234 >> 117.195.254.3 >> 118.32.44.99 >> 118.42.15.21 >> 118.43.112.120 >> 118.100.64.159 >> 118.163.191.208 >> 119.199.160.207 >> 119.202.78.47 >> 120.71.215.81 >> 121.129.203.22 >> 121.178.104.129 >> 121.180.53.143 >> 122.117.245.28 >> 123.9.72.86 >> 123.16.78.77 >> 123.23.49.149 >> 123.24.108.10 >> 123.24.250.187 >> 123.25.74.209 >> 123.27.159.13 >> 123.240.245.72 >> 124.66.99.251 >> 124.131.28.38 >> 125.166.193.206 >> 125.227.138.132 >> 138.204.203.66 >> 171.97.245.221 >> 171.224.7.147 >> 171.226.20.220 >> 171.232.118.93 >> 171.248.210.120 >> 171.249.223.213 >> 171.250.26.209 >> 173.56.21.67 >> 175.138.81.130 >> 175.203.202.232 >> 175.207.137.139 >> 175.211.251.156 >> 177.207.49.108 >> 177.207.67.170 >> 177.223.52.193 >> 178.222.246.96 >> 179.4.140.63 >> 179.235.55.39 >> 179.253.163.107 >> 180.73.117.62 >> 180.254.224.10 >> 182.37.156.98 >> 182.180.80.75 >> 182.180.123.43 >> 183.46.49.216 >> 183.144.245.235 >> 186.19.48.158 >> 186.69.170.130 >> 186.219.1.156 >> 187.104.248.17 >> 187.211.63.51 >> 188.209.153.15 >> 189.101.220.244 >> 189.234.9.147 >> 191.103.35.250 >> 191.180.198.31 >> 191.249.21.41 >> 196.207.83.23 >> 197.224.37.108 >> 201.243.225.103 >> 210.178.250.121 >> 211.7.146.51 >> 211.216.202.191 >> 213.5.216.213 >> 213.14.195.100 >> 213.170.76.149 >> 217.129.243.48 >> 218.161.121.178 >> 218.186.43.224 >> 220.85.169.133 >> 220.132.111.124 >> 220.133.24.142 >> 220.133.198.71 >> 220.133.234.229 >> 220.134.132.200 >> 220.134.193.133 >> 220.135.64.43 >> 221.145.147.78 >> 221.159.105.17 >> 221.167.64.53 >> 222.254.238.188 >> 223.154.223.159 >
Re: Port 2323/tcp
Probably best to go with A) what we could do in the best of situations and B) what the rest will do. Some of us are last mile networks and *DO* care. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mel Beckman" To: l...@satchell.net Cc: nanog@nanog.org Sent: Wednesday, November 16, 2016 11:25:34 AM Subject: Re: Port 2323/tcp It's pretty much part of the IBR now. And what can a provider do, really? It's not likely he will expend much effort blocking customers. Maybe we should all start filtering 2323? -mel via cell > On Nov 16, 2016, at 11:53 AM, Stephen Satchell wrote: > > I've been seeing a lot of rejections in my logs for 2323/tcp. According > to the Storm Center, this is what the Mirai botnet scanner uses to look > for other target devices. > > Is it worthwhile to report sightings to the appropriate abuse addresses? > (That assumes there *is* an abuse address associated with the IPv4 > address that is the source.) Would administrations receiving these > notices do anything with them? > > Alternatively, is there anyone collecting this information from people > like me to expose the IP addresses of possible infections? > > I am toying with the idea of setting up a honey-pot, but I'm so far > behind with $DAYJOB that such a project will have to wait a bit. > > I want to be a good net citizen. I also want to make sure I'm not > wasting my time. > > Today's crop: > >> 1.34.169.183 >> 12.221.236.2 >> 14.138.22.12 >> 14.169.142.30 >> 14.174.71.158 >> 14.177.197.101 >> 31.168.146.33 >> 31.168.212.174 >> 36.71.224.179 >> 36.72.253.206 >> 37.106.18.86 >> 42.115.187.189 >> 42.117.254.248 >> 42.119.228.222 >> 43.225.195.180 >> 46.59.6.249 >> 49.114.192.91 >> 58.11.238.146 >> 58.186.231.59 >> 59.8.136.21 >> 59.49.191.4 >> 59.57.68.56 >> 59.126.35.47 >> 59.126.242.70 >> 59.127.104.67 >> 59.127.242.8 >> 60.251.125.125 >> 61.219.165.38 >> 73.84.152.194 >> 78.179.113.148 >> 78.186.61.30 >> 78.189.169.142 >> 78.226.222.234 >> 79.119.74.255 >> 81.16.8.193 >> 81.101.233.14 >> 81.214.121.43 >> 81.214.134.133 >> 81.214.137.197 >> 82.77.68.189 >> 83.233.40.141 >> 85.96.202.199 >> 85.99.121.41 >> 85.238.103.111 >> 86.121.225.48 >> 87.251.252.22 >> 88.249.224.167 >> 89.122.87.239 >> 89.151.128.198 >> 90.177.91.201 >> 92.53.52.235 >> 92.55.231.90 >> 94.31.239.178 >> 94.254.41.152 >> 94.255.162.90 >> 95.78.245.54 >> 95.106.34.92 >> 95.161.236.182 >> 96.57.103.19 >> 101.0.43.13 >> 108.203.68.245 >> 110.55.108.215 >> 110.136.233.10 >> 112.133.69.176 >> 112.165.93.130 >> 112.186.42.216 >> 113.5.224.110 >> 113.161.64.11 >> 113.169.18.153 >> 113.171.98.158 >> 113.172.4.204 >> 113.183.204.112 >> 113.188.44.246 >> 114.32.28.219 >> 114.32.87.32 >> 114.32.189.5 >> 114.34.29.167 >> 114.34.170.10 >> 114.35.153.123 >> 114.226.53.133 >> 115.76.127.118 >> 116.73.65.248 >> 116.100.170.92 >> 117.0.7.77 >> 117.1.26.234 >> 117.195.254.3 >> 118.32.44.99 >> 118.42.15.21 >> 118.43.112.120 >> 118.100.64.159 >> 118.163.191.208 >> 119.199.160.207 >> 119.202.78.47 >> 120.71.215.81 >> 121.129.203.22 >> 121.178.104.129 >> 121.180.53.143 >> 122.117.245.28 >> 123.9.72.86 >> 123.16.78.77 >> 123.23.49.149 >> 123.24.108.10 >> 123.24.250.187 >> 123.25.74.209 >> 123.27.159.13 >> 123.240.245.72 >> 124.66.99.251 >> 124.131.28.38 >> 125.166.193.206 >> 125.227.138.132 >> 138.204.203.66 >> 171.97.245.221 >> 171.224.7.147 >> 171.226.20.220 >> 171.232.118.93 >> 171.248.210.120 >> 171.249.223.213 >> 171.250.26.209 >> 173.56.21.67 >> 175.138.81.130 >> 175.203.202.232 >> 175.207.137.139 >> 175.211.251.156 >> 177.207.49.108 >> 177.207.67.170 >> 177.223.52.193 >> 178.222.246.96 >> 179.4.140.63 >> 179.235.55.39 >> 179.253.163.107 >> 180.73.117.62 >> 180.254.224.10 >> 182.37.156.98 >> 182.180.80.75 >> 182.180.123.43 >> 183.46.49.216 >> 183.144.245.235 >> 186.19.48.158 >> 186.69.170.130 >> 186.219.1.156 >> 187.104.248.17 >> 187.211.63.51 >> 188.209.153.15 >> 189.101.220.244 >> 189.234.9.147 >> 191.103.35.250 >> 191.180.198.31 >> 191.249.21.41 >> 196.207.83.23 >> 197.224.37.108 >> 201.243.225.103 >> 210.178.250.121 >> 211.7.146.51 >> 211.216.202.191 >> 213.5.216.213 >> 213.14.195.100 >> 213.170.76.149 >> 217.129.243.48 >> 218.161.121.178 >> 218.186.43.224 >> 220.85.169.133 >> 220.132.111.124 >> 220.133.24.142 >> 220.133.198.71 >> 220.133.234.229 >> 220.134.132.200 >> 220.134.193.133 >> 220.135.64.43 >> 221.145.147.78 >> 221.159.105.17 >> 221.167.64.53 >> 222.254.238.188 >> 223.154.223.159 >
pay.gov and IPv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following up on a two year old thread, one of my clients just hit this problem. The failure is not that www.pay.gov is not reachable over ipv6 (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 connection, but the connection then hangs waiting for the TLS handshake. openssl s_client -connect www.pay.gov:443 openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 Browsers (at least firefox) see that as a very slow site, and it does not trigger their happy eyeballs fast failover to ipv4. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgoo9AACgkQL6j7milTFsEIhwCfS2nVWDwjGk5LLaPpAntLC8la RpMAniYdP2OmTcx4+lJmaIu538LK9pqJ =SOdT -END PGP SIGNATURE-
198.154.60.0/22 bogon/hijacked?
pay.gov and IPv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following up on a two year old thread, one of my clients just hit this problem. The failure is not that www.pay.gov is not reachable over ipv6 (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 connection, but the connection then hangs waiting for the TLS handshake. openssl s_client -connect www.pay.gov:443 openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 Browsers (at least firefox) see that as a very slow site, and it does not trigger their happy eyeballs fast failover to ipv4. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC =MS8j -END PGP SIGNATURE-
Re: Port 2323/tcp
We’ve been monitoring/logging/blocking ports 23 and 2323 at our site for the past several weeks, after remediating a 60-75 Mbps attack on a 100 Mbps fiber feed. On port 23, we have accumulated 377,319 different IP addresses hitting our systems. For port 2323, 42,913 different IP addresses. The addresses are widely distributed, making aggregation nearly impossible. Below is a list of offending subnets, ranked by number of offenders (powers of 2), sorry for the length. 14.0.0.0/8 16384 78.0.0.0/8 8192 113.0.0.0/8 8192 117.0.0.0/8 8192 122.0.0.0/8 8192 177.0.0.0/8 8192 179.0.0.0/8 8192 186.0.0.0/8 8192 187.0.0.0/8 8192 189.0.0.0/8 8192 190.0.0.0/8 8192 201.0.0.0/8 8192 1.0.0.0/8 4096 5.0.0.0/8 4096 27.0.0.0/8 4096 36.0.0.0/8 4096 37.0.0.0/8 4096 41.0.0.0/8 4096 42.0.0.0/8 4096 46.0.0.0/8 4096 49.0.0.0/8 4096 59.0.0.0/8 4096 79.0.0.0/8 4096 82.0.0.0/8 4096 88.0.0.0/8 4096 89.0.0.0/8 4096 95.0.0.0/8 4096 109.0.0.0/8 4096 110.0.0.0/8 4096 112.0.0.0/8 4096 114.0.0.0/8 4096 116.0.0.0/8 4096 118.0.0.0/8 4096 119.0.0.0/8 4096 121.0.0.0/8 4096 123.0.0.0/8 4096 124.0.0.0/8 4096 171.0.0.0/8 4096 175.0.0.0/8 4096 176.0.0.0/8 4096 178.0.0.0/8 4096 180.0.0.0/8 4096 181.0.0.0/8 4096 182.0.0.0/8 4096 183.0.0.0/8 4096 191.0.0.0/8 4096 200.0.0.0/8 4096 220.0.0.0/8 4096 31.0.0.0/8 2048 58.0.0.0/8 2048 60.0.0.0/8 2048 61.0.0.0/8 2048 77.0.0.0/8 2048 80.0.0.0/8 2048 81.0.0.0/8 2048 83.0.0.0/8 2048 85.0.0.0/8 2048 86.0.0.0/8 2048 87.0.0.0/8 2048 91.0.0.0/8 2048 92.0.0.0/8 2048 93.0.0.0/8 2048 94.0.0.0/8 2048 103.0.0.0/8 2048 111.0.0.0/8 2048 115.0.0.0/8 2048 120.0.0.0/8 2048 125.0.0.0/8 2048 151.0.0.0/8 2048 188.0.0.0/8 2048 213.0.0.0/8 2048 218.0.0.0/8 2048 222.0.0.0/8 2048 223.0.0.0/8 2048 3.0.0.0/8 1024 6.0.0.0/8 1024 7.0.0.0/8 1024 9.0.0.0/8 1024 11.0.0.0/8 1024 15.0.0.0/8 1024 16.0.0.0/8 1024 17.0.0.0/8 1024 19.0.0.0/8 1024 20.0.0.0/8 1024 21.0.0.0/8 1024 22.0.0.0/8 1024 24.0.0.0/8 1024 25.0.0.0/8 1024 26.0.0.0/8 1024 28.0.0.0/8 1024 29.0.0.0/8 1024 30.0.0.0/8 1024 33.0.0.0/8 1024 34.0.0.0/8 1024 39.0.0.0/8 1024 44.0.0.0/8 1024 48.0.0.0/8 1024 53.0.0.0/8 1024 55.0.0.0/8 1024 56.0.0.0/8 1024 57.0.0.0/8 1024 62.0.0.0/8 1024 84.0.0.0/8 1024 101.0.0.0/8 1024 102.0.0.0/8 1024 106.0.0.0/8 1024 185.0.0.0/8 1024 193.0.0.0/8 1024 194.0.0.0/8 1024 195.0.0.0/8 1024 197.0.0.0/8 1024 202.0.0.0/8 1024 203.0.0.0/8 1024 210.0.0.0/8 1024 211.0.0.0/8 1024 212.0.0.0/8 1024 214.0.0.0/8 1024 215.0.0.0/8 1024 217.0.0.0/8 1024 219.0.0.0/8 1024 221.0.0.0/8 1024 2.0.0.0/8 512 43.0.0.0/8 512 45.0.0.0/8 512 47.0.0.0/8 512 50.0.0.0/8 512 70.0.0.0/8 512 71.0.0.0/8 512 72.0.0.0/8 512 73.0.0.0/8 512 90.0.0.0/8 512 96.0.0.0/8 512 105.0.0.0/8 512 108.0.0.0/8 512 134.0.0.0/8 512 138.0.0.0/8 512 139.0.0.0/8 512 152.0.0.0/8 512 167.0.0.0/8 512 173.0.0.0/8 512 64.0.0.0/8 256 66.0.0.0/8 256 67.0.0.0/8 256 68.0.0.0/8 256 69.0.0.0/8 256 74.0.0.0/8 256 75.0.0.0/8 256 76.0.0.0/8 256 98.0.0.0/8 256 104.0.0.0/8 256 150.0.0.0/8 256 159.0.0.0/8 256 168.0.0.0/8 256 174.0.0.0/8 256 192.0.0.0/8 256 196.0.0.0/8 256 216.0.0.0/8 256 23.0.0.0/8 128 65.0.0.0/8 128 97.0.0.0/8 128 100.0.0.0/8 128 107.0.0.0/8 128 128.0.0.0/8 128 130.0.0.0/8 128 131.0.0.0/8 128 140.0.0.0/8 128 141.0.0.0/8 128 149.0.0.0/8 128 153.0.0.0/8 128 154.0.0.0/8 128 160.0.0.0/8 128 161.0.0.0/8 128 162.0.0.0/8 128 163.0.0.0/8 128 170.0.0.0/8 128 172.0.0.0/8 128 184.0.0.0/8 128 198.0.0.0/8 128 207.0.0.0/8 128 208.0.0.0/8 128 209.0.0.0/8 128 4.0.0.0/8 64 8.0.0.0/8 64 12.0.0.0/8 64 13.0.0.0/8 64 18.0.0.0/8 64 32.0.0.0/8 64 35.0.0.0/8 64 38.0.0.0/8 64 40.0.0.0/8 64 51.0.0.0/8 64 52.0.0.0/8 64 54.0.0.0/8 64 63.0.0.0/8 64 99.0.0.0/8 64 10122.0.0.0/8 64 11122.0.0.0/8 64 114122.0.0.0/8 64 126.0.0.0/8 64 129.0.0.0/8 64 132.0.0.0/8 64 133.0.0.0/8 64 135.0.0.0/8 64 136.0.0.0/8 64 137.0.0.0/8 64 142.0.0.0/8 64 143.0.0.0/8 64 144.0.0.0/8 64 145.0.0.0/8 64 146.0.0.0/8 64 147.0.0.0/8 64 148.0.0.0/8 64 155.0.0.0/8 64 156.0.0.0/8 64 157.0.0.0/8 64 158.0.0.0/8 64 164.0.0.0/8 64 165.0.0.0/8 64 166.0.0.0/8 64 169.0.0.0/8 64 199.0.0.0/8 64 204.0.0.0/8
Re: 198.154.60.0/22 bogon/hijacked?
Hum, Its a 6 weeks old entries in my routers. Even "oddish" its 26272 coming of GTT & HE. 26272 is unassigned at ARIN. -- My experience with GTT & HE find it curious that they let that happen. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 11/13/16 19:49, Jeremy Parsons wrote:
Re: Port 2323/tcp
We have actively started to block 23/tcp to our customer's CPEs Huge amounts of connection attempts / scans over our prefixes. All IPv4, zero on IPv6 (not yet at least). On Wed, Nov 16, 2016 at 8:12 PM, Otto Monnig wrote: > We’ve been monitoring/logging/blocking ports 23 and 2323 at our site for > the past several weeks, after remediating a 60-75 Mbps attack on a 100 Mbps > fiber feed. > > On port 23, we have accumulated 377,319 different IP addresses hitting our > systems. For port 2323, 42,913 different IP addresses. > > The addresses are widely distributed, making aggregation nearly impossible. > > Below is a list of offending subnets, ranked by number of offenders > (powers of 2), sorry for the length. > > 14.0.0.0/8 16384 > 78.0.0.0/8 8192 > 113.0.0.0/8 8192 > 117.0.0.0/8 8192 > 122.0.0.0/8 8192 > 177.0.0.0/8 8192 > 179.0.0.0/8 8192 > 186.0.0.0/8 8192 > 187.0.0.0/8 8192 > 189.0.0.0/8 8192 > 190.0.0.0/8 8192 > 201.0.0.0/8 8192 > 1.0.0.0/8 4096 > 5.0.0.0/8 4096 > 27.0.0.0/8 4096 > 36.0.0.0/8 4096 > 37.0.0.0/8 4096 > 41.0.0.0/8 4096 > 42.0.0.0/8 4096 > 46.0.0.0/8 4096 > 49.0.0.0/8 4096 > 59.0.0.0/8 4096 > 79.0.0.0/8 4096 > 82.0.0.0/8 4096 > 88.0.0.0/8 4096 > 89.0.0.0/8 4096 > 95.0.0.0/8 4096 > 109.0.0.0/8 4096 > 110.0.0.0/8 4096 > 112.0.0.0/8 4096 > 114.0.0.0/8 4096 > 116.0.0.0/8 4096 > 118.0.0.0/8 4096 > 119.0.0.0/8 4096 > 121.0.0.0/8 4096 > 123.0.0.0/8 4096 > 124.0.0.0/8 4096 > 171.0.0.0/8 4096 > 175.0.0.0/8 4096 > 176.0.0.0/8 4096 > 178.0.0.0/8 4096 > 180.0.0.0/8 4096 > 181.0.0.0/8 4096 > 182.0.0.0/8 4096 > 183.0.0.0/8 4096 > 191.0.0.0/8 4096 > 200.0.0.0/8 4096 > 220.0.0.0/8 4096 > 31.0.0.0/8 2048 > 58.0.0.0/8 2048 > 60.0.0.0/8 2048 > 61.0.0.0/8 2048 > 77.0.0.0/8 2048 > 80.0.0.0/8 2048 > 81.0.0.0/8 2048 > 83.0.0.0/8 2048 > 85.0.0.0/8 2048 > 86.0.0.0/8 2048 > 87.0.0.0/8 2048 > 91.0.0.0/8 2048 > 92.0.0.0/8 2048 > 93.0.0.0/8 2048 > 94.0.0.0/8 2048 > 103.0.0.0/8 2048 > 111.0.0.0/8 2048 > 115.0.0.0/8 2048 > 120.0.0.0/8 2048 > 125.0.0.0/8 2048 > 151.0.0.0/8 2048 > 188.0.0.0/8 2048 > 213.0.0.0/8 2048 > 218.0.0.0/8 2048 > 222.0.0.0/8 2048 > 223.0.0.0/8 2048 > 3.0.0.0/8 1024 > 6.0.0.0/8 1024 > 7.0.0.0/8 1024 > 9.0.0.0/8 1024 > 11.0.0.0/8 1024 > 15.0.0.0/8 1024 > 16.0.0.0/8 1024 > 17.0.0.0/8 1024 > 19.0.0.0/8 1024 > 20.0.0.0/8 1024 > 21.0.0.0/8 1024 > 22.0.0.0/8 1024 > 24.0.0.0/8 1024 > 25.0.0.0/8 1024 > 26.0.0.0/8 1024 > 28.0.0.0/8 1024 > 29.0.0.0/8 1024 > 30.0.0.0/8 1024 > 33.0.0.0/8 1024 > 34.0.0.0/8 1024 > 39.0.0.0/8 1024 > 44.0.0.0/8 1024 > 48.0.0.0/8 1024 > 53.0.0.0/8 1024 > 55.0.0.0/8 1024 > 56.0.0.0/8 1024 > 57.0.0.0/8 1024 > 62.0.0.0/8 1024 > 84.0.0.0/8 1024 > 101.0.0.0/8 1024 > 102.0.0.0/8 1024 > 106.0.0.0/8 1024 > 185.0.0.0/8 1024 > 193.0.0.0/8 1024 > 194.0.0.0/8 1024 > 195.0.0.0/8 1024 > 197.0.0.0/8 1024 > 202.0.0.0/8 1024 > 203.0.0.0/8 1024 > 210.0.0.0/8 1024 > 211.0.0.0/8 1024 > 212.0.0.0/8 1024 > 214.0.0.0/8 1024 > 215.0.0.0/8 1024 > 217.0.0.0/8 1024 > 219.0.0.0/8 1024 > 221.0.0.0/8 1024 > 2.0.0.0/8 512 > 43.0.0.0/8 512 > 45.0.0.0/8 512 > 47.0.0.0/8 512 > 50.0.0.0/8 512 > 70.0.0.0/8 512 > 71.0.0.0/8 512 > 72.0.0.0/8 512 > 73.0.0.0/8 512 > 90.0.0.0/8 512 > 96.0.0.0/8 512 > 105.0.0.0/8 512 > 108.0.0.0/8 512 > 134.0.0.0/8 512 > 138.0.0.0/8 512 > 139.0.0.0/8 512 > 152.0.0.0/8 512 > 167.0.0.0/8 512 > 173.0.0.0/8 512 > 64.0.0.0/8 256 > 66.0.0.0/8 256 > 67.0.0.0/8 256 > 68.0.0.0/8 256 > 69.0.0.0/8 256 > 74.0.0.0/8 256 > 75.0.0.0/8 256 > 76.0.0.0/8 256 > 98.0.0.0/8 256 > 104.0.0.0/8 256 > 150.0.0.0/8 256 > 159.0.0.0/8 256 > 168.0.0.0/8 256 > 174.0.0.0/8 256 > 192.0.0.0/8 256 > 196.0.0.0/8 256 > 216.0.0.0/8 256 > 23.0.0.0/8 128 > 65.0.0.0/8 128 > 97.0.0.0/8 128 > 100.0.0.0/8 128 > 107.0.0.0/8 128 > 128.0.0.0/8 128 > 130.0.0.0/8 128 > 131.0.0.0/8 128 > 140.0.0.0/8 128 > 141.0.0.0/8 128 > 149.0.0.0/8 128 > 153.0.0.0/8 128 > 154.0.0.0/8 128 > 160.0.0.0/8 128 > 161.0.0.0/8 128 > 162.0.0.0/8 128 > 163.0.0.0/8 128 > 170.0.0.0/8 128 > 172.0.0.0/8 128 > 184.0.0.0/8 128 > 198.0.0.0/8 128 > 207.0.0.0/8 128 > 208.0.0.0/8 128 > 209.0.0.0/8 128 > 4.0.0.0/8 64 > 8.0.0.0/8 64 > 12.0.0.0/8 64 > 13.0.0.0/8 64 > 18.0.0.0/8 64 > 32.0.0.0/8 64 > 35.0.0.0/8 64 > 38.0.0.0/8 64
Re: 198.154.60.0/22 bogon/hijacked?
Looks likeAS26272 and 198.154.60.0/22 have been deregistered about a week ago. In ARIN delegation statistics from Nov 8, ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20161108 these are listed as assigned and allocated but in later files that changed to 'reserved'. RIPEstat shows 198.154.60.0/22 has been in the routing system with origin AS26272 since October 2012. https://stat.ripe.net/widget/routing-history#w.resource=198.154.60.0/22 -- Rene On 11/16/16 7:19 PM, Alain Hebert wrote: Hum, Its a 6 weeks old entries in my routers. Even "oddish" its 26272 coming of GTT & HE. 26272 is unassigned at ARIN. -- My experience with GTT & HE find it curious that they let that happen. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 11/13/16 19:49, Jeremy Parsons wrote:
Re: pay.gov and IPv6
In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington writes : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Following up on a two year old thread, one of my clients just hit this > problem. The failure is not that www.pay.gov is not reachable over ipv6 > (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > connection, but the connection then hangs waiting for the TLS handshake. > > openssl s_client -connect www.pay.gov:443 > > openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > > Browsers (at least firefox) see that as a very slow site, and it does > not trigger their happy eyeballs fast failover to ipv4. Happy eyeballs is about making the connection not whether TCP connections work after the initial packet exchange. I would send a physical letter to the relevent Inspector General requesting that they ensure all web sites under their juristiction that are supposed to be reachable from the public net get audited regularly to ensure that IPv6 connections work from public IP space. While you are sending the letter can you also ask why pay.gov's DNS servers are broken. Checking: 'pay.gov' as at 2016-11-16T20:21:28Z pay.gov @199.169.194.28 (ns1.twai.gov.): edns=ok edns1=timeout edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok optlist=ok pay.gov @2605:3100:fffc:100::7 (ns1.twai.gov.): edns=ok edns1=timeout edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok optlist=ok pay.gov @199.169.192.28 (ns2.twai.gov.): edns=ok edns1=timeout edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok optlist=ok pay.gov @2605:3100:fffd:100::7 (ns2.twai.gov.): edns=ok edns1=timeout edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok optlist=ok Mark > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA > LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC > =MS8j > -END PGP SIGNATURE- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: pay.gov and IPv6
I fixed it (and Netflix) by turning off IPv6 for all my users... but any chance this is a path MTU issue causing the apparent hang? Matthew Kaufman On Wed, Nov 16, 2016 at 12:26 PM Mark Andrews wrote: > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington > writes > : > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Following up on a two year old thread, one of my clients just hit this > > problem. The failure is not that www.pay.gov is not reachable over ipv6 > > (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > > connection, but the connection then hangs waiting for the TLS handshake. > > > > openssl s_client -connect www.pay.gov:443 > > > > openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > > > > Browsers (at least firefox) see that as a very slow site, and it does > > not trigger their happy eyeballs fast failover to ipv4. > > Happy eyeballs is about making the connection not whether TCP > connections work after the initial packet exchange. > > I would send a physical letter to the relevent Inspector General > requesting that they ensure all web sites under their juristiction > that are supposed to be reachable from the public net get audited > regularly to ensure that IPv6 connections work from public IP space. > > While you are sending the letter can you also ask why pay.gov's DNS > servers are broken. > > Checking: 'pay.gov' as at 2016-11-16T20:21:28Z > > pay.gov @199.169.194.28 (ns1.twai.gov.): edns=ok edns1=timeout edns@512=noopt > ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok > optlist=ok > pay.gov @2605:3100:fffc:100::7 (ns1.twai.gov.): edns=ok edns1=timeout > edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok > edns@512tcp=ok optlist=ok > pay.gov @199.169.192.28 (ns2.twai.gov.): edns=ok edns1=timeout edns@512=noopt > ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok > optlist=ok > pay.gov @2605:3100:fffd:100::7 (ns2.twai.gov.): edns=ok edns1=timeout > edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok > edns@512tcp=ok optlist=ok > > Mark > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.14 (GNU/Linux) > > > > iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA > > LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC > > =MS8j > > -END PGP SIGNATURE- > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
Re: pay.gov and IPv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2016-11-16 at 20:59 +, Matthew Kaufman wrote: > I fixed it (and Netflix) by turning off IPv6 for all my users... but > any chance this is a path MTU issue causing the apparent hang? I fixed it by using the rpz feature of bind to disable the record for www.pay.gov. I lookup the real A record, and then put www.pay.gov IN A %s into the local rpz zone. That suppresses the record, so local clients are forced into IPv4 for that site. That allows them to use IPv6 for other sites. path MTU - hm, I need to check that. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgsz0YACgkQL6j7milTFsEbpwCgiJwZm3R/0VowqNFu4afHwPRq siwAmwdAj2YCLnlNQAs5Q5E5hcthaoiP =yqXb -END PGP SIGNATURE-
Re: pay.gov and IPv6
> On Nov 15, 2016, at 5:30 PM, Carl Byington wrote: > > openssl s_client -connect www.pay.gov:443 I’m not seeing the issue here, but they do have some possible issues the way they’re setting cookies (See details below). What path are you seeing to them? I’m also not having the issue from the IETF97 network here in Seoul which has IPv6 as well. puck:~$ traceroute6 www.pay.gov. traceroute to www.pay.gov. (2605:3100:fffd:100::15), 30 hops max, 80 byte packets 1 ge-0-7-0-22.r05.chcgil09.us.bb.gin.ntt.net (2001:418:3f4::1) 0.751 ms 0.871 ms 0.994 ms 2 verio-gw.cgcil.ipv6.att.net (2001:1890:1fff:307:192:205:32:193) 2.008 ms 1.991 ms 2.837 ms 3 cgcil22crs.ipv6.att.net (2001:1890:ff::12:122:132:198) 27.333 ms 27.167 ms 27.070 ms 4 sl9mo22crs.ipv6.att.net (2001:1890:ff::12:122:2:178) 27.602 ms 27.646 ms 27.628 ms 5 sl9mo21crs.ipv6.att.net (2001:1890:ff::12:122:2:217) 30.055 ms 29.894 ms 29.855 ms 6 dlstx22crs.ipv6.att.net (2001:1890:ff::12:122:2:1) 28.888 ms 27.016 ms 26.933 ms 7 dlstx84crs.ipv6.att.net (2001:1890:ff::12:123:18:249) 28.126 ms 26.757 ms 26.645 ms 8 2001:1890:ff::12:122:124:141 (2001:1890:ff::12:122:124:141) 26.142 ms 26.269 ms 26.179 ms 9 2001:1890:c00:610b::1138:7d27 (2001:1890:c00:610b::1138:7d27) 27.273 ms 27.255 ms 27.544 ms 10 2001:1890:1c08:cf01::2 (2001:1890:1c08:cf01::2) 27.673 ms !X 27.559 ms !X 27.465 ms !X curl -v https://www.pay.gov/public/home * Trying 2605:3100:fffd:100::15... * TCP_NODELAY set * Connected to www.pay.gov (2605:3100:fffd:100::15) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * ALPN/NPN, server did not agree to a protocol * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=www.pay.gov,O=United States Department of Treasury,L=Washington,ST=District of Columbia,C=US * start date: May 28 14:58:43 2015 GMT * expire date: May 29 06:16:02 2018 GMT * common name: www.pay.gov * issuer: CN=Entrust Certification Authority - L1K,OU="(c) 2012 Entrust, Inc. - for authorized use only",OU=See www.entrust.net/legal-terms,O="Entrust, Inc.",C=US > GET /public/home HTTP/1.1 > Host: www.pay.gov > User-Agent: curl/7.51.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Wed, 16 Nov 2016 21:52:08 GMT < Content-type: text/html; charset=ISO-8859-1 < Strict-transport-security: max-age=31536001; includeSubDomains < Cache-Control: no-cache < Cache-Control: no-store < Pragma: no-cache < Expires: Thu, 01 Jan 1970 00:00:00 GMT < X-XSS-Protection: 1; mode=block < Strict-Transport-Security: max-age=31536000 < Set-Cookie: JSESSIONID=949QYsVLKQqBB42HTy91pJnGfnfJthLfQTv02CvDnt7rNQnpSvb1!1259175335!-1040755441!1479333128223; path=/public; secure; HttpOnly < Set-Cookie: JSESSIONID=949QYsVLKQqBB42HTy91pJnGfnfJthLfQTv02CvDnt7rNQnpSvb1!1259175335!-1040755441; path=/public; HttpOnly < Set-Cookie: ClientId=14793331282345260; path=/public; HttpOnly; secure < Set-Cookie: ClientId=1479333128244363; path=/public; HttpOnly; secure < X-FRAME-OPTIONS: DENY < Content-Language: en-US < X-Powered-By: Servlet/2.5 JSP/2.1 < Transfer-encoding: chunked
Re: pay.gov and IPv6
On 11/16/16, Mark Andrews wrote: > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington > writes > : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Following up on a two year old thread, one of my clients just hit this >> problem. The failure is not that www.pay.gov is not reachable over ipv6 >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 >> connection, but the connection then hangs waiting for the TLS handshake. >> >> openssl s_client -connect www.pay.gov:443 >> >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 >> >> Browsers (at least firefox) see that as a very slow site, and it does >> not trigger their happy eyeballs fast failover to ipv4. > > Happy eyeballs is about making the connection not whether TCP > connections work after the initial packet exchange. > > I would send a physical letter to the relevent Inspector General > requesting that they ensure all web sites under their juristiction > that are supposed to be reachable from the public net get audited > regularly to ensure that IPv6 connections work from public IP space. That will absolutely work. NIST is still monitoring ipv6 .gov sites https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov so the IG isn't going to do anything there & pay.gov has a contact us page https://pay.gov/public/home/contact that I'd bet works much better than a letter to the IG Regards, Lee
Re: pay.gov and IPv6
It happens too often, unfortunately. People deploying IPv6 at web sites and other services, don’t check if PMTUD is broken by filtering, ECMP, load balancers, etc. This is the case here: tbit from 2001:df0:4:4000::1:115 to 2605:3100:fffd:100::15 server-mss 1440, result: pmtud-fail app: http, url: https://www.pay.gov/ [ 0.009] TX SYN 64 seq = 0:0 [ 0.165] RX SYN/ACK 64 seq = 0:1 [ 0.166] TX 60 seq = 1:1 [ 0.166] TX371 seq = 1:1(311) [ 0.325] RX 1500 seq = 1:312(1440) [ 0.325] RX 1500 seq = 1441:312(1440) [ 0.325] TX PTB 1280 mtu = 1280 [ 0.325] RX 1362 seq = 2881:312(1302) [ 3.325] RX 1500 seq = 1:312(1440) [ 3.325] TX PTB 1280 mtu = 1280 [ 9.326] RX 1500 seq = 1:312(1440) [ 9.326] TX PTB 1280 mtu = 1280 [ 21.325] RX 1500 seq = 1:312(1440) [ 21.325] TX PTB 1280 mtu = 1280 [ 45.325] RX 1500 seq = 1:312(1440) Regards, Jordi -Mensaje original- De: NANOG en nombre de Carl Byington Responder a: Fecha: miércoles, 16 de noviembre de 2016, 7:30 Para: Asunto: pay.gov and IPv6 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following up on a two year old thread, one of my clients just hit this problem. The failure is not that www.pay.gov is not reachable over ipv6 (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 connection, but the connection then hangs waiting for the TLS handshake. openssl s_client -connect www.pay.gov:443 openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 Browsers (at least firefox) see that as a very slow site, and it does not trigger their happy eyeballs fast failover to ipv4. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC =MS8j -END PGP SIGNATURE- ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: pay.gov and IPv6
In message , Lee writes: > On 11/16/16, Mark Andrews wrote: > > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington > > writes > > : > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA512 > >> > >> Following up on a two year old thread, one of my clients just hit this > >> problem. The failure is not that www.pay.gov is not reachable over ipv6 > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > >> connection, but the connection then hangs waiting for the TLS handshake. > >> > >> openssl s_client -connect www.pay.gov:443 > >> > >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > >> > >> Browsers (at least firefox) see that as a very slow site, and it does > >> not trigger their happy eyeballs fast failover to ipv4. > > > > Happy eyeballs is about making the connection not whether TCP > > connections work after the initial packet exchange. > > > > I would send a physical letter to the relevent Inspector General > > requesting that they ensure all web sites under their juristiction > > that are supposed to be reachable from the public net get audited > > regularly to ensure that IPv6 connections work from public IP space. > > That will absolutely work. > > NIST is still monitoring ipv6 .gov sites > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov Which show green which means that the tests they are doing are not sufficient. They need to test from behind a 1280 mtu link. The DNSSEC testing is also insufficient. 9-11commission.gov shows green for example but if you use DNS COOKIES (which BIND 9.10.4 and BIND 9.11.0 do) then servers barf and return BADVERS and validation fails. QWEST you have been informed of this already. Why the hell should validating resolver have to work around the crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT servers. You get PAID to do DNS because people think you are compentent to do the job. Evidence shows otherwise. https://ednscomp.isc.org/compliance/gov-full-report.html show the broken servers for .gov. It isn't hard to check. > so the IG isn't going to do anything there & pay.gov has a contact us page > https://pay.gov/public/home/contact > that I'd bet works much better than a letter to the IG You have to be able to get to https://pay.gov/public/home/contact to use it. Most people don't have the skill set to force the use of IPv4. If it is production it should work. It is the I-G's role to ensure this happens. Butts need to kicked. Mark > Regards, > Lee -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Facebook Geo Routing Issues
Hello, Does anybody have a contact I could use at Facebook to get a routing issue resolved? Some of our networks are being routed to Miami, rather than using the much closer PoP of Sydney, and it's obviously causing significant performance issues when browsing Facebook.
Re: Facebook Geo Routing Issues
I'm in Chicago and I saw mine going to Miami as well (per rDNS). Haven't looked into it at all. I did see a video where they said they occasionally purposely give people less than ideal facilities to test connectivity. Maybe that process buggered up? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "John Cenile" To: nanog@nanog.org Sent: Wednesday, November 16, 2016 7:48:25 PM Subject: Facebook Geo Routing Issues Hello, Does anybody have a contact I could use at Facebook to get a routing issue resolved? Some of our networks are being routed to Miami, rather than using the much closer PoP of Sydney, and it's obviously causing significant performance issues when browsing Facebook.
Re: pay.gov and IPv6
I think it is not just a matter of testing behind a 1280 MTU, but about making sure that PMTUD is not broken, so it just works in any circumstances. Regards, Jordi -Mensaje original- De: NANOG en nombre de Mark Andrews Responder a: Fecha: jueves, 17 de noviembre de 2016, 9:26 Para: Lee CC: Asunto: Re: pay.gov and IPv6 In message , Lee writes: > On 11/16/16, Mark Andrews wrote: > > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington > > writes > > : > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA512 > >> > >> Following up on a two year old thread, one of my clients just hit this > >> problem. The failure is not that www.pay.gov is not reachable over ipv6 > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > >> connection, but the connection then hangs waiting for the TLS handshake. > >> > >> openssl s_client -connect www.pay.gov:443 > >> > >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > >> > >> Browsers (at least firefox) see that as a very slow site, and it does > >> not trigger their happy eyeballs fast failover to ipv4. > > > > Happy eyeballs is about making the connection not whether TCP > > connections work after the initial packet exchange. > > > > I would send a physical letter to the relevent Inspector General > > requesting that they ensure all web sites under their juristiction > > that are supposed to be reachable from the public net get audited > > regularly to ensure that IPv6 connections work from public IP space. > > That will absolutely work. > > NIST is still monitoring ipv6 .gov sites > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov Which show green which means that the tests they are doing are not sufficient. They need to test from behind a 1280 mtu link. The DNSSEC testing is also insufficient. 9-11commission.gov shows green for example but if you use DNS COOKIES (which BIND 9.10.4 and BIND 9.11.0 do) then servers barf and return BADVERS and validation fails. QWEST you have been informed of this already. Why the hell should validating resolver have to work around the crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT servers. You get PAID to do DNS because people think you are compentent to do the job. Evidence shows otherwise. https://ednscomp.isc.org/compliance/gov-full-report.html show the broken servers for .gov. It isn't hard to check. > so the IG isn't going to do anything there & pay.gov has a contact us page > https://pay.gov/public/home/contact > that I'd bet works much better than a letter to the IG You have to be able to get to https://pay.gov/public/home/contact to use it. Most people don't have the skill set to force the use of IPv4. If it is production it should work. It is the I-G's role to ensure this happens. Butts need to kicked. Mark > Regards, > Lee -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: pay.gov and IPv6
In message , JORDI PALET M ARTINEZ writes: > I think it is not just a matter of testing behind a 1280 MTU, but about makin > g sure that PMTUD is not broken, so it just works in any circumstances. > > Regards, > Jordi If you don't do MSS fix up a 1280 link in the middle will find PMTUD issues provided the testing host has a MTU > 1280. Mark > -Mensaje original- > De: NANOG en nombre de Mark Andrews > Responder a: > Fecha: jueves, 17 de noviembre de 2016, 9:26 > Para: Lee > CC: > Asunto: Re: pay.gov and IPv6 > > > In message l.com> > , Lee writes: > > On 11/16/16, Mark Andrews wrote: > > > > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byingto > n > > > writes > > > : > > >> -BEGIN PGP SIGNED MESSAGE- > > >> Hash: SHA512 > > >> > > >> Following up on a two year old thread, one of my clients just hit th > is > > >> problem. The failure is not that www.pay.gov is not reachable over i > pv6 > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > > >> connection, but the connection then hangs waiting for the TLS handsh > ake. > > >> > > >> openssl s_client -connect www.pay.gov:443 > > >> > > >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > > >> > > >> Browsers (at least firefox) see that as a very slow site, and it doe > s > > >> not trigger their happy eyeballs fast failover to ipv4. > > > > > > Happy eyeballs is about making the connection not whether TCP > > > connections work after the initial packet exchange. > > > > > > I would send a physical letter to the relevent Inspector General > > > requesting that they ensure all web sites under their juristiction > > > that are supposed to be reachable from the public net get audited > > > regularly to ensure that IPv6 connections work from public IP space. > > > > That will absolutely work. > > > > NIST is still monitoring ipv6 .gov sites > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov > > Which show green which means that the tests they are doing are not > sufficient. They need to test from behind a 1280 mtu link. > > The DNSSEC testing is also insufficient. 9-11commission.gov shows > green for example but if you use DNS COOKIES (which BIND 9.10.4 and > BIND 9.11.0 do) then servers barf and return BADVERS and validation > fails. QWEST you have been informed of this already. > > Why the hell should validating resolver have to work around the > crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT > servers. You get PAID to do DNS because people think you are > compentent to do the job. Evidence shows otherwise. > > https://ednscomp.isc.org/compliance/gov-full-report.html show the broken > servers for .gov. It isn't hard to check. > > > so the IG isn't going to do anything there & pay.gov has a contact us p > age > > https://pay.gov/public/home/contact > > that I'd bet works much better than a letter to the IG > > You have to be able to get to https://pay.gov/public/home/contact to use > it. Most people don't have the skill set to force the use of IPv4. > > If it is production it should work. It is the I-G's role to ensure this > happens. Butts need to kicked. > > Mark > > > Regards, > > Lee > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confi > dential. The information is intended to be for the use of the individual(s) n > amed above. If you are not the intended recipient be aware that any disclosur > e, copying, distribution or use of the contents of this information, includin > g attached files, is prohibited. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: NEVERMIND! (was: Seeking Google reverse DNS delegation contact)
On Sun, Nov 13, 2016 at 3:57 PM, Christopher Morrow wrote: > So... actually someone did tell arin to aim these at ns1/2google.com... > I'll go ask arin to 'fix the glitch'. > > the glitch got fixed, shortly after this message, but not by my/our doing... hrm.. I see passive dns data: bailiwick 136.8.204.in-addr.arpa. count 19 first seen 2016-10-28 16:17:02 - last seen 2016-11-13 08:59:50 - 136.8.204.in-addr.arpa. NS ns1.google.com. 136.8.204.in-addr.arpa. NS ns2.google.com. and after that: (overlapping that) bailiwick 204.in-addr.arpa. count 2335 first seen 2015-05-01 16:20:01 - last seen 2016-11-16 21:54:01 - 136.8.204.in-addr.arpa. NS ns1.rossinc.net. 136.8.204.in-addr.arpa. NS ns2.rossinc.net. so.. I suspect ross digital/rossinc.net noticed they made a 'mistake' and that that 'mistake' was seen externally and .. fixed things on thier own. With that said, it's possible (so they'll also fix this new problem): dig ns1.rossinc.net dig ns2.rossinc.net both are 'nxdomain' from: ;; ANSWER SECTION: rossinc.net. 3057 IN NS ns57.domaincontrol.com. rossinc.net. 3057 IN NS ns58.domaincontrol.com. which seems sad, and bad.. and .. like someone has made another 'mistake' :( rossinc, you probably want to fix this as well. > thanks! > -chris > (sometimes people do this, I have no idea why... perhaps they just like > broken ptrs?) > > On Thu, Nov 10, 2016 at 10:05 PM, Ronald F. Guilmette < > r...@tristatelogic.com> wrote: > >> >> >> My profuse apologies to everyone. It seems that Google is not in fact >> involved in any way with providing reverse DNS for the 204.8.136.0/21 >> IP address block. I was deceived into believing it was by some >> unusual trickey on the part of the spammer-controlled name servers >> ns1.saversagreeable.com and ns2.saversagreeable.com. You can see >> the clever deception toward the very end of the dig +trace listing >> I posted: >> >> http://pastebin.com/raw/VNwmgMHh >> >> It seems those clever rascal spammers tried to implicate Google's >> name servers, but it is only their's which are giving out the >> reverse DNS which suoorts their snowshoe spamming efforts in the >> 204.8.136.0/21 block. >> >> Sorry for my mistake everyone. I wasn't expecting quite this level >> or kind of reverse DNS delegation trickery. >> >> >> Regards, >> rfg >> > >
Re: pay.gov and IPv6
The good news is that I reported this particular site as a problem two and three years ago, both, and it isn't any worse. Matthew Kaufman On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews wrote: > > In message , JORDI > PALET M > ARTINEZ writes: > > I think it is not just a matter of testing behind a 1280 MTU, but about > makin > > g sure that PMTUD is not broken, so it just works in any circumstances. > > > > Regards, > > Jordi > > If you don't do MSS fix up a 1280 link in the middle will find PMTUD issues > provided the testing host has a MTU > 1280. > > Mark > > > -Mensaje original- > > De: NANOG en nombre de Mark Andrews < > ma...@isc.org> > > Responder a: > > Fecha: jueves, 17 de noviembre de 2016, 9:26 > > Para: Lee > > CC: > > Asunto: Re: pay.gov and IPv6 > > > > > > In message > > l.com> > > , Lee writes: > > > On 11/16/16, Mark Andrews wrote: > > > > > > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl > Byingto > > n > > > > writes > > > > : > > > >> -BEGIN PGP SIGNED MESSAGE- > > > >> Hash: SHA512 > > > >> > > > >> Following up on a two year old thread, one of my clients just > hit th > > is > > > >> problem. The failure is not that www.pay.gov is not reachable > over i > > pv6 > > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port > 443 > > > >> connection, but the connection then hangs waiting for the TLS > handsh > > ake. > > > >> > > > >> openssl s_client -connect www.pay.gov:443 > > > >> > > > >> openssl s_client -servername www.pay.gov -connect > 199.169.192.21:443 > > > >> > > > >> Browsers (at least firefox) see that as a very slow site, and > it doe > > s > > > >> not trigger their happy eyeballs fast failover to ipv4. > > > > > > > > Happy eyeballs is about making the connection not whether TCP > > > > connections work after the initial packet exchange. > > > > > > > > I would send a physical letter to the relevent Inspector General > > > > requesting that they ensure all web sites under their > juristiction > > > > that are supposed to be reachable from the public net get audited > > > > regularly to ensure that IPv6 connections work from public IP > space. > > > > > > That will absolutely work. > > > > > > NIST is still monitoring ipv6 .gov sites > > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov > > > > Which show green which means that the tests they are doing are not > > sufficient. They need to test from behind a 1280 mtu link. > > > > The DNSSEC testing is also insufficient. 9-11commission.gov shows > > green for example but if you use DNS COOKIES (which BIND 9.10.4 and > > BIND 9.11.0 do) then servers barf and return BADVERS and validation > > fails. QWEST you have been informed of this already. > > > > Why the hell should validating resolver have to work around the > > crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT > > servers. You get PAID to do DNS because people think you are > > compentent to do the job. Evidence shows otherwise. > > > > https://ednscomp.isc.org/compliance/gov-full-report.html show the > broken > > servers for .gov. It isn't hard to check. > > > > > so the IG isn't going to do anything there & pay.gov has a > contact us p > > age > > > https://pay.gov/public/home/contact > > > that I'd bet works much better than a letter to the IG > > > > You have to be able to get to https://pay.gov/public/home/contact > to use > > it. Most people don't have the skill set to force the use of IPv4. > > > > If it is production it should work. It is the I-G's role to ensure > this > > happens. Butts need to kicked. > > > > Mark > > > > > Regards, > > > Lee > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > > > > > > > > ** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confi > > dential. The information is intended to be for the use of the > individual(s) n > > amed above. If you are not the intended recipient be aware that any > disclosur > > e, copying, distribution or use of the contents of this information, > includin > > g attached files, is prohibited. > > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
Re: Network Diagnostic Tool
https://twitter.com/jhackenthal/status/799091998594650112 > On Nov 12, 2016, at 22:05, J. Hellenthal wrote: > > That is a very cool contribution you've made. Let me run it through some > tests and put it to work right away and see if I can provide some feedback > and maybe possible patches or incites > > But thank you!! > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Nov 12, 2016, at 13:28, Mehrdad Arshad Rad wrote: > > Hi, > > I've started to develop an open source tool 4 months ago to help > neteng/sysadmin/sysops please take look at the below link and let me know > if you have any suggestions. > > https://github.com/mehrdadrad/mylg > > p.s you can download it for different operating systems at http://mylg.io > > Thanks, > Mehrdad -- Jason Hellenthal JJH48-ARIN
