ICMP_SOURCEQUENCH

[Dan Lukes]

On 18 Aug 99 at 9:26, Martin Machacek wrote:

> >     Mate tedy nekdo nejake zkusenosti s provozem "za dummynetem" s nejakou
> > aplikaci, ktere by zavisela na zasilani ICMP_SOURCEQUENCH ? (To nebudou 

> S provozem za dummynetem zadne zkusenosti nemam, ale mam zkusenosti s provozem
> za Cisco routery, ktere se taktez s posilanim ICMP source quench (vetsinou)
> neobtezuji. Nezda se mi, ze by jejich absence  mela nejaky nepriznivy vliv na
> komunikaci, nicmene nemam zadne "overitelne" srovnani  s opacnou situaci. Navic

    Ona je take vetsina komunikace take TCP, ktere se s pretizenim dokaze 
vyrovnat i bez SQ

> mam takovy pocit, ze vetsina implementaci IP stejne na ICMP source quench nijak

    No, mam ne moc podlozeny pocit, ze vetsina BSD based IP stacku SQ 
pouziva - pochopitelne pouze na TCP komunikaci. U UDP to neni bez aplikace 
mozne.

> nereaguje. Do zdroju FreeBSD jsem se nedival (a momentalne na to ani nemam cas),
> ale zajimalo by me, jak jsme na tom. Reaguje IP stack ve FreeBSD nejak "sam o
> sobe" (tedy bez explicitni podpory aplikace) na ICMP source quench? Pokud ano,

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)
   

> tak aby byl system konzistentni sam se sebou mel by ICMP source quench i posilat
> (a to i pro packety zahazovane dummynetem nebo dokonce i ALTQ). Vzhledem k

    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.

> net.inet.ip.send_icmp_source_quench {0,1}
> net.inet.ip.receive_icmp_source_quench {0,1}
> 
> 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.
 
> > Mimochodem, FreeBSD ma velice daleko k tomu, aby splnovalo pozadavky, ktere 
> > RFC1812 na router klade - nestaci to ani na "conditionally compliant" a 
> > jestli ho bude potreba prizpusobit, bude to jeste pomerne hodne zmen v kodu 
> > TCP/IP stacku ...
> 
> Dalo by nejak strucne sumarizovat, co FreeBSD schazi, aby mohlo byt
> "opravdovym" routerem dle  RFC1812? Velmi by me to zajimalo.

    Uf, jsem se ctenim 1812 teprve ve dvou tretinach, ale uz mam popsano pul 
A4 - jen ji ted nemohu najit (uz se tomu zase skoro mesic nevenuji).
    Co si tak vzpominam:
    
    Zasila ICMP_SOURCEQUENCH a nema, nebo je nema limitovane.
    Vubec, pro nepodminenou shodu musi byt vsechny ICMP limitovate, FreeBSD 
zatim bezne nelimituje nic, pokud se prelozi s ICMP_BANDLIM tak jenom Port 
Unreachable.
   
     Pro nepodminenou shodu by muselo mit implementovane Security Option in 
IP (RFC1108)

    Neni implementovan Router Discovery Protocol.

    Pri routovani se nepouziva TOS, nejsou "precedence ordered" fronty, 
chyby interface pro lower layer precedence mapping (vse nutne pro 
nepodminenou shodu).    
    
Neni take uplne jasne, jestli je spravne osetreno zpracovani paketu 
se zdrojovou adresou 0.0.0.0 - RFC vyzaduje aby paket byl prijat, pokud je 
asociovan daemon, ktery TAKOVE pakety umi korektne zpracovat (napr. BOOTPD), 
jinak aby byl odmitnut - FreeBSD se ale nechova ruzne podle toho, jestli 
zrovna BOOTPD jede nebo nejede, ale podle toho jak bylo zrovna prelozeno
ccoz asi neni uplne presne to, co RFC pozaduje.

    
-----------
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.    

 =================================================================
 
 
    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 ...
Treba prijde driv IPV6 a RFC1812 bude pase ... ;-)

                                                    Dan
                                                    

    
Dan Lukes            tel: +420 2 24102474, fax: +420 2 24102301
root, postmaster (and *master) of FIONet, webmaster of KolejNET
Administrator   of    www.antispam.cz's    spammer    blacklist
AKA: dan at obluda.cz, dan at freebsd.cz, dan at kolej.mff.cuni.cz