[195976] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Settle Free Peering - Default Route Abuse Monitoring

daemon@ATHENA.MIT.EDU (Raymond Beaudoin)
Sun Sep 24 20:22:05 2017

X-Original-To: nanog@nanog.org
In-Reply-To: <CACWOCC9pFo1As-RvHiA5b0TuN6+HXptuVknQpbpHWB7X2b9CzA@mail.gmail.com>
From: Raymond Beaudoin <raymond.beaudoin@icarustech.com>
Date: Sun, 24 Sep 2017 19:21:40 -0500
To: Job Snijders <job@ntt.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

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
> =E2=80=9Cunexpected traffic flows=E2=80=9D 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=E2=80=99t 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=E2=80=99=
t have a
> BGP session.
>
> Kind regards,
>
> Job
>

home help back first fref pref prev next nref lref last post