August 2010 - Test - lists.nanog.org

Cisco Security Advisory: Cisco IOS Software TCP Denial of Service Vulnerability
by Cisco Systems Product Security Incident Response Team 12 Aug '10

12 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software TCP Denial of Service Vulnerability Advisory ID: cisco-sa-20100812-tcp http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml Revision 1.0 For Public Release 2010 August 12 2130 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software Release, 15.1(2)T is affected by a denial of service (DoS) vulnerability during the TCP establishment phase. The vulnerability could cause embryonic TCP connections to remain in a SYNRCVD or SYNSENT state. Enough embryonic TCP connections in these states could consume system resources and prevent an affected device from accepting or initiating new TCP connections, including any TCP-based remote management access to the device. No authentication is required to exploit this vulnerability. An attacker does not need to complete a three-way handshake to trigger this vulnerability; therefore, this this vunerability can be exploited using spoofed packets. This vulnerability may be triggered by normal network traffic. Cisco has released Cisco IOS Software Release 15.1(2)T0a to address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml. Affected Products ================= This vulnerability affects only Cisco IOS Software Release 15.1(2)T. No other Cisco IOS Software Releases are affected. Cisco IOS XE Software, Cisco IOS XR Software, and Cisco NX-OS Software are not affected by this vulnerability. Vulnerable Products +------------------ A Cisco device is vulnerable when it is running Cisco IOS Software Release 15.1(2)T. To determine the Cisco IOS Software Release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software Release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.1(2)T with an installed image name of C2800NM-ENTSERVICES-M: Router#show version Cisco IOS Software, 2800 Software (C2800NM-ENTSERVICES-M), Version 15.1(2)T, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Mon 19-Jul-10 16:38 by prod_rel_team <output truncated> Additional information about Cisco IOS Software Release naming conventions is available in the White Paper: Cisco IOS Reference Guide. Products Confirmed Not Vulnerable +-------------------------------- No other Cisco IOS Software versions are affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= TCP provides reliable data transmission services in packet-switched network environments. TCP corresponds to the transport layer (Layer 4) of the OSI reference model. Among the services TCP provides are stream data transfer, reliability, efficient flow control, full-duplex operation, and multiplexing. When TCP connections are terminated in Cisco IOS Software, they are allocated a transmission control block (TCB). All allocated TCBs, associated TCP port numbers, and the TCP state are displayed in the output of the "show tcp brief all" command-line interface (CLI) command. Cisco IOS Software version 15.1(2)T contains a vulnerability that could cause an embryonic TCP connection to remain in SYNRCVD or SYNSENT state without a further TCP state transition. Examining the output of the "show tcp brief all" command multiple times will indicate if TCP sessions remain in one of these states. This vulnerability is triggered only by TCP traffic that is terminated by or originated from the device. Transit traffic will not trigger this vulnerability. Both connections to and from the router could trigger this vulnerability. An example of a connection to the router is that you may still be able to ping the device, but fail to establish a TELNET or SSH connection to the device. For example, an administrator may still be able to ping the device but fail to establish a Telnet or SSH connection to the device. Administrators who attempt a Telnet or a SSH connection to a remote device from the CLI prompt will encounter a hung session and the "Trying <ip address|hostname> ..." prompt. The connection that is initiated or terminated by the router can be removed from the socket table by clearing the associated TCB with the "clear tcp tcb 0x<address>" command. Devices could be vulnerable if examining the output of the CLI command "debug ip tcp transactions", displays the error messages "connection queue limit reached: port <port number>" or "No wild listener: port <port number>". Devices could also be vulnerable if output from repetitive show tcp brief all CLI commands indicates many TCBs in the state SYNRCVD or SYNSENT. The following example shows a device that has several HTTP, SSH, and Telnet sessions in the TCP SYNRCVD state: Example#show tcp brief all TCB Local Address Foreign Address (state) 07C2D6C8 192.168.0.2.443 192.168.0.5.11660 SYNRCVD 07C38128 192.168.0.2.23 192.168.0.5.35018 SYNRCVD 07C2DD60 192.168.0.2.443 192.168.0.5.19316 SYNRCVD 07C2A8A0 192.168.0.2.80 192.168.0.5.13818 SYNRCVD <output truncated> Any TCP sessions can be cleared by clearing the associated TCB with "clear tcp tcb 0x<address>". Alternatively Administrators can clear all TCBs at once by issuing "clear tcp tcb *". Note: This will clear all active and hung TCP connections. This vulnerability is documented in the Cisco bug ID CSCti18193. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2827. Some TCP application specific information is provided in the following sections: Telnet and SSH +------------- Telnet can not be explicitly disabled on a Cisco IOS device. Configuring "transport input none" on the vty lines of a vulnerable device will prevent it from being exploited on TCP port 23. However, if the Cisco IOS SSH server feature is configured on the device, "transport input none" will not prevent the device from being exploited on TCP port 22. Configuration of vty access control lists can partially mitigate this vulnerability because the vulnerability can be exploited using spoofed IP source addresses. Border Gateway Protocol +---------------------- Routers that are configured with Border Gateway Protocol (BGP) can be protected further by using the Generalized Time to Live (TTL) Security Mechanism (GTSM) feature. GTSM allows users to configure the expected TTL of a packet between a source and destination address. Packets that fail the GTSM check will be dropped before TCP processing occurs, which prevents an attacker from exploiting this vulnerability through BGP. GTSM is implemented with the command "ttl-security hops". Further information on protecting BGP can be found in "Protecting Border Gateway Protocol for the Enterprise" (http://www.cisco.com/web/about/security/intelligence/protecting_bgp.html#7) TCP MD5 Authentication for BGP does not prevent this vulnerability from being exploited. Vulnerability Scoring Details ============================= Cisco has provided a score for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCti18193 ("TCP connections never timeout in IOS 15.1(2)T") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may prevent some TCP applications on Cisco IOS Software from accepting any new connections. Exploitation could also prevent remote access to the affected system via the vtys. Remote access to the affected device via out-of-band connectivity to the console port should still be available. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +---------------------------------------+ | Major | Availability of Repaired | | Release | Releases | |------------+--------------------------| | Affected | | | 12.x-Based | First Fixed Release | | Releases | | |------------+--------------------------| | 12.0 - | 12.0 through 12.4 based | | 12.4 | releases are not | | | affected | |------------+--------------------------| | Affected | | | 15.0-Based | First Fixed Release | | Releases | | |------------+--------------------------| | 15.0 | There are no affected | | | 15.0 based releases | |------------+--------------------------| | Affected | | | 15.1-Based | First Fixed Release | | Releases | | |------------+--------------------------| | | 15.1(2)T0a | | | | | | 15.1(2)T1; available on | | | 20-AUG-2010 | | 15.1T | | | | Releases prior to 15.1 | | | (2)T are not vulnerable. | | | The vulnerability is | | | first fixed in release | | | 15.1(2)T0a. | +---------------------------------------+ Workarounds =========== The only complete workaround to mitigate this vulnerability is to disable the specific features that make a device vulnerable, if this action is feasible. Allowing only legitimate devices to connect to affected devices will help limit exposure to this vulnerability. Refer to the following Control Plane Policing and Configuring Infrastructure Access Lists subsections for further details. Because a TCP three-way handshake is not required, the mitigation must be combined with anti-spoofing measures on the network edge to increase effectiveness. Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20100812-tcp.shtml Cisco Guide to Harden Cisco IOS Devices +-------------------------------------- The Cisco Guide to Harden Cisco IOS Devices provides examples of many useful techniques to mitigate TCP state manipulation vulnerabilities. These include: * Infrastructure Access Control Lists (iACL) * Receive Access Control Lists (rACL) * Transit Access Control Lists (tACL) * vty Access Control Lists * Control Plane Policing (CoPP) * Control Plane Protection (CPPr) For more information on these topics, consult "Cisco Guide to Harden Cisco IOS Devices" (http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a008…) CoPP +--- For devices that need to offer TCP services, administrators can use CoPP to block TCP traffic from untrusted sources that is destined to the affected device. Cisco IOS Software Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to specific network configurations: ! !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit), !-- then traffic will be dropped. If the access list does not !-- match (deny), then traffic will be processed by the router. !-- Note that TCP ports 22 and 23 are examples; this !-- configuration needs to be expanded to include all used !-- TCP ports. ! access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 22 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 23 access-list 100 deny tcp host 172.16.1.1 any eq 22 access-list 100 deny tcp host 172.16.1.1 any eq 23 access-list 100 permit tcp any any ! !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a class map for traffic that will be policed by !-- the CoPP feature. ! class-map match-all drop-tcp-class match access-group 100 ! !-- Create a policy map that will be applied to the !-- Control Plane of the device, and add the "drop-tcp-traffic" !-- class map. ! policy-map control-plane-policy class drop-tcp-class drop ! !-- Apply the policy map to the control plane of the !-- device. ! control-plane service-policy input control-plane-policy Warning: Because a TCP three-way handshake is not required to exploit this vulnerability, it is possible to spoof the IP address of the sender, which could defeat access control lists (ACLs) that permit communication to these ports from trusted IP addresses. In the preceding CoPP example, the access control entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at "Control Plane Policing Implementation Best Practices" (http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html) and "Control Plane Policing" (http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html) Configuring iACLs +---------------- Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper "Protecting Your Core: Infrastructure Protection Access Control Lists" (http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a0…) presents guidelines and recommended deployment techniques for infrastructure protection ACLs. BGP Considerations +---------------- GTSM can help prevent exploitation of this vulnerability by means of the BGP port because packets that originate from devices that do not pass the TTL check configured by GTSM are dropped before any TCP processing occurs. For information on GTSM refer to "BGP Support for TTL Security Check" (http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html) and "BGP Time To Live Security Check" (http://www.cisco.com/web/about/security/intelligence/protecting_bgp.html#7) Embedded Event Manager (EEM) +--------------------------- A Cisco IOS Embedded Event Manager (EEM) policy that is based on Tool Command Language (Tcl) can be used on vulnerable Cisco IOS devices to identify and detect a hung, extended, or indefinite TCP connection that is caused by this vulnerability. The policy allows administrators to monitor TCP connections on a Cisco IOS device. When Cisco IOS EEM detects potential exploitation of this vulnerability, the policy can trigger a response by sending a syslog message or a Simple Network Management Protocol (SNMP) trap to clear the TCP connection. The example policy provided in this document is based on a Tcl script that monitors and parses the output from two commands at defined intervals, produces a syslog message when the monitor threshold reaches its configured value, and can reset the TCP connection. The Tcl script is available for download at the "Cisco Beyond: Embedded Event Manager (EEM) Scripting Community" (http://www.cisco.com/go/ciscobeyond) at the following link http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=2041, and the device sample configuration is provided below. ! !-- Location where the Tcl script will be stored ! event manager directory user policy disk0:/eem ! !-- Define variable and set the monitoring interval !-- as an integer (expressed in seconds) ! event manager environment EEM_MONITOR_INTERVAL 60 ! !-- Define variable and set the threshold value as !-- an integer for the number of retransmissions !-- that determine if the TCP connection is hung !-- (a recommended value to use is 15) ! event manager environment EEM_MONITOR_THRESHOLD 15 ! !-- Define variable and set the value to "yes" to !-- enable the clearing of hung TCP connections ! event manager environment EEM_MONITOR_CLEAR yes ! !-- Define variable and set to the TCP connection !-- state or states that script will monitor, which !-- can be a single state or a space-separated list !-- of states ! event manager environment EEM_MONITOR_STATES SYNRCVD SYNSENT ! !-- Register the script as a Cisco EEM policy ! event manager policy monitor-sockets.tcl Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt(a)cisco.com or security-alert(a)cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by a customer. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * first-bulletins(a)lists.first.org * bugtraq(a)securityfocus.com * vulnwatch(a)vulnwatch.org * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.grok.org.uk * comp.dcom.sys.cisco(a)newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2010-August-12 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.…. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2008-2010 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- Updated: Aug 12, 2010 Document ID: 112099 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxkdOsACgkQ86n/Gc8U/uApYwCfeZAQ3FcneSd+MEaIn+qMV2zb bYgAn2Zg6rcHlDyLaPepO/C0hwINLk2v =5Pfg -----END PGP SIGNATURE-----

