- Test - lists.nanog.org

Cisco Security Advisory: Cisco IOS and IOS XE Software IPv6 First Hop Security Denial of Service Vulnerabilities
by Cisco Systems Product Security Incident Response Team 23 Sep '15

23 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS and IOS XE Software IPv6 First Hop Security Denial of Service Vulnerabilities Advisory ID: cisco-sa-20150923-fhs Revision 1.0 For Public Release 2015 September 23 16:00 UTC (GMT) +------------------------------------------------------------------------------- Summary ======= Two vulnerabilities in the IPv6 first hop security feature of Cisco IOS and IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload. Cisco has released software updates that address these vulnerabilities. There are no workarounds to mitigate these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The September 23, 2015, release of the Cisco IOS and IOS XE Software Security Advisory bundled publication includes three Cisco Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: September 2015 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep15.html -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWAWwcAAoJEIpI1I6i1Mx3wYkQAJU+71c6l6BRNwQ65d7XucdS r64mrlpga6Mud4jxqsbatCM76W+DDcSE1xtz2lqWN8L3Aqndq/ZmsysZPID81lr/ kPWpVaNbOjr/BgXe8K8f/xYS6ExIMs7jcLSOcB5obdQaHXOvOf8yPOP4SuHodILO i5JJ+kjE22dmRw1srBCtZF0HdNUFa+aXYuR0OSrqHwaPARMsRPQbsAF7djBVDdRU 1XB4YH5zVXG0q3yMpdlJLdVkPtQesC+BSka66qcSJBnC6tqQ/KEMkUkt+Uk1Yh9s Qpuh9UcIB78/oBy/VZI8IGsTL4uVLczRhonQe5KFP3uvM0LJvMXAn+dTXXBZJXlm 9NEHrOuoxZjPlMYntaY3xE9Ocl3ObA4Y12H1S+E1djhVogdNjW4qN8dorqIq10g5 jAi0o8qhM7o5vRjDt8os0UnuAHPaqtY0C5oaTruZN28N7Hzey4mdM9wkOL/oY+rq Lgd9BT+BHAO+Yop0cgpmPAs2EXYzVz7zN5euYzuFywQOfQvko84YFfzxt6Y+ofIH SbAHZ1tdtw059IQk6Q6nlK3rE9jk+vO7wQ8MW39OXCgjEMlXn7kWQ3gctXz0Qesj li2+OFzXVhLBk3JDiqBQJ08FYoyuH25e58MumDLxZnoQi4jS5YqJcSQjSfnRLn2n eU9LswAcnFiAlRAE34PP =pjAl -----END PGP SIGNATURE-----

1 0

Fw: important
by Gisele Kamanou 23 Sep '15

23 Sep '15

Hey! Important message, please visit <http://majorinvesting.com/hope.php?i> Gisele Kamanou

1 0

Verizon Wireless LTE/4G and SIP Header Manipulation
by Mark Stevens 22 Sep '15

22 Sep '15

Hi All, Has anyone seen that something (most likely an alg) on Verizon's LTE/4G network is rewriting SIP headers,in particular From Tag identifiers? We cannot make a SIP call from our cellphones (using cellular data) beyond 30 seconds because the TAGs are rewritten and the destination Asterisk server drops the call because of this. Thanks Mark

6 9

Re: Verizon Wireless LTE/4G and SIP Header Manipulation
by Dovid Bender 22 Sep '15

22 Sep '15

We have this every now and then. Mainly with traffic from the middle east. Switching the port to something other than 5060 seems to help most of the time. Every so often we need to go the vpn route. I know that yealink, snim and possibly polycom have vpn clients built into them. ------Original Message------ From: Mark Stevens Sender: NANOG To: nanog(a)nanog.org Subject: Verizon Wireless LTE/4G and SIP Header Manipulation Sent: Sep 22, 2015 12:03 Hi All, Has anyone seen that something (most likely an alg) on Verizon's LTE/4G network is rewriting SIP headers,in particular From Tag identifiers? We cannot make a SIP call from our cellphones (using cellular data) beyond 30 seconds because the TAGs are rewritten and the destination Asterisk server drops the call because of this. Thanks Mark Regards, Dovid

1 0

IX Peering - BGP Session Filtering Best Practice
by Erik Sundberg 22 Sep '15

22 Sep '15

Just wondering how far everyone is going on filtering BGP sessions when peering with other content providers and carriers over an internet exchange. What are you doing. 1. Just filtering out IPv4 Reserved Space, RFC 1918, and Default Routes. 2. AS Path Filtering. Only filtering by the AS's that are present in the IRR Record. 3. Filtering by IP Prefix based on the IRR Record for the Peer. (Yes some Prefix Filter list can be a couple thousand lines) 4. Doing both #3 and 4 listed above. Besides Peering DB is there any software to help keep track of IX and Peering info. So far I have only found IXP-MANGER ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

2 1

Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN
by Rod Beck 21 Sep '15

21 Sep '15

This might of interest to network engineers seeking to ensure their upstreams are physical diverse. http://pages.cs.wisc.edu/~pb/tubes_final.pdf Roderick Beck Sales - Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment.

6 8

cisco.com unavailable
by Murat Kaipov 21 Sep '15

21 Sep '15

Hi folks! Is cisco.com <http://cisco.com/> unavailable or it is affected just for Rostelecom?

16 18

Segment Routing for L2VPN?
by Jason Lixfeld 21 Sep '15

21 Sep '15

Hello! I've been doing some reading recently on Segment Routing. By all accounts, it seems that the (only?) implementation for SR supports L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply the extent of the first generation? Sent from my iPhone

3 2

ICANN Public Comment period related to DNS Root Zone KSK closes October 5, 2015
by Edward Lewis 21 Sep '15

21 Sep '15

(Apologies for duplicates of this) ICANN has an open Public Comment period on work relating to changing the Root Zone's DNSSEC Public KSK. The formal Public Comment process closes October 5, 2015. For further details, consult this URL: https://www.icann.org/public-comments/root-ksk-2015-08-06-en The title of the Public Comment period is: Design Team Review of Plan for DNS Root Zone KSK Change URLs of note, all of these are found from the URL above. The draft report in English: https://www.icann.org/en/system/files/files/root-zone-ksk-rollover-plan-dra ft-04aug15-en.pdf There are also versions of the report in 6 other languages. And the comments forum: http://forum.icann.org/lists/comments-root-ksk-06aug15/

1 0

DDoS auto-mitigation best practices (for eyeball networks)
by Frank Bulk 21 Sep '15

21 Sep '15

Could the community share some DDoS auto-mitigation best practices for eyeball networks, where the target is a residential broadband subscriber? I'm not asking so much about the customer communication as much as configuration of any thresholds or settings, such as: - minimum traffic volume before responding (for volumetric attacks) - minimum time to wait before responding - filter percentage: 100% of the traffic toward target (or if volumetric, just a certain percentage)? - time before mitigation is automatically removed - and if the attack should recur shortly thereafter, time to respond and remove again - use of an upstream provider(s) mitigation services versus one's own mitigation tools - network placement of mitigation (presumably upstream as possible) - and anything else I ask about best practice for broadband subscribers on eyeball networks because it's different environment than data center and hosting environments or when one's network is being used to DDoS a target. Regards, Frank

9 8