- Test - lists.nanog.org

OpenSource IPTV and VoD Solution
by Meftah Tayeb 16 Nov '11

16 Nov '11

Hello Guys i'm looking for a solution to stream diferent DVB transponders through RTSP VLC look like complicated a bit i use MumuDVB for Multicasting but i didn't found anything for RTSP any help Would by welcome thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

5 6

Security Contact from k12.fl.us
by Nathan Eisenberg 16 Nov '11

16 Nov '11

Please contact me off-list.

1 2

[ISC Security Advisory] BIND 9 Resolver crashes after logging an error in query.c
by Peter Losher 16 Nov '11

16 Nov '11

BIND 9 Resolver crashes after logging an error in query.c Summary: Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions were reported being affected, including all currently supported release versions of ISC BIND 9. ISC is actively investigating the root cause and has produced patches which prevent the crash. Further information will be made available soon. CVE: CVE-2011-4313 Document Version: 1.1 Document URL: http://www.isc.org/software/bind/advisories/cve-2011-4313 Posting date: 16 Nov 2011 Program Impacted: BIND Versions affected: All currently supported versions of BIND, 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x Severity: Serious Exploitable: Remotely Description: An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached.At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit. The patch has two components. When a client query is handled, the code which processes the response to the client has to ask the cache for the records for the name that is being queried. The first component of the patch prevents the cache from returning the inconsistent data. The second component prevents named from crashing if it detects that it has been given an inconsistent answer of this nature. CVSS Score: 7.8 CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C) Workarounds: No workarounds are known. The solution is to upgrade. Upgrade BIND to one of the following patched versions: BIND 9.8.1-P1, 9.7.4-P1, 9.6-ESV-R5-P1, 9.4-ESV-R5-P1 Active exploits: Under investigation Solution: Patches mitigating the issue are available at: https://www.isc.org/software/bind/981-p1 https://www.isc.org/software/bind/974-p1 https://www.isc.org/software/bind/96-esv-r5-p1 https://www.isc.org/software/bind/94-esv-r5-p1 ISC is receiving multiple reports and working with multiple customers on this issue. Please E-mail all questions, packet captures, and details to security-officer(a)isc.org We very much appreciate all reports received on this issue. Related Documents: Do you have Questions? Questions regarding this advisory should go to security-officer(a)isc.org. ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: https://www.isc.org/security-vulnerability-disclosure-policy Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. -- [ plosher(a)isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]

1 0

state.va.us contact on list?
by David Hiers 16 Nov '11

16 Nov '11

We are aparently being attacked from a server in state.va.us. If there is a contact for state.va.us on the list, please contact me off list. Thanks, David

1 1

Re: Arguing against using public IP space
by Eric C. Miller 16 Nov '11

16 Nov '11

Not sure if anyone has thought of it like this, but: Air Gap is still only as secure as the people with access to it. NAT and firewalls provide a compromise between security and connectivity. But remember that at a power plant, the PBX system still connects to the outside world, and there is a phone in the control room. What stops a nefarious social hacker from calling up the control room and convincing the 3rd shift operator to stop producing power (claiming to be from the regional authority)? Caller-ID can be hacked. My personal belief is that all layers of the OSI/DOD model should assume that the adjacent lower level can and will be compromised at some point and measures should be put in place to encrypt or authenticate messages. Unfortunately for us, our critical infrastructure in this country still operates on outdated security-less network architectures like ArcNET. Even most of the PLCs in use at power plants utilize no security or have simple passwords like "supervisor" and "operator." The US gov's NERC has random inspections for CIP compliance, but I feel that they happen so infrequently, that nothing will be done in time to adequately protect us from certain dangers that loom. Eric Miller Network Engineering Consultant

1 0

AS9929 - Anyone with Clue
by Mark Tinka 16 Nov '11

16 Nov '11

Hi all. If there's anyone on here from AS9929 (Chine Netcom) with some clue, kindly ping me off-list. Thanks. Cheers, Mark.

1 0

Foundry MRP cohabit with STP
by Viet-Hung Ton 16 Nov '11

16 Nov '11

