March 2013 - Test - lists.nanog.org

Cisco Security Advisory: Cisco IOS Software Smart Install Denial of Service Vulnerability
by Cisco Systems Product Security Incident Response Team 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Smart Install Denial of Service Vulnerability Advisory ID: cisco-sa-20130327-smartinstall Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Smart Install client feature in Cisco IOS Software contains a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. Affected devices that are configured as Smart Install clients are vulnerable. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that have the Smart Install client feature enabled. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd4ACgkQUddfH3/BbToUsAD+NSDtaCAvOzfjmsqhxVZN6Uy+ ceAxXTPCp6M0n8yGk0sA/1uJk8CWE1yjCtTu1IDGX8K/SUvWFEUi0pqFyKfKVFEa =eRMY -----END PGP SIGNATURE-----

1 0

Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerability
by Cisco Systems Product Security Incident Response Team 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Network Address Translation Vulnerability Advisory ID: cisco-sa-20130327-nat Revision 1.0 For Public Release 2013 March 27 10:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software implementation of the virtual routing and forwarding (VRF) aware network address translation (NAT) feature contains a vulnerability when translating IP packets that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTrndAD/Qxm/suF3S/US+6bDND+/OKB3 9KpBW/wUPVC2+87IFRQBAIXFrAjFqnbmmBAKFEVZztVhRN1TlOW9JL7mKd6SXwZw =jAQM -----END PGP SIGNATURE-----

1 0

Cisco Security Advisory: Cisco IOS Software Resource Reservation Protocol Denial of Service Vulnerability
by Cisco Systems Product Security Incident Response Team 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Resource Reservation Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20130327-rsvp Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Resource Reservation Protocol (RSVP) feature in Cisco IOS Software and Cisco IOS XE Software contains a vulnerability when used on a device that has Multiprotocol Label Switching with Traffic Engineering (MPLS-TE) enabled. Successful exploitation of the vulnerability could allow an unauthenticated, remote attacker to cause a reload of the affected device. Repeated exploitation could result in a sustained denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. There are no workarounds available to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd4ACgkQUddfH3/BbTqZ+AD/SPWuHu+4uf/xKA+RAbRbCZxd H9SFakcWJIPsy9TYjBABAI6/LmnQ9FrB1PHcVABckjYOnB+9JUd03ynxrsFPzIQS =W+Lt -----END PGP SIGNATURE-----

1 0

Cisco Security Advisory: Cisco IOS Software Internet Key Exchange Vulnerability
by Cisco Systems Product Security Incident Response Team 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Internet Key Exchange Vulnerability Advisory ID: cisco-sa-20130327-ike Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software Internet Key Exchange (IKE) feature contains a denial of service (DoS) vulnerability. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTovwQD8DwYcxZks8h9lxLcC9YX0Stal GfVltUM7jduv3M2tsQgBAIdGU+jBhC8Ct4i/0idzEkoX6o8TAK3EbcUqZt9QjK6F =Viuu -----END PGP SIGNATURE-----

1 0

Cisco Security Advisory: Cisco IOS Software Zone-Based Policy Firewall Session Initiation Protocol Inspection Denial of Service Vulnerability
by Cisco Systems Product Security Incident Response Team 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Zone-Based Policy Firewall Session Initiation Protocol Inspection Denial of Service Vulnerability Advisory ID: cisco-sa-20130327-cce Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a memory leak vulnerability that could be triggered through the processing of malformed Session Initiation Protocol (SIP) messages. Exploitation of this vulnerability could cause an interruption of services. Only devices that are configured for SIP inspection are affected by this vulnerability. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that must run SIP inspection. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTo1NQD+JTLByafJPlfucXQ7tGEHnYy5 vVv944CH2/B0vC3+AHUA/Aw9dc2MzCzkrKELNu9FQDBFkr5lIhdY9i942xPDfHKQ =6IL2 -----END PGP SIGNATURE-----

1 0

