This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] Defining routing abuse
- Previous message (by thread): [anti-abuse-wg] Defining routing abuse
- Next message (by thread): [anti-abuse-wg] Defining routing abuse
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrey Korolyov
andrey at xdel.ru
Sat Apr 13 17:10:09 CEST 2019
> > But, anyway, it is a hijack by perception: the LIR managing the > prefixes didn't authorize the split announcement. Also, frankly, it's > not really clear if it's an optimizer just *leaking* or that's on > purpose. > Has this route split (not including 25s) been visible globally? Hijacks or simular behavior happening only in scope of certain IXP are undoubtfully problematic in terms of automated issue escalation as IXP members probably had some sort of agreement on traffic engineering and whatever else being used within a limited scope. The 2019-03 is not about having a purpose or not and I highly doubt that it will be possible to define legal matters for hijacks with limited visibility scope as no trusted parties could observe it at a time. Covering all possible misuses of a global routing table certainly seems possible when we are describing global leaks, because everything else is a matter of trusted route propagation and not the application of a policy where trusted actors not always be able detect the problem at all. tl;dr - don't try to fix all possible leak scenarios with the policy, consider only ones been globally (a bad term, yeah) visible where space owner has a complaint against the leak -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20190413/a224ed52/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Defining routing abuse
- Next message (by thread): [anti-abuse-wg] Defining routing abuse
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]