Re: traceroute

Autor: Mariusz Krukowski <kruk_at_no.spam.pl>
Data: Tue 23 Nov 2004 - 10:04:41 MET
Message-ID: <cnuufa$n63$1@news2.ipartners.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

Marek Moskal wrote:
> Piotr KUCHARSKI napisal(a) [22 Nov 2004]:
>
>
>>>>A taka telia/tpsa nie powinna tego wycinac? Czy moze byłoby to zbyt
>>>>'meczace' dla routerow?
>>
>>Jeżeli ma klientów końcowych, to oczywiście. W tranzycie sensu nie ma.
>
>
> W pewnej mierze ma - nawet w przypadku tranzytu operator powinien MBSZ
> wycinac na brzegu pakiety z niewlasciwymi adresami zrodlowymi, np. z sieci
> prywatnych czy tez z wlasnej sieci operatora (!). Taka odrobina higieny.
>
> PS: dla kompletnosci dyskusji - mechanizm do tego sluzacy na "duzych"
> routerach nazywa sie "unicast Reverse Path Forwarding check" (uRPF) i jego
> dwie podstawowe odmiany to tryb "strict" (dla laczy do klientow koncowych,
> weryfikacja czy adres zrodlowy ma w tablicy routingu trase wskazujaca na
> interfejs z ktorego taki pakiet przyszedl) albo "loose" (dla ruchu
> tranzytowego lub pochodzacego od klientow typu multi-home, weryfikacja czy
> trasa do adresu zrodlowego w ogole jest w tablicu routingu). Pozwala to
> "wyczyscic" to, co sie wpuszcza do wlasnego szkieletu.

To wszystko pięknie Marku, ale w teorii. W praktyce zaraz wychodzą różne
"kwiatki". A to w tablicach BGP (nawet tych od najwiekszych światowych
operatorów) nie pojawia się komplet informacji o wszystkich używanych
sieciach, a to zdażają się nieprzewidziane, hmmm, trudności ze sprzętem.
Żeby daleko nie szukać: np. włączenie uRPF na karcie STM-16 na GSR
wyłącza obsługę NetFlow (niezbędny z kolei do wykrywania ataków DoS) :-(
Received on Tue Nov 23 10:05:21 2004

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Tue 23 Nov 2004 - 10:40:05 MET