1 0

Reminder: DENOG 2 Call for Participation and Papers
by Marcus Stoegbauer 12 Aug '10

12 Aug '10

DENOG 2 - Call for Participation and Papers The second meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 4th of November 2010. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www2.denog.de/ Information about the meeting will be published at http://www.denog.de/. Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers May 11th, 2010 Deadline for all submissions September 15th, 2010 Beginning of Registration Period End of August, 2010 Publication of final programme End of September, 2010 Deadline for receipt of final slides October 24th, 2010 Meeting Day November 4th, 2010 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals for longer/shorter presentations or presentations whose subject falls outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 29th, with the deadline for submission of the corresponding slides being November 3rd. Topic #1: Power Efficiency in Networks --------------------------------------- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security ------------------------------------------------------------------ Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Network Neutrality ---------------------------- In the US, Network Neutrality has been a subject of controversy and debate. Is an ISP allowed to sell "Internet access" which only offers access to a subset of the whole Internet? Is an ISP allowed to prioritise video streams from Company A while imposing a higher delay to video streams from Company B? In Germany Network Neutrality is mainly an issue for mobile networks and not extensively discussed thus far. But what kind of problems will an upcoming debate on Network Neutrality bring to German ISPs and is there a good way to address these problems? Topic #4: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #5: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to <denog-pc(a)denog.de>: * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be published on the DENOG website after the event.

