- Test - lists.nanog.org

Cisco Security Advisory: Multiple Vulnerabilities Found by PROTOS IPSec Test Suite
by Cisco Systems Product Security Incident Response Team 14 Nov '05

14 Nov '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Vulnerabilities Found by PROTOS IPSec Test Suite Advisory ID: 68158 http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml Revision 1.0 For Public Release 2005 November 14 1100 GMT (UTC) - --------------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures - --------------------------------------------------------------------------- Summary ======= Multiple Cisco products contain vulnerabilities in the processing of IPSec IKE (Internet Key Exchange) messages. These vulnerabilities were identified by the University of Oulu Secure Programming Group (OUSPG) "PROTOS" Test Suite for IPSec and can be repeatedly exploited to produce a denial of service. Cisco has made free software available to address this vulnerability for affected customers. 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. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml. Affected Products ================= Vulnerable Products +------------------ Cisco devices running affected versions of software and configured for IKE are vulnerable. This vulnerability is not dependent on a specific hardware configuration. For example, the Cisco VPNSM or VPN SPA are not required for the device to be vulnerable. * Cisco IOS versions based on 12.2SXD, 12.3T, 12.4 and 12.4T * Cisco PIX Firewall versions up to but not including 6.3(5) * Cisco PIX Firewall/ASA versions up to but not including 7.0.1.4 * Cisco Firewall Services Module (FWSM) versions up to but not including 2.3(3) * Cisco VPN 3000 Series Concentrators versions up to but not including 4.1(7)H and 4.7(2)B * Cisco MDS Series SanOS versions up to but not including 2.1(2) To determine the software running on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices will not have the show version command, or will give different output. The following example identifies a Cisco 7200 router running Cisco IOS release 12.3(10a) with an installed image name of C7200-JO3S-M. Router# show version Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-JO3S-M), Version 12.3(10a), RELEASE SOFTWARE (fc2) Copyright (c) 1986-2004 by cisco Systems, Inc. Additional information about Cisco IOS release naming can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper…. Only Cisco IOS images that contain the Crypto Feature Set contain the vulnerable IPSec code. Customers that are not running an IOS image with crypto support are not exposed to this vulnerability. Cisco IOS feature set naming indicates that IOS images with crypto support will have 'K8' or 'K9' in the feature designator field. For example, the image in the example above, C7200-JO3S-M, does not contain 'K8' or 'K9.' This indicates that this image does not support crypto, and is therefore not vulnerable to the issues described in this Security Advisory. The following output was taken from a device that is running an IOS image with crypto support: Cisco Internetwork Operating System Software IOS (tm) c6sup2_rp Software (c6sup2_rp-PK9S-M), Version 12.2(18)SXD5, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc. Compiled Fri 13-May-05 21:12 by ssearch Since the feature set designator (PK9S) contains 'K9', we can quickly determine that this feature set contains crypto support. Products Confirmed Not Vulnerable +-------------------------------- No other IOS trains are known to be affected. Cisco IOS XR is not affected. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= IP Security, or IPSec, is a set of protocols standardized by the IETF to support encrypted and/or authenticated transmission of IP packets. IPSec is a protocol commonly used in Virtual Private Networks (VPNs). The Internet Key Exchange (IKE) protocol is used to negotiate keying material for IPSec Security Associations (SAs) and provides authentication of peers. For more complete information on IPSec, consult IETF Request For Comments (RFCs) 2401: http://www.ietf.org/rfc/rfc2401.txt For more complete information on IKE, consult IETF Request For Comments (RFCs) 2408 and 2409: http://www.ietf.org/rfc/rfc2408.txt http://www.ietf.org/rfc/rfc2409.txt IPSec is used in two general cases. The first case is LAN-to-LAN VPN operation in which two devices negotiate an IPSec connection between them for the purposes of connecting two remote LANs via an IPSec tunnel. In this case the devices negotiating the IPSec connection generally have static IP addresses, and the IPSec tunnel is up as long as there is traffic that needs to traverse the tunnel. The second case is a Remote Access (RA) VPN which is typically used to allow remote clients a connection to a secure network or service. A common example of this is a user connecting to a corporate network while away from the office. In this scenario, the remote user could be connecting from anywhere, and their IP address is not static, but rather dynamically assigned via the transport provider. IKE is not a requirement for the establishment of IPSec connections. Depending on your requirements and the devices involved, it may be possible to statically configure the SA information and disable IKE. This type of configuration may not be possible in the case of RA VPNs due to the user's IP address being unknown prior to the establishment of the IPSec connection. See the Workarounds Section for more information. The PROTOS test suite for IPSec is designed to test the design limits of IPSec implementations by sending malformed IKE messages to the target device. When receiving certain malformed packets, vulnerable Cisco devices may reset, causing a temporary Denial of Service (DoS). The vulnerabilities identified can be easily and repeatedly reproduced with the use of the OUSPG "PROTOS" Test Suite for IKE. This suite is designed to test the design limits of implementations that process IKE messages. Additional Details for Cisco IOS +------------------------------- The vulnerabilities addressed by this Advisory were introduced in IOS version 12.3(11)T and are present in versions of 12.3T, 12.4, 12.4T and 12.2SXD. Prior to IOS version 12.3(8)T, IKE was enabled by default, with no crypto configuration needed for the IOS device to process IKE messages. As of IOS version 12.3(8)T (which includes all 12.4-based versions), crypto configuration is required to enable IKE message processing. In order for an IOS device to process IKE packets, a crypto map must be configured and applied to an interface. Additional Details for Cisco PIX +------------------------------- The Cisco PIX does not enable IKE processing by default in any versions of software. For Cisco PIX versions prior to 7.0, use the following to determine if IKE message processing is enabled: show isakmp enable The following example shows the output when IKE is enabled on the outside interface: pixfirewall(config)# show isakmp enable isakmp enable outside The following example shows the output when IKE is not enabled on any interface: pixfirewall(config)# show isakmp enable pixfirewall(config)# For Cisco PIX/ASA versions 7.0 and later, IKE is enabled only if the following command is in the device configuration: isakmp enable Cisco Bug IDs +------------ Below are the Cisco bug IDs and their corresponding product(s): * Cisco IOS versions based on 12.2SX, 12.3T, 12.4 and 12.4T - CSCed94829 * Cisco PIX Firewall versions up to but not including 6.3(5) - CSCei14171 * Cisco PIX Firewall/ASA versions up to but not including 7.0.1.4 - CSCei15053 * Cisco Firewall Services Module (FWSM) versions up to but not including 2.3(3) - CSCei19275 * Cisco VPN 3000 Series Concentrators versions up to but not including 4.1(7)H and 4.7(2)B - CSCsb15296 * Cisco MDS Series SanOS versions up to but not including 2.1(2) CSCei46258 Impact ====== Successful exploitation of the vulnerability on the Cisco MDS Series may result in the restart of the IKE process. All other Cisco MDS device operations will continue normally. Successful exploitation of the vulnerabilities on all other Cisco devices may result in the restart of the device. The device will return to normal operation without any intervention required. 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. Non-IOS Products +--------------- +---------------------------------------------+ | Affected Product | Vulnerable | Fixed | | | Version | Version | |--------------------+--------------+---------| | | Up to, but | 6.3(5) | | Cisco PIX running | not | or | | pre-7.0 code | including, | later | | | 6.3(5) | | |--------------------+--------------+---------| | Cisco PIX/ASA | | | | running 7.0 or | 7.0.1.4 | 7.0.1.4 | | later code | | | |--------------------+--------------+---------| | Cisco FWSM for | Up to, but | 2.3(3) | | Catalyst 6500 or | not | or | | 7600 | including, | later | | | 2.3(3) | | |--------------------+--------------+---------| | Cisco VPN3000 | | | | Concentrators | 4.1(7)H | 4.1(7)H | | running pre 4.7 | | | | code | | | |--------------------+--------------+---------| | Cisco VPN3000 | Up to, but | 4.7(2)B | | Concentrators | not | or | | running 4.7 code | including, | later | | | 4.7(2)B | | |--------------------+--------------+---------| | | Up to, but | 2.1(2) | | Cisco MDS devices | not | or | | | including, | later | | | 2.1(2) | | +---------------------------------------------+ Cisco IOS +-------- Each row of the Cisco IOS software table (below) describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild" and "Maintenance" columns. 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. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label). For further information on the terms "Rebuild" and "Maintenance, " please consult the following URL: http://www.cisco.com/warp/public/620/1.html For Cisco IOS, the vulnerabilities were introduced with 12.3(11)T and 12.2(18) SXD. Previous versions of Cisco IOS are not affected. +---------------------------------------------+ | Major | Availability of Repaired | | Release | Releases | |------------+--------------------------------| | Affected | | | | 12.2-Based | Rebuild | Maintenance | | Release | | | |------------+------------------+-------------| | | 12.2(18)SXD7; | | | | available End of | | | 12.2SXD | Dec, 2005 | | | |------------------+-------------| | | | Migrate to | | | | 12.2(18)SXE | |------------+------------------+-------------| | Affected | | | | 12.3-Based | Rebuild | Maintenance | | Release | | | |------------+------------------+-------------| | | 12.3(11)T9; | | | | available | | | 12.3T | 12-Dec-05 | | | |------------------| | | | 12.3(14)T5 | | |------------+------------------+-------------| | 12.3YF | Vulnerable; | | | | contact TAC | | |------------+------------------+-------------| | | Vulnerable; | | | 12.3YK | migrate to 12.4 | | | | (4)T | | |------------+------------------+-------------| | 12.3YM | 12.3(14)YM4 | | |------------+------------------+-------------| | 12.3YQ | 12.3(14)YQ4; | | | | available TBD | | |------------+------------------+-------------| | 12.3YS | Vulnerable; | | | | contact TAC | | |------------+------------------+-------------| | | Vulnerable; | | | 12.3YT | migrate to 12.4 | | | | (4)T | | |------------+------------------+-------------| | 12.3YU | Vulnerable; | | | | contact TAC | | |------------+------------------+-------------| | 12.3YX | Vulnerable; | | | | contact TAC | | |------------+------------------+-------------| | Affected | | | | 12.4-Based | Rebuild | Maintenance | | Release | | | |------------+------------------+-------------| | | 12.4(1c); | | | | available | | | | 14-Nov-05 | | |12.4 |------------------+-------------| | | 12.4(3b); | | | | available | 12.4(5) | | | 15-Nov-05 | | |------------+------------------+-------------| | | 12.4(2)T2 | | |12.4T |------------------+-------------| | | | 12.4(4)T | |------------+------------------+-------------| | 12.4XA | Vulnerable; | | | | contact TAC | | |------------+------------------+-------------| | | | 12.4(2)XB; | | 12.4XB | | available | | | | TBD | +---------------------------------------------+ Workarounds =========== The effectiveness of any workaround is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround is the most appropriate for use in the intended network before it is deployed. For customers that use IPSec, but do not require IKE for connection establishment, IPSec connection information may be able to be entered manually, and IKE can be disabled, eliminating the exposure. Note: Due to the potential complexity of configuring IPSec information, this is likely not a viable alternative for most customers, but is mentioned here for completeness. Please consult your product documentation for further information on static IPSec configuration. Restricting IKE Messages +----------------------- It is possible to mitigate the effects of this vulnerability by restricting the devices that can send IKE traffic to your IPSec devices. Due to the potential for IKE traffic to come from a spoofed source address, a combination of Access Control Lists (ACLs) and anti-spoofing mechanisms will be most effective. Anti-spoofing +------------ The Unicast Reverse Path Forwarding (Unicast RPF) feature helps to mitigate problems that are caused by spoofed IP source addresses. It is available on Cisco routers and firewalls. For further details, please refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fse… By enabling Unicast Reverse Path Forwarding (uRPF), all spoofed packets will be dropped at the first device. To enable uRPF, use the following commands. router(config)# ip cef router(config)# interface <interface #> router(config-if)# ip verify unicast reverse-path Infrastructure Access Control Lists +---------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your 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" presents guidelines and recommended deployment techniques for infrastructure protection ACLs: http://www.cisco.com/warp/public/707/iacl.html. Obtaining Fixed Software ======================== Cisco has made free software available to address this vulnerability for affected customers. 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/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact either "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 using Third-party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their 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 Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The OUSPG Test Suite for IPSec can be used to trigger these vulnerabilities. These vulnerabilities were discovered in cooperation with CERT-FI and NISCC. For their release information, please see http://www.niscc.gov.uk/niscc/vulnAdv-en.html. 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-20051114-ipsec.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-teams(a)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 | | Initial | | 1.0 | 14-November-2005 | 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. - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDeIRSezGozzK2tZARAkFxAJ44jM1QSJo1uHlhQi3ZR+XgACdtwgCdEy7X FxWHIxrPcMGZ/xrfwjpi4IA= =2ro+ -----END PGP SIGNATURE-----

