RE: Heads up: Long AS-sets announced in the next few days

2005-03-03 Thread Brian (nanog)

James [mailto:[EMAIL PROTECTED] wrote:

They are not playing with the core. The result of what they are 
doing is dependent on specific topology and level of direction
they are throwing prefixes at.

While I will not dispute your statement, I believe that every 
ASN should be responsible of their own and should not trust the
General Internet to not cause harm on their network. If your 
router is going to crash b/c of someone advertising an unusual
AS_PATH, I don't view that differently from a box getting owned
because it was running unpatched OS since 1999 without any 
firewall rules either.
-J

I think most of the concern comes from the fact that this
experiment is being done on a network that many people rely
upon for various reasons, and it's unknown side effects have are
in the scope of global financial/communication/emergency crisises.
It might not cause any harm, but I'd think you guys could have
probably come up with a better test bed than using other people's
equipment and networks without permission and risking unforseen
disasters.  Why wasn't this experiment tested in a lab
environment?  We don't test new pharmaceuticals directly on humans
in the first round of testing, and after they've been proven safe
on animals, the tests then go on to compensated volunteers

Even if this type of experiment fell into compliance with the
RFCs, it surely wasn't the intended use of AS-PATHS and should
be considered experimental, and therefore tested in a lab setting.
The risks imposed by using the global internet routing
infrastructure as your testbed far outweigh any benefits your tool
might realize.

If this experiment that you're running causes downtime for 
someone elses systems, are you willing to pay for the damages?

-Brian



Strange public traceroutes return private RFC1918 addresses

2004-02-02 Thread Brian (nanog-list)
Title: Strange public traceroutes return private RFC1918 addresses





Any ideas how (or why) the following traceroutes are leaking private RFC1918 addresses back to me when I do a traceroute?

Maybe try from your side of the internet and see if you get the same types of responses.


It's really strange to see 10/8's and 192.168/16 addresses coming from the public internet. Has this phenomenon been documented anywhere? Connectivity to the end-sites is fine, it's just the traceroutes that are strange.

(initial few hops sanitized)


[EMAIL PROTECTED] /]# traceroute www.ibm.com
traceroute: Warning: www.ibm.com has multiple addresses; using 129.42.17.99
traceroute to www.ibm.com (129.42.17.99), 30 hops max, 38 byte packets
1 (---.---.---.---) 2.481 ms 2.444 ms 2.379 ms
2 (---.---.---.---) 17.964 ms 17.529 ms 17.632 ms
3 so-1-2.core1.Chicago1.Level3.net (209.0.225.1) 17.891 ms 17.985 ms 18.026 ms
4 so-11-0.core2.chicago1.level3.net (4.68.112.194) 18.272 ms 18.109 ms 17.795 ms
5 so-4-1-0.bbr2.chicago1.level3.net (4.68.112.197) 17.851 ms 17.859 ms 18.094 ms
6 so-3-0-0.mp1.stlouis1.level3.net (64.159.0.49) 23.095 ms 22.975 ms 22.998 ms
7 ge-7-1.hsa2.stlouis1.level3.net (64.159.4.130) 23.106 ms 23.237 ms 22.977 ms
8 unknown.level3.net (63.20.48.6) 24.264 ms 24.099 ms 24.154 ms
9 10.16.255.10 (10.16.255.10) 24.164 ms 24.108 ms 24.105 ms
10 * * *



[EMAIL PROTECTED] /]# traceroute www.att.net
traceroute: Warning: www.att.net has multiple addresses; using 204.127.166.135
traceroute to www.att.net (204.127.166.135), 30 hops max, 38 byte packets
1 (---.---.---.---) 2.404 ms 2.576 ms 2.389 ms
2 (---.---.---.---) 17.953 ms 18.170 ms 17.435 ms
3 500.pos2-1.gw10.chi2.alter.net (63.84.96.9) 18.077 ms * 18.628 ms
4 0.so-6-2-0.xl1.chi2.alter.net (152.63.69.170) 18.238 ms 18.321 ms 18.213 ms
5 0.so-6-1-0.BR6.CHI2.ALTER.NET (152.63.64.49) 18.269 ms 18.396 ms 18.329 ms
6 204.255.169.146 (204.255.169.146) 19.231 ms 19.042 ms 18.982 ms
7 tbr2-p012702.cgcil.ip.att.net (12.122.11.209) 20.530 ms 20.542 ms 23.033 ms
8 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 26.904 ms 27.378 ms 27.320 ms
9 tbr1-cl2.sl9mo.ip.att.net (12.122.9.141) 27.194 ms 27.673 ms 26.677 ms
10 gbr1-p10.bgtmo.ip.att.net (12.122.4.69) 26.606 ms 28.026 ms 26.246 ms
11 12.122.248.250 (12.122.248.250) 27.296 ms 28.321 ms 28.997 ms
12 192.168.254.46 (192.168.254.46) 28.522 ms 30.111 ms 27.439 ms
13 * * *
14 * * *