- NANOG - lists.nanog.org

Best way to supply colo customer with specific provider
by Rick Kunkel 01 Feb '07

01 Feb '07

Hello all, Being relatively new to the colocation business, we run into a fair number of issues that we've never run into before. Got a new one today, and although I can think of kludgey ways to accomplish what he wants, I'd rather get some other ideas first... We just had our first customer that's requesting bandwidth exclusively through a particular provider of ours (Cogent) at less expensive pricing. The money people here are up for it, but obviously, they want to make sure that he's confined to that Cogent connection. So now of course we're attempting to figure out the best way to do this, and I figured that rather than reinventing the wheel, I'd check to see how others accomplish things like this. The way I can imagine doing it is by using route-maps to steer all of this customer's traffic out the Cogent pipe, and modifying our BGP announcements by AS prepending on whatever block or blocks we set aside to be "Cogent-exclusive". Again though, this seems to me to lack a certain amount of, for lack of a better word, "grace". Any other suggestions? Thanks, Rick Kunkel

7 6

NANOG 39 IPv6 Network Operations BOF
by sdb＠stewartb.com 01 Feb '07

01 Feb '07

Hi, I'm going to be running the IPv6 Network Operations BOF at NANOG 39 in Toronto. The BOF will be held in Sheraton Hall B/C, 2pm to 3.30pm on Tuesday February 6th. A basic list of topics is available via the agenda page. If you have any other (relevant) issues you'd like to raise about IPv6, let me know and I'll try to get them in. I'd also be interested to know if people are definitely coming, just so I know I'm not going to be sitting there by myself :) If you're around and not going to either the BGP tutorial or the Peering BOF (part I) and are interested in IPv6, please drop in. Hopefully it won't just be about how awful IPv6 is and how multihoming is broken! Regards, Stewart Bamford -- Stewart Bamford (Posting as an individual) Level3 Snr IP Engineer *** Views expressed are my own and not necessarily those of Level3 *** Primary email stewart(a)whoever.com Secondary email me(a)stewartb.com Personal website http://www.stewartb.com/

1 0

Re: WWPVD
by J. Oquendo 01 Feb '07

01 Feb '07

> I suppose in some universe, it *IS* possible that Paul could be found negligent by some jury trial and ordered to pay millions of dollars. > But that's the same universe were swine routinely fly to and fourth across the green sky. Apparently you've never been in a jury trial and hopefully you won't have to be. The problems (to some this is the solution) with jury trials is, define "peer". You're under the impression - if on a worst case scenario there was a jury trial - that, Paul would be sitting with a jury of his peers. Peers in the sense that those hearing the case would be in his demographic range: Computer Engineer (heck even an avid user) of some form, around his age, hopefully in the same profession. Often what will happen is some poor shmoe will be sitting on the case, bored by the fact he won't understand anything, the explanation of it all will be convoluted, aggravated that he/she has to sit at a jury trial (how many people loathe jury duty). Couple this with moronic logic: "If I was suing I would want someone to have mercy on my pockets" ... So GUILTY! So while Chivalry may be dead frivolry (Yes another Bushism/craptabulous/butchery of a word) isn't... What I would do is offer a warning of sorts for the duration of 90 days and pull the plug with copies of messages that were sent forewarning (l)users of impending changes. This to some degree exonerates you from possible repercussions. Now before you take my advice, this is based of logic not factual law as (obviously) IANAL.

1 0

Re: WWPVD (was what the heck do I do know)
by J. Oquendo 01 Feb '07

01 Feb '07

