DDoS Mitigation using BGP Flowspec

all right thanks Jeff we'll jump right into it I don't want to spend a lot of time on Who I am I figured this is Nanog you guys are probably know more about me that I know about myself by the time I'm done up here but I didn't want to spend a minute on why I chose this topic while I'm up here talking about this today and it really comes down to in the late 90s and early 2000s I worked for a surf provider in operations and I had the pleasure of tracking some dos attacks at 3 o'clock in the morning and at that time we didn't have a lot of tools we didn't have a lot of traffic graphing we didn't have net flow anomaly type of tool we didn't have automation tools for automating our configs and it was a very manual process it was very tedious it was a you know very cumbersome and I remember thinking at the time there's got to be a better way to do this and so fast forward to today I think beetus mitigation using BGP flowspec is one of a number of tools that operators having a tool belt that they can use for blocking dos attacks so and I won't spend a lot of time on this I'm assuming if you didn't think DDoS was an issue you probably would have left the room or I started talking but I thought these were some interesting articles that point out that not only is dos attacks something that's annoying that takes up our time that's a problem that we as operators have to deal with it takes us away from other things we'd rather be doing but it's also an economic impact to you not to us to our customers as you can see from this NBC News article they estimated more than 40% of das attacks cost an estimate of a million dollars per day so there's significant economic impact from this problem all right so how do we use to block the attacks back in the old days like I was talking about when I worked for an operator the customer call in they'd say help I'm being attacked I you know my website is down in this in this example hopefully you got a hold of a guy and a knock who had clue and config access he could go in and track back what the attack traffic was figure out what that was versus legitimate traffic put filters in place in the network make the attack traffic go away allow the illegitimate traffic to flow through and while all your your web server in this case is backup that was great I mean it's fairly easily to implement and how to use it as yes fairly well understood as long as you have not guys that are fairly well trained in the CLI on your on your particular vendors devices it does however require a degree of coordination between the customer provider because the customer has to Kunal in saying I'm being attacked and the provider login and take a look and figure out what's what's happening and again if you're in a large network with lots of devices this becomes very manual very hard to scale and I guess the last thing is that when you have people inputting filters and manually in routers it's only a matter of time until somebody makes a mistake and you do something you didn't didn't do that's gonna cause a very costly problem so then we as an industry came up with this idea of remotely triggered black holes destination remotely trigger black holes that does and the idea here is that the victim initiates when once they're under attack they initiate a route back to their service provider telling them what address is being attacked and that they want that address basically no routed and the service providers in the Surfrider's network they do that through sending a discard community that they've agreed to beforehand with our service provider the Surfrider then takes that BGP prefix that's the next top to a discard route that they have configured on their on their device and the they'd send that traffic through the bit bucket for the discard right the only problem with that is then if you had that server only with one IP address you've now completed the attack right the server is completely down hopefully you have to be n s you can just change the IP address for your server and it comes back up assuming that the miscreants aren't attacking you by a name they're only attacking by a few so there's some some pros and some cons to this approach too right this has been around for about 10 or 11 years you know in it like I said it was still better than the manual manual process we were doing before but it does require this pre configuration of discard routes on all the edge routers and knowing what community you've got to send to your service provider in order make this happen and again the victims destination dress is now completely unreachable for that back alright so then the next step was an idea of source remotely triggered black holes and the way this works is normally again we go back to where the person under attack has to call in and say hey I'm being attacked the knock person puts in a black hole route in the route server that advertises out all the service providers routers and what this actually does is no routes the the source instead of the destination essentially and it works in combination with with RPF or source address validation whatever your particular vendor calls it to drop the source of the traffic instead of the destination a traffic right and then hopefully if that works well your web servers backup the IP address is still reachable by everybody except for the source of the attack yeah and this is something that's been around for quite a while kima was an rfp at sea that was approved in 2009 again it requires a decent amount of pre configuration before the attack you have to put in the discard routes and you have to have RPF or source address validation period on all your interfaces in order for this to work correctly in the advantages that the victims address the nation address is still usable but it only works if you have a known or a small handful of source addresses if it's widely distributed this is probably a little bit less than useful right so inner bgp flowspec this is an RFC that's been around now for about five what's going on six years it is an IETF standard we find new BGP a fee and Safie new NLR eyes or advertising the information about the attack to our routers and I'll go more into what the what that is bgp flowspec has this idea of validating the routes against the unicast routing table to make sure that someone's not the goal being to make sure that somebody's not advertising a route black hole that they don't own that they're not already advertising to you as a service provider via unicast BGP once that's validated then those bgp routes are actually turned into an access list or a firewall filter to take whatever action you have specified you want to take to that drive right so the good news about BGP flowspec is it's a lot more robust in the things that you can do so you can do things like destination and source prefix a combination of those protocols ports ICP flags TCP flags there's a lot of different things that you can match on so you can get a lot more granular so just black holing an entire untier IP address and then you can also take multiple actions probably the two most common here are dropping and sending a traffic rate to zero or doing a redirect but you can also mark it with dscp values as well or sampled breath and I think an important thing to note here is that this is this is something that is gaining more traction in the industry I think over the years it's not something I know I'm a Juniper employee standing up here talking to you about it but it's not something that only juniper supports right this is not an exhaustive list there are others out there but this is just some some that I researched and put into the deck for make my point here so there's a number of vendors that have detection tools that support be creating BGP flowspec routes and sending those out as well as router vendors that support receiving the flow spec routes and tend creating those firewall filters those ACLs block traffic all right so what makes me chiefly BGP flowspec better and I alluded to some of this and and it comes down to gives you more granularity than just a straight access list it gives you the same granularity that you had with access list right I mean get a lot more particular about what the what the traffic is you want to block versus the traffic you want to allow but you the similar automation that we had with remote trigger black hole where either from an internal route server you can advertise those routes or if you trust your customers you can allow your customers to send you flowspec routes and block traffic based on their routes I mean again it it leverages the BGP best practices and policies that we as an industry have been using for years it's not like we're running a new protocol to it to accomplish this so all right so what would what would an inter domain boss mitigation using flowspec look like right and this is where you have a customer that you you're allowing them to send you flowspec route so your victim is being attacked they have a web server and then this example the particular attack they're getting a DNS attack 53 UDP attack so they send a flow spec route to their service provider saying please block or rate limit to zero my my destination address all packets that are 53 UDP right that routes received by the Surfrider it's a it's sent to all of the edge routers it's like I said set with an action action to a rate of zero the traffic is then black hold and the edge routers via an automatic access list or a firewall filter the attack traffic is dropped the legitimate traffic continues to pass and the customers web servers back up this of course allows the customer of the ISP to initiate their own filters automatically it of course on the search writers side is going to require saying filtering of BGP to not allow then the send you a ton routes the routes they don't own those kind of things good common policy and procedures there all right so what would what would configurations look like and again I want to point out that this is not just something that one vendor supports so I have just three examples and again not necessarily an exhaustive list of vendors and what their configurations look like and for the example that I just showed where you're receiving BGP flowspec routes from from up from a customer all you really do is turn on the flow spec in honor I that I talked about that we've added the BGP and pretty pretty straightforward from that alright so as far as intradomain DDoS mitigation so this is if you if last one was a little too scary for you to allow your customers to send you flowspec routes if you don't have that kind of trust in your customers I get it okay so what how do we do it if we want to do it inside of our own domain inside of our own control all right so presumably your customer has to still call you and say hey I'm being attacked the NOC logs in and configures the flowspec route on the route server has some automated tool that does this for them the flow spec routes go out to the edge router same as before the the edge router receives those routes creates the firewall filters the access list it pushes down to the boarding plane and drops the traffic the DNS traffic is scrubbed out the the DNS attack traffic are scrubbed out the legitimate web traffic continues to pass right again this could be initiated by a phone call into the NOC you could have a detection tool that you're running looking your flow data to see when there are traffic anomalies or you could create a web portal where a customer can log in and tell you the information about the about what kind of attack they're seeing and that be what actually generates the flow spec route on your route server no matter how you do that you still have to require our coordination between your customers and yourself if you're the Surfrider of course so one of the one of these configs look like again the edge router config looks exactly the same because it's not doing anything different I just put it here for completeness but it's the same as it was before well we do have different on the route server now we have another router in there so we have to create the the its turn on the NL RI for bgp flowspec on the route server as well and then as far as I'm aware Alcatel is current code doesn't allow you to create flow spec routes to use as a routes already created but I could be mistaken on that but I found Cisco's config and junipers config on how you create the route and essentially we're creating a flow spec we're creating a new route that's a flow spec type route and injecting it into bgp and advertising it from the route server out to our outdoor edge server right again we could do this through some sort of automation tool through a web portal or we could have a NOC engineer who's doing this manually scrubbing center so another thing that is of interest I think to the community and it's being done quite a bit is instead of just by calling it at the edges of the network maybe taking like that entire slash 32 maybe they did inspire slash 24 even that's being attacked and redirecting that to a scrubbing Center that may have some sort of deep packet inspection tools that can scrub out the attack traffic and then pass the legitimate traffic on to the customers do again the customer calls in or somehow notifies you that they're under attack the NOC configures the flow spec were out on the route server very similar what we've already seen but instead of setting the action to a rate limit of zero to drop the traffic we're actually setting a redirection to redirect this to a scrubbing center all the traffic both legitimate and attack for this particular router then since the scrubbing center bad traffic is taken out the legitimate traffic is sent back on down to the data center and ultimately on to the customers web server of course it's important to note here that if if you're doing this once it leaves the scrubbing Center you got to put it as some sort of tunnel either a GRE or a PRF some sort of tunneling mechanism not back in the global routing table you'll create a loop the other way to do this would be to have the tunnel be between the edge router and scrubbing Center and then the scrubbing Center put it back in the global table so one of the other you just can't have both ends of that equation in the global routing table without creating a loop this allows you of course to mitigate the the attack without completing the attack like you do with a remote trigger black bowl what a so what does an edge router look like in this type of scenario and from the edge router perspective it's again the same that we've seen on all the previous slides all we do is just enable the the beach be flowspec in all RI same thing on the route server we didn't able the NLR I and then we go in and we create a route but you'll notice this time instead of setting our action to be a rate limit of zero we're actually setting it to rewrite the next hop to the IP address presumably that's the router and our scrubbing center that's been a receive this path for the appliance our scrubbing center it's gonna receive this traffic alright so if I've done this if I set this up of my network how do I know it works so I put together a few show commands across all three of the vendors I've been using as an example here things you can look at to see are the flow spec routes being generated are they being announced are they being received and ultimately are my firewall filters being created in the forwarding plane and are they actually getting hits against them all right so where where are we as an industry going so again this is this BGP has a flow spec as the technology has been around for about five or six years now but there's still work being done in the IETF there's still work being done in the vendor community to add more features and functionality to it every day so one of the things that we're working on is adding in this protocol you guys may have heard about called ipv6 that we may or may not at some point adopt so we're gonna add that into flow spec so that you know we can scrub out not just ipv4 attacks but also ipv6 attacks there's some discussion on going about doing some relaxing of validation because when you do some interesting things with your route server you may not necessarily have the same path for receiving those routes that you had for the unicast so you may have to relax a little bit of the validation rules specific or certain use cases where the path may be may be different and come up with a different way to validate that these routes are authenticated and should be allowed and then some additional next top options when you're when you're trying to do things like the redirecting to a do a scrubbing Center there's some some additions being done in the IDF for that as well all right so that's kind of BGP flowspec and where we're at the second half of this this deck sent out a survey that allow you may have seen to the nanog mailing alias asking about people's thoughts on bgp flows back had they adopted it so forth I wanted to provide the results of that survey and kind of where people see us as an industry when it comes to flows back though not surprising since this is nanog that the majority of their respondents are in technology or telecom or internet type of industries but there were a few other industries responding things like education entertainment leisure finance so you know a little bit of people outside of the pure internet telecom type of companies responding all right so the first question in the survey was do you have or have you ever enabled bgp flowspec in any part of your network and the majority here almost we'll call it 61 percent of people haven't haven't tried it and I think that really comes comes back to why I wanted to come and talk about this today I just kind of want to raise awareness about it I'd like to make kind of a call-to-action to the community you know if you've got a lab try it in the lab if you you know maybe can put it in a sanitized area the network where if something went wrong it wouldn't have a huge impact try it there you know kick the tires and let your vendors know hey this is working for me this isn't working I need additional functionality I think the more that we we talk about this technology the more that we try it the more that we figure out what's working what's not working and have these conversations the better this is going to get over so the next question in the survey was if you have not enabled it why have you not enabled it the two most common answers here as you can see we're not familiar enough with it again that comes back to why I'm here want to continue the conversation get people talking about it learning about it hearing about it knowing what it does the next most common response was that it's not a high priority so you know people have just been busy working on other things haven't gotten a chance to get around to it beyond that there were some that I think the next most common thing that I hear not just in a survey but in talking to people about this is a lack of vendor support or lack of vendor scale I think that is is getting better there's still you know some features that aren't supported there's still some scaling the neat work that needs to be done by the vendor community obviously but I think that's that's getting better as we go along as well so next question was if you have enabled it but have since disabled it why why did you disable it in the NA here I interpret to mean that for the most people who have enabled it in their network and if given bgp flowspec a try they've left it on right they haven't gone back and disabled the later now there were a few people who either ran into a code bug or they ran into an issue with the way it worked in their design or they ran into a scaling parameter which required them to remove it so that not going to stand up here and say that doesn't happen or that it hasn't happened because it has but over the seems like the overwhelming majority almost 81% of people who have been able to have stuck it out all right so if you do not have it enabled currently how likely are you to enable it in the future so kind of you know what is your attitude towards enabling in the future and it's kind of a mixture between not at all likely people who really just have no interest in trying it and likely you know not not yes we're going to anywhere between yes we're gonna do it or we're thinking about it we're working on it maybe we're testing it in our lab somewhere in that in that neighborhood okay experience so the next question was overall how would you rate your experience with Beefalo spec so if you're one of those people who's tried it you've played with it either in a lab or in production you know haha you know how is your experience but unfortunately and I think this talks to the work that's still to be done but to make it a more robust solution the overwhelming majority the respondents said almost 53 percent said that their their experience with it has been pretty negative so clearly still some work that we can do around this technology as an industry how likely is it that you would recommend it to a friend fairly even across across you know would-wouldn't don't really care you know fairly even spread not a real strong opinion there so for those people who do have it enabled the question the next question was do you allow your customers to send you bgp flowspec around five each be almost everybody said no so apparently that scares people do allow their customers to send them flowspec routes although they Louden's and a lot of people allow them to send destination blackhole around so I find that kind of an interesting dynamic but for those people who are doing flowspec the next question was do you have a web portal where your customers can log in and inject BGP flowspec routes through some sort of web tool and again the overwhelming majority almost 90% was no we don't we don't allow that again it speaks one of two things in my mind either speaks to a lack of trust with the customers that they might do something they shouldn't been influenced either other people's traffic or and wants themselves in negative ways or just a lack of time and to develop a tool such as that do you have a central router from which you inject your BGP flowspec routes so this one was pretty close between the yeses and the knows maybe a little bit more on the know than in the yes side but it seems like that's a you know fairly common things people are starting to use a central router a route server of some sort to inject their flow spec routes and instead of just going out to in a random edge router and figuring them there do you allow a DDoS detection tool to send BGP flow specs into your igb so the other necessarily have to be hardware that was just the first one that came to mind when I was doing the survey but there are a number of DDoS detection tools the question is do you allow those to create these flowspec routes and inject them into your IGP tables I'm sorry your ibgp tables and the overwhelming majority of that was was No then the next highest category at 22% was yes after review so a lot of people if they are allowing the detection tool to create the flow spec routes and automate sort of the mitigation of the of the dos attacks they're making an employee and engineer or NOC guy double-check and sanitize anity check them before they allow those full spots to get created um and then there's actually a higher number than I kind of expected to see 17% of the respondents said that yes they just allow it to be automate now there's probably I'm assuming done a decent amount of testing and have a lot obviously a level of trust in their detection tool that it's not going to create we're gonna create flowspec routes that don't make sense or that they don't want alright so you know we're talking about any new technology I always find interesting to see you know do you charge for bgp medication is there a way we can make money with BGP flowspec can we charge for it the the majority of the respondents said about 57% said no there are a few who did respond saying that they that they do charge for it so there were a number of places where you could write in comments based on your answers if you wanted wanted to give me more comment and I didn't put all of them in here I just summarized kind of what the theme of the comments that I was getting was and essentially it comes down to most people that responded said that they thought that BGP flowspec was a good idea and that they would think that of course DDoS mitigation is an important issue to address and they'd love to see this take off but the enterprise companies the content providers the the non service providers I guess I would say are waiting for the surf writers to start accepting their BGP flow routes so that they can automate the DDoS detection I'm sorry the DDoS mitigation by sending these flowspec routes similar to what I showed in the intra D intro domain mitigation interestingly enough kind of as I guess a sidebar or some respondents even said they would be willing to use that as a reason to pick a service provider so if they go to RFP for a new service provider they'd be willing to use that as a reason to choose one source writer or another so maybe there is a way to make money in in using BGP flowspec after all so the next thing they became some were sort of evident in reading the comments in the survey was that while that's what the enterprise and content companies are waiting for or the ISPs the service providers are waiting for their vendors to support it or at least they have been waiting for their vendors to support it to this point they either need the particular vendor that they use which may not be one of the three that that I mentioned earlier to support it or they need it in a certain version of code from that vendor a certain platform from that vendor or they need specific features and there and that aren't currently supported that they're working with their vendor to try and get some new features that they need specific to their use case implemented or it comes down to their vendor supports it but it doesn't scale the way they need a scale for the size of network that they run they have to maintain these are some some of the references that I used for some of the articles I had as well as where I got the configs from some of the some of the slides that's it I guess we'll open up the mics for questions if anybody has a question sure in this community somebody's got a question hey Justin jean-christophe from Team Camry may be more of a comment than a question so tried flowspec a couple of times one of the original times was maybe about three years ago here at Nana the community flowspec project and really fell flat no one really took to it then and probably for some of the reasons that you've outlined but the most the the biggest advocate who wanted to do it with me was someone who his name was on the original specification but had no network so it really helped us but I've had had two or three people since then reference that Paige asked me if I was still doing it and I told no it fell flat so and they said oh it's too bad so we've started up a new thing recently just doing a basically community rotary or black hole service and I've had about maybe I'd say five or six people who have asked for it which surprised me a little not enough for me to justify doing it one of the things that would help me I don't know if juniper does it's been a while since I've looked at it is having a little bit better control over the policy foe just to give you a contrived example someone sends a flowspec route to block port 53 on 8.8.8.8 you know perhaps by mistake but obviously affecting probably some traffic that maybe they didn't intend to so policy controls to be able to either reject or deal with certain flow spec routes that I that I get and ensure that ii don't actually pass the monks i think it's a transitive attribute to yeah I mean so as far as the policy goes I can't speak to what Cisco and Alcatel have as far as their policy engines I haven't really spent a lot of time researching that but in the Juniper engine they do have the ability to create some policy around what routes you're gonna allow in on the session just like you do with unicast routes and then obviously that's good sanitation or good best common practices if you're gonna enable BGP flowspec in your network that's something you're gonna want to spend some time thinking about sometimes testing and developing good policies around them I don't know I didn't catch who was first my name is Ron Bukowski just a question I mean the way you described in your survey about the providers who do support it or they don't support or they would accept the flowspec routes from customers or not it sounds like there's a piece missing about trust and or trust and verify like if a customer sends you a flowspec route that they say to mitigate does the provider just take that and implement it or do they check and verify that that's really a DDoS going on before they mitigate it and is there is that a mechanism that's part of what you're talking about so let me let me ask a clarification on that are you saying that they would create a policy to verify that route should be allowed or they would in fact check to make sure that a DOS attack is actively going on before they accept the route would I guess both I don't know I can't think off my top of my head of a way that they would unless they had already a traffic anomaly tool running inside of their own network being able to tell whether there was an active attack or which that route matched and validate that being interesting and interesting design I'm not I'm not aware of a way to do that obviously kind of back to John's question about the policy you can obviously create policies to validate that the route that you're receiving that customer is allowed to send you that it matches either a unicast route there that they're sending you or as part of a block that you're allowing from them assuming you have route filtering on your customers sessions either using you know a route database or manual filters however you're doing it today with your unicast customer filters I mean because if you don't if you don't verify it as the example he gave were if the customer says block 8.8.8.8 port 53 that can cause a pretty pretty huge impact on everyone it's not just one customer mitigating one customers problem it's actually causing a bigger problem oh yeah for sure I mean it's definitely I'm you know not something I mean we do flow specs not something you clearly just turn on and let it do its thing and it's magic behind the scenes and you don't you know they have any policies or sanity checking around it right clearly something that could have some policy and only allow certain routes similar to yes it's maybe even a little more than what we do with unicast but we do as a community most of us do the same thing with unicast where you don't allow routes that aren't out that are unallocated space they're part of the Bogue on space I mean there's usually on edge filters for bgp unicast routes system some and sanity check and validating of what's being sent you want to do similar things probably even a little more so for flows back routes for sure thank you hi Gary Hauser I've worked on a couple of solutions this year utilizing this feature for various customers and something that I found when I was researching was that there's very limited detailed documentation and even examples of utilizing this along with the other tools that would be required to make this a complete solution and I kind of feel like maybe it's because this is in the routing domain and really the problem is a security problem that there are missing pieces but you know and I plan on contributing the knowledge I gained over the last year to the beat cop that's currently under review but I think that's part of the problem is there's just not enough information out there and not enough general approaches to the missing pieces to say here's the problems you have to solve and here are particular ways you could solve that you know to make it a complete solution as opposed to here's flowspec it's a BGP thing good luck you know what's just kind of the approach that's been taken that's a fair point and I was talking to somebody in the hallway before the session and they were asking me about well how do you get to the point where even create the route right you somehow have to you can figure out that there is a das attack going on and what does that das attack look like right in my example I'm creating a flow spec route for DNS you know UDP port port 53 to a certain I'd Peter so how did I know that that that was what the attack vector what right so I kind of glaze over that there are some tools out there that can do those type of things for you both commercially and open-source but yeah stitching those two together and a good document whether it be a book or a white paper I agree Gary some I think needs to be done so I would I'd love to see some of the stuff that you've done in and see that get back into the end of the bcop which is another good point I was going to bring up if everybody hasn't seen the bcop stuff that I was talked about yesterday in the track around DDoS mitigation there's a number of things beyond just flow spec that are talked about in there good edge filtering and reverse path filtering and things some of the things that I alluded to in the deck that I would encourage everybody to read through and take a look at and comment on to well thank you yeah I mean even breaking it down into best practices for accepting customer flow spec and best practices for you know circulation domain of the routes and those kind of things if they came out is the larger community of this is the approach that is considered the best practice I think that you'd see much more utilization here especially now that we have three major vendors supporting FairPoint thanks hi Jason row quiche with FairPoint Communications I guess my question is around what's already been discussed here to some extent but the I look at the risks especially of extending BGP flowspec capabilities to ebgp peers and I ask kind of what the biggest security concerns would be for doing so and I think the biggest one that I came up with original it was just the case where okay they block Google DNS what I found looking at the RFC is that the in order for an ebgp flowspec route to be accepted it has to be validated against an existing unicast route from that pier so assuming the vendor implements it correctly I'm okay with that I was wondering if there are any other major security concerns that we should be considering from accepting these routes from each BGP piers if there's anything specific that would be risky other than maybe redirection communities yeah I mean I guess that maybe there's two pieces of the flow spec variety is the matching criteria you want to make sure that those matching criteria they're matching something that they have authority to match against which is a bit difficult to do but things like the validation that's built into the protocol from the in the RF seed helps with the second bate piece of course is the redirection or the filtering or the three limiting of the traffic you got to make sure that there that doesn't cause any other problems so it's you know so I think there are mechanisms out there it takes a little bit of work it's not something that's easy to just turn on and it just goes but I think it can be done the other thing I would encourage again encourage people is if you're reading about it you're finding things that are that are missing in it feed that information you know back into the in either the IETF or back into your vendor account teams when you talk to them but hey I need I need this feature or this functionality there's additional checks or these additional things to be added for this really to be useful in my network because this is the way I plan on implementing or this is these are the concerns the security screens parents that I have about it no Carlos we sent a dine I guess if I were a tier one provider my concern would be you know if I have hundreds of customers sending me you know instructions to put ACLs on my core routers that's kind of scary because of the possible performance impact any any have you heard anything on that regard well I mean I guess there's two ways I don't want say protect against that but the Brian mitigate that and one would be setting something somewhere to a max prefect specific for flowspec routes so they'd like you know only one cut each customers only allowed to send I don't know you know they're only sending you twenty routes you don't want to be able to send you hundreds of closed backdrops that would seem like overkill right so you know let's say they can send you a twenty routes maybe you said of Mack reflected by they can listen you five flowspec routes at any one time right but a bound on it that would help yeah I mean that's the only thing I can think of that would help with that but it is it is something to consider that you're allowing your customers to send you to send you flows back and there are going to be scaling limitations and every vendors architecture and knowing what those are of course is is something that's that you're gonna need to do as part of your research and as part of your testing to find out alright how many how many flowspec routes can I receive and even a layer below that of those flowspec routes so how does that translate into firewall filters or access lists whatever your vendor calls it how does that get pushed down to my forwarding plane and how does that affect my forwarding lanes performance so you can set you know limits on how much of that you're allowing to happen is it all right thanks everybody you

Channel: NANOG

Views: 13,370

Rating: 4.8878503 out of 5

Keywords: NANOG, NANOG 63, DDos, BGP Flow, Flowspec

Id: ttDUoDf6xzM

Length: 41min 4sec (2464 seconds)

Published: Wed Feb 04 2015