1 0

Re: Networking Pearl Harbor in the Making
by Robert Bonomi 13 Nov '05

13 Nov '05

> Date: Fri, 11 Nov 2005 14:15:40 +0000 (GMT) > From: "Edward B. Dreger" <eddy+public+spam(a)noc.everquick.net> > Subject: Re: Networking Pearl Harbor in the Making > > RB> Date: Mon, 7 Nov 2005 14:43:54 -0600 (CST) > RB> From: Robert Bonomi > > RB> Re-coding to eliminate all 'possible' buffer overflow situations is a *big* > RB> job. The required field-length checking for every multi-byte copy/move > RB> operation does have a significant negative impact on performance, as well. > > Getting "owned" can also have a significant negative impact on > performance. Of course, maybe the attacker will be benevolent, so > perhaps all will be okay... > > Correctness before speed. Who wants a machine that just gives bad > results faster? "Upgrades" or 'fixes' that cause a machine to run noticably _slower_ than the 'down-rev' machine are a really good way to alienate customers. Especially thosw whose machines are running at nearly 100% capacity before the "upgrade". If there is a way to render the matter 'harmless' -without- the performance hit of the 'do it in the theoretically correct manner', *and* that 'defanging' solution can be delivered in weeks (vs. -years-, for a 'theoretically correct' approach), there is _clear_benefit_ to taking the 'incorrect' route. Benefit that accrues both to the manufacturer _and_ to the CUSTOMERS. > RB> Merely _identifying_ the 'tainted' (by being in contact -- directly or in- > RB> directly -- with 'user-supplied' data) data-structures is a task measured > RB> in man-years. As is isolating _all_ the points where such tainting occurs. > > Sounds like a pretty good argument for "do it right the first time". "Irrelevant", when the subject under discussion is pre-existing code that is _known_ to have (at least one) buffer-overflow problem. "Do it right the first time" is a _really_ difficult target, when the consensus as to what 'do it right' *means* has changed _since_ the code in question was first written. <wry grin> I'll also quote: "In any application, discovered bugs are finite in number, UNDISCOVERED BUGS, however, are, by definition _infinite_ in number." > RB> Then, and only then, can you begin to -plan- how to remove the taint, whether > RB> by sanity-based bounds-checking, 'clipping' to known limits, explicit length > RB> checks, or whatever else is appropriate. > > Hopefully the code is modular. e.g., running cscope and searching for > strcpy(3) invocations is easier than tracking down implemented-in-place > equivalents. *snicker* _That_ only addresses one small subset of the underlying problem. strncpy() and/or memcpy() can also corrupt memory -- when the 'length' param is larger than the receiving field, for example. This can happen, for example, when the 'length' is taken 'on faith' from user input, and not validated.

