Settle Free Peering - Default Route Abuse Monitoring
Hello, Everyone! Many SFP agreements include terms that the peering link will not be used as an upstream with static defaults. A few examples are provided below. *h. must agree not to abuse the peering relationship by engaging in activities such as but not limited to: pointing a default route at the other or otherwise forwarding traffic for destinations not explicitly advertised, resetting next-hop, selling or giving next-hop to others;* Source: http://www.level3.com/en/legal/ip-traffic-exchange-policy/ *2.6. Neither Network shall point default into or transit the other Network where that network has* *not advertised a route for the destination in question.* Source: http://www.zayo.com/wp-content/uploads/2017/02/ZayoPeeringPolicy.pdf How is this monitored and tracked? Are ACLs applied to help enforce this (seems to be limited at scale)? Flow export and alarming? Analytics and anomalous behavior detection? Common professional courtesy? Thanks so much for any insight you may have. I'd like to ensure I'm following all best practices when in IX and peer situations. -Raymond Beaudoin
Dear Raymond, On Sun, 24 Sep 2017 at 21:33, Raymond Beaudoin < raymond.beaudoin@icarustech.com> wrote:
How is this monitored and tracked? Are ACLs applied to help enforce this (seems to be limited at scale)? Flow export and alarming? Analytics and anomalous behavior detection? Common professional courtesy?
This RFC https://tools.ietf.org/html/rfc7789 covers the topic of “unexpected traffic flows” which is essentially the same as having default being pointed at you without you permission. May be worth reading! A most scalable option is to use a flow collection / monitoring program like pmacct (http://pmacct.net/) to inspect flows and flag the ones that shouldn’t exist according to your policy. Paolo Lucente has done excellent work to make this problem space manageable: http://wiki.pmacct.net/DetectingRoutingViolations Also, if you are at an internet exchange, make sure to enable MAC accounting (if available) on the IX facing interface, so you can easily monitor for traffic coming from MAC addresses with which you don’t have a BGP session. Kind regards, Job
Job, Thanks so much for the helpful information, especially the RFC. This is exactly what I was looking for. Have a fantastic week! Warm Regards, Raymond Beaudoin On Sun, Sep 24, 2017 at 3:05 PM, Job Snijders <job@ntt.net> wrote:
Dear Raymond,
On Sun, 24 Sep 2017 at 21:33, Raymond Beaudoin < raymond.beaudoin@icarustech.com> wrote:
How is this monitored and tracked? Are ACLs applied to help enforce this (seems to be limited at scale)? Flow export and alarming? Analytics and anomalous behavior detection? Common professional courtesy?
This RFC https://tools.ietf.org/html/rfc7789 covers the topic of “unexpected traffic flows” which is essentially the same as having default being pointed at you without you permission. May be worth reading!
A most scalable option is to use a flow collection / monitoring program like pmacct (http://pmacct.net/) to inspect flows and flag the ones that shouldn’t exist according to your policy. Paolo Lucente has done excellent work to make this problem space manageable: http://wiki.pmacct.net/ DetectingRoutingViolations
Also, if you are at an internet exchange, make sure to enable MAC accounting (if available) on the IX facing interface, so you can easily monitor for traffic coming from MAC addresses with which you don’t have a BGP session.
Kind regards,
Job
participants (2)
-
Job Snijders -
Raymond Beaudoin