1 0

Re: Policy Based Routing advice
by Andrey Khomyakov 12 Aug '10

12 Aug '10

I bit more explanation: 172.25/16 is a hop away and the packets with that source IP will enter on Gi2/6 and need to exit Gi2/14. So it goes like that: 172.25/16 is vlan25 on the student router Gi0/1 has ip address 192.168.250.2 on the student router default route is towards 192.168.250.1 on the student router > On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov < > khomyakov.andrey(a)gmail.com> wrote: > >> Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E >> and >> for some reason I can't see it taking effect. I'm definitely sourcing >> packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). >> For >> some reason the packets still go out towards the default gateway instead >> of >> what's specified in the route-map. The switch is running >> cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) >> According to stats on the ACL and the route-map it's just not being hit >> for >> some reason. Applying the ACL directly to the interface (as an >> access-group) >> shows that the ACL is correct and I see hits, however, via the route map >> it's not being hit. I don't know what those "2 matches" are, but there >> definitely should be a lot more than 2. And in addition, I see the packets >> arriving on the firewall that is the "default gateway". >> >> Does anyone have any tips on why this might now work? >> >> >> ip access-list standard acl_Students >> permit 172.25.0.0 0.0.255.255 >> >> route-map Students-Route-Map permit 10 >> match ip address acl_Students >> set ip next-hop 192.168.168.22 >> >> interface GigabitEthernet2/6 >> no switchport >> ip address 192.168.250.1 255.255.255.252 >> ip pim dense-mode >> ip policy route-map Students-Route-Map >> >> interface GigabitEthernet2/14 >> no switchport >> ip address 192.168.168.21 255.255.255.252 >> no ip redirects >> no ip mroute-cache >> flowcontrol send desired >> >> cat4503#sh access-lists acl_Students >> Standard IP access list acl_Students >> 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) >> >> >> cat4503#sh route-map >> route-map Students-Route-Map, permit, sequence 10 >> Match clauses: >> ip address (access-lists): acl_Students >> Set clauses: >> ip next-hop 192.168.168.22 >> Policy routing matches: 2 packets, 180 bytes >> >> cat4503#sh ip route 0.0.0.0 >> Routing entry for 0.0.0.0/0, supernet >> Known via "static", distance 1, metric 0, candidate default path >> Redistributing via eigrp 179 >> Advertised by eigrp 179 >> Routing Descriptor Blocks: >> * 192.168.168.10 >> Route metric is 0, traffic share count is 1 >> >> -- >> Andrey Khomyakov >> [khomyakov.andrey(a)gmail.com] >> > > -- Andrey Khomyakov [khomyakov.andrey(a)gmail.com]

