- NANOG - lists.nanog.org

Re: Megaupload.com seized
by Steven Bellovin 01 Feb '12

01 Feb '12

On Jan 19, 2012, at 6:44 PM, james(a)smithwaysecurity.com wrote: > You guys serous, when did the order come in to sezie the domain? http://arstechnica.com/tech-policy/news/2012/01/why-the-feds-smashed-megaup… has a good analysis; also see http://online.wsj.com/article_email/SB1000142405297020461650457717106061194… (which seems to be outside their paywall). What differentiates this from many of the earlier domain name seizures is that this is based on a grand jury indictment, not just an administrative decision by Immigration and Customs Enforcement. It may be heavy-handed or questionable, per the Ars Technica analysis, but as a matter of process it's about as good as you'll get. > > Sent from my HTC > > ----- Reply message ----- > From: "Ryan Gelobter" <ryan.g(a)atwgpc.net> > To: "NANOG" <nanog(a)nanog.org> > Subject: Megaupload.com seized > Date: Thu, Jan 19, 2012 6:41 pm > > > The megaupload.com domain was seized today, has anyone noticed significant > drops in network traffic as a result? > > http://www.scribd.com/doc/78786408/Mega-Indictment > http://techland.time.com/2012/01/19/feds-shut-down-megaupload-com-file-shar… --Steve Bellovin, https://www.cs.columbia.edu/~smb

37 67

Route Optimization Software / Appliance
by Babak Pasdar 01 Feb '12

01 Feb '12