RE: Question on Ipv6 address
by Keith Medcalf 27 Mar '13

27 Mar '13

The "default" mtu of 576 is because, well, 2400 baud signaling is pretty darn slow and interactive performance (or any kind of multileaving of more than a single connection packet stream) is, what do we call it, laggy. Sort of like trying to telnet while doing a bulk transfer if you have bloated buffers, and do not use a decent QoS scheduler -- only with echo times in the order of seconds per character. I believe LCP uses a signed two-octet integer for frame size negotiation, so you can negotiate quite large frames if you so desire and so configure your endpoints. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > > > -----Original Message----- > > From: Frank Bulk (iname.com) [mailto:frnkblk@iname.com] > > Sent: Tuesday, 26 March, 2013 22:46 > > To: 'Mark Jeremy'; Justin Wilson > > Cc: nanog(a)nanog.org > > Subject: RE: Question on Ipv6 address > > > > My understanding is that because IPv6 has a minimum MTU of 1280 and > dial- > > up > > maxes out at 576, that special measures must be taken for IPv6 to work > > over > > a dial-up connection. > > > > Please correct me if someone has this working out of the box. > > > > Frank > > > > -----Original Message----- > > From: Mark Jeremy [mailto:mejndp@rit.edu] > > Sent: Tuesday, March 26, 2013 2:10 PM > > To: Justin Wilson > > Cc: nanog(a)nanog.org > > Subject: RE: Question on Ipv6 address > > > > Justin, > > > > Dial-up modem is just a layer 2 device with no IP address. Just think of > > it > > as a converter, its sole function is to convert the telephone line to > > something your PC can use, in this case, Ethernet. Both IPv4 and IPv6 > > operate on the layer 3 of the OSI model which is taken care of by the > RAS. > > So basically any dial-up modem support IPv6. > > > > -MJ > > > > -----Original Message----- > > From: Justin Wilson [mailto:lists@mtin.net] > > Sent: Tuesday, March 26, 2013 12:06 PM > > To: NANOG > > Subject: Re: Question on Ipv6 address > > > > I don't mean to hijack the thread so if someone wants to open a new one > > that¹s cool. But my question is what dial-up hardware supports v6? I am > > *assuming* Cisco does. > > > > > > Justin > > > > -- > > Justin Wilson <j2sw(a)mtin.net> > > Aol & Yahoo IM: j2sw > > http://www.mtin.net/blog xISP News > > http://www.zigwireless.com High Speed Internet Options > > http://www.thebrotherswisp.com The Brothers Wisp > > > > > > > > -----Original Message----- > > From: Joe <sj_hznm(a)hotmail.com> > > Date: Tuesday, March 26, 2013 11:39 AM > > To: NANOG <nanog(a)nanog.org> > > Subject: Question on Ipv6 address > > > > >I'm new to Ipv6 and trying to understanding something about IPv6 in > > >service provider network. > > >I've got the following questions , could anybody do some helps? > > >1. In a dial-up network (Q-in-Q for each customer who dials in ) Should > > >each customer be assigned to ipv6 subnet prefix like /64 unique > > >universily? I've read a rfc which stated point-to-point like should > be > > >assigned /64. But to my understanding, in dial-up network , each user > > >should only needed to be assigned a single ipv4 address, with wich > > >customer could used in his PC or his home router. > > >2. In dial-up network, could each vlan's ipv6 link-id be planned with > > >its vlan number? if so, IP v6 address confliction could be avoided > > >when BAS is assigned a /64 or longer prefix. > > >3. we are testing some BAS with IPv6 accessing, in radius accouting > > >packets, there is IP-v6-prefix, Ip-v6-link-id, > > >Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be > > >calculated with above information? > > >4. should it be necessary to plan different > > >IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in > BAS? > > >5. How could delegated IPv6 prefix be used in service provider's > network? > > >is this useful in dial-up access network? > > > > > >each word will be highly appreciated. > > >Joe > > > > > > > > > > >

1 0