Hi, We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). Best thanks, Viet Ton.

3 2

Question about operational concerns with Routing Protocol Security
by Christopher Morrow 16 Nov '11

16 Nov '11

Howdy, while enjoying some (oddly not controversial) meeting time at the IETF, one of the presenters (Sam Hartman[1]) noted he's looking for some people to chat with with respect to 'deployment scenarios' surrounding network gear and protocol security. Today that probably takes the form of things like: "Hey, be sure to copy the password into the config before turning up the interfaces!" I can imagine other methods as well, for things like: eBGP iBGP ISIS OSPF would any of the folks on-list that currently have key material (passwords and such) configured for these protocols AND who also deploy new gear into the field be willing to chat some with Sam? (Note, you don't have to tell Sam your passwds/keys, and you don't have to tell anyone else that the passwd is 'chocolate' either...) Thanks! -Chris (also, note that I copied in at least one of Sam's emails, maybe this one won't get too filtered...) [1]: The draft Sam could use some advice on: <http://tools.ietf.org/id/draft-ietf-karp-ops-model-01.txt>

1 0

Minimum Allocation Size by RIRs (IPv4)
by Fredy Kuenzler 16 Nov '11

16 Nov '11

I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/m… (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. -- Fredy Künzler Init Seven AG AS13030 Elias-Canetti-Strasse 7 CH-8050 Zürich Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 http://www.init7.net/

6 5

FW: Savvis broken link / underperforming between DC and Atlanta?
by Lorell Hathcock 16 Nov '11

16 Nov '11

All: I did not see a reply to this. Anyone else having a problem on this link? Lorell From: Lorell Hathcock [mailto:lorell@hathcock.org] Sent: Friday, November 11, 2011 9:10 AM To: nanog(a)nanog.org Subject: Savvis broken link / underperforming between DC and Atlanta? Any one else seeing this? This was done yesterday from Hawaii. tracert speedtest.saas.infor.com 3 5 ms 5 ms 4 ms ip64-75-240-210.aloha.net [64.75.240.210] 4 5 ms 5 ms 5 ms hnl-edge-02.inet.qwest.net [67.129.94.69] 5 * * * Request timed out. 6 56 ms 56 ms 56 ms 63-235-40-18.dia.static.qwest.net [63.235.40.18] 7 58 ms 58 ms 59 ms cr1-tenge-0-3-5-0.sanfrancisco.savvis.net [204.70.200.198] 8 138 ms 138 ms 138 ms cr1-bundle-pos2.Washington.savvis.net [204.70.200.90] 9 135 ms 136 ms 136 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 10 139 ms 136 ms 137 ms 165.193.78.106 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. But from Houston it was fine yesterday. It took a different route. Today I have the same problem from Houston. tracert speedtest.saas.infor.com 4 2 ms 2 ms 2 ms te4-1.3509.ccr01.iah02.atlas.cogentco.com [66.28.6.21] 5 3 ms 2 ms 2 ms te0-2-0-4.ccr21.iah01.atlas.cogentco.com [154.54.3.149] 6 9 ms 10 ms 8 ms te0-1-0-5.ccr21.dfw01.atlas.cogentco.com [154.54.2.225] 7 8 ms 8 ms 8 ms te7-3.mpd01.dfw03.atlas.cogentco.com [154.54.6.66] 8 15 ms 8 ms 12 ms aer1-ge-4-2.dallasequinix.savvis.net [208.175.175.5] 9 17 ms 8 ms 15 ms 204.70.207.182 10 10 ms 9 ms 10 ms cr1-tengig0-7-5-0.Dallas.savvis.net [204.70.200.170] 11 37 ms 37 ms 37 ms cr1-tengig-0-7-0-0.Washington.savvis.net [204.70.196.105] 12 36 ms 36 ms 36 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 13 37 ms 36 ms 37 ms 165.193.78.106 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. This the end IP address is in Rackspace in Atlanta I am told. Known issues out there? Any de-peering going on? Or is this just a firewall or private IP space that is not responding to traceroute information requests? Thanks for any help, Lorell Hathcock

1 0