December 2012 - NANOG - lists.nanog.org

btw, the itu imploded
by Randy Bush 19 Dec '12

19 Dec '12

12 15

Google contact
by J. Oquendo 19 Dec '12

19 Dec '12

Can someone from GOOG contact me off-list. After many submissions to have my corp IP space fixed for geolocation, I'm at wits end looking at British news, finding British searches, knowing more about the UK then the US than I care to. Makes for difficult GHDB'ing when searching as well. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF

1 1

32-bit ASes at routeviews
by Iljitsch van Beijnum 19 Dec '12

19 Dec '12

Looking for 32-bit AS numbers, I get some strange results from routeviews: route-views>sh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. Maybe a bug in the IOS they're running? route-views>sh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) Or is something else going on?

8 7

www.eftps.gov contact
by Darren Pilgrim 18 Dec '12

18 Dec '12

The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. Thanks,

6 17

REMINDER: Include as much detail as you have on problem reports (was eftps.gov)
by Jay Ashworth 18 Dec '12

18 Dec '12

Aside from the fact that it helps unrelated people aid you in diagnosing the problem, there's another, more practical reason to do it: When you do, problems you're having will sometimes "magically" disappear, because someone who a) is in a position to fix it, but b) is not in a position to *talk about it* will see the report, do a facepalm, and twist the proper knob to make it go away. While this isn't as optimal in the global sense as a full dialogue on the problem would be, it's a helluva lot better than "it still doesn't work, a week later". And the shorter the thread, the higher the odds this might happen. "One posting" is optimal. :-) Just a thought. Cheers, -- jr 'Happy Chriskwanzukkah, and a Cool Yule' a -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 0

William was raided for running a Tor exit node. Please help if you can.
by Chris 18 Dec '12

18 Dec '12

I'm not William and a friend pasted a link on IRC to me. I'm going to send him a few bucks because I know how it feels to get blindsided by the police on one random day and your world is turned upside down. Source: http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-acc… >From the URL: Yes, it happened to me now as well - Yesterday i got raided for someone sharing child pornography over one of my Tor exits. I'm good so far, not in jail, but all my computers and hardware have been confiscated. (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) If convicted i could face up to 6 years in jail, of course i do not want that and i also want to try to set a legal base for running Tor exit nodes in Austria or even the EU. Sadly we have nothing like the EFF here that could help me in this case by legal assistance, so i'm on my own and require a good lawyer. Thus i'm accepting donations for my legal expenses which i expect to be around 5000-10000 EUR. If you can i would appreciate if you could donate a bit (every amount helps, even the smallest) either by PayPal (any currency is ok): https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7… Or by Bank Transfer (EUR only please): Holder: William Weber Bank: EasyBank AG (Vienna, Austria) Account: 20011351213 Bank sort number: 14200 IBAN: AT031420020011351213 BIC: EASYATW1 I will try to pay them back when i'm out of this (or even before) but i can obviously not guarantee this, please keep this in mind. This money will only be used for legal expenses related to this case. If you have any questions or want to donate by another way (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free to send me a mail (william(a)william.si) or a PM, or contact me in LET IRC. Thanks! William -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton

47 126

Advisory — D-root is changing its IPv4 address on the 3rd of January.
by Jason Castonguay 17 Dec '12

17 Dec '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Advisory — D-root is changing its IPv4 address on the 3rd of January. This is advance notice that there is a scheduled change to the IPv4 address for one of the authorities listed for the DNS root zone and the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is administered by the University of Maryland. The new IPv4 address for this authority is 199.7.91.13 The current IPv6 address for this authority is 2001:500:2d::d and it will continue to remain unchanged. This change is anticipated to be implemented in the root zone on 3 January 2013, however the new address is currently operational. It will replace the previous IP address of 128.8.10.90 (also once known as TERP.UMD.EDU) We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root “hints” file. This should be updated with the new IP address. New hints files will be available at the following URLs once the change has been formally executed: http://www.internic.net/domain/named.root http://www.internic.net/domain/named.cache The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. - -- Jason Castonguay Network Integration Software Engineer Division of Information Technology University of Maryland College Park, MD 20742 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDKXLEACgkQA5NiLuECHn4lRQCgoOlYQhq+kXk2Az3nPeN1hUfz 0e4AoKCwp0cLpABJFc/7RV5E/ecfWwoJ =ktnM -----END PGP SIGNATURE-----

29 54

Strict route filtering at IX?
by Dan Luedtke 17 Dec '12

17 Dec '12

Hi NANOGers, tl;dr What is the best practice for filtering a large number of prefixes at an internet exchange? Yesterday I ran into problems while writing new filtering rules for my peerings at a local Exchange. My workflow probably has a flaw, although it works fine for IPv6 (well, less prefixes there). After the physical link was set up I startet a BGP session with the route server of the exchange. A few minutes later some other AS imported my prefix, e.g. those listed at HE[1]. I guess they filtered "less strict" :) The next day the exchange's route server administrator added my AS-SET to the AS-SET of the route server. --- snip RIPE DB --- as-set: AS-KLEYREX-RS1 descr: KleyReX Internet Exchange Frankfurt [...] members: AS-NONATTACHED --- snap --- A few days have passed since then but the number of peers has not increased as expected. Is this normal? My mp-* entries look like this: --- snip RIPE DB --- aut-num: AS57821 as-name: NONATTACHED-AS [...] mp-import: afi ipv4.unicast from AS31142 accept AS-KLEYREX-RS1 mp-export: afi ipv4.unicast to AS31142 announce AS-NONATTACHED --- snap --- Yesterday I thought about importing the route servers prefixes and, of course, to filter them. Using rtconfig[2] I created a filter for BIRD[3] like this: --- snip bird.conf --- if (prefix_too_long()) then reject; @rtconfig printPrefixes "if (net ~ [ %p/%l+ ]) then accept;\n" filter AS-KLEYREX-RS1 reject; --- snap --- This takes about 10-20 minutes and results in an very large config file constiting of hundreds of prefixes in IPv4. The same config file for IPv6 would be smaller. However, legacy protocol IPv4 is not yet dead so I need to filter it somehow. BIRD sometimes segfaults when it is advised to read those large filters. So, here's the question: How do you filter at exchanges? Where is the error in my workflow? Is strict route filtering a myth? Thanks for helping! Dan [1] http://bgp.he.net/AS57821#_peers [2] http://irrtoolset.isc.org/wiki/RtConfig [3] http://bird.network.cz