2 1

Level3 Question
by Dan Mahoney, System Admin 13 Nov '05

13 Nov '05

Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation. A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure. Then again, is anyone? Thanks, -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

21 30

ISP License for Korea and Japan
by Dave Hughes 13 Nov '05

13 Nov '05

Hello, My company is looking to open pops in Koera and Japan. Before I go talk to my lawyers, does anyone know what's involved in getting the proper license and just how dificult is it? Thanks in advance for any help. Regards, Dave

2 1

Re: IAB and "private" numbering
by Christopher L. Morrow 13 Nov '05

13 Nov '05

On Sun, 13 Nov 2005 bmanning(a)vacation.karoshi.com wrote: > > On Sun, Nov 13, 2005 at 02:12:13AM +0000, Christopher L. Morrow wrote: > > > > 'public routing table' == Internet > > as seen from which ASN? or are they all the same? > if you don't have a more specific, or a covering prefix > and are not deluding yourself (aka Sprint circa 1994 > w/ the great 192.0.0.0/3 lie) does NOT mean you have > a full routing table... it just means you have a covering > prefix or more specific prefix from each of your peers... > <voila, the DFZ> does not mean you have all routes tho. yes, I give :) > > > nothing more, nothing less. this is distinct from SIPRnet and some > > portions of NIPRnet, or other 'private' networks out there. > > as alluded to earlier, "private" networks overtook the > "Internet" before... it could happen again. :) > I'd venture to guess that they have already... it's tough to measure though.