Question on Ipv6 address
by Joe 27 Mar '13

27 Mar '13

I'm new to Ipv6 and trying to understanding something about IPv6 in service provider network. I've got the following questions , could anybody do some helps? 1. In a dial-up network (Q-in-Q for each customer who dials in ) Should each customer be assigned to ipv6 subnet prefix like /64 unique universily? I've read a rfc which stated point-to-point like should be assigned /64. But to my understanding, in dial-up network , each user should only needed to be assigned a single ipv4 address, with wich customer could used in his PC or his home router. 2. In dial-up network, could each vlan's ipv6 link-id be planned with its vlan number? if so, IP v6 address confliction could be avoided when BAS is assigned a /64 or longer prefix. 3. we are testing some BAS with IPv6 accessing, in radius accouting packets, there is IP-v6-prefix, Ip-v6-link-id, Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be calculated with above information? 4. should it be necessary to plan different IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? 5. How could delegated IPv6 prefix be used in service provider's network? is this useful in dial-up access network? each word will be highly appreciated. Joe

6 7

glass fiber @ 0.997 c
by Eugen Leitl 27 Mar '13

27 Mar '13

http://www.newscientist.com/article/dn23309-information-superhighway-approa… Information superhighway approaches light speed 18:00 24 March 2013 by Jacob Aron Nothing moves faster than light in a vacuum, but large volumes of data can now travel at 99.7 per cent of this ultimate speed limit. In glass optical fibres, light travels 31 per cent slower than in a vacuum. Hollowing them out so that most of the light travels through air speeds things up. But these hollow fibres are a poor replacement as light scatters at the glass-air interface, limiting the number of wavelengths, and therefore the volume of data, transmitted at once. Now Francesco Poletti and colleagues at the University of Southampton, UK, have made fibres with an ultra-thin glass rim, enabling a much wider band of wavelengths to travel at high speed at once. The team's record is a 73.7 terabit per second transmission over 310 metres, a 15,000-fold increase over ordinary hollow fibres. "Previous fibres either have higher bandwidth but high loss, or lower loss but narrower bandwidth," says Poletti. "We've achieved both in the same fibre." Journal reference: Nature Photonics, DOI: 10.1038/nphoton.2013.45 http://www.nature.com/nphoton/journal/vaop/ncurrent/full/nphoton.2013.45.ht… Towards high-capacity fibre-optic communications at the speed of light in vacuum F. Poletti, N. V. Wheeler, M. N. Petrovich, N. Baddela, E. Numkam Fokoua, J. R. Hayes, D. R. Gray, Z. Li, R. Slavík & D. J. Richardson Nature Photonics (2013) doi:10.1038/nphoton.2013.45 Received 13 September 2012 Accepted 08 February 2013 Published online 24 March 2013 Abstract Wide-bandwidth signal transmission with low latency is emerging as a key requirement in a number of applications, including the development of future exaflop-scale supercomputers, financial algorithmic trading and cloud computing1, 2, 3. Optical fibres provide unsurpassed transmission bandwidth, but light propagates 31% slower in a silica glass fibre than in vacuum, thus compromising latency. Air guidance in hollow-core fibres can reduce fibre latency very significantly. However, state-of-the-art technology cannot achieve the combined values of loss, bandwidth and mode-coupling characteristics required for high-capacity data transmission. Here, we report a fundamentally improved hollow-core photonic-bandgap fibre that provides a record combination of low loss (3.5 dB km−1) and wide bandwidth (160 nm), and use it to transmit 37 × 40 Gbit s−1 channels at a 1.54 µs km−1 faster speed than in a conventional fibre. This represents the first experimental demonstration of fibre-based wavelength division multiplexed data transmission at close to (99.7%) the speed of light in vacuum.

3 2

frontiernet.net Email Server Admin
by Josh Galvez 26 Mar '13

26 Mar '13

Can someone who administers frontiernet.net email servers please contact me off list? Your bounce message does not indicate why our "access to submit messages to this e-mail system has been rejected" Thanks.

