- Test - lists.nanog.org

PI space and colocation
by up＠3.am 19 Jan '06

19 Jan '06

Questions: If one gets PI space from ARIN for their network, then moves the servers to a rack at a data center (still using the space efficiently), will most colocation providers announce this space for them, or would most providers require them to take allocated space from them? Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? Is this ok per ARINs requirements, assuming you first acquired this space under their multihomed network guidelines? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

9 12

IP Addresses from a different region
by Sam Stickland 19 Jan '06

19 Jan '06

Hi, Long story short... I'm under some considerable pressure from management to obtain a /24 of addresses from ARIN. We are a UK based ISP that are, of course, members of RIPE. Is this possible? If I approach one of ARIN's LIRs can they obtain ARIN PI space for our client, and are their any volunteers? Or, is it the case, that being outside of ARIN's geographic reach that we can't approach them? Short story long... This is for a client that currently has a USA based operation, that wants to consolidate everything in one of our colo centres. Their USA servers are involved in some of kind advertising system that attempts to do geographic location based on the IP address prefix. I am assured that traceroutes, SWIP data, and AS number play no part in this geographic lookup. The client insists that they must have addresses from a prefix that appear to have been allocated by ARIN for this system to continue to work. The language barrier between us has been scrupering attempts by me to get more techincal information from them. As usual management are interested in "solutions not problems" ;) and this deal is worth quite a bit of money. I hate to be contributing to the ever increasing PI swamp space, but unfortunately I don't pay my own wages. Any suggestions? Sam

2 1

RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T
by sam_ml＠spacething.org 19 Jan '06

19 Jan '06

Hopefully the cisco copper GBIC supports Auto-MDI though, so a straight cable should be good. S On Sun, 15 Jan 2006, David Prall wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > GigE 1000Base-T requires all 4 pairs of wire. Auto-MDI is not supported > on the 2950 series, so it won't handle this automagically. I would test > with speed set to 100 if the foundry can support 10/100/1000 with the > Copper GBIC. Put the two next to each other and test with 1000Base-T > crossover cable, removing all the extra stuff if that doesn't work. > > 1000Base-T requires that pairs 1 and 4 are also crossed along with 2 and 3. > http://en.wikipedia.org/wiki/Crossover_cable > > David > > - -- > David C Prall dcp(a)dcptech.com http://dcp.dcptech.com > > >> -----Original Message----- >> From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On >> Behalf Of Mark Smith >> Sent: Sunday, January 15, 2006 5:44 PM >> To: Randy Bush >> Cc: dhubbard(a)dino.hostasaurus.com; sam_ml(a)spacething.org; >> nanog(a)nanog.org >> Subject: Re: Problems connectivity GE on Foundry BigIron to >> Cisco 2950T >> >> >> Hi Randy, >> >> On Sun, 15 Jan 2006 11:10:04 -1000 >> Randy Bush <randy(a)psg.com> wrote: >> >>> >>>> You are using a crossover cable right? >>>>> I'm having a right mare trying to get a Foundry BigIron to >>>>> connect up to a cisco 2950T, via Gigabit copper. >>> >>> i was under the impression that gige spec handled crossover >>> automagically >>> >> >> According to "Ethernet, The Definitive Guide", that feature is an >> optional part of the spec. >> >> One thing I've heard people encounter is that if they use a cross-over >> cable, which probably really implies a 100BASE-TX cross-over, then the >> ports only go to 100Mbps. A Gig-E rated straight through, in >> conjunction >> with the automatic crossover feature, was necessary to get to GigE. >> >> Regards, >> Mark. >> >> -- >> >> "Sheep are slow and tasty, and therefore must remain >> constantly >> alert." >> - Bruce Schneier, "Beyond Fear" >> > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.0.3 (Build 2932) > > iQEVAwUBQ8rlb4YwPzEDHVgLAQjCAQgAnb36uEi0T6NuJZj7bu2vJXPgr7Y0rFK8 > TjDip2kT1DYwf3mF2j0ZPCWIh7eKM4skx431VB9C8nq5glUwtOv7LYxnyMHCsyTo > W6aixupMiDA2l4po1pxzoNaw1p2CVvdTxhVBEG/AP73+Ls9k2lgJii59X+4BF8qw > ChmZwGdQ8GDOIWKjvax63hbsprBhf1ORUwP2qZPcg2p8P4M0yqznhrk84VpSipGU > itdv/juvrFmfkGyPSozBqErpYx4hmVzBz6uLPQ2cF6ux48sPIUDz3+ta49xKlMwY > zhON0whXxZA49YlwZZV5CzbjAmp8/zJWfMnl76kYkISxOqgX0Xo9dg== > =D7cE > -----END PGP SIGNATURE----- > > >

2 1

Intradomain Traffic Engineering
by Hao Wang 19 Jan '06

19 Jan '06

Hi All, I'm a PhD student currently studying intra-domain traffic engineering, and I have two questions that I really wish to hear some opinions from you network operators. I'm experimenting with a prediction-based intra-domain traffic engineering technique. The technique uses traffic demand matrices observed in the history to predict future traffic demands, and computes a routing that minimizes maximum link utilization (MLU) for those future demands. I evaluate the performance of the technique using Abilene traffic traces collected at every 5 minutes interval. The results show that when the model is able to predict the real traffic matrix, the technique can achieve close to optimal MLU. However, when the model makes wrong prediction, the technique suffers very high MLU (as high as 140%). Basically, I have the following two questions: 1. In the traces I have, there exist several intervals with a huge, sudden increase of traffic on some links. The prediction model I use cannot predict those 'big spikes'. Do these 'big spikes' really happen in operational networks? Or are they merely measurement errors? If they really happen, is there a gradual ramp up of traffic in smaller time scale, say, on the order of tens of seconds? Or do these 'big spikes' really occur very quickly, say, in a few seconds? 2. I have the option to make a tradeoff between average case performance and worst case performance guarantee, but I don't know which one is deemed more important by you. Are ISP networks currently optimized for worst case or average case performance? Is the trade-off between these two an appealing idea, or may the ISP networks are already doing it? I really appreciate any feedback from you about the above two questions, and your help will be acknowledged in any publication about this work. Thanks, Edgar

2 2

Re: Collateral Damage
by Scott McGrath 19 Jan '06

19 Jan '06

1 Yes 2 No 3 No 4 No -----Original Message----- From: "Patrick W. Gilmore" <patrick(a)ianai.net> Subj: Collateral Damage Date: Tue Jan 17, 2006 4:44 pm Size: 2K To: nanog(a)nanog.org cc: "Patrick W. Gilmore" <patrick(a)ianai.net> My previous post sparked quite a bit of traffic (mostly to me personally). It also sparked some confusion. That's mostly my fault for writing e-mails far too late at night and mixing it with an emotionally charged thread. So I would like to separate my questions out of the GoDaddy thread, write them slightly differently, and give a little more scope for clarity. These questions are designed as "yes/no", not "it depends". The idea being if there are general circumstances (not billion-in-one corner cases) which would make the action in question acceptable, please answer yes, and move to the next question. For instance, I would answer the first question as "yes", because there are circumstances which happen reasonably often where I would take down an innocent domain to stop network abuse. (E.g. I would null-route a /24 that is sending gigabits of DoS traffic, even if there is an "innocent" mail server in that block.) Anyway, on to the poll. You are welcome and encouraged to send the answers to me privately, I will collate and post back to the list in a few days. * Please answer yes/no. - Additional text is encouraged, but I need a yes/no to tabulate the vote. * These questions are not regarding a specific provider or even specific abuse type. - You can consider spam, DoS, phishing, hacking, etc. - Please assume what you consider to be the "worst" abuse which is common on the Internet today. * There is a basic assumption that due diligence has been applied. - You have investigated and are certain this is not a false positive or such. - I hope we can all agree that shutting someone down without doing proper investigation is a Bad Thing. * There is a basic assumption of notification and grace period. - The provider in question knows Bad Things are happening. - The provider in question has had a reasonable amount of time to fix said Bad Things. - Bad Things are still happening. * Please do not consider extremely rare occurrences or utra-extreme scenarios. - Null-routing an IP address to stop nuclear war is not in scope of this survey. If you have any questions, please feel free to e-mail me. 1) Do you think it is ever acceptable to cause collateral damage to innocent bystanders if it will stop network abuse? 2) If yes, do you still think it is ever acceptable to take down a provider with 100s of innocent customers because one customer is misbehaving? 3) If yes, do you still think it is ever acceptable if the "misbehaving" customer is not intentionally misbehaving - i.e. they've been hacked? 4) If yes, do you still think it is ever acceptable if the collateral damage (taking out 100s of innocent businesses) doesn't actually stop the spam run / DoS attack / etc.? Thank you all for your time. -- TTFN, patrick

1 0

RE: PI space and colocation
by Chris Ranch 18 Jan '06

18 Jan '06

On Wednesday, January 18, 2006 12:10 PM, Pat wrote: > On Jan 18, 2006, at 3:03 PM, Jon Lewis wrote: > > >>> Is it a reasonable alternative to establish a BGP connection with > >>> the provider over ethernet? > >> > >> It is technical feasible, but I don't think 'reasonable'. > Stub ASes > >> are pollution on the 'Net. > > > > We've done this as well. Whats wrong with letting the customer use > > their ASN and BGP peering with them in your data center? > They might > > even get a connection to someone else there and multihome again. > > Either way, the routes are getting into the global table...does the > > end of the aspath matter that much? > > It adds zero useful data to the global table, but increases > RAM, CPU, etc. on every router looking at the global table. > > Given how vociferously people argue against items in the > table which _do_ add useful data, superfluous info should be > avoided whenever possible. IMHO, of course. In the past under these circumstances, if the customer still insists on BGP after I strongly recommeded just a static DFG, I'd peer with the customer with a private AS (64512-65535). Then they usually ask me to annouce a DFG to them. Sometimes they'd want a full table. Sigh. At least they'd have the future flexibility of adding another provider without much change. I've personally done that too. Chris

2 1

Strange issue involving sampling
by Peering 18 Jan '06

18 Jan '06

First, apologies if this isn't the right place, but I was hoping to hit a lot of networking folks in one shot and this seemed like the likely venue. I have this problem where a customer of mine has issues getting to secure websites (https sites like Charles Schwab's). It doesn't happen all the time, maybe once a month or so. We went to Juniper with the issue (we're using M-20s as our edge routers) and they couldn't figure it out, but one of our engineers found that the config pasted below (with proprietary info removed) fixed the problem. The only problem is that even with this config, we have to restart the sampling daemon every month or so because the problem will come back. Understandably, the customer would prefer to have a more permanent solution. Anyone have an idea why this one customer on my entire network would have this issue? Supposedly the customer had Cisco come out and look at their network and they couldn't find any reason for it either. routerx# show | compare rollback 0 [edit] - forwarding-options { - sampling { - input { - family inet { - rate 1; - } - } - output { - file filename customer.sample; - } - } - } [edit firewall] - filter customer { - term 1 { - then { - sample; - accept; - } - } - term default { - then accept; - } - } [edit interfaces ls-2/3/0 unit 3] routerx# show description "Customer X"; encapsulation multilink-ppp; ml-pic-compatible; family inet { no-redirects; filter { input customer; output customer; } address x.x.x.x/30; } Diane Turley Sr. Network Engineer Xspedius Communications Co. 636-625-7178

2 1

Network Solutions DNS Outage
by Justin M. Wilson 18 Jan '06

18 Jan '06

Network Solutions seem to be having a DNS outage--the worldnic servers are timing out--all of the domains they host DNS for seem to be down. Customer Service indicated that they were having a problem, and were working to resolve it. ---- Justin M. Wilson justin(a)justin.net

1 0

Cisco Security Advisory: IOS Stack Group Bidding Protocol Crafted Packet DoS
by Cisco Systems Product Security Incident Response Team 18 Jan '06

18 Jan '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: IOS Stack Group Bidding Protocol Crafted Packet DoS Document ID: 68793 Advisory ID: cisco-sa-20060118-sgbp http://www.cisco.com/warp/public/707/cisco-sa-20060118-sgbp.shtml Revision 1.0 ============ For Public Release 2006 January 18 1600 UTC (GMT) - --------------------------------------------------------------------- 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 ======= The Cisco IOS Stack Group Bidding Protocol (SGBP) feature in certain versions of Cisco IOS software is vulnerable to a remotely-exploitable denial of service condition. Devices that do not support or have not enabled the SGBP protocol are not affected by this vulnerability. Cisco has made free software available to address this vulnerability for affected customers. There are workarounds available to mitigate the effects of the vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20060118-sgbp.shtml Affected Products ================= Vulnerable Products +------------------ This vulnerability affects any device that runs Cisco IOS and has enabled the SGBP protocol. SGBP is enabled by defining a stack group, which is done using the global IOS command "sgbp group <name>". The presence of this command will cause the device to begin listening on port 9900, even if the remaining SGBP parameters are not fully configured. The following examples demonstrate device configurations for which SGBP is enabled: Router#show sgbp Group Name: test Ref: 0xA3728C00 Seed bid: default, 50, default seed bid setting Or: Router#show running-config | include sgbp sgbp group test_group If your device displays output similar to either of the above examples, please consult the IOS software table below to determine whether your version of IOS is affected. Products Confirmed Not Vulnerable +-------------------------------- Cisco products that do not run IOS, do not contain support for SGBP, or do not have SGBP enabled are not affected by this vulnerability. Systems on which SGBP is not supported or enabled will return either blank output or an error message. The following examples demonstrate device configurations that are not affected by this vulnerability: * A system that supports but is not enabled for SGBP returns this output: Router#show sgbp Router# * A system that does not support SGBP returns this error message: Router#show sgbp Router#show sgbp ^ % Invalid input detected at '^' marker. Details ======= Multilink PPP (MLP) allows users to combine multiple PPP links into a single logical network connection, thus enabling on demand bandwidth allocation. When implemented across multiple device chassis, this is known as Multichassis Multilink PPP (MMP). The Stack Group Bidding Protocol is the mechanism by which devices participating in MMP locate each other and negotiate for a connection termination point. The SGBP implementation provided by the Cisco Internetwork Operating System (IOS) is susceptible to a denial of service attack when presented with a crafted UDP packet. Sending such a packet to port 9900 of an affected device will cause it to freeze and stop responding to or passing traffic. After a delay, the system watchdog timer will detect this condition and force a reset of the device. The system recovery behavior will be controlled by the device configuration register; for example, the router may reload or drop to the ROM monitor. This vulnerability is documented in Cisco bug ID CSCsb11124. Impact ====== Successful exploitation of this vulnerability may cause the affected device to become unresponsive and trigger a hardware reset, resulting in a denial of service condition. Software Versions and Fixes =========================== Cisco has provided updated software to address this vulnerability. For further details, please refer to the software table below. 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 | Migrate to 12.2(32) | |------------+---------------------------| | | 12.0(28)S6 | | | |-------------+-------------| | | 12.0(30)S5; | | | | available | | | | 23-Feb-06 | | | |-------------+-------------| | 12.0S | 12.0(31)S3; | | | | available | | | | 26-Jan-06 | | | |-------------+-------------| | | | 12.0(32)S; | | | | available | | | | 26-Jan-06 | |------------+---------------------------| | 12.0SC | Migrate to 12.3(13a)BC or | | | later | |------------+---------------------------| | 12.0T | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XA | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XC | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XD | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XE | Migrate to 12.1(26)E5 | |------------+---------------------------| | 12.0XG | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XH | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XI | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XJ | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XK | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XL | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XN | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.0XR | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | Affected | | | | 12.1-Based | Rebuild | Maintenance | | Release | | | |------------+---------------------------| | 12.1 | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1AA | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1E | 12.1(26)E5 | | |------------+---------------------------| | 12.1EC | Migrate to 12.3(13a)BC or | | | later | |------------+---------------------------| | 12.1EX | Migrate to 12.1(26)E5 | |------------+---------------------------| | 12.1EZ | Migrate to 12.1(26)E5 | |------------+---------------------------| | 12.1GA | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1GB | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1T | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XA | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XD | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XH | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XI | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XL | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.1XM | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.1XQ | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.1XS | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XU | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XW | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XX | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XY | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1XZ | Migrate to 12.2(32) or | | | later | |------------+---------------------------| | 12.1YA | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.1YB | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.1YD | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | Affected | | | | 12.2-Based | Rebuild | Maintenance | | Release | | | |------------+-------------+-------------| | 12.2 | | 12.2(32) | |------------+---------------------------| | 12.2B | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2BC | Migrate to 12.3(13a)BC or | | | later | |------------+---------------------------| | 12.2BW | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2BY | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2CX | Migrate to 12.3(13a)BC or | | | later | |------------+---------------------------| | 12.2DD | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2DX | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2MC | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | | 12.2(14) | | | | S16; | | | | available | | | | 9-Feb-06 | | | 12.2S | | | | | 12.2(18)S | | | | and later | | | | are not | | | | vulnerable. | | |------------+---------------------------| | 12.2SU | Migrate to 12.3(14)T6 | |------------+---------------------------| | 12.2SY | Migrate to 12.2SXD or | | | later | |------------+---------------------------| | 12.2SZ | Migrate to 12.2S or later | |------------+---------------------------| | 12.2T | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XA | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XB | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XC | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2XF | Migrate to 12.3(13a)BC or | | | later | |------------+---------------------------| | 12.2XG | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XK | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XL | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XS | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XT | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2XV | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2YD | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2YE | Migrate to 12.2S or later | |------------+---------------------------| | 12.2YN | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2YT | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2YW | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2YX | Migrate to 12.3(14)T6 | |------------+---------------------------| | 12.2YY | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2YZ | Migrate to 12.2S or later | |------------+---------------------------| | 12.2ZA | Migrate to 12.2SXD or | | | later | |------------+---------------------------| | 12.2ZB | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2ZD | Contact TAC | |------------+---------------------------| | 12.2ZE | Migrate to 12.3(16) or | | | later | |------------+---------------------------| | 12.2ZJ | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.2ZN | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | Affected | | | | 12.3-Based | Rebuild | Maintenance | | Release | | | |------------+-------------+-------------| | 12.3 | | 12.3(16) | |------------+---------------------------| | 12.3B | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.3BC | | 12.3(13a)BC | |------------+---------------------------| | 12.3BW | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | | 12.3(11)T9 | | |12.3T |-------------+-------------| | | 12.3(14)T6 | | |------------+---------------------------| | 12.3XB | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.3XD | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.3XF | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.3XH | Migrate to 12.3(11)T9 or | | | later | |------------+---------------------------| | 12.3XI | Contact TAC | |------------+---------------------------| | 12.3XJ | Migrate to 12.3(14)YX or | | | later | |------------+---------------------------| | 12.3XM | Migrate to 12.3(14)T6 | |------------+---------------------------| | 12.3XQ | Migrate to 12.4(3) or | | | later | |------------+---------------------------| | 12.3XU | Migrate to 12.4(4)T or | | | later | |------------+---------------------------| | 12.3XW | Migrate to 12.3(14)YX or | | | later | |------------+---------------------------| | 12.3YF | Migrate to 12.3(14)YX or | | | later | |------------+---------------------------| | 12.3YG | Contact TAC | |------------+---------------------------| | 12.3YJ | Migrate to 12.3(14)YQ2 | |------------+---------------------------| | 12.3YK | Contact TAC | |------------+---------------------------| | 12.3YM | 12.3(14)YM4 | | |------------+-------------+-------------| | 12.3YQ | 12.3(14)YQ2 | | |------------+---------------------------| | 12.3YT | Contact TAC | |------------+---------------------------| | 12.3YU | Contact TAC | |------------+---------------------------| | 12.3YX | | 12.3(14)YX | |------------+-------------+-------------| | Affected | | | | 12.4-Based | Rebuild | Maintenance | | Release | | | |------------+-------------+-------------| | | 12.4(1b) | | |12.4 |-------------+-------------| | | | 12.4(3) | |------------+-------------+-------------| | 12.4MR | | 12.4(4)MR | |------------+-------------+-------------| | | 12.4(2)T3 | | |12.4T |-------------+-------------| | | | 12.4(4)T | |------------+-------------+-------------| | 12.4XA | | 12.4(2)XA | |------------+-------------+-------------| | 12.4XB | | 12.4(2)XB | +----------------------------------------+ Workarounds =========== * Configure Access Control Lists (ACLs) For sites that require the SGBP protocol to be enabled, it may be possible to apply Access Control Lists (ACLs) to prevent untrusted hosts from exploiting this vulnerability. The following extended access-list can be adapted to your network. This example assumes that the SGBP members communicate using the 192.168.10.0 network. access-list 101 permit udp 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255 port eq 9900 access-list 101 deny udp any 192.168.10.0 0.0.0.255 port eq 9900 access-list 101 permit ip any any The access-list must then be applied to all interfaces using configuration commands such as: interface ethernet 0/0 ip access-group 101 in * Enable Control Plane Policing The Control Plane Policy (CoPP) feature may be used to mitigate this vulnerability, as in this example: ! Do not police SGBP traffic from the trusted network access-list 140 deny udp 192.168.10.0 0.0.0.255 any eq 9900 ! Police SGBP traffic from untrusted hosts and networks access-list 140 permit udp any any eq 9900 ! Do not police any other type of traffic going to the router access-list 140 deny ip any any ! class-map match-all sgbp-class match access-group 140 ! policy-map control-plane-policy ! Drop all traffic that matches the class "sgbp-class" class sgbp-class drop ! control-plane service-policy input control-plane-policy Note: CoPP is only available on certain platforms and IOS release trains. Additional information on the configuration and use of the CoPP feature can be found at the following URL: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/ products_white_paper09186a0080211f39.shtml * Infrastructure ACLs (iACL) 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 entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for iACLs: http://www.cisco.com/warp/public/707/iacl.html * Configuring Receive Access Lists (rACLs) For distributed platforms, rACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 series GSR and 12.0(24)S for the 7500 series. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. Receive path 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 CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/public/707/racl.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 Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered during internal testing. 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-20060118-sgbp.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 | 2006-January-18 | 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.0 (SunOS) iD8DBQFDzm47ezGozzK2tZARAmLxAKDYI8fIszCIrKEPbtnxG5A/3zcS6QCfS0FC vB8TjPqap9cvnRRPrpNWrQ4= =BpZb -----END PGP SIGNATURE-----

1 0

Yahoo Reception is Monday not Sunday
by Susan Harris 18 Jan '06

18 Jan '06

Oopsie - I misspoke below: > SUNDAY ACTIVITIES > ----------------- > Newcomer's Orientation and Reception 3:30 - 5:00 p.m. > Steering Committee Community Meeting 5:00 - 7:00 p.m. > Welcome Reception, location TBA 6:30 - 11:00 p.m. Yahoo's Welcome Reception is actually *Monday* evening, not Sunday. The Beer 'n Gear is Tuesday evening. Sorry for the confusion.

1 0