4 3

VIDEO: Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape – NYC 12/5 #DDoS
by Joly MacFie 16 Dec '12

16 Dec '12

As promised this is the full video of PIR's recent DDoS event in NYC. I've waited to post it until we got the closed captioning done. If anyone should be willing to volunteer to help translate the captions into other languages they can do so via AMARA - http://www.universalsubtitles.org/en/videos/lvgGlpwZR0lA/info/mitigating-dd… it's possible to just contribute as much or as little as you have time to do. ** joly posted: "The Internet Society's New York Chapter (ISOC-NY) and the New York Technology Council (NYTECH) joined the Public Interest Registry (PIR) in presenting a midday symposium "Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape" in New Yor" [image: Mitigating DDoS Attacks 12/5/2012]<http://isoc-ny.org/p2/wp-content/uploads/2012/11/end43.png>The Internet Society's New York Chapter (ISOC-NY <http://isoc-ny.org>) and the New York Technology Council (NYTECH <http://nytech.org>) joined the Public Interest Registry (PIR <http://www.pir.org>) in presenting a midday symposium "Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape <http://www.pir.org/why/security/ddos>" in New York City on December 5 2012. Participating organizations included Afilias, Google, Neustar, Symantec, EFF, and De Natris Consult. The event was webcast live via the Internet Society Chapters Livestream Channel. Audio / transcript links are below. English Closed captions are available. MODERATOR Brian Cute - CEO, Public Interest Registry (PIR) SPEAKERS Jeff Greene - Senior Policy Counsel, Symantec Ram Mohan - EVP & Chief Technology Officer, Afilias Damian Menscher -- Security Engineer, Google Miguel Ramos - Senior Product Manager, Neustar Danny McPherson - Chief Security Officer, Verisign Jillian York - Director for International Freedom of Expression, Electronic Frontier Foundation (EFF) <http://www.youtube.com/watch?v=FR0660X9lGc?rel=0> - Download audio : http://isoc-ny.org/ddos/mitigating_ddos.mp3 - Download transcript: http://isoc-ny.org/ddos/mitigating_ddos.txt Comment <http://isoc-ny.org/p2/4505#respond> See all comments<http://isoc-ny.org/p2/4505#comments> *Trouble clicking?* Copy and paste this URL into your browser: http://isoc-ny.org/p2/4505 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- -

1 1

Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
by Keith Medcalf 16 Dec '12

16 Dec '12

If your grandmother were running her own recursive DNS resolver, I expect she would have no difficulty understanding the message. It is the young-uns that have difficulty comprehending (and using) the English language. Sent from Samsung Mobile -------- Original message -------- From: bmanning(a)vacation.karoshi.com Date: To: Nick Hilliard <nick(a)foobar.org> Cc: "nanog(a)nanog.org Group" <nanog(a)nanog.org> Subject: Re: Advisory — D-root is changing its IPv4 address on the 3rd of January. On Sun, Dec 16, 2012 at 12:45:32AM +0000, Nick Hilliard wrote: > On 15/12/2012 23:07, David Conrad wrote: > > The handwringing over this issue is a bit over the top. > > It's a question of what's procedurally sensible. Sensible things would > include longer notice of the impending change to the root zone, more > widespread notice of what's happening and generally not poking around with > really important bits of the Internet at times which are well known for > having configuration freezes and/or when many people are going to be on > holidays. There are many bits of the internet where changes will only > affect small areas, but this change will affect everyone even if they > people don't realise it (and yes, it probably won't affect them visibly > because of root cache repriming). how much notice would you like? > > Other sensible things might include: > > - liaising with operating system vendors and recurser servers code authors > and providing them with extra advance notice so that they can roll these > changes into their code in a structured way. Software update release > cycles often take many months to roll out, particularly for non OSS code. its not clear this has not been done. nor is it clear that it would be needed, given the bootstrap methods that have been current for more than a decade. > - perhaps some targeted localisation of the d.root-servers.org notice so > that more than 15% of the world population can read it (english == 5% > native speakers, 10% second language)? its not clear this has not been done. where you you localise this notice and what methods would you use? > Lots of people are aware that resolver dns servers will automatically > reprime their root cache without manual intervention. However, not > everyone will realise it and a random punter who looks at this notice and > doesn't understand root cache mechanics may well think that they need to > start updating their DNS configuration files on Jan 3. It's not clear from > the change notification that you don't necessarily need to do this. true - there is an expectation that the reader has a basic understanding of the DNS. My grandmother would be confused, but would clearly understand from the notice that there were many months before the existing system would change. Perhaps the notice should suggest talking with your service provider if you don't understand or have questions. > This change wasn't planned over a coffee last thursday morning. It's > obviously been on the cards for several years, so asking for more carefully > structured notice in a procedurally sensible sort of way isn't an > unreasonable thing to expect as part of the migration plan. are these all the points that concern you? are there others? lets get them all on the table. > > Nick >

1 0