Re: nLayer IP transit
On (2013-08-01 10:00 +1000), Mark Tees wrote: I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Anyone planning to do this might want to be aware that the validation process of flowspec does not limit actions. In practice this means, if you do run flowspec to your customers, your customers likely can inject traffic to arbitrary VRFs. I feel RFC should have explicitly stated valid actions for validation process, which operator MAY change, and any other action MUST cause validation process to fail. -- ++ytti
Re: SNMP DDoS: the vulnerability you might not know you have
On (2013-07-31 17:07 -0700), bottiger wrote: But realistically those 2 problems are not going to be solved any time in the next decade. I have tested 7 large hosting networks only one of them had BCP38. I wonder if it's truly that unrealistic. If we target access networks, it seems impractical target. We have about 40k origin only ASNs and about 7k ASNs which offer transit, who could arguably trivially ACL those 40k peers. If we truly tried, as a community to make deploying these ACLs easy and actively reach out those 7k ASNs and offer help, would it be unrealistic to have ACL deployed to sufficiently large portion of networks to make spoofing impractical/expensive? Do we have other approaches? Can we make this ACL dynamic to a degree? Can we extract ACL information from BGP table? If origin only ASN advertises prefix to global table anywhere, allow it at matching 'remote-as' port. Does not look like difficult feature to build, does not require magic HW support, essentially dynamically built ACL. After this spoof would require injected trash BGP route, which would also steal return traffic, making it useless for DoS. -- ++ytti
Re: nLayer IP transit
On Thu, Aug 01, 2013 at 09:13:59AM +0300, Saku Ytti wrote: On (2013-08-01 10:00 +1000), Mark Tees wrote: I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Anyone planning to do this might want to be aware that the validation process of flowspec does not limit actions. In practice this means, if you do run flowspec to your customers, your customers likely can inject traffic to arbitrary VRFs. You can match flow actions by extended communities and not accept actions you do not like. For example, to permit only discard action you can match community flow_discard members traffic-rate:*:0; Or am I missing something ? I feel RFC should have explicitly stated valid actions for validation process, which operator MAY change, and any other action MUST cause validation process to fail. -- ++ytti -- In theory, there is no difference between theory and practice. But, in practice, there is.
Re: nLayer IP transit
On (2013-08-01 11:35 +0400), Alexandre Snarskii wrote: You can match flow actions by extended communities and not accept actions you do not like. For example, to permit only discard action you can match community flow_discard members traffic-rate:*:0; Or am I missing something ? No you're not missing anything. This is what I implied with 'likely', I feel validation check should guarantee eBGP safety as most operators won't deploy additional security via manual config, because issue isn't mentioned in RFC or vendor docs. -- ++ytti
BGP related question
My apology if I am asking for a repeat question on the list. On 7/29/13 I read an incident about accidental BGP broadcast see article here https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ My questions: 1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. 2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is implementable/enforceable by ISPs (do anyone have any insight)? 3) If I was to ask for an opinion, from your viewpoint which one is better and why and which one is not doable and why not? Thank you in advance, Parthiv This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and notify us immediately.
Feds snooping and FCC 477 and FCC 499 forms and 214 licenses
Good Morning Nanog List, I'm not normally the tinfoil hat type howerver I do want to know other operators opinions on the FCC 477, 499 and the 214 license requirements in light of the recent revealations. Do you think the info is actually for the stated purposes? I'm trying hard not to become a member of the tin foil club but it's getting hard each day. Thanks. Sam * Moderators please delete the copy of this I sent from s...@circlenet.us.
RE: BGP related question
-Original Message- From: Shah, Parthiv [mailto:parthiv.s...@theclearinghouse.org] Sent: Thursday, August 01, 2013 9:00 AM To: nanog@nanog.org Subject: BGP related question 1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. The most basic short answer would be use of proper filtering and LOAs. Transit providers should be checking whether or not customers have permission to act as a transit provider for prefixes or originate the prefixes not registered to them by the RIRs. If every operator would have controls in place to ensure folks are originating the routes they are supposed to then you wouldn't have a problem. However, it seems the best course of action is to implement checks and balances internally to each organization which usually prevents all together or mitigate things as much as possible. Human error is inevitable. We have outside monitoring (bgpmon) for our prefixes. 2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is implementable/enforceable by ISPs (do anyone have any insight)? If I had to pick one based on practicality it would be secure original BGP. You can create a fairly secure BGP session by using multiple mechanisms (prefix lists/filters/routemaps, password, iACL, TTL-security, AS limits etc.) However, there are caveats to anything.
Feds snooping and FCC 477 and FCC 499 forms and 214 licenses
On 2013-08-01 10:57, Sam Moats wrote: Good Morning Nanog List, I'm not normally the tinfoil hat type howerver I do want to know other operators opinions on the FCC 477, 499 and the 214 license requirements in light of the recent revealations. Do you think the info is actually for the stated purposes? I'm trying hard not to become a member of the tin foil club but it's getting hard each day. Thanks. Sam
FCC 477 and FCC499 forms
Good Morning Nanog List, I'm not normally the tinfoil hat type howerver I do want to know other operators opinions on the FCC 477, 499 and the 214 license requirements in light of the recent revealations. Do you think the info is actually for the stated purposes? I'm trying hard not to become a member of the tin foil club but it's getting hard each day. Thanks. Sam
Re: nLayer IP transit
On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: Howdy listers, I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? We were forced to stop offering flowspec connections to customers, after we started experiencing a rash of issues with it. Among other things, we found ways for flowspec generated rules to easily cause non line-rate performance on Juniper MX boxes, and we had a couple of incidents where customer generated routes were able to cause cascading failure behaviors like crashing the firewall compiler processes across the entire network. I previously mentioned some of this here: http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html There have also been a few other high profile outages caused by bugs in the Juniper implementation, for example: https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 As a concept I still very much like Flowspec, and wish we could continue to offer it to customers, but as with any new routing protocol there are significant risks of network-wide impact if the implementation is not stable. IMHO Juniper has done a horrible job of maintaining support for Flowspec in recent years, and has effectively abandoned doing the proper testing and support necessary to run it in production. Until that changes, or until some other major router vendors pick it up and do better with it, I don't expect to see any major changes in this position any time soon. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
[NANOG-announce] NANOG on The Road
NANOGers, You are invited to attend NANOG's first one-day meeting, NANOG on the Roadjoint with ARIN on September 10, 2013 in Portland, OR. ARIN + NANOG on the Road Portland will provide an opportunity to network with colleagues, access to a day's worth of professional education and current Internet operations. Content will be provided by speakers from both ARIN and NANOG. ** ** Complete Event details are available on the NANOG website: ARIN + NANOG on the Road in Portland, Oregonhttp://www.nanog.org/meetings/road1/home will be held at the Courtyard by Marriott Portland Downtown/Convention Center. * * Registration is free but required, so make sure to register nowhttps://www.arin.net/participate/meetings/on-the-road/portland.html ! Spend the morning getting up to speed on the history of the Regional Registry System, Internet Governance, and ARIN technical services. Find out the latest about Internet number resource management – including IPv4 transfers and IPv6 adoption, and current ARIN policy developments. Then spend some time networking with fellow attendees over lunch. ** ** Kick off the afternoon with tutorials from ARIN on RPKI, NANOG on DNSSEC, and additional NANOG educational content. NANOG will host a session on its role in the network operator community and ways to engage with and take part in its lively professional community of Internet engineers and architects. The day will conclude with an Open Microphone / QA session, followed by a networking Happy Hour where conversation can continue in a more relaxed setting. ** ** Attendees who complete a short survey about the event will be eligible to win one of two $100 Amazon gift cards. *Register today*https://www.arin.net/participate/meetings/on-the-road/portland.html ! ** ** Please feel free to forward this invitation to friends and colleagues who may be interested in attending this ARIN + NANOG on the Road event. Contact us at nanog-supp...@nanog.org if you have any questions. ** ** Regards, ** ** ARIN + NANOG on the Road Team American Registry for Internet Numbers (ARIN) https://www.arin.net/ North American Network Operators Group (NANOG) http://www.nanog.org/ -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 ___ NANOG-announce mailing list nanog-annou...@mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: nLayer IP transit
Thanks for the replies. I think I saw somewhere around the Cloudflare outage post someone mentioning that since the person at Juniper that was responsible for Flowspec left it all went down hill. I take it then Flowspec is still used internally then? I am still wondering if its best to avoid Flowspec and roll your own firewall rules applied via Netconf for transit interfaces to achieve the same sort of functionality. On 02/08/2013, at 3:30 AM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: Howdy listers, I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? We were forced to stop offering flowspec connections to customers, after we started experiencing a rash of issues with it. Among other things, we found ways for flowspec generated rules to easily cause non line-rate performance on Juniper MX boxes, and we had a couple of incidents where customer generated routes were able to cause cascading failure behaviors like crashing the firewall compiler processes across the entire network. I previously mentioned some of this here: http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html There have also been a few other high profile outages caused by bugs in the Juniper implementation, for example: https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 As a concept I still very much like Flowspec, and wish we could continue to offer it to customers, but as with any new routing protocol there are significant risks of network-wide impact if the implementation is not stable. IMHO Juniper has done a horrible job of maintaining support for Flowspec in recent years, and has effectively abandoned doing the proper testing and support necessary to run it in production. Until that changes, or until some other major router vendors pick it up and do better with it, I don't expect to see any major changes in this position any time soon. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: BGP related question
Hi Parthiv, .-- My secret spy satellite informs me that at 2013-08-01 7:00 AM Shah, Parthiv wrote: My apology if I am asking for a repeat question on the list. On 7/29/13 I read an incident about accidental BGP broadcast see article here https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ This was the same issue as was discussed last week on Nanog: http://mailman.nanog.org/pipermail/nanog/2013-July/059992.html In summary there were 72 prefixes hijacked, they also leaked a few hundred more specifics of their own prefixes. You can examples of similar events here: http://www.bgpmon.net/blog/ 1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. There are a few BGP monitoring tools available, BGPMon.net is one such service. 2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is implementable/enforceable by ISPs (do anyone have any insight)? The thing we can improve today is providers doing a better job of filtering. But that's still not full proof. Since many folks use max-prefix filters only on for example Internet Exchange points, it's easy to pick up a hijacked route from peers. In the long term RPKI should solve this, but that's not full proof either. The next step is full path validation, that's going to take a while. For more info see for example: http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/ or http://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure Cheers, Andree
Re: Revealed: NSA program collects 'nearly everything a user does on the internet'
I'll make this short. Is our OpenVPN server prone?
L3 Contact
Will an IP engineer from Level3 contact me off list. We having trouble routing traffic through.. Possible bogon update issue ? Thanks Sent from my iPhone
IP allocations / bogon - verification
Gang, I apologize for a double post on this same topic tonight however I thought that broadening my request may help our cause. This month we had one of our IP allocations revoked and just recently got everything squared away with ARIN and things are turned back on so to speak. However I still have some customers having issues hitting a number of financial related websites ..etc and I assume its because of bogons ..etc I saw some earlier posts on here where folks have posted their allocation to ensure that others are routing it properly so I wanted to do the same. My allocation which has recently been revived: 66.185.0.0/20 Test point traceroute .etc 66.185.0.198 We do seem to be having some issues with some level 3 routing our range to some desitnations and can provide specifics off list. Thanks all for the help / verification. Kenny
