Re: [NLNOG] atom86: invalid==reject (RPKI)
Hallo Robert, filteren jullie alleen invalid prefixes die binnenkomen "vanaf het Internet", of ook van jullie klanten? Groet, Paul Hoogsteder Meanie AS31019
Beste NLNOG-ers,
Circa drie weken geleden heeft atom86 invalid==reject (RPKI) geïmplementeerd op haar peers en upstreams.
Mijn gewaardeerde collega Ralph Dirkse heeft hier een niet te technisch artikel voor gemaakt en op LinkedIn geplaatst: https://www.linkedin.com/pulse/atom86-leveraging-rpki-make-internet-safer-pl...
We vertrouwen erop dat velen ons zullen volgen om het internet een veiligere plek te maken ;)
Mvg,
Robert Heuvel atom86
+31 624590510 +31 207506500 Boeing Avenue 271 1119 PD Schiphol-Rijk
_______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
Hoi Paul, Voor klanten filteren we middels een prefix filter dus valideren is dan eigenlijk niet nodig. Toch valideren we klant prefixes wel echter zonder de reject. Mvg, Ralph On 04/09/2018, 13:46, "NLNOG on behalf of Paul Hoogsteder" <nlnog-bounces@nlnog.net on behalf of nlnog@meanie.nl> wrote: Hallo Robert, filteren jullie alleen invalid prefixes die binnenkomen "vanaf het Internet", of ook van jullie klanten? Groet, Paul Hoogsteder Meanie AS31019 > Beste NLNOG-ers, > > Circa drie weken geleden heeft atom86 invalid==reject (RPKI) > geïmplementeerd op haar peers en upstreams. > > Mijn gewaardeerde collega Ralph Dirkse heeft hier een niet te technisch artikel voor gemaakt en op LinkedIn geplaatst: > https://www.linkedin.com/pulse/atom86-leveraging-rpki-make-internet-safer-pl... > > We vertrouwen erop dat velen ons zullen volgen om het internet een veiligere plek te maken ;) > > Mvg, > > Robert Heuvel > atom86 > > +31 624590510 > +31 207506500 > Boeing Avenue 271 > 1119 PD Schiphol-Rijk > > _______________________________________________ > NLNOG mailing list > NLNOG@nlnog.net > http://mailman.nlnog.net/listinfo/nlnog > _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
Beste Ralph, On Tue, Sep 04, 2018 at 11:47:42AM +0000, Ralph Dirkse wrote:
Voor klanten filteren we middels een prefix filter dus valideren is dan eigenlijk niet nodig. Toch valideren we klant prefixes wel echter zonder de reject.
Ik raad aan om op alle EBGP sessies "invalid == reject" te doen, ook op klant sessies. Ik denk dat dit makkelijker is voor zowel jullie als de klanten. Een prefix kan zowel onderdeel zijn van het prefix-filter, maar tegelijk een RPKI invalid zijn (omdat het origin niet klopt). Mogelijk heeft een klant een prefix verkocht, of op een andere manier de autoriteit verloren om de prefix te announcen - de echte eigenaar van de prefix hoeft dan enkel de RPKI ROAs te updaten om zaken naar hun hand te zetten. Met vriendelijke groeten, Job
Job, Ik ben het met je eens, we valideren de routes wel maar rejecten ze (nog) niet. Gr, Ralph On 04/09/2018, 14:03, "Job Snijders" <job@ntt.net> wrote: Beste Ralph, On Tue, Sep 04, 2018 at 11:47:42AM +0000, Ralph Dirkse wrote: > Voor klanten filteren we middels een prefix filter dus valideren is > dan eigenlijk niet nodig. Toch valideren we klant prefixes wel echter > zonder de reject. Ik raad aan om op alle EBGP sessies "invalid == reject" te doen, ook op klant sessies. Ik denk dat dit makkelijker is voor zowel jullie als de klanten. Een prefix kan zowel onderdeel zijn van het prefix-filter, maar tegelijk een RPKI invalid zijn (omdat het origin niet klopt). Mogelijk heeft een klant een prefix verkocht, of op een andere manier de autoriteit verloren om de prefix te announcen - de echte eigenaar van de prefix hoeft dan enkel de RPKI ROAs te updaten om zaken naar hun hand te zetten. Met vriendelijke groeten, Job
Beste Ralph, 2018-09-04 14:06 GMT+02:00 Ralph Dirkse <rdirkse@atom86.net>:
Ik ben het met je eens, we valideren de routes wel maar rejecten ze (nog) niet.
En wat ook mee speelt, zodra meer netwerken RPKI doen, is dat de de ervaring voor klanten consistenter is wanneer een transit provider dezelfde announcements reject als de peers/upstreams van de transit provider. Door in de hele keten van ASN naar ASN onder dezelfde voorwaarden te rejecten is het speelveld voor iedereen gelijk :-) Wel zie ik voor me dat mensen misschien dankzij een speciale BGP community een invalid more-specific kunnen announcen (maar die qua origin wel valid is), waar dan automatisch NO_EXPORT op gezet word en als specifiek doel heeft traffic-engineering te faciliteren als er meerdere uplinks zijn tussen provider en de downstream. Met vriendelijke groeten, Job
participants (3)
-
Job Snijders -
Paul Hoogsteder -
Ralph Dirkse