Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-19 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2016-11-19 at 14:04 -0500, valdis.kletni...@vt.edu wrote:

> > OK, you're *almost* done.  Now take the sites that failed, and
> traceroute -6 to them, and then to several sites that work (just as a
> control).

> What router(s) do the 3 failing sites (yahoo, mega, and lfichier) have
> in common, which are *not* in the path to a site that works?

The empty set.

These two fail:

traceroute -6 -n 2a00:fb40:a:1::140  # www.1fichier.com
 1  2001:470:d:9d6::1  0.160 ms  0.152 ms  0.143 ms
 2  2001:470:c:9d6::1  23.144 ms  28.472 ms  33.245 ms
 3  2001:470:0:9d::1  36.805 ms  36.801 ms  36.794 ms
 4  2001:470:0:72::2  34.623 ms  34.620 ms  34.614 ms
 5  2001:470:0:15d::1  58.575 ms  59.748 ms  59.743 ms

traceroute -6 -n 2001:4998:c:e33::50  # login.yahoo.com
 1  2001:470:d:9d6::1  0.198 ms  0.191 ms  0.185 ms
 2  2001:470:c:9d6::1  19.079 ms  24.164 ms  28.938 ms
 3  2001:470:0:9d::1  32.637 ms  32.632 ms  32.626 ms
 4  2001:504:0:3:0:1:310:1  32.028 ms  32.024 ms  32.017 ms
 5  2001:4998:f005:201::  37.030 ms  37.026 ms  37.020 ms

The only hops that are common are *very* close to the tunnel far end.


These work properly, and of course they go thru the same hops near the
tunnel far end.

traceroute -6 -n 2607:b400:92:26:0:97:1e7:3947 # www.vt.edu
 1  2001:470:d:9d6::1  0.164 ms  0.155 ms  0.146 ms
 2  2001:470:c:9d6::1  20.198 ms  25.497 ms  30.534 ms
 3  2001:470:0:9d::1  32.176 ms  32.168 ms  32.163 ms
 4  2001:470:0:72::2  32.143 ms  40.322 ms  40.315 ms
 5  2001:470:0:362::2  42.431 ms  42.431 ms  42.419 ms

traceroute -n -6 2607:f8b0:400f:802::2004 # www.google.com
 1  2001:470:d:9d6::1  0.176 ms  0.164 ms  0.155 ms
 2  2001:470:c:9d6::1  19.455 ms  24.677 ms  29.582 ms
 3  2001:470:0:9d::1  31.802 ms  31.798 ms  31.790 ms
 4  2001:470:0:72::2  30.941 ms  30.938 ms  30.932 ms
 5  2001:4860:1:1:0:1b1b:0:19  30.923 ms  31.149 ms  30.908 ms

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgwxu4ACgkQL6j7milTFsFriwCfUVLyFdRx8UiODcc2+e662pxM
0TUAn0CKE8nVIjG9x1xIISFVzKhIiOwd
=vCnf
-END PGP SIGNATURE-



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-19 Thread Valdis . Kletnieks
On Sat, 19 Nov 2016 08:33:27 -0800, Carl Byington said:

> Of the 220 sites identified above, 218 of them manage to see the icmpv6
> packet and respond by resending with a packet that makes it thru the
> tunnel. I suspect that packets from at least one of those 218 sites goes
> thru many of the same systems as the packets from login.yahoo.com.

> https://www.mega.nz and https://www.1fichier.com seem to have the same
> icmpv6 filtering issue.

OK, you're *almost* done.  Now take the sites that failed, and traceroute -6
to them, and then to several sites that work (just as a control).

What router(s) do the 3 failing sites (yahoo, mega, and lfichier) have in
common, which are *not* in the path to a site that works?

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-19 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2016-11-18 at 16:52 -0500, valdis.kletni...@vt.edu wrote:
> And you identified that the problem was at Yahoo, and not one or more
> of the hops between the far end of your tunnel and Yahoo, how,
> exactly?

Taking the top 1000 sites from Alexa, for those domain names $n where
www.$n has at least one  record $ip, and where "nmap -6 -Pn -p 443
$ip" shows that something seems to be running https there, we try

echo -e 'GET / HTTP/1.0\n' | \
openssl s_client -servername www.$n -ign_eof -connect "[$ip]:443"


In general, even if the TLS certificate is small enough to fit into
about 1500 bytes, the home page is almost always larger that that. So
something in that request would result in the server trying to send a
large packet, getting an icmpv6 "too big", and resending with a smaller
MSS.

Of the 220 sites identified above, 218 of them manage to see the icmpv6
packet and respond by resending with a packet that makes it thru the
tunnel. I suspect that packets from at least one of those 218 sites goes
thru many of the same systems as the packets from login.yahoo.com.

https://www.mega.nz and https://www.1fichier.com seem to have the same
icmpv6 filtering issue.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgwfrkACgkQL6j7milTFsFCAwCfQHnivoU5QlBvmfABC8swnutz
QR8AnRIsSUaCIw6dh1Jr92+5/FgXeSqq
=Hx/k
-END PGP SIGNATURE-



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-19 Thread Johann Klasek
On Fri, Nov 18, 2016 at 01:01:50PM -0800, Carl Byington wrote:
> On Fri, 2016-11-18 at 15:41 -0500, valdis.kletni...@vt.edu wrote:
> 
> > Did you do anything to specifically identify Yahoo's routers as the
> > offenders?
> 
> > Hint: If there's a tunnel in the path, it will be *your* end of the
> > tunnel
> > that sends back the "can't frag" ICMP.  So the filtering is happening
> > somewhere
> > between your end of the tunnel and you.
> 
> This happens very early in the TLS handshake. The tcp (syn,syn-ack,ack)
> handshake works; my system sends a 286 byte TLS client hello, and the
> response to that will be a bunch of full size packets from Yahoo with
> the certificate, etc. The *far* end of my tunnel will be sending the
> icmpv6 "packet too big" back to Yahoo.

Could this "packet too big" part of the path MTU discovery? Probably not
wrong if you see this. Maybe the fragmentation to the other site (or
somewhere in between) is broken? (as said before)


Johann K.




___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop