- Test - lists.nanog.org

NANOG 51 (Miami): ISP Security BOF
by Paul Scanlon 27 Jan '11

27 Jan '11

Hi All, Happy New Year. NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. Slides are welcome but not required. Much thanks, Eric & Paul ------------------------------------ Paul Scanlon Arbor Networks +1.303.477.0919 office +1.303.810.7260 mobile ------------------------------------

2 2

Re: NANOG Digest, Vol 36, Issue 141
by Ivan Brunello 27 Jan '11

27 Jan '11

> > Message: 10 > Date: Tue, 25 Jan 2011 16:11:46 -0500 > From: Christopher <caldcv(a)gmail.com> > Subject: Re: Network Naming > To: nanog(a)nanog.org > Message-ID: <4D3F3C92.9050401(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I usually name them after ex-girlfriends > > > On 01/25/2011 03:50 PM, Nick Olsen wrote: > > Whats the rule of thumb for naming gear these days > > (routers,switches...etc). Or is there one? > > > > looks like level3 does something like > > interface.routertype.location.level3.net > > > > Nick Olsen > > Network Operations > > (855) FLSPEED x106 > > > > > > > I would then get short of names VERY FAST :-) Ivan Brunello Net Ops ....

2 1

Re: Using IPv6 with prefixes shorter than a /64 on a LAN
by bmanning＠vacation.karoshi.com 27 Jan '11

27 Jan '11

well... you are correct - he did say shorter. me - i'd hollar for my good friends Fred and Radia (helped w/ the old vitalink mess) on the best way to manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was hard enough to manage a "lan"/single broadcast domain that was global in scope and had 300,000 devices on it. "route when you can, bridge when you must" --bill On Mon, Jan 24, 2011 at 08:58:25AM -0800, Owen DeLong wrote: > Bill... Last I looked, /120 was longer than /64, not shorter. > > What I'm not understanding would be why anyone would want to use > something shorter than /64 on a LAN. > > Owen > > On Jan 24, 2011, at 5:28 AM, bmanning(a)vacation.karoshi.com wrote: > > > as a test case, i built a small home network out of /120. works just fine. > > my home network has been native IPv6 for about 5 years now, using a /96 and IVI. > > > > some thoughts. disable RD/RA/ND. > > none of the DHCPv6 code works like DHCP, so I re-wrote > > client and server code so that it does. > > static address assignment is a good thing for services like DNS/HTTP > > secure dynmaic update is your friend > > > > summary - its not easy, vendors don't want to help. but it can be done. > > > > --bill > > > > > > On Mon, Jan 24, 2011 at 10:59:59AM -0200, Carlos Martinez-Cagnazzo wrote: > >> The subject says it all... anyone with experience with a setup like this ? > >> > >> I am particularly wondering about possible NDP breakage. > >> > >> cheers! > >> > >> Carlos > >> > >> -- > >> -- > >> ========================= > >> Carlos M. Martinez-Cagnazzo > >> http://www.labs.lacnic.net > >> ========================= >

3 4

IPv6 filtering
by Franck Martin 26 Jan '11

26 Jan '11

• ipv6 41 IPv6 # IPv6 • ipv6-route 43 IPv6-Route # Routing Header for IPv6 • ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 • ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 • ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 • ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6 • ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 • ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. But what about the others, should they be blocked, restricted? Does a ios "deny ipv6 any any" affect them?

9 9

Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities
by Cisco Systems Product Security Incident Response Team 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities Advisory ID: cisco-sa-20110126-csg2 http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml Revision 1.0 For Public Release 2011 January 26 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A service policy bypass vulnerability exists in the Cisco Content Services Gateway - Second Generation (CSG2), which runs on the Cisco Service and Application Module for IP (SAMI). Under certain configurations this vulnerability could allow: * Customers to access sites that would normally match a billing policy to be accessed without being charged to the end customer * Customers to access sites that would normally be denied based on configured restriction policies Additionally, Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2 contains two vulnerabilities that can be exploited by a remote, unauthenticated attacker to create a denial of service condition that prevents traffic from passing through the CSG2. These vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml. Affected Products ================= The service policy bypass vulnerability affects all versions of the Cisco IOS Software for the CSG2 prior to the first fixed release, as indicated in the "Software Versions and Fixes" section of this advisory. The two denial of service vulnerabilities only affect Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2. No other Cisco IOS Software releases are affected. Vulnerable Products +------------------ To determine the version of Cisco IOS Software that is running on the Cisco CSG2, issue the "show module" command from Cisco IOS Software on the switch on which the Cisco CSG2 module is installed to identify what modules and sub-modules are installed on the system. Cisco CSG2 runs on the Cisco Service and Application Module for IP (SAMI) card, and is identified in the following example in slot 2 via the WS-SVC-SAMI-BB-K9 identification: C7600#show module Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Supervisor Engine 720 (Active) WS-SUP720-3BXL JAF1226ARQS 2 1 SAMI Module (csgk9) WS-SVC-SAMI-BB-K9 SAD113906P1 4 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL1127T6XY Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 001e.be6e.a018 to 001e.be6e.a01b 5.6 8.5(2) 12.2(33)SRC5 Ok 2 001d.45f8.f3dc to 001d.45f8.f3e3 2.1 8.7(0.22)FW1 12.4(2010040 Ok 4 001c.587a.ef20 to 001c.587a.ef4f 2.6 12.2(14r)S5 12.2(33)SRC5 Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 3 WS-F6K-PFC3BXL JAF1226BNQM 1.8 Ok 1 MSFC3 Daughterboard WS-SUP720 JAF1226BNMC 3.1 Ok 2 SAMI Daughterboard 1 SAMI-DC-BB SAD114400L9 1.1 Other 2 SAMI Daughterboard 2 SAMI-DC-BB SAD114207FU 1.1 Other 4 Centralized Forwarding Card WS-F6700-CFC SAL1029VGFK 2.0 Ok Mod Online Diag Status ---- ------------------- 1 Pass 2 Pass 4 Pass C7600# After locating the correct slot, issue the "session slot <module number> processor <3-9>" command to open a console connection to the respective Cisco CSG2. Once connected to the Cisco CSG2, perform the "show version" command: The following example shows that the Cisco CSG2 is running software Release 12.4(24)MD1: CSG2#show version Cisco IOS Software, SAMI Software (SAMI-CSGK9-M), Version 12.4(24)MD1, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Wed 07-Apr-10 09:50 by prod_rel_team --- output truncated --- Products Confirmed Not Vulnerable +-------------------------------- The Cisco Content Services Gateway - 1st Generation (CSG) is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco Content Services Gateway - Second Generation (CSG2) provides intelligent network capabilities such as flexible policy management and billing based on deep-packet inspection, as well as subscriber and application awareness capabilities that enable mobile operators to quickly and easily offer value-added, differentiated services over their mobile data networks. The service policy bypass vulnerability affects configurations that allow end users to first access non-accounted or billed sites. After a user accesses a non-accounted site, it is possible to access other sites that are defined by a billing service policy or to access sites that may be blocked by other policies by sending specially crafted HTTP packets. This vulnerability only affects HTTP content traffic. HTTPS and other traffic types are not affected. Both denial of service vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. The vulnerabilities are triggered by TCP traffic that transits the Cisco CSG2. The service policy bypass vulnerability is documented in Cisco Bug ID CSCtk35917 and has been assigned CVE ID CVE-2011-0348. The denial of service bugs are documented in Cisco Bug ID CSCth17178 and Cisco Bug ID CSCth41891 and have been assigned CVE IDs CVE-2011-0349 and CVE-2011-0350 respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtk35917 ("Service Policy Bypass Vulnerability") CVSS Base Score - 6.4 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Partial Integrity Impact - Partial Availability Impact - None CVSS Temporal Score - 5.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCth41891/CSCth17178 ("Crafted TCP packet causes CSG2 to restart") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the service policy bypass can allow customers to obtain access to sites that would normally be accounted and billed according to the billing policy without the billing policy being engaged. Additionally, customers could gain access to URLs that are configured in the Cisco CSG2 to be explicitly denied. Successful exploitation of either denial of service vulnerability could result in the Cisco CSG2 reloading or potentially hanging. Due to Cisco Bug ID CSCtg50821, the Cisco CSG2 may not automatically recover and may require a manual reload of the SAMI card by issuing the "hw-module module <x> reset" CLI command from the switch. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +---------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+--------------------------------------------------| | Affected | | | 12.x-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 12.0 - | 12.0 through 12.3 based releases are not | | 12.3 | affected | |------------+--------------------------------------------------| | Affected | First Fixed Release | | 12.4-Based |--------------------------------------------------| | Releases | DoS | Service Policy Bypass | | | Vulnerabilities | Vulnerability | |------------+------------------+-------------------------------| | | All 12.4(11)MD | | | | releases are not | All 12.4(11)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(15)MD | | | | releases are not | All 12.4(15)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(22)MD | | | 12.4MD | releases are not | All 12.4(22)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | Releases prior | | | | to 12.4(24)MD1 | All 12.4(24)MD releases prior | | | are not | to 12.4(24)MD3 are affected. | | | affected. | | | | | First fixed in 12.4(24)MD3 | | | First fixed in | | | | 12.4(24)MD2 | | |------------+------------------+-------------------------------| | | | All 12.4(22)MDA releases | | | | prior to 12.4(22)MDA5 are | | | | affected. First fixed in 12.4 | | | No releases | (22)MDA5 | | 12.4MDA | affected. | | | | | All 12.4(24)MDA releases | | | | prior to 12.4(24)MDA3 are | | | | affected. First fixed in 12.4 | | | | (24)MDA3 | |------------+--------------------------------------------------| | Affected | | | 15.X-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 15.0 - | 15.0 through 15.1 based releases are not | | 15.1 | affected | +---------------------------------------------------------------+ Cisco IOS Software for the CSG2 is located on Cisco Software Download center at the following location: Cisco Interfaces and Modules --> Cisco Services Modules --> Cisco Service Application Module for IP. Workarounds =========== There are no workarounds for these vulnerabilities. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt(a)cisco.com or security-alert(a)cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements 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 do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is aware of public announcements of the service billing bypass vulnerability on some external blog sites. However the Cisco PSIRT is not aware of any malicious use of the vulnerabilities described in this advisory. These vulnerabilities were found by both internal testing and when handling customer support calls. 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-20110126-csg2.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * first-bulletins(a)lists.first.org * bugtraq(a)securityfocus.com * vulnwatch(a)vulnwatch.org * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.grok.org.uk * comp.dcom.sys.cisco(a)newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2011-January-26 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.…. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2010-2011 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk1APx0ACgkQQXnnBKKRMNBE4QD/WfH2GXgAJub+4ech0JhHizBO 98PLNKENutVsJpa0eCUA/2hKwfofNSloEh7i5JZXrwKFcjgBYJcPnDa1W2JRHSfZ =EZt9 -----END PGP SIGNATURE-----

1 0

Network Naming
by Nick Olsen 26 Jan '11

26 Jan '11

Whats the rule of thumb for naming gear these days (routers,switches...etc). Or is there one? looks like level3 does something like interface.routertype.location.level3.net Nick Olsen Network Operations (855) FLSPEED x106

7 7

Understanding reverse DNS better
by Caleb Tennis 26 Jan '11

26 Jan '11

We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. It's like the nameserver information against that reverse DNS is just magically gone. The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? Thanks, Caleb

7 8

Re: IPv6 filtering
by Hank Nussbacher 26 Jan '11

26 Jan '11

At 18:20 26/01/2011 +1300, Franck Martin wrote: >Content-Transfer-Encoding: 7bit > >Well we filter icmp due to exploits, if no exploits, then we can let the >whole of icmpv6 through. Or is there something terribly dangerous in >icmpv6 already? Ever since Cisco came out with "IPv6 Routing Header Vulnerability" in 2007 http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb… I have had the following enabled: On the protected interface: ipv6 traffic-filter filter-rh in ipv6 access-list filter-rh deny ipv6 any any log routing permit ipv6 any any and have stopped many pkts that way. I still occasionally see hits in our log from all sorts of newbies who continue to try old bugs. -Hank

1 0

IPv6 - real vs theoretical problems
by Deepak Jain 26 Jan '11

26 Jan '11

Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ

20 37

Re: Network Naming
by GP Wooden 25 Jan '11

25 Jan '11

Punk bands here .... ----- Reply message ----- From: "Christopher" <caldcv(a)gmail.com> Date: Tue, Jan 25, 2011 3:11 pm Subject: Network Naming To: <nanog(a)nanog.org> I usually name them after ex-girlfriends On 01/25/2011 03:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? > > looks like level3 does something like > interface.routertype.location.level3.net > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > >

1 0