почему source address должен быть из пула провайдера

[ayvango]

Объясните идиоту, почему он не может ставить на своих пакетиках произвольный source address. Вроде как это же не обязывает анонсировать провайдера данный адрес как свой. А просто показывает куда будет уходить ответу - и это будет другой провайдер, владелец этого самого адреса. По крайней мере после чтения Танненбаума у меня сложилось такое впечатление. Опять же помнится раньше был популярен полуспутниковый асимметричный интернет, который без подобного подхода не представим.

[Saab95]

А при полуспутниковом канале разве не надо было поднимать VPN до сервера провайдера? Интерфейс для отправки данных был у него, там же все и растекалось по направлениям.

[Ivan_83]

Приличные провайдеры следят за тем чтобы у уходящих пакетов были адреса их сетей, чтобы вирусы не спуфили во врем доса и чтобы случайно не пропустить чужой трафик. Ещё бывает всякий ошибочный и мусорный, которому на магистралях тоже нечего делать.

[woddy]

потомучто провайдеру это нафиг не надо :) нормальные абоненты (99.9% ) обойдутся своим адресом. а ненормальные - пусть платят деньги за свое желание странного.

[LionSprings]

Объясните идиоту, почему он не может ставить на своих пакетиках произвольный source address

Почему не может? Может. Ставьте на здоровье. Только провайдер их выкинет, потому что это пакетики с какого-то левого адреса, не клиентского ниразу.

 

А вопрос позабавил. "Почему при покупке в интернет магазине я не могу использовать карту и адрес человека с другого континента?"

[vIv]

Как–раз адрес и карту вполне можешь, плохой пример.

[Прохожий]

Патамушто!

 

Собственно, это совершенно исчерпывающий ответ. Спецам очевидно, а неспецам - долго и не нужно объяснять. Технически это возможно, практически это формально запрещено, но фэйковые адреса все уважающие себя люди режут.

[thodin]

А вот в сигнальных сетях на уровне SCCP не режут. Что приводит к существованию всяких разных схем..

[vIv]

Спецам очевидно, а неспецам - долго и не нужно объяснять. Технически это возможно, практически это формально запрещено, но фэйковые адреса все уважающие себя люди режут.

Ты думаешь, что китайские хостеры себя не уважают? =)

Скорее, им насрать, уважают ли их другие.

[s.lobanov]

vIv

Почему только китайские хостеры? Существует и европейские ДЦ, которые не режут ip spoof, да и вообще сейчас почти любые "Рога и КОпыта" могут прийти на какой-нибудь IX и баловаться с src_ip.

[pliskinsad]

Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета.

[AlexBT]

А вот в сигнальных сетях на уровне SCCP не режут. Что приводит к существованию всяких разных схем..

 

Не понял. Поподробней можно? Вы об ОКС7 пишите, или о чем то другом?

[DelSt]

Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета.

rpf нельзя применять в случае наличия bgp :/

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться :)

И он логично выкатит претензию своему второму аплинку

Edited March 8, 2012 by DelSt

[pliskinsad]

DelSt так точно. На магистралях нельзя, а вот конечному провайдеру нужно озаботиться такой фичей.

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться

Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей.

Edited March 8, 2012 by pliskinsad

[Savaoff]

Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета.

rpf нельзя применять в случае наличия bgp :/

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться :)

И он логично выкатит претензию своему второму аплинку

 

RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF...

[thodin]

Не понял. Поподробней можно? Вы об ОКС7 пишите, или о чем то другом?

 

Ага, я могу запустить в сеть Telia sccp пакет c cgpa из нашего российского номерного плана и ответ придет через МТТ.

На жаргоне - "треугольник".

 

Имеет большой смысл из-за различий в тарификации сигнального трафика разными операторам - транзитными, большой тройкой и т.д...

Edited March 8, 2012 by thodin

[Janus]

DelSt так точно. На магистралях нельзя, а вот конечному провайдеру нужно озаботиться такой фичей.

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться

Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей.

А что не так?

Если я ещё чёто помню, то "не вижу в бестах префикс - не принимаю с него входняк".

[DelSt]

DelSt так точно. На магистралях нельзя, а вот конечному провайдеру нужно озаботиться такой фичей.

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться

Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей.

Ну да. Предположим кастомер повесил backup-community которое понижает LP до минимального уровня.

И в таком случае rpf похерит исходящий от клиента трафик

 

RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF...

Печаль. Подпортило мнение о ретне.

 

У меня были мысли о включении rpf на юриков, но в итоге отказался от этой идеи, так ACL и висят (есс-но для тех у кого нет bgp)

Edited March 8, 2012 by DelSt

[Janus]

RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF...

ну разбирали же по полочкам...

Опять? :(

 

Его кто заставлял, имея пир с Ретном, становится клиентом его клиента? Жадность? Экономия? :)))

Напрямую подключиться было западло? :)

Всё очень просто: видишь анонсы сетки от своего даунлинка - автоматом принимаешь с этой сетки входняк. любой.

в том числе идущий на свои аплинки.

Теперь к тебе прилетает от той же сетки исходняк на твои аплинки, но через пировый порт.

В момент входа сеть трафик "теряет цвет" откуда он пришел.

