- Test - lists.nanog.org

AOL Help Request
by Jeffrey Sharpe 30 Apr '07

30 Apr '07

If someone has a contact for a AOL mail Admin, could you please contact me off list. We just moved to new netblocks and are getting nowhere with the phone support or the postmaster(a)aol.com contacts. ------------------------------------------------ Jeffrey Sharpe CyberLynk Helpdesk and Support 414.858.9335 or 800.942.8022 jsharpe(a)cyberlynk.net ------------------------------------------------

1 0

Thanks (off topic yet again)
by J. Oquendo 30 Apr '07

30 Apr '07

Thanks to the great folks on this list! Someone responded and the cable has been loaned! If anyone ever needs something in or around New Haven or Hartford just yell. -- ==================================================== J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 echo infiltrated.net|sed 's/^/sil@/g' "Wise men talk because they have something to say; fools, because they have to say something." -- Plato

1 0

Extremely off topic but semi urgent
by J. Oquendo 30 Apr '07

30 Apr '07

Anyone around 1533 Broadway NYC vicinity that has a loaner console cable for a customer who's router bit the bullet? Off list response appreciated... And apologies for disturbing the peace... -- ==================================================== J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 echo infiltrated.net|sed 's/^/sil@/g' "Wise men talk because they have something to say; fools, because they have to say something." -- Plato

1 0

ARIN is allocating from 96/8,97/8,98/8,99/8
by Leslie Nobile 30 Apr '07

30 Apr '07

Hello- This announcement is being sent to multiple lists. Apologies for any duplicates. ARIN was issued the IPv4 address blocks 96/8, 97/8, 98/8, and 99/8 by the IANA on Oct. 3, 2006. ARIN is now issuing /20 and shorter prefixes from these blocks to customers. Network operators may wish to adjust any filters in place accordingly. For informational purposes, a list of ARIN's currently administered IP blocks can be found at: http://www.arin.net/reference/ip_blocks.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)

1 0

URL for the Drone Armies C&C report
by RL Vaughn 30 Apr '07

30 Apr '07

Those interested in the latest botnet C&C reports can find the most recent Drone Armies C&C report on <http://isotf.org/ccreport.html> Randal Vaughn

1 0

from the academic side of the house
by bmanning＠karoshi.com 29 Apr '07

29 Apr '07

For the first set of IPv6 records, a team from the University of Tokyo, WIDE Project, NTT Communications, JGN2, SURFnet, CANARIE, Pacific Northwest Gigapop and other institutions collaborated to create a network path over 30,000 kilometers in distance, crossing 6 international networks - over 3/4 the circumference of the Earth. In doing so, the team successfully transferred data in the single and multi-stream categories at a rate of 7.67 Gbps which is equal to 230,100 terabit-meters per second (Tb-m/s). This record setting attempt leveraged standard TCP to achieve the new mark. The next day, the team used a modified version of TCP to achieve an even greater record. Using the same 30,000 km path, the network was able to achieve a throughput of 9.08 Gbps which is equal to 272,400 Tb-m/s for both the IPv6 multi and single stream categories. In doing so, the team surpassed the current IPv4 records, proving that IPv6 networks are able to provide the same, if not better, performance as IPv4. --bill

7 9

Fw: [spoofing-tf] BCP38 Business Case Document
by Fergie 29 Apr '07

29 Apr '07