4 6

Springnet Underground
by Justin Shore 12 Aug '10

12 Aug '10

Does anyone have any experience with the Springnet Underground in Springfield, MO? In case people don't know it's a working limestone mine. In the areas that have already been mined close to the entrance, they've sold or rented out space between the rock pillars that hold up the mine roof. The city of Springfield put in a data center and started selling services out of it that complimented their city-wide fiber plant. They've been suggested as a site for hosting a cabinet full of gear. I'm wondering what the connectivity options are for that facility and so far haven't been able to get a straight answer from anyone. For the most part it looks like the SprintNet folks want to sell you their own upstream which won't cut it for our needs. AT&T serves the area of course but I will not have them as my last mile (or any mile for that matter). Does L3 or any other large carrier have facilities there? Does anyone have any experience with the facility in general? Thanks Justin

1 0

Chunghwa Telecom Tech Support Reg.
by Natarajan Balasubramanian 12 Aug '10

12 Aug '10

Hi All, Does anyone have the contact number for "Chunghwa Telecom's" Business Users - Technical Support number ? -Nat

4 5

Re: IPv6 Server Load Balancing - DSR
by Leland Vandervort 12 Aug '10

12 Aug '10

Well, Frankly our "culture" is very much open source, so if we can find something along those lines, then it would be preferred. (Hence looking at OpenSolaris and ILB). -- having said that, we do have both F5 and Foundry kit here, but it's all pre-IPv6 so doesn't have the support built in. Not really looking to replace what is in existence already for IPv4 with something new to do both, so really that reinforces the open-source avenue really. I think the biggest problem is really the DSR aspect for IPv6, since the OS/ILB solution works perfectly in NAT mode, and DSR works perfectly with IPv4 on this solution. So either I'm missing something critical on the "real" server configuration, or ILB's implementation of DSR for IPv6 doesn't really work. The "virtual" IP is bound to loopback on the real servers, exactly the same was as for IPv4. So other than something quirky going on with ND, or simply ILB not correctly rewriting the L2 frame, or there's something else more sinister afoot that I'm unable to put my finger on. Back to the drawing board... :) Thanks, Leland On 12 Aug 2010, at 19:23, William Cooper wrote: > I know there have been quite a few responses for both h/w and s/w > solutions, it's not clear > which your preference is of the two. I know there are various h/w > vendors that offer a s/w > solution (mostly in conjunction with some form of virtualization > environment), such as A10. > > I've been testing A10 for a while now, and they seem very keen on > developing parity between > v4 and v6 feature sets / performance. > > DSR is more or less a L2 trick that plays on some inherent weaknesses > and constraints > that are present with v4 local address resolution (don't mean to > preach to the chior); I think > most responses here have touched on the primary challenges of DSR with > v6. I'll be exploring > DSR with dual stack v4/6 in the near future, I'll let you know how > that turns out. > > Hmm... not sure how this helped. > > Regards, > > -Tony > > On Thu, Aug 12, 2010 at 12:40 PM, Leland Vandervort > <leland(a)taranta.discpro.org> wrote: >> Hi Owen, >> >> The DSR address is indeed on a loopback in our case. >> >> lo Link encap:Local Loopback >> inet6 addr: ::1/128 Scope:Host >> inet6 addr: xxxx:xxxx:x:xxxx::xx/128 Scope:Global >> >> >> >> The mystery continues... >> >> >> Leland >> >> >> On 12 Aug 2010, at 18:28, Owen DeLong wrote: >> >>> >>> On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: >>> >>>> Hi Leland, >>>> >>>> Le 12 août 2010 à 15:11, Leland Vandervort a écrit : >>>> >>>>> OpenSolaris ILB is open solution ;) >>>>> >>>>> but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) >>>>> >>>>> does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? >>>> >>>> It does everything... :) L2 -> L7... >>>> >>>>> In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... >>>> >>>> Maybe on some setup you should desactivate ND... >>>> >>>> Xavier >>> >>> If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD >>> will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will >>> shut down all. >>> >>> >>> Owen >> >> >>