1 0

Last mile multihoming
by Charles Wyble 26 Mar '13

26 Mar '13

So isnt the most likely interruption to service due to a last mile physical media issue? Or say a regional fiber cut that takes out the towers you can reach and the upstream connection from your cable and telco providers? Imo at the edge, BGP mostly protects you from layer 8 fail (if youve done some basic best practice configuration). In theory, issues below that (at least in the dist/core at l1 to 3) are handled by other redundancy protections hidden from you (hsrp, fiber ring with protected path etc). As for dfz explosion, would mpls/private as/ vrf be a workable approach for bgp at the edge? So I live in Austin. I have available to me two hfc providers (grande and twc) and att. I also have sprint/clear vzw/tmo. I havent done an analysis of wisp offerings (if any are on list, please email me at charles(a)thefnf.org as im looking for a non ilec path for redunancy). So lets break this down: I only know of one att co in town. (Im sure if there is more, you will let me know). So the chances of that failing are decently high. Also my experience with att dsl have been mixed, unless im homed direct to the co. Vz dsl otoh has always been rock solid. Also att is retiring dsl/copper. I refuse to use uverse as they dont offer a unbundled modem/router or a way to do bridge mode. Oh and no ipv6. (If you can put a modem in bridge mode and still have working tv, please let me know. Ive not been able to find a solution). The chances of someone driving into the dslam serving my complex or the pedastal down the street is high (100% as it has happend a couple times). So this means I need a wireless backhaul. All of the providers I can reach colocate on exactly one tower. Surrounded by a chain link fence, across from a walmart. (Im in north austin near cameron and 183 for anyone who lives in town). The chances of the fiber serving that tower being cut is unknown, but not outside the realm of possibility. Or say the walmart big rig over correcting due to a driver coming around the blind curve near there and plowing into thr tower. Etc. So my best bet for uninterrupted connectivity seems to be running two openvpn tunels on my home edge pfsense router, each to a endpoint in a colo. I already have a full rack of gear in joesdatacenter in kc, and its fully redundant. I also run all of my web/mail/software dev from there, so its not soley for bgp purposes. Most folks I imagine may have their stuff in a colo as well and not want to run that at home. (I started a thread on that once upon a time). It so happens, that I have various things which I cant run there (rf equipment which I need to frequently reflash and move around). So running bgp on my colo gear and announcing a /48 that ive assigned to my house seems like a good idea. And I can easily cross connect to kcix and have lots of bgp fun. The latency would be a bit high, but it already is and I dont have any redundant connectivitym Ok. So thats great. Now who is my secondary? Is a vps at say linode sufficient for a secondary bgp announcer? Will they sell me bgp enabled transit? Will other vps providers? Do I need a box in a rack at a local nap? Is there an ix in austin, or should I rack a box in Dallas? Once i have two providerdls, then i can easily use pfsense multi wan failover and if a circuit goes down, life goes on as I rely on bgp to detect the link failure and handle it. Yes? No? Maybe? So to me, this seems like a solved problem. Run multilple diverse (carrier, media type) circuits to your edge, put a pfsense (asa, whatever is your poison but i like pfsense the best for multi wan failover), openvpn (i cant stand ipsec) to colo, cross connect to ... oh I dunno he.net :) bgp for free. Done. For about... hmmm.. 500.00 a month? (Many colos might not do bgp with you for less then a quarter rack, and I presume anyone serious enough about uninterrupted service on a reasonable budget can do 500.00 a month). Thie discussion on soho multihoming has been fascinating to me, and I wanted to go through a thought exercise for what I imagine is a common scenario (main gear in a bgp enabled sp, office gear needing to be reachable by remote personnel in a non bgp enabled sp). Would love to hear what you folks think. -- Charles Wyble charles(a)thefnf.org / 818 280 7059 CTO Free Network Foundation (www.thefnf.org)

3 2