While we're working out problems on the IETF SAVA list, I'd like to float this here (if you haven't already seen it), and hear some comments from the NANOG landscape. Is this relevant? Thanks, - ferg [snip] From: Daniel Karrenberg <daniel.karrenberg(a)ripe.net> To: RIPE IP Anti-Spoofing Task Force <spoofing-tf(a)ripe.net> Date: Thu, 26 Apr 2007 16:14:31 +0200 Here is the latest draft of the "Network Hygiene Pays Off" document. The goal is to publish this after Talinn. Daniel ---- "Network Hygiene Pays Off" The Business Case for IP Source Address Verification Joao Luis Silva Damas Daniel Karrenberg v0.3 Tue Apr 24 09:45:15 CEST 2007 Introduction IP source address verification entirely prevents a class of prevalent reflector-type DDoS attacks, helps to track down attacking hosts and simplifies some network management tasks. Yet a significant number of ISPs do not deploy it at the edge of their networks. Common wisdom seems to be that doing so would be expensive and would only help they "other guy" who is being attacked. This memo tries to contrast common wisdom with some facts. What is BCP38 BCP 38 is a "Best Current Practice" document of the IETF. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. BCP 38 has been updated by BCP 84, RFC3704. No Confidence in IP Source Addresses is Bad Suppose you need to investigate some unusual traffic flows or you just plain want to analyze current traffic load. If you do not do BCP38 there is absolutely nothing you can get to know about the source of a packet from the packet alone. You cannot trust the source address at all. They packet could have entered your network *anywhere*. Can that be good? Suppose someone launches an attack on one of your customers with packets that appear to come from another customer. The victim will likely request that you take action and stop the harmful traffic that appears to originate from another customer of yours. If you do not do BCP38 you will have to tell the victim that this traffic could come from anywhere and that you cannot determine very quickly where the traffic is indeed coming from. Someone Can Pretend to be You Even worse, if you do not do BCP38 an attacker can launch an attack with packets that appear to be coming from one of the machines you operate yourself. Imagine the reaction of a customer that gets attacked by such packets. Are they going to trust you when you explain it is not really you? What will they think if you tell them that your network operating practices allow such masquerading? Imagine the cost of that. Good Practice is Not Hard It is not hard to prevent such a scenario. You simply have to do BCP38 towards your customers and drop all packets with internal source addresses coming in from external peerings. Once you have done that you *know* exactly who has sent a packet with an internal source address and you also know that any packet with an external source address must have come in via one of the external peerings. Some multi-homing customers may require special configuration efforts. However these are neither impossible or very costly if implemented well. Our how-to documents explain the technical details. Since large classes of customers cannot be multi-homed to start with, you can gain a lot by starting to do BCP38 for them. Doing BCP38 Helps A Lot and Builds Confidence Doing BCP38 helps a lot with analyzing anomalies and makes understanding normal traffic load very much more reliable. In case any attacks or anomalies do happen, you can determine with any source within your own network or from any customer with confidence, simply by looking at the traffic itself! The decision about any countermeasures can be made very quickly and without any involved specialist traceback analysis. In case the source of the attack traffic is external, you can also state that with confidence to your customers and take action. Reflector Attacks Cannot Happen Between Customers If you do not do BCP38 one customer can attack another with a DoS reflector attack. Consider your responsibility and possible liability if this were possible. If you do BCP38 your customers cannot do this to each other and any reflector attack traffic has to come from outside your network, thus form outside your direct responsibility. Doing BCP38 is Good Publicity Showing that you operate your network responsibly and safely is good publicity; stating that you do BCP38 is helps with that. Showing responsibility for operating safely discourages regulation and legislation of operating practices. Consider the difficulty to convince policy makers that enabling users to lie about their "caller-ID" is your normal operating practice. Consider All Costs When considering the cost of implementing BCP38 in your network, you should consider the costs of not doing so together with the costs for implementation of BCP38 itself. The savings in the network management area and in mitigation of DoS attacks may well outweigh the implementation costs. The added good publicity and confidence in good operating practices should not be neglected either. Testimonials of ISPs Who Do BCP38 [Add ISP statements about experiences, illustrating both cost and benefits.] [end] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

PANAP: free IX in Paris - France
by Frederic NGUYEN 29 Apr '07

29 Apr '07

Dear Collegues, Some of you may consider this email as a spam. However, can we really consider a free network service proposal as such? PANAP is a free IX located in Paris, France. Membership is completely free and we offer up to 10GE connection. All we ask you is to peer with us :) Currently only IPv4 is available. But IPv6 will come before summer. Multicast will come next. I created PANAP with my teams in July 2005. Since then, it grew up very rapidly, counting now over 100 members. http://www.panap.fr/members.php For those interested, I'd like to invite you to join PANAP by applying here: http://www.panap.fr/join.php Best regards, _________________________________________________ Frederic NGUYEN (aka chainess) Senior Manager Network Engineering Club-Internet / T-Online France

1 0

Re: from the academic side of the house
by Simon Leinen 29 Apr '07

29 Apr '07

Tony Li writes: > On Apr 25, 2007, at 2:55 PM, Simon Leinen wrote: >> Routing table lookups(*) are what's most relevant here, [...] > Actually, what's most relevant here is the ability to get end-hosts > to run at rate. Packet forwarding at line rate has been > demonstrated for quite awhile now. That's true (although Steve's question was about the routers). The host bottleneck for raw 10Gb/s transfers used to be bus bandwidth. The 10GE adapters in most older land-speed record entries used the slower PCI-X, while this entry was done with PCI Express (x8) adapters. Another host issue would be interrupts and CPU load for checksum, but most modern 10GE (and also GigE!) adapters offload checksum segmentation and reassembly, as well as checksum computation and validation to the adapter if the OS/driver supports it. The adapters used in this record (Chelsio S310E) contain a full TOE (TCP Offload Engine) that can run the entire TCP state machine on the adapter, although I'm more sure whether they made use of that. Details on http://data-reservoir.adm.s.u-tokyo.ac.jp/lsr-200612-02/ -- Simon.

2 1

MEDIA: Interview with Karl Auerbach
by william(at)elan.net 28 Apr '07

28 Apr '07

http://www.theregister.co.uk/2007/04/24/icann_auerbach_interview_lisbon/ "ICANN is the USSR of the internet - Karl Auerbach speaks out" by Burke Hansen published Tuesday 24th April 2007 00:38 GMT -- William Leibzon Elan Networks william(a)elan.net

1 0