Why not write a real-time script and loop the querier right back to his own self... Luzer --> *.vix.com --> Luzer This sort of reminded me of the days of "bandwidth raping" where others used someone's own bandwidth to their own disadvantage. > We've told people for years that when they choose to use a DNSBL or > RHSBL that they need to (a) subscribe to the relevant mailing list, > if it has one and/or (b) periodically revisit the relevant web site Akin to a mailing list asking someone to configure their options so autoresponding "Out of the office" replies don't annoy. Rarely works. In the case of system administration/network administration, the industry shifts so much whereas someone who managed a machine is likely not working for that company any more. From my experiences, I've seen the horrible documentation(ing (Bushism?)) companies maintain so its likely unknown to these offenders. Michael Froomkin - U.Miami School of Law wrote: > Bottom line is that in the absence of a promise -- explicit or implicit (!) > -- to the contrary, you can usually turn off your gear and get on with your life Promissory Estoppel might hinder shutting off the power. http://facstaff.gallaudet.edu/marshall.wick/bus447/promissory_estoppel.html -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo echo @infiltrated|sed 's/^/sil/g;s/$/.net/g' http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey

3 2

Birmingham UK colocation
by Andrew Gristina 01 Feb '07

01 Feb '07

I have two racks in London UK. The colocation is currently in London. The contract is up soon and most of the feet on the ground in the UK of the company is in the greater Birmingham area. So I'm interested in colocating about two racks of servers to Birmingham. I would need a cage if the space were shared. What is peering like in the Birmingham area? Will getting multiple provider feeds in Birmingham be possible? It was easy in London. And can anyone recommend colocation in Birmingham? The alternative is stick with London (in spite of difficulty for remote hands) so any suggestions on excellent colocation in London? Google search for "Birmingham UK colocation" only useably yeilds "F1 colocation" and "easy net". Off list is fine. -Andrew ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail

6 6

gmail admin anywhere?
by Mark Jeftovic 01 Feb '07

01 Feb '07

Is there a gmail admin around? Could you give me a shout offlist? -mark -- Mark Jeftovic <markjr(a)easydns.com> Founder & President, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(866) 273-2892

1 0

RE: Google wants to be your Internet
by michael.dillon＠bt.com 31 Jan '07

31 Jan '07

> The problem is that you can't be sure that if you use RFC1918 > today you won't be bitten by it's non-uniqueness property in > the future. When you're asked to diagnose a fault with a > device with the IP address 192.168.1.1, and you've got an > unknown number of candidate devices using that address, you > really start to see the value in having world wide unique, > but not necessarily publically visible addressing. A lot of people who implemented RFC 1918 addressing in the past didn't actually read RFC 1918. They just heard the mantra of address conservation and learned that RFC 1918 defined something called "private" addresses. Then, without reading the RFC, they made assumptions in interpreting the meaning of "private". Now, many of those people or their successors have been bit hard by problems created by using RFC 1918 addresses in networks which are not really private at all, i.e. wholly unconnected from other IP networks. Those people now see the benefits of using truly globally unique registered addresses. The whole address conservation mantra has turned out to be a lot of smoke and mirrors anyway. The dotcom collapse followed by the telecom collapse shows that it was a sham argument based on the ridiculous theory that exponential growth of the network was really sustainable. Now we live in a time where there is no shortage of IP addresses. Even IPv4 addresses are not guaranteed to ever run out as IPv6 begins to be used for some of the drivers of network growth. IPv6 makes NAT obsolete because IPv6 firewalls can provide all the useful features of IPv4 NAT without any of the downsides. --Michael Dillon

12 14

RE: Google wants to be your Internet
by michael.dillon＠bt.com 31 Jan '07

31 Jan '07

> > IPv6 makes NAT obsolete because IPv6 firewalls can provide all > > the useful features of IPv4 NAT without any of the downsides. > IPv6 firewalls? Where? Good ones? Why good ones. NAT is a basic IPv4 firewall. All IPv6 needs to obsolete NAT is a firewall that offers all the features of NAT without requiring the address translation. Then, instead of setting up a port translation for a particular incoming protocol, you simply open up that port without modifying the packets as they flow through. Suddenly, SIP works and incoming VoIP phonecalls work just like on the phone network. --Michael Dillon

3 2

NANOG39 (Sheraton Centre Toronto)
by Carol Wadsworth 31 Jan '07