Представь: пришел траф на твой аплинк с /24, которая у тебя прописана уже как валидная клиентская.

Как отличить первый траф от второго?

 

Кому-то хотелось поискать в Ретне "дырки" и решили гнать исходняк на его аплинки бесплатно - через пир.

Какое средство борьбы предложишь?

 

А так да... во всем виноват Ретн.

А "умники" такие белые и пушистые.

С такими только так и можно - на входе юрпфом по хитрой рыжей морде! :)))

 

Печаль. Подпортило мнение о ретне.

Ты не спешил бы с выводами.

Пусть тебе Савва ВСЮ историю раскажет, вместе с названием клиента.

[DelSt]

Его кто заставлял, имея пир с Ретном, становится клиентом его клиента? Жадность? Экономия? :)))

Напрямую подключиться было западло? :)

Всё очень просто: видишь анонсы сетки от своего даунлинка - автоматом принимаешь с этой сетки входняк. любой.

в том числе идущий на свои аплинки.

Теперь к тебе прилетает от той же сетки исходняк на твои аплинки, но через пировый порт.

В момент входа сеть трафик "теряет цвет" откуда он пришел.

Представь: пришел траф на твой аплинк с /24, которая у тебя прописана уже как валидная клиентская.

Как отличить первый траф от второго?

ОК, случай такой:

У RETN 2 клиента - х и у.

ООО Рога и Копыта включается в х и у.

И в какой-то момент у них сильно перекосился трафик и они на часть своих анонсов в х сунули препенд. Исходняк который прет через х подропается.

 

p.s. Кстати это одна из причин по которой я против присутствия на IX.

Edited March 8, 2012 by DelSt

[s.lobanov]

Janus

Тогда объясните почему РЕТН не пожаловался на участника, который вливал в него трафик через ix? Вычислить мак-адрес подлеца и отправить жалобу администрации IX.

[Savaoff]

Пусть тебе Савва ВСЮ историю раскажет, вместе с названием клиента.

 

Да пожалуйста. МФТИ. Дело было давно, поэтому я уже не помню, почему именно РЕТН по крайней мере часть их анонсов видел не через нас (мы были клиентами ретна, а мфти - нашим). По-моему, МФТИ тупо часть сетей нам не анонсили по каким-то своим причинам, и надо сказать - имели полное право этого не делать. В любом случае, DelSt привел достаточно примеров, когда применение rpf на BGP линках приводит к проблемам.

Edited March 8, 2012 by Savaoff

[evd]

ОК, случай такой:

У RETN 2 клиента - х и у.

ООО Рога и Копыта включается в х и у.

И в какой-то момент у них сильно перекосился трафик и они на часть своих анонсов в х сунули препенд. Исходняк который прет через х подропается.

Нифига не дропается. И никогда не дропался при наличии анонса на клиентском стыке. То, что он не best - пофиг, при включённой на Джуне опции 'urpf feasible-paths'

 

Но Janus прав, от клиента надо пропускать любой трафик. Впрочем, не совсем любой. Фейковые source ip типа приватных, то есть вообще не предполагающие ответного трафика, есть мусор, который надо давить на первом же хопе. С этим хорошо справляется urpf loose mode, которым и тирваны не брезгуют

 

p.s. Кстати это одна из причин по которой я против присутствия на IX.

Были случаи, когда клиент, отдавая на аплинковом стыке агрегат и на ix-е его морспецифики, нимало этим не смущался, будучи в полной уверенности, что это его неотъемлемое право. Но urpf - не самый убедительный способ указать такому поборнику "свободы анонсов" на его неправоту. Потому от этого средства убеждения уже очень давно отказались

[DelSt]

Нифига не дропается. И никогда не дропался при наличии анонса на клиентском стыке. То, что он не best - пофиг, при включённой на Джуне опции 'urpf feasible-paths'

Не анонсировать свои префиксы аплинку есть святое право клиента.

 

Но Janus прав, от клиента надо пропускать любой трафик. Впрочем, не совсем любой. Фейковые source ip типа приватных, то есть вообще не предполагающие ответного трафика, есть мусор, который надо давить на первом же хопе. С этим хорошо справляется urpf loose mode, которым и тирваны не брезгуют

Для клиентов без bgp я ACL'ем убиваю трафик сорс-адрес которого не из диапазона клиента - об этом и тема.

 

Были случаи, когда клиент, отдавая на аплинковом стыке агрегат и на ix-е его морспецифики, нимало этим не смущался, будучи в полной уверенности, что это его неотъемлемое право. Но urpf - не самый убедительный способ указать такому поборнику "свободы анонсов" на его неправоту. Потому от этого средства убеждения уже очень давно отказались

Такой трафик надо дропать однозначно :) А как теперь боритесь с этим?

[evd]

Janus

Тогда объясните почему РЕТН не пожаловался на участника, который вливал в него трафик через ix? Вычислить мак-адрес подлеца и отправить жалобу администрации IX.

Администрация IX не является третейским судьей в спорах его members на предмет routing policy. Принимать какие бы то ни было меры в отношении "виновного" у него нет никаких прав. Да и технических средств доказать его "неправоту" у IX-а нет