1 0

IPv6 Server Load Balancing - DSR
by Leland Vandervort 12 Aug '10

12 Aug '10

Dear Colleagues, I've been scratching my head over this for the past couple of months and have come up with blanks, and several weeks of scouring various resources on the net have not yielded anything more fruitful. I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. I have evaluated a number of different load balancing solutions purporting to support IPv6 with varying results (and costs)... a few examples: F5 : according to marketing blurb supposedly supports IPv6 in NAT and DSR mode, both UDP and TCP. Their documentation, however, has no mention of IPv6 capability. Other disadvantage = cost... Brocade/Foundry: Similar situation to F5 Zeus: IPv6 in NAT only, and even more expensive than F5. Exceliance Aloha: IPv6 in NAT only, and ONLY in TCP (no UDP) A few others also tested... including LVM/HAProxy (same situation as Exceliance Aloha), and others... Finally in the end, only OpenSolaris ILB seems to put all the checks in the right boxes for my requirements. But there is still a problem. 1. IPv4 TCP and UDP work fine in NAT, Half-NAT, and DSR 2. IPv6 I've managed to get working, complete with healthchecks, in TCP and UDP in NAT only although the documentation stipulates that DSR is also possible (but not HalfNAT for the moment). The problem with #2: Using the same server farm behind, but in dual-stack, and configuring ILB for TCP and UDP services using NAT, everything is fine. If I configure it for DSR, immediately it fails (both with and without healthchecks). Although from the ILB host itself, I can certainly do a manual heathcheck.. (e.g. telnet <server_real_ipv6_addr> 80 and do GET / or HEAD / with no problems. Using ARP poisoning from the shell I can also perform the healthcheck on the real server via telnet using the virtual ip. The servers are configured normally for DSR.. with the virtual IP attached to a local dummy or loopback interface, and with IPv4 DSR works fine. Nevertheless, I've been unable to get DSR working with ILB -- and have found absolutely nothing around the net with working examples of IPv6 SLB with DSR. NAT mode works fine, but the real server loses visibility of the end user's IP as the requests come from the internal IP of the ILB host, and with a system that uses client IP address as part of the various criteria for session tracking, it creates a few problems... I am suspecting that the issue may be related to ND, as the behaviour is similar to the old story with doing DSR on real-servers using older linux distributions that do not by default disable proxy-ARP replies by the server for IP addresses on dummy or loopback interfaces, and of course the proxy ARP causes confusion to the load balancer and breaks the whole thing. But the real servers are recent Debian distributions, and both ipv4 ARP and ipv6 ND is disabled on the dummy interfaces, as is proxy ARP. Would anyone happen to have any useful pointers, tips, or other on how to resolve the issue? Many thanks in advance. Leland

