MT
Уже есть первая информация, почему они не сделали аннонс /24.
RPKI ;)
RPKI ;)
Size: a a a
2019 June 24
MT
Испугались возможных глюков, или долго было публиковать изменения и ждать вступления их в силу - не знаю
AZ
Ну им могло непредсказуемо трафик перекосить, думаю.
AZ
Конкретно здесь он бы не помог. Это полная ответственность ликера внедрить его у себя везде на границе, чтобы лика не допустить. А ответственность Verizonа все еще остается, причем в данном случае даже большая, чем у допустившего лик оператора.
Альтернативные драфты (пускай будет https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/) тоже под вопросом, потому что если ты анонсишь more specificи в своего клиента, наверное тебе не до best practice.
ASPA, как это ни странно, тоже мимо, потому что если Verizon пофиг на фильтры со стороны клиентов, то фильтровать больше некому и все это уже радостно распространится как минимум на весь его Customer Cone.
Альтернативные драфты (пускай будет https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/) тоже под вопросом, потому что если ты анонсишь more specificи в своего клиента, наверное тебе не до best practice.
ASPA, как это ни странно, тоже мимо, потому что если Verizon пофиг на фильтры со стороны клиентов, то фильтровать больше некому и все это уже радостно распространится как минимум на весь его Customer Cone.
Ну как не помогло бы. Суть же этого всего и в том, чтобы это было проще делать или вообще изкаробки. Да, это тоже надо настраивать. Но больше шансов, что ликер настроил бы типы пиров, чем правильные фильтры как надо. И aspa для веризона тоже может оказаться хорошим компромисом, если они не хотят с клиентскими фильтрами возиться.
EB
Ну как не помогло бы. Суть же этого всего и в том, чтобы это было проще делать или вообще изкаробки. Да, это тоже надо настраивать. Но больше шансов, что ликер настроил бы типы пиров, чем правильные фильтры как надо. И aspa для веризона тоже может оказаться хорошим компромисом, если они не хотят с клиентскими фильтрами возиться.
ASPA для Веризона - если они только согласятся фильтровать на ее базе. Но да, это все равно проще и достовернее (по крайней мере в будущем), чем префиксные фильтры.
Open Policy - скорее я говорил в контексте обнаружения таких проблем третьей стороной, где она становится бесполезной (для тех же принимающих лик). Но для самого ликера да, это проще и с меньшей вероятностью ошибок, чем настраивать свои собственные комьюнити и полиси.
Open Policy - скорее я говорил в контексте обнаружения таких проблем третьей стороной, где она становится бесполезной (для тех же принимающих лик). Но для самого ликера да, это проще и с меньшей вероятностью ошибок, чем настраивать свои собственные комьюнити и полиси.
AZ
Да, эти механизмы, конечно, тут требовали бы содействия от участвующих сторон.
2019 June 25
AS
Конкретно здесь он бы не помог. Это полная ответственность ликера внедрить его у себя везде на границе, чтобы лика не допустить. А ответственность Verizonа все еще остается, причем в данном случае даже большая, чем у допустившего лик оператора.
Альтернативные драфты (пускай будет https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/) тоже под вопросом, потому что если ты анонсишь more specificи в своего клиента, наверное тебе не до best practice.
ASPA, как это ни странно, тоже мимо, потому что если Verizon пофиг на фильтры со стороны клиентов, то фильтровать больше некому и все это уже радостно распространится как минимум на весь его Customer Cone.
Альтернативные драфты (пускай будет https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/) тоже под вопросом, потому что если ты анонсишь more specificи в своего клиента, наверное тебе не до best practice.
ASPA, как это ни странно, тоже мимо, потому что если Verizon пофиг на фильтры со стороны клиентов, то фильтровать больше некому и все это уже радостно распространится как минимум на весь его Customer Cone.
КМК, ASPA с большей вероятностью бы помогло. В том смысле, что фильтрация клиентских префиксов требует больше телодвижений, а ASPA будет работать почти искаропки. Соответственно, шансов на её внедрение больше.
AS
Ну, в предположении, что появятся простые верификаторы. Но они появятся, никуда не денутся.
O
Друзья, а каким сервисом можно глянуть историю анонса подсети в определенный период? В нормальном читаемом виде, что б как доказательство можно было бы приложить. Ripe stats даёт сложно читаемую выборку для человека не в теме.
Хы-хы.
У меня в деле пытались приплести статистику с ripe stat как доказательство. Но только по факту префикс не анонсируется год как, а часть ris-ов его до сих пор видит.
Так что доказательства такие так себе.
У меня в деле пытались приплести статистику с ripe stat как доказательство. Но только по факту префикс не анонсируется год как, а часть ris-ов его до сих пор видит.
Так что доказательства такие так себе.
А
Хы-хы.
У меня в деле пытались приплести статистику с ripe stat как доказательство. Но только по факту префикс не анонсируется год как, а часть ris-ов его до сих пор видит.
Так что доказательства такие так себе.
У меня в деле пытались приплести статистику с ripe stat как доказательство. Но только по факту префикс не анонсируется год как, а часть ris-ов его до сих пор видит.
Так что доказательства такие так себе.
Если видит, то значит анонсируется. Это вы год назад, возможно, роут-объект из RIPEDB удалили. Что не мешает кому-то анонсировать вашу сеть.
O
Если @semenyaka не против, могу письмо от ncc по этому поводу выложить.
А
Если @semenyaka не против, могу письмо от ncc по этому поводу выложить.
А почему он может быть против?