Hello Group, I was wondering if anyone could share their experience with any route optimization approaches, methodologies or platforms, either open source or commercial (Internap FCP), that can actively adjust BGP parameters based on latency and number of layer 3 hops to a network rather than AS hops. We have upstreams all over the country and we would like to automate optimization to take the best egress path. Thank you for your feedback in advance. Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability . Performance (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games Bat Blue's AS: 25885 | BGP Policy | Peering Policy Receive Bat Blue's Daily Security Intelligence Report Bat Blue's Legal Notice

8 9

Route Management Best Practices
by Joe Marr 31 Jan '12

31 Jan '12

My network has grown large enough that maintaining my prefix announcements to the rest of the world has become increasingly difficult. I currently use static routes and tags on my edge routers to inject route into BGP. The tags correspond to communities that reflect how the routes are announced per region. I would love to heat from others on how they handle this.

3 6

RE: Hijacked Network Ranges - paging Cogent and GBLX/L3
by Manish Karir 31 Jan '12

31 Jan '12

You can take a closer look at the aspaths (lengths) to various global locations by looking at the following: http://bgptables.merit.edu/prefix.php?z=&z=&prefixcw=208.110.48.0/20&view=a… http://bgptables.merit.edu/prefix.php?z=&z=&prefixcw=63.246.112.0/20&view=a… http://bgptables.merit.edu/prefix.php?z=&z=&prefixcw=68.66.112.0/20&view=al… Hope that helps. -manish > Message: 7 > Date: Tue, 31 Jan 2012 22:06:03 +0200 > From: Ido Szargel <ido(a)oasis-tech.net> > To: "Schiller, Heather A" <heather.schiller(a)verizon.com>, Kelvin > Williams <kwilliams(a)altuscgi.com>, "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: RE: Hijacked Network Ranges - paging Cogent and GBLX/L3 > Message-ID: > <7A848D4888ADA94B8A46A17296740133B38D3E5473(a)DEXTER.oasis-tech.local> > Content-Type: text/plain; charset="us-ascii" > > I would go at first by advertising your prefixes as a /24 as well, just > randomly checked 2 different locations and the as-path to 11325 is shorter > than to 33611 > This seems to be the case for customers of Tiscali and L3, so this will > probably get most of your traffic back to you... > > Regards, > Ido >> >> -----Original Message----- >> From: Kelvin Williams [mailto:kwilliams@altuscgi.com] >> Sent: Tuesday, January 31, 2012 1:01 PM >> To: nanog(a)nanog.org >> Subject: Hijacked Network Ranges >> >> Greetings all. >> >> We've been in a 12+ hour ordeal requesting that AS19181 (Cavecreek Internet >> Exchange) immediately filter out network blocks that are being advertised by >> ASAS33611 (SBJ Media, LLC) who provided to them a forged LOA. >> >> The routes for networks: 208.110.48.0/20, 63.246.112.0/20, and >> 68.66.112.0/20 are registered in various IRRs all as having an origin AS >> 11325 (ours), and are directly allocated to us. >> >> The malicious hijacking is being announced as /24s therefore making route >> selection pick them. >> >> Our customers and services have been impaired. Does anyone have any >> contacts for anyone at Cavecreek that would actually take a look at ARINs >> WHOIS, and IRRs so the networks can be restored and our services back in >> operation? >> >> Additionally, does anyone have any suggestion for mitigating in the interim? >> Since we can't announce as /25s and IRRs are apparently a pipe dream. >> >> -- >> Kelvin Williams >> Sr. Service Delivery Engineer >> Broadband & Carrier Services >> Altus Communications Group, Inc. >> > > "If you only have a hammer, you tend to see every problem as a nail." -- > Abraham Maslow

1 0

MD5?
by Brian Stengel 31 Jan '12

31 Jan '12

We have a potential customer that is asking for us to enable MD5 authentication on a TCP connection between two BGP peers? Is this still common practice today? Any potential problems or gotchas to keep in mind? Thanks! -- Brian Stengel KINBER Director of Operations bstengel(a)kinber.org 412.254.3481 Skype: brian_stengel KINBER - Keystone Initiative for Network Based Education and Research - www.kinber.org PennREN - Pennsylvania's Research and Education Network

17 22

using ULA for 'hidden' v6 devices?
by Justin M. Streiner 31 Jan '12

31 Jan '12

Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC. There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice. jms

19 42

Re: Hijacked Network Ranges
by John Schneider 31 Jan '12

31 Jan '12

If you both announce a /24, the BGP route selection process should begin to return some of the traffic to these prefixes back to your AS. Also, if you begin to advertise your prefixes as /24s and as a result, they try to advertise /25s, I would venture a guess that their /25s would get blocked entirely, effectively returning traffic to those prefixes to you. that would be best-case scenario until you can get someone at AS36111 to listen to you. Best of Luck to you >Upstream requirements. Additionally, I don't believe it would do us any >good. If they're announcing /24 now, why would they not announce a /25.

1 0

IPv6 BGP MIBs
by chip 31 Jan '12

31 Jan '12

Hi all, Can anyone point me to ongoing discussion about IPv6 BGP SNMP MIBs going on in the IETF? As I understand it RFC 4293 was somewhat abandoned by most vendors. Cisco has a new BGPV4-2 Mib but that still doesn't address all the needs. While I can try and push all my vendors to come up with a MIB that has parity with IPv4 I assume our standards bodies are working towards that goal as well. I can't seem to locate where these discussions are happening within the IETF...or if they even are. Any pointers or education for my ignorance is appreciated. Thanks all, --chip -- Just my $.02, your mileage may vary, batteries not included, etc....

3 2

Microbursts on Ceragon IP-10G
by Abel Alejandro 31 Jan '12

31 Jan '12

Hello, I have a Ceragon IP-10G to provide backhaul access for an LTE network. The client wants to have 50Mbps of throughput with an RTT of 50ms on a single TCP session. The problem are the packet drops due to microbursts due to tcp slow start come from a 1GE port and then they get dropped at the radio. I can burst about 60KB of data before experiencing packet loss. Has anyone has a similar problem with this problem and found a solution? PS: I already have a case open, its just going kind of slow. Thanks, Abel.

1 0

ARP is sourced from loopback address
by Joe Maimon 31 Jan '12

31 Jan '12

Hey All, Anycast related. Is this normal behavior? Whats the workaround? Why havent I run into this before? 192.168.76.1 is a HSRP address on a ring of routers transiting a private non routed vlan to the service addresses hosted on systems that have independent management interfaces. Best, Joe root@debian31:~# ifconfig lo:0 lo:0 Link encap:Local Loopback inet addr:209.54.140.64 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1 root@debian31:~# ip rule list 0: from all lookup local 32764: from 209.54.140.0/24 lookup pbr1-exit 32765: from 216.222.144.16/28 lookup pbr1-exit 32766: from all lookup main 32767: from all lookup default root@debian31:~# ip route list table pbr1-exit default via 192.168.76.1 dev eth1 192.168.34.0/24 dev eth1 scope link src 192.168.76.16 192.168.76.0/24 dev eth1 scope link src 192.168.76.16 root@debian31:~# tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 11:08:09.053943 ARP, Request who-has 192.168.76.1 tell 209.54.140.64, length 28 11:08:10.035126 IP noc08rt08.noc08.chl.net > 209.54.140.64: ICMP echo request, id 517, seq 0, length 80 11:08:10.051276 ARP, Request who-has 192.168.76.1 tell 209.54.140.64, length 28 11:08:11.052548 ARP, Request who-has 192.168.76.1 tell 209.54.140.64, length 28 11:08:12.035964 IP noc08rt08.noc08.chl.net > 209.54.140.64: ICMP echo request, id 517, seq 1, length 80 ^C root@debian31:~# ip neigh fe80::230:71ff:fe3b:6808 dev eth0 lladdr 00:30:71:3b:68:08 router STALE 192.168.76.1 dev eth1 FAILED 192.168.34.254 dev eth0 lladdr 00:11:93:04:7a:1b DELAY 192.168.34.48 dev eth0 lladdr 00:0c:29:fd:64:8a STALE root@debian31:~# uname -a Linux debian31 3.2.0-1-686-pae #1 SMP Tue Jan 24 06:09:30 UTC 2012 i686 GNU/Linux root@debian31:~# ping 192.168.76.1 PING 192.168.76.1 (192.168.76.1) 56(84) bytes of data. 64 bytes from 192.168.76.1: icmp_req=1 ttl=255 time=2.95 ms ^C --- 192.168.76.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.952/2.952/2.952/0.000 ms root@debian31:~# ip neigh fe80::230:71ff:fe3b:6808 dev eth0 lladdr 00:30:71:3b:68:08 router STALE 192.168.76.1 dev eth1 lladdr 00:00:0c:9f:f0:01 REACHABLE 192.168.34.254 dev eth0 lladdr 00:11:93:04:7a:1b REACHABLE 192.168.34.48 dev eth0 lladdr 00:0c:29:fd:64:8a STALE 192.168.76.2 dev eth1 lladdr 00:b0:4a:9e:54:00 STALE root@debian31:~# !tcp tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 11:12:22.476479 IP noc08rt08-l0.noc08.chl.net > 209.54.140.64: ICMP echo request, id 518, seq 0, length 80 11:12:22.476572 IP 209.54.140.64 > noc08rt08-l0.noc08.chl.net: ICMP echo reply, id 518, seq 0, length 80 11:12:22.479495 IP noc08rt08-l0.noc08.chl.net > 209.54.140.64: ICMP echo request, id 518, seq 1, length 80 11:12:22.479533 IP 209.54.140.64 > noc08rt08-l0.noc08.chl.net: ICMP echo reply, id 518, seq 1, length 80 11:12:22.484346 IP noc08rt08-l0.noc08.chl.net > 209.54.140.64: ICMP echo request, id 518, seq 2, length 80 11:12:22.484392 IP 209.54.140.64 > noc08rt08-l0.noc08.chl.net: ICMP echo reply, id 518, seq 2, length 80 11:12:22.487670 IP noc08rt08-l0.noc08.chl.net > 209.54.140.64: ICMP echo request, id 518, seq 3, length 80 11:12:22.487705 IP 209.54.140.64 > noc08rt08-l0.noc08.chl.net: ICMP echo reply, id 518, seq 3, length 80 11:12:22.490639 IP noc08rt08-l0.noc08.chl.net > 209.54.140.64: ICMP echo request, id 518, seq 4, length 80 11:12:22.490675 IP 209.54.140.64 > noc08rt08-l0.noc08.chl.net: ICMP echo reply, id 518, seq 4, length 80 ^C

4 7