7 10

Policy Based Routing advice
by Andrey Khomyakov 12 Aug '10

12 Aug '10

Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E and for some reason I can't see it taking effect. I'm definitely sourcing packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). For some reason the packets still go out towards the default gateway instead of what's specified in the route-map. The switch is running cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) According to stats on the ACL and the route-map it's just not being hit for some reason. Applying the ACL directly to the interface (as an access-group) shows that the ACL is correct and I see hits, however, via the route map it's not being hit. I don't know what those "2 matches" are, but there definitely should be a lot more than 2. And in addition, I see the packets arriving on the firewall that is the "default gateway". Does anyone have any tips on why this might now work? ip access-list standard acl_Students permit 172.25.0.0 0.0.255.255 route-map Students-Route-Map permit 10 match ip address acl_Students set ip next-hop 192.168.168.22 interface GigabitEthernet2/6 no switchport ip address 192.168.250.1 255.255.255.252 ip pim dense-mode ip policy route-map Students-Route-Map interface GigabitEthernet2/14 no switchport ip address 192.168.168.21 255.255.255.252 no ip redirects no ip mroute-cache flowcontrol send desired cat4503#sh access-lists acl_Students Standard IP access list acl_Students 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) cat4503#sh route-map route-map Students-Route-Map, permit, sequence 10 Match clauses: ip address (access-lists): acl_Students Set clauses: ip next-hop 192.168.168.22 Policy routing matches: 2 packets, 180 bytes cat4503#sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Redistributing via eigrp 179 Advertised by eigrp 179 Routing Descriptor Blocks: * 192.168.168.10 Route metric is 0, traffic share count is 1 -- Andrey Khomyakov [khomyakov.andrey(a)gmail.com]

1 0

net-neutrality
by Sven Olaf Kamphuis 12 Aug '10

12 Aug '10

Hi, considering the fact that several organisations have been severely undermining net-neutrality over the past few months, which they seem to see as less important than their copyright bullshit, we have decided to set an example: Should the following networks, to which list more will be added over the coming month, desire to exchange traffic with AS34109, they can obtain a traffic relay contract at sales(a)cb3rob.net, the costs of which amount to 10000 euros per month, excl. 19% VAT, if not, well, then it's simply no more internets for them... sorry peeps. 193.108.8.0/21#GEMA-NET 195.109.249.64/29#SONYMUSIC 195.143.92.160/27#SBMG1-NETS 212.123.224.240/29#Net-WEGENER-MEDIA-BV 212.123.227.64/29#BumaStemra2 212.136.193.216/29#BUMA 212.78.179.240/28#BUMA-STEMRA 213.208.242.160/29#NL-COLT-BUMA-STEMRA 217.148.80.112/28#NL-NXS-CUST-1004613 85.236.46.0/24#IX-UNIVERSAL-NET -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven(a)cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.

10 17

RE: off-topic: summary on Internet traffic growth History
by John Lee 12 Aug '10

12 Aug '10

