06-14-2011 06:57 PM
I am just being introduced into Juniper automation and have a general question on XSLT/SLAX capabilities. I am not sure if this is the right tool for what I am after (and I don't believe what I am looking for is built into Junos).
Only accept traffic on an interface if the ingress traffic on said interface is destined to a prefix that is included in the current RIB-out on said interface's BGP session. Assume that the interface is a point-to-point interface where you will only have a single BGP session and that the BGP session is established over the directly connected interface (no multihop). In other words, if I didn't tell you about routes x, y, and z you shouldn't be sending traffic to me destined to x, y, and z.
The idea here is to protect a network from being misused as a transit network (you really can't prevent someone from pointing their default towards you). uRPF is not going to work here, don't care what their source address is - assume I'll always have a route for their source address and asymmetric routing may be occurring.
How I envision it:
Some how parse the RIB-out for each neighbor (or group), create a list of prefixes sent to neighbor (RIB-out), call said list of prefixes in a firewall filter that is applied ingress on interface that drops traffic destined towards said list of prefixes.
How do others protect from this?
I guess the real question is, how do folks protect their networks from being misused for transit? There are a couple other ideas that are being considered but they are all overly complex for what should be a pretty straight forward solution.
Thanks for reading, any help is greatly appreciated!
06-15-2011 12:33 AM - edited 06-15-2011 12:34 AM
first of all I'd like to suggest you to have a look at this book, it explains well what you can do using Junoscript and how to do it!
As for your question, it is certainly possible to implement such a filtering via junoscript, the way you described; you can use a commit script (explained in the third part of the above-mentioned book) which, at the time of each commit, will read the prefix list announced to the bgp peer, and will copy this list in a firewall filter applied on the ingress interface, in order to discard (or reject) any packet destined to a subnet that you are not announcing.
Having said that, I'm not sure about other ways to accomplish this, probably if you notice that your AS is being misused as a transit path you can contact the network administrator of the peer AS, and ask him to check the way traffic exits its network...
06-15-2011 06:47 AM
Thanks for the reply! I will defiantly check the book. You describe that a commit would have to occur for the firewall filter prefix list based on RIB-Out to be updated. Is there a way to dynamically do this? Preferably in real time as RIB-Out is modified? Somehow signal the script that RIB-Out has changed causing the script to redo its magic? If 'real-time' is not possible, does the possibility exist for running this script every couple of seconds? If so, what kind of hit of resources (CPU, mem, ...) should one expect? That last question is not really clear. Would there be any CPU or memory issues with running a script every second? Thank.
06-15-2011 07:46 AM
As for the "real-time" triggering of the script, I think a commit script is a good option; in fact, whenever you change the advertised prefixes, editing the bgp export policy, you have to issue a commit.
This will trigger the script, which will go through your candidate configuration, and, in case it finds a change in the bgp export policies, it will update the firewall filter consistently in the candidate configuration. Then it will complete the commit process, so the firewall filter update happens at exactly the same time as the rib-out change.
You could also schedule an event-script to run each X minutes, and update the firewall filter, but I think this option does not have any advantage, on the contrary (as you wrote) will have a greater impact on system resources.
Let me know if I understood your questions correctly!
06-15-2011 01:04 PM
The decision of which prefixes are to be sent to a neighbor will be made by BGP community tags, we won't be defining prefix lists (in this case). So, the contents of RIB-Out per neighbor (or group) is a bit more dynamic in the sense that we won't necessary be making config changes on the box that is applying the inbound firewall filter. This is why I was asking about somehow signaling the script automatically when the RIB-Out changes. This would make it "real-time". Appolgoies for not mentioning this before. If signaling is not possible, the only other option I can think of is running the script every so often (as often as possible w/o adversely affecting router/control plane performance while at the same time inadvertently blockholing traffic b/c the firewall filter does not contain an updated copy of the RIB-Out prefixes). Here is an example of the scripts application:
Router A in ASN 1 is going to advertise routes/prefixes/NLRIs that have their BGP community tag set to 1:123 to Router B in ASN 2. Router A wants to apply a firewall filter ingress on the interface that interconnects itself to Router B and only accept packets that are destined to prefixes that were advertised to Router B.
In the above example, another router in ASN 1, lets say Router X, adds and removes the BGP community tag of 1:123 to various prefixes throughout the day. This would cause in turn Router A to advertise/withdraw various prefixes throughout the day to Router B while at the same time updating its magical firewall filter.
BTW, thanks again for taking the time to read through this crazy idea. It really is appreciated!
07-06-2011 10:35 AM - edited 07-06-2011 10:37 AM
As far as I can see, the problem here is how to react to a bgp update message... I did check the bgp related events but I could not find anything useful...
So maybe you could try to use a time-based event in order to launch the script every X minutes; the script will have to parse the output of "show route advertising-protocol bgp" command, to compare the result with the firewall filter configuration and if needed, change the FF.
Anyway, I'm not sure this is a suitable approach, for the reason you mentioned (tradeoff between performances and the problem of inadvertently dropping "legitimate" traffic).
Having said that, I am not sure wheter you have control of Router X (which changes the community tag); if this is the case, you could use an external server to coordinate Router A and Router X, this way:
- Router X changes a community tag;
- A commit script running on router X somehow notifies the external server that the bgp community tag has been changed;
- The server updates (through another script) the firewall filter configured of Router A according to the change of the community tag.