ICMP_SOURCEQUENCH

[Martin Machacek]

On 19-Aug-99 Dan Lukes wrote:
> Ano, sys/neinet/tcp_subr.c :
> /* When a source quench is received, close congestion window
>  * to one segment.  We will gradually open it again as we proceed. */
> void
> tcp_quench(inp, errno)

Hmm, tak to vypada, ze SQ se opravdu pouziva ... (jeste ze to filtruju na
routerech :-))

>     I ja se priklanim k tomuto vykladu. Jedinou vyjimkou jsou pakety 
> zahazovane "nahodnym vyberem" pokud je dummynet nakonfigurovan na simulaci 
> vadne linku a ztrate paketu na ni.

S tim bych souhlasil.

>> Jinak systemy reagujici na ICMP source quench jsou (IMHO) ohrozene denial of
>> service utoky, prostrednictvnim zasilani falesnych notifikaci.
> 
>     To v kazdem pripade, takze je nutne maximalni rychlost jejich generovani 
> omezit. Momentalne (3.2-RELEASE) to limitovane neni.

No, ono nejde jen o omezeni generovani SQ, ale i o to,z e kdyz mi nekdo bude
dostatecne dlouho posilat SQ s falesnymi informacemi, tak me muze zpomalit nebo
mozna zcela zamezit v komunikaci se sitemi lezicimi za podvrhovanou adresou.
moje stroje si budou myslet, ze je tam precpana linka, zavrou congestion
window, a komunikace bude hooodne pomala.

>      Pro nepodminenou shodu by muselo mit implementovane Security Option in 
> IP (RFC1108)

Hmm, to je mozna uz trochu prekonane a ve skutecnosti se to nikdy nepouzivalo k
puvodnimu ucelu.

>     Neni implementovan Router Discovery Protocol.

Ten asi malokomu schazi.

>     Pri routovani se nepouziva TOS, nejsou "precedence ordered" fronty, 
> chyby interface pro lower layer precedence mapping (vse nutne pro 
> nepodminenou shodu).

Hmm, to je zajimavejsi ...

> Obecne je na tom FreeBSD pomerne mizerne co se tyce source-routovanych 
> paketu:    
> 
>     Pokud vznika ICMP na zaklade source-routovaneho paketu, vznikle ICMP 
> musi byt take source-routovano (reverznim smerem). Totez plati pro 
> ICCMP_*REPLY  zpravy, pokud jsou implementovany.
> 
>     Source-routovany paket s jeste nevycerpanym seznamem adres s "moji" 
> vlastni adresou jako cilovou by musi byt forwardovan dale a neni.
> 
>     FreeBSD nedetekuje nasobny vyskyt source-routing option.

Zase, pro normalni pouziti to urceite nevadi, protoze neznam jediny "rozumny"
duvod, proc by se sourceroutovane packety mely vubec nejak zpracovavat.

>     Aby nedoslo k omylu - tohle jsou zatim jen nektere moje poznamky jak jsem
> s RFC1812 v ruce prochazel zdrojaky - u nekterych veci se tedy ve 
> skutecnosti muze ukazat, ze jsou implementovany spravne. A urcite to neni 
> jeste vsechno. Takze pokud se nekdy RFC1812 stane standardem, bude to 
> potreba ponekud prekopat. Ale zatim bych se do toho moc nehnal ...

Jasne. Diky moc za informace. Je jasny, ze lectere schazejici vlastnosti nejsou
pro drtivou vetsinu aplikaci potrebne a  nektere jsou jiz zcela prekonane. Zda
se, ze i RFC1812 je alespon zcasti out-of-date.

> Treba prijde driv IPV6 a RFC1812 bude pase ... ;-)

Ze by RFC1812 bylo nahrazeno necim aktualnejsim, to je pravdepodobne, domnivam
se vsak, ze IPv6 se v globalnim meritku hned tak nedockame. Letos na Usenix
Technical Conference byl na toto tema docela zajimavy prispevek. Zda se, ze
jedina cast sveta, ktera by IPv6 potrebovala ted hned, je Asie. Rychly rozvoj
Internetu napr. v Indii zpusobuje, ze nekteri "IP provideri" v teto oblasti
disponuji prave 1 (slovy jednou!) IP adresou. Ostatni "zajimave" vlastnosti IPv6
se postupne backportuji do IPv4 (napr. IPsec). Odhad globalnejsiho rozsireni
IPv6 byl (jak uz tomu cca. posledni 2 roky byva) 2-3 roky :-). Ale to jsem
uz dost off-topic ...


        Martin 

---
[PGP KeyID F3F409C4]