Andrew, Earlier this week I had a meeting with the ex-Director of the Network Operations Center for MFS-Datanet/MCI whose tenure was through 1999. From 1994 to 1998 they were re-architeching the Frame Relay and ATM networks to handle the growth in traffic including these new facilities called peering points of MAE-East and MAE-West. From roughly 1990 to then end of 1996 they saw traffic on their switches grow at 50-70% growth every 6 months. By the last half of 1996 there was a head of line blocking problem on the DEC FDDI switches that was "regularly" bringing down the Internet. The architecture had lower traffic circuits were going through concentrators while higher traffic circuits were directly attached to ports on the switchs. MFS-Datanet was not going to take the hit for the interruptions to the Internet and was going to inform the trade press there was a problem with DEC FDDI switches so Digital "gave" six switches for the re-architecture of the MAEs to solve the problem. Once this problem was solved the first quarter of 1997 saw a 70% jump in traffic that quarter alone. This "historical event" would in my memory be the genesis of the 100% traffic growth in 100 days legend. (So it was only 70% in 90 days which for the marketing folks does not cut it so 100% in 100 days sounds much better?? :) ) MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET "merged" with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. Personal Note: from 1983 to 90 I worked for Hayes the modem folks and became the Godfather to Ascend communications with Jeanette, Rob, Jay and Steve whose team produced the TNT line of modem/ISDN to Ethernet central site concentrators (in the early ninties) that drove a large portion of the user traffic to the Internet at the time, generating the "bubble". John (ISDN) Lee ________________________________________ From: Andrew Odlyzko [odlyzko(a)umn.edu] Sent: Wednesday, August 11, 2010 12:55 PM To: nanog(a)nanog.org Subject: off-topic: summary on Internet traffic growth myths Since several members of this list requested it, here is a summary of the responses to my request for information about Internet growth during the telecom bubble, in particular the perceptions of the O'Dell/Sidgmore/WorldCom/UUNet "Internet doubling every 100 days" myth. First of all, many thanks to all those who responded, on and off-list. This involved extensive correspondence and some long phone conversations, and helped fill out the picture of those very confusing times (and also made it even clearer than before that there were many different perspectives on what was happening). The entire message is rather long, but it is written in sections, to make it easy to get the gist quickly and neglect the rest. Andrew ------------------------------------------------------------------- 1. Short summary: People who got into the game late, or had been working at small ISPs or other enterprises, were generally willing to give serious credence to the "Internet doubling every 100 days" tale. The old-timers, especially those who worked for large ISPs or other large corporate establishment or research networks, were convinced by the late 1990s that this tale was false, but did not talk about it publicly, even inside the NANOG community. ------------------------------------------------------------------- 2. Longer version: The range of views was very wide, and hard to give justice to in full. But there seemed to be two distinct groups, and the consensus views (which obviously exclude quite a few people) appear to have been: 2A: Those who entered the field in the late 1990s, especially if they worked for small ISPs or other small enterprises, tended to regard the claim seriously. (But it should be remarked that hardly anybody devoted too much effort or thought to the claim, they were too busy putting out fires in their own backyards to worry about global issues.) They remembered periods of desperate efforts to keep up with exploding demand in their businesses. We saw just a few hours ago a post about LINX growing 5.5x in one year. Somebody else wrote about growing their business's traffic 1,000x in 2 years, or about 30x per year. People involved in such incidents often tended to think that their experience during such times might not have been untypical. 2B: Those who worked at places with large traffic, and especially those who got into the field in the early 1990s, were quite sure by the late 1990s that the UUNet fable was just that. Comments regarding everything emanating from UUNet during that period included phrases like "blowing smoke," "rolling our eyes," "taking it with a rock of salt." They had no direct knowledge of what went on inside UUNet, but from watching peering traffic, talking to salespeople about customer losses and wins, and to suppliers about deliveries of equipment, they could be pretty certain that neither the traffic nor the capacity of UUNet could be exploding at the mythical rates. They could see occasional spikes in traffic growth at some customers, or in some parts of their networks, but overall could see traffic growth settling down to a fairly regular doubling or a bit more than doubling each year. However, they did not discuss this in public, and I discuss that below, in point #4. ------------------------------------------------------------------- 3. Growth spurt in mid-1990s: The old-timers also provided very informative feedback about the global Internet traffic growth spurt in the 1995-96 time frame. It did hit suddenly and unexpectedly. (I am still trying to get confirmation on this, but I believe one of the informants said that before this period, the engineers at that person's Tier-1 ISP would routinely double the forecasts provided by the marketing team. At the peak of the bubble, the marketers would demand that the engineers plan for double the capacity that the engineers thought was going to be necessary.) Moreover, the dramatic slowdown in traffic growth that took place in 1997 was, at least in a number of cases, due substantially to a capacity crunch. Router and photonic equipment manufacturers did not have the technology needed for the traffic, and ILECs were slow in supplying access as well as backbone links. Hence the traffic growth spurt in 1996-96 was followed by a capacity growth spurt in 1997-98, which helped provide more credibility for the myth. ------------------------------------------------------------------- 4. Information viscosity: This incident provides far more information confirming the concept of "information viscosity" that I wrote about in my paper, that important and relevant information was available, but was not widely dispersed. Why did the information that Internet traffic was not doubling every 100 days get out to the public? It was not a closely guarded national security secret, after all. There seemed to be many reasons operating. In the case of Genuity (as the quote from Scott Marcus in my paper explains) it was a high-level decision, that going public would hurt the company, as it might be suspected of losing market share. But that seemed to be unusual, in that Genuity, while a major Tier-1 ISP, was small and independent, and so had people like Scott who were engineers, yet involved in policy making. At other places, other dynamics operated. At AT&T, for example, I was called in to a meeting with the management of WorldNet, the AT&T ISP unit, at the end of 2000. They had been telling their customers that Internet traffic was growing 10x per year, and some of those customers asked them about the discrepancy between that claim and the estimates of some folks from AT&T Labs - Research (Kerry Coffman and myself) that growth was just 2x per year. Now it is an interesting perspective on "information viscosity" and AT&T (and other large bureaucratic organizations) that those folks had not heard of Kerry's and my work, even though we had publicized it at the company. But in any event, at that meeting, I did succeed in convincing them that Internet traffic was growing only 2x per year (using evidence in my papers with Kerry, as well as extensive additional data from within AT&T itself), and they agreed they would not propagate the myth among customers. But the interesting thing was that many of the attendees (who included quite a few engineering types, not just the management) seemed disappointed. That really surprised me. After all, AT&T's Internet traffic was growing just about 4x per year, which meant our market share was doubling, instead of being cut in half. But it seems that many of them had really bought into the Internet dream. And, furthermore, the story that we were losing market share was a good one to pry additional resources from the corporation. Several of the NANOG old-timers said that they felt constrained from speaking about the falsity of the myth of astronomical growth rates by group solidarity. After all, it was a small, select group, and bad-mouthing one of their own in front of outsiders or even NANOG newbies did not seem the right thing to do. Then there was the additional factor that one person discussed very explicitly, and that I infer also applied in other cases. The myth was useful. Back in the mid-1990s, when it was not a myth, it did spur equipment suppliers and ILECs to greater effort. And afterwards, it was handy in internal fights over power and resources. If the Internet was exploding, one should not worry about closely examining expansion plans. In some ways, the persistence of false perceptions about Internet traffic growth mirrors that of utilization rates of data networks. When I wrote the paper "Data networks are lightly utilized, and will stay that way," back in 1998, http://www.dtc.umn.edu/~odlyzko/doc/network.utilization.pdf the more clueful data network engineers all knew that utilization rates were generally low, and usually had a good understanding as to why. But top management, as well as the research community, were almost uniformly convinced that congestion was the rule. It took me a while to understand the dynamics of the situation, in which network engineers and managers found it easier to say that they were experiencing 80% utilization and 20% packet losses and needed to upgrade, without having to explain to CEOs, CIOs, and especially to clueless CFOs, that this referred just to the peak hour on one crucial corporate WAN link, and yet justified a big new investment. Few people were lying, but many had incentives to maintain delusions among the top levels of the hierarchy. These demonstrations of information viscosity of course undermine the foundations of much of modern economics, especially of the efficient markets hypothesis. But that last myth is even more durable than "Internet traffic doubling every 100 days," especially since it does not lead directly to lots of dark fiber lying around unused, and lots of companies bankrupt. Information viscosity in facts and ideas in economics is very high, so we should not expect any changes on that scene. ------------------------------------------------------------------- 5. As a reminder, the paper that led to this discussion is "Bubbles, gullibility, and other challenges for economics, psychology, sociology, and information sciences," http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf The page with source materials from the bubbles times, http://www.dtc.umn.edu/~odlyzko/isources/ now has, in addition to a transcript of the O'Dell lecture at Stanford in May 2000, a copy of the Sidgmore paper from the Vortex98 Conference of May 1998.

10 12