1 0

Re: [Latest draft of Internet regulation bill]
by Tom Vest 13 Nov '05

13 Nov '05

On Nov 12, 2005, at 6:48 PM, Christopher L. Morrow wrote: >> Are you suggesting a return to cost-based regulation? At one time >> airline >> prices were regulated based on air mile distance. > > No, I'm not, actually I think that the answer to my question was: "All > bits cost the same to push inside 'my' network" (where 'my' is > really any > single entities network, and the cost is for that entity). Is cost-based regulation so bad for critical, non-substitutable infrastructure? That's how the US market got flat-rate Internet access. Is flat-rate the same thing as "making some people pay for more than they want"? >> MCI Friends & Family charged different rates for phone calls >> depending >> whether the person you called was also a MCI customer. Was MCI >> illegally >> interfering with people calling AT&T customers by charging a >> different >> rate? Level 3 charges different rates for "on-net" versus "off-net" >> traffic. Is Level 3 illegally interfering with people accessing >> content on >> other ISPs buy charging more? Many cell phone companies offer "free" >> minutes when you call other people in your plan. Is Verizon >> illegally >> interfering with other cell phone companies by charging more? Or >> in each >> of this cases, are they actually charging some people less? How >> do you >> decide what is a "discount" or a "surcharge"? > > good question, I think all of the examples though have on thing in > common: > all the 'discount' is on 'local' traffic (local to the network), > the cost > differential is applied to 'non-local' traffic. This sort of goes > to my > point that inside a network bits all cost the same, its the external > places that cost more... Are the folks advocating making content > providers > pay for 'access' to their customers willing to stand up competing > services > locally? (something to keep their customers who lose access to > things they > really care about) There no such thing as a market price for critical, non-substitutable infrastructure. Most markets/regulatory jurisdictions around the world don't have / never had any cost-based pricing requirements for network infrastructure, and in most of those markets the "market price" of infrastructure inputs is somewhere between 90-200% of the projected revenue potential that the infrastructure creates. That's why there are so few operators/ASNs in most countries -- there's very little upside for non-telcos -- and one of the reasons that markets like the US spawned so many infrastructure users. That may be where the Internet is headed in the absence of some major trend shift, but is that where it should go, where we want it to go? TV