31 Jan '07

NANOG 39 Meeting Attendees, Please note if you are staying in the Sheraton Centre Toronto and have a room reservation in the NANOG room block at the NANOG rate, you are entitled to receive complimentary in-room Internet access, complimentary access to the fitness center, and discounted valet parking on a space available basis. Charges for these services, if utilized, will be billed to a guest's folio and then rebated back on a daily basis or at the conclusion of one's stay. Again, in order to receive these benefits, your reservation *must* be under the NANOG room block at the NANOG group rate. See you there!

1 0

Cisco Security Advisory: SIP Packet Reloads IOS Devices Not Configured for SIP
by Cisco Systems Product Security Incident Response Team 31 Jan '07

31 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: SIP Packet Reloads IOS Devices Not Configured for SIP Advisory ID: cisco-sa-20070131-sip http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml Revision 1.0 For Public Release 2007 Jan 31 0900 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco devices running IOS which support voice and are not configured for Session Initiated Protocol (SIP) are vulnerable to a crash under yet to be determined conditions, but isolated to traffic destined to Port 5060. SIP is enabled by default on all Advanced images which support voice and do not contain the fix for CSCsb25337. There are no reports of this vulnerability on the devices which are properly configured for SIP processing. Workarounds exist to mitigate the effects of this problem. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml Affected Products ================= IOS releases that include voice support after 12.3(14)T, 12.3(8)YC1, 12.3(8)YG and all of 12.4 are affected. Please see the fixed software table for a complete list of fixed and vulnerable trains. To determine if your device has SIP enabled, enter the commands 'show ip sockets' and 'show tcp brief all'. Below is an example of a router running code without the fix, and without the workaround enabled. The router in this example is vulnerable to this issue. IOS image in example: 7200-p-mz.124-3.bin Router#show ip sockets Proto Remote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 --any-- 5060 0 0 211 0 17 0.0.0.0 0 192.168.100.2 67 0 0 2211 0 17 0.0.0.0 0 192.168.100.2 2517 0 0 11 0 The first line with UDP Port 5060 shows that UDP SIP is enabled. Router#show tcp brief all TCB Local Address Foreign Address (state) 2051E680 *.5060 *.* LISTEN 2051E680 *.5060 *.* LISTEN The above lines with *.5060 show that TCP SIP is enabled. Vulnerable Products +------------------ The following is a list of products that support voice and could be affected by this vulnerability. * 815 * 871 * 876 * 877 * 878 * 1701 * 1711 * 1712 * 1721 * 1751 * 1751-V * 1760 * 1801 * 1802 * 1803 * 1811 * 1812 * 1841 * 2610XM-2611XM * 2620XM-2621XM * 2650XM-2651XM * 2691 * 2801 * 2811 * 2821 * 2851 * 3220 * 3250 * 3270 * 3725 * 3745 * 3825 * 3845 * 7200 * 7200-NPE-G2 * 7301 Products Confirmed Not Vulnerable +-------------------------------- Devices which do not support voice are not affected by this issue. Devices which are properly configured for SIP processing are not affected by this issue. We have no reports of this vunerability on devices that are configured for SIP processing. We also have no reports of affected IOS-XR devices, CatOS devices, or any device which does not run IOS, but can not conclusively rule them out without further testing. This advisory will be updated with more information as it becomes available. Below is an example of a router not vulnerable to this issue. The router in this example is running the fixed release c7200-js-mz.124-5b.bin. Router#show tcp brief all Router#show ip sockets Proto Remote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 192.168.100.2 67 0 0 2211 0 No lines with UDP Port 5060 are shown and UDP SIP is not enabled. In this example UDP port 67 is used by DHCP is not related to this vulnerability. Details ======= SIP is a protocol designed for use in IP phone networks, and is widely used for Voice over Internet Protocol (VOIP) communications worldwide. Cisco devices running an affected image which supports voice services automatically enable SIP, which opens a listening port on UDP port 5060. TCP port 5060 is also opened, but does not appear to be related to the IOS crash detailed in this advisory. CSCsb25337 turns off the listening ports TCP and UDP 5060, and there have been no reports of this vulnerability in any images with this fix integrated. Impact ====== Successful exploitation of the vulnerability may result in a reload of the device. The issue may be repeatedly exploited, leading to an extended Denial Of Service (DOS) condition. Software Version 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) 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 more information on the terms "Rebuild" and "Maintenance," consult the following URL: http://www.cisco.com/warp/public/620/1.html +---------------------------------------+ | Major | Availability of Repaired | | Release | Releases | |------------+--------------------------| | Affected | | | | 12.0-Based | Rebuild | Maintenance | | Release | | | |------------+--------------------------| | 12.0 | All 12.0 releases are | | | not vulnerable | |------------+--------------------------| | Affected | | | | 12.1-Based | Rebuild | Maintenance | | Release | | | |------------+--------------------------| | 12.1 | All 12.1 releases are | | | not vulnerable | |------------+--------------------------| | Affected | | | | 12.2-Based | Rebuild | Maintenance | | Release | | | |------------+--------------------------| | 12.2 | All 12.2 releases are | | | not vulnerable | |------------+--------------------------| | Affected | | | | 12.3-Based | Rebuild | Maintenance | | Release | | | |------------+--------------------------| | 12.3 | Not vulnerable | |------------+--------------------------| | 12.3B | Not vulnerable | |------------+--------------------------| | 12.3BC | Not vulnerable | |------------+--------------------------| | 12.3BW | Not vulnerable | |------------+--------------------------| | 12.3JA | Not vulnerable | |------------+--------------------------| | 12.3JEA | Not vulnerable | |------------+--------------------------| | 12.3JEB | Not vulnerable | |------------+--------------------------| | 12.3JK | Not vulnerable | |------------+--------------------------| | 12.3JX | Not vulnerable | |------------+--------------------------| | | Only 12.3(14)T releases | | | are vulnerable; migrate | | 12.3T | to 12.4(8) or later. All | | | other 12.3T releases are | | | not vulnerable. | |------------+--------------------------| | 12.3TPC | Not vulnerable | |------------+--------------------------| | 12.3XA | Not vulnerable | |------------+--------------------------| | 12.3XB | Not vulnerable | |------------+--------------------------| | 12.3XC | Not vulnerable | |------------+--------------------------| | 12.3XD | Not vulnerable | |------------+--------------------------| | 12.3XE | Not vulnerable | |------------+--------------------------| | 12.3XF | Not vulnerable | |------------+--------------------------| | 12.3XG | Not vulnerable | |------------+--------------------------| | 12.3XH | Not vulnerable | |------------+--------------------------| | 12.3XI | Not vulnerable | |------------+--------------------------| | 12.3XJ | Not vulnerable | |------------+--------------------------| | 12.3XK | Not vulnerable | |------------+--------------------------| | 12.3XQ | Not vulnerable | |------------+--------------------------| | 12.3XR | Not vulnerable | |------------+--------------------------| | 12.3XS | Not vulnerable | |------------+--------------------------| | 12.3XU | Not vulnerable | |------------+--------------------------| | 12.3XW | Not vulnerable | |------------+--------------------------| | 12.3XX | Not vulnerable | |------------+--------------------------| | 12.3XY | Not vulnerable | |------------+--------------------------| | 12.3YA | Not vulnerable | |------------+--------------------------| | 12.3YD | Not vulnerable | |------------+--------------------------| | 12.3YF | Not vulnerable | |------------+--------------------------| | 12.3YG | 12.3(8)YG5 | | |------------+--------------------------| | 12.3YH | Not vulnerable | |------------+--------------------------| | 12.3YI | Not vulnerable | |------------+--------------------------| | 12.3YJ | Not vulnerable | |------------+--------------------------| | 12.3YK | Vulnerable; migrate to | | | 12.4(4)T3 or later | |------------+--------------------------| | 12.3YM | 12.3(14) | | | | YM8 | | |------------+--------------------------| | 12.3YQ | Vulnerable; migrate to | | | 12.4(6)T1 or later | |------------+--------------------------| | 12.3YS | Not vulnerable | |------------+--------------------------| | 12.3YT | Vulnerable; migrate to | | | 12.4(4)T3 or later | |------------+--------------------------| | 12.3YU | Vulnerable; migrate to | | | 12.4(2)XB2 or later | |------------+--------------------------| | 12.3YX | 12.3(14) | | | | YX2 | | |------------+--------------------------| | 12.3YZ | Not vulnerable | |------------+--------------------------| | Affected | | | | 12.4-Based | Rebuild | Maintenance | | Release | | | |------------+------------+-------------| | | 12.4(3d) | | | |------------+-------------| | 12.4 | 12.4(5b) | | | |------------+-------------| | | 12.4(7a) | 12.4(8) | |------------+------------+-------------| | 12.4MR | | 12.4(6)MR | |------------+--------------------------| | 12.4SW | All 12.4SW releases are | | | fixed | |------------+--------------------------| | | 12.4(2)T5 | | | |------------+-------------| | 12.4T | 12.4(4)T3 | | | |------------+-------------| | | 12.4(6)T1 | 12.4(9)T | |------------+--------------------------| | 12.4XA | Vulnerable; migrate to | | | 12.4(6)T1 or later | |------------+--------------------------| | 12.4XB | 12.4(4)XB2 | | |------------+--------------------------| | 12.4XC | Vulnerable; contact TAC | |------------+--------------------------| | 12.4XD | 12.4(4)XD2 | | |------------+--------------------------| | 12.4XE | All 12.4XE releases are | | | fixed | |------------+--------------------------| | 12.4XG | All 12.4XG releases are | | | fixed | |------------+--------------------------| | 12.4XJ | All 12.4XJ releases are | | | fixed | |------------+--------------------------| | 12.4XP | All 12.4XP releases are | | | fixed | |------------+--------------------------| | 12.4XT | All 12.4XT releases are | | | fixed | +---------------------------------------+ Workarounds =========== Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-air-20070131-sip.shtml Turn off SIP processing +----------------------- Since this vulnerability is reported only in routers not configured for SIP, the simplest and most effective workaround is to turn SIP processing off. Enter configuration commands, one per line. End with CNTL/Z. Router(config)#sip-ua Router(config-sip-ua)#no transport udp Router(config-sip-ua)#no transport tcp Router(config-sip-ua)#end Control Plane Policing +--------------------- Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the Control Plane Policing (CoPP) feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure device in accordance with existing security policies and configurations. The following example can be adapted to your network. !-- Permit all TCP and UDP SIP traffic sent to all IP addresses !-- configured on all interfaces of the affected device so that it !-- will be policed and dropped by the CoPP feature access-list 100 permit tcp any any eq 5060 access-list 100 permit udp any any eq 5060 !-- 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 to be policed by !-- the CoPP feature class-map match-all drop-sip-class match access-group 100 !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device policy-map drop-sip-traffic class drop-sip-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device control-plane service-policy input drop-sip-traffic Note: In the above CoPP example, the access control list entries (ACEs) which 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 http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804f… and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_gui…. Obtaining Fixed Software ======================== Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. 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 ===================================== This issue was first reported to Cisco by a customer. Cisco PSIRT is seeing randomly generated traffic which may be unintentionally causing this issue to manifest. Status of this Notice: INTERIM ============================== 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. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. 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-20070131-sip.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 | 2007-January-31 | 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.5 (Darwin) iD8DBQFFwGMG8NUAbBmDaxQRAlTmAKCRiz8v9q0ooRzpmx89W6HhITrUVwCZARsf mIdw8K1qQSI6UXkaxlUsXS8= =pSPg -----END PGP SIGNATURE-----

1 0