2 2

RE: Level3 Question
by Susan Hares 12 Nov '05

12 Nov '05

Per: I had hands experience from EGP, BGP-2, BGP-3, BGP-4, and MP-BGP. Cost/Money/Operational Pain drive transitions. In EGP/BGP-2 it was 12-15 routers. In BGP-3/BGP thousands. Now? I'll let you estimate for Internet routers in the planet. Of course, I like you would like things to be orderly. Sue Hares -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Per Gregers Bilse Sent: Friday, November 11, 2005 4:42 PM To: nanog(a)nanog.org Subject: Re: Level3 Question On Nov 11, 1:14pm tony.li(a)tony.li wrote: > The only way to get 32-bit AS number support deployed is to run out > of AS numbers in > the 16 bit space. Exactly. - When will the Internet deploy X? - Just before it's too late. How many people on this list remember the transition from BGP3 to BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there was an EGP to BGP transition, but that was less of an issue. But history will repeat itself. Not that I see any great evil in that -- people are always busy, have always been. It's a case of which priorities are most pressing, so, indeed, yes, the only way is to run out of the existing resource. Likewise for whatever will provide more address space.-) -- Per

1 0

reminiscing (was re: level 3)
by brett watson 11 Nov '05

11 Nov '05

On Nov 11, 2005, at 2:50 PM, bmanning(a)vacation.karoshi.com wrote: > we clustered the engineers into the IETF terminal > room > since we're reminiscing, we did this at dallas ietf in 1995, i think it was (yes, http://merit.edu/mail.archives/nanog/2000-11/ msg00222.html). we had hit a timer bug in is-is that was causing routers to lose adjacencies. ravi sat down at a terminal, found the bug in the code, compiled a new image, and we loaded and "rebooted the network" that evening. nasty, but fun. we don't seem to have fun like this anymore. (maybe it wasn't as simple as ravi "finding the bug", but i do seem to remember he fixed this in short order) -b

1 0

[Re: [Latest draft of Internet regulation bill]
by charles cala 11 Nov '05

11 Nov '05

--- Blaine Christian <blaine(a)blaines.net> wrote: <snip> > I suspect the section regarding nondiscriminatory access could have > been worded better. Half the text is repeated. Are they paid by > the word you think? > I believe this part is how utilities (ele, gas, tel(traditional), sewage, etc) who doesn't do tcp/ip must give access to a tcp/ip provider at normal rates� to their trench�.( pole, duct, conduit, or right-of-way). > (a) NONDISCRIMINATORY ACCESS.A utility shall > provide a BITS provider, BIT provider, or broadband > video service provider with rates, terms, and conditions for > access to any pole, duct, conduit, or right-of-way owned > or controlled by such utility that are nondiscriminatory as > compared to the rates, terms, and conditions for such ac- > cess provided to any telecommunications carrier, cable op- > erator, or other BITS provider, BIT provider, or > broadband video service provider. I believe this part is for the tcp/ip speakers , they also have to share the trench. (pole, duct, conduit, or right-of-way). > A BITS provider, BIT > provider, or broadband video service provider shall provide > a cable television system, a telecommunications carrier, or > any other BITS provider, BIT provider, or broadband > video service provider with rates, terms, and conditions for > access to any pole, duct, conduit, or right-of-way owned > or controlled by that provider that are nondiscriminatory > as compared to the rates, terms, and conditions for such > access provided to any telecommunications carrier, cable > operator, or other BITS provider, BIT provider, or > broadband video service provider. > The question that comes up in my mind is... If the city is putting a new water main in a road that connects 2 of my data centers, does this act force them to let me toss in a big bundle of fiber before they cover the pipe up? Is the defense listed on page 64 of http://energycommerce.house.gov/108/news/11032005_Broadband.pdf [(b) CAPACITY EXCEPTION. Notwithstanding para- graph (1), a utility providing electric service may deny a BITS provider or BIT provider access to its poles, ducts, conduits, or rights-of-way, on a nondiscriminatory basis where there is insufficient capacity and for reasons of safety, reliability, and generally applicable engineering purposes.] going to prevent such action? ( Utility per 1934 act = a local exchange carrier, or a electric, gas, water, steam or other public utility and who owns or controls, poles, ducts, conduits, or rights-of-way used, in whole or in part, for any wire communications (the rights-of-way). Incumbent local exchange carriers are considered utilities. ) I can see this allowing a bunch of short dark fiber runs to be installed in highly dense places (times-sq.ny.ny.us) as well as through rural zones. I've set reply-to = me because of perceived drift, feel free to override.

1 0

Re: the iab simplifies internet architecture!
by Sam Crooks 11 Nov '05

11 Nov '05

On Thu, 2005-11-10 at 20:37 -1000, Randy Bush wrote: > btw, for another great giggle (many thanks to brian candler > for reporting it) > > From the documentation for Cisco's VPN client software for > Linux: > http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_user_guide_c… > > "User profiles [which contain all your IPSEC parameters: > pre-shared key, username and password] reside in the > /etc/CiscoSystemsVPNClient/Profiles/ directory. Leave the > permissions for the Profiles folder set at drwxrwxrwx. > Each profile in the Profiles folder should have the > follwoing permissions: -rw-rw-rw-." The password string is encrypted in the Profile, however, when you save it... CONFIDENTIALITY NOTICE: This message, and any attachments, are intended only for the lawful and specified use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are STRICTLY PROHIBITED from disclosing, printing, storing, disseminating, distributing or copying this communication, or admitting to take any action relying thereon, and doing so may be unlawful. It should be noted that any use of this communication outside of the intended and specified use as designated by the sender, may be unlawful. If you have received this in error, please immediately notify us by return e-mail, fax and/or telephone, and destroy this original transmission and its attachments without reading or saving in any manner.

4 4