[Nlnog] IP header & TTL modificatie door bridges

[Boudewijn Visser]

>>> = AvdO
>>  = BV
>   = AvdO
    = BV
>
>

[geen knips deze keer, aangezien deze reply van Arjan de lijst niet
haalde, maar er wel voor bedoeld was]


>> [knip wireless bridge, speelt met DSCP en doet ook TTL decrement]
> -snip-
>> Mee eens, dwz, ik vind het wel TTL decrementen, en dan niet sturen van
>> unreachables ook verkeerd gedrag, en kan er niet echt een argument voor
>> verzinnen waarom je het zou willen.
>> Het enige wat me nu voor de geest komt is dat de * * * in de traceroute
>> een indicatie geeft dat het pad tussen twee hops "bijzonder" is
>> [radio<->ethernet] en geen gewone PtP of ether segment.
>
> Wat Steven ook al zei ja, dat was mijn argument ook. De reden dat het
> kreng geen unreachables stuurt is me ook nog vaag, maar zit
> waarschijnlijk in de hoek van a) het is een semi laag-twee device dus
> waarom ICMP's sturen in de dataplane of b) we hebben in de
> controlplane voor het gemak OOK maar alle binnenkomende ICMP's
> dichtgezet, want dat is zo lekker veilig... (must resist.....)
>
>> (of je er wat mee kunt, een aantal opinies pro of con van nlnog, is iets
>> anders..).
>
> Het geeft in ieder geval een indicatie of mijn mening al dan niet het
> stempel 'absurd' verdient.
>
> *cue voor-de-hand-liggende-inkoppertjes*

Ik ben nooit vies van makkelijke inkoppertjes, maar dit is t? :-)

>
>> Feitelijk is laag-3 manipulatie door een laag-2 device al een beetje
>> verdacht, maar er zijn genoeg situaties waar het nodig of handig is,
>> zoals
>> wanneer het voor de hand liggende L3 device om technische of
>> organistorische redenen niet zelf de L3 manipulaties kan doen.
>
> Sja, het hele device is uberhaupt al een beetje een gek ding, maar het
> gaat te ver om alle design issues hier te bespreken. Neem van me aan
> dat er al meer dingen zijn waar enkele wenkbrauwen over opgetrokken
> zijn. Maar het ding wordt in eerste instantie als laag-2 beestje
> neergezet door $vendor en in mijn optiek is het dat ook. Ware het niet
> dat het dus op een paar punten laag-3 aware is en daar op wederom een
> paar punten ook op kan acteren, zoals het beschreven DSCP verhaal, wat
> laag-3 filtering, etc. Maar qua IP forwarding is het ding gewoon geen
> laag-3 device en in mijn optiek moet je dan uberhaupt van de TTL
> afblijven. Wat mij dwarsboomt in die stelling is RFC791 die dus gewoon
> simpel zegt : in IP rommelen = TTL verlagen. Gevalletje vlees noch
> vis.
>
>> Als de bridge wel icmp unreachables moet sturen is de vraag natuurlijk
>> met
>> welk ip adres.
>
> Dat is dus de grap, het ding heeft maar *een* IP adres, in de control
> plane, in een heel ander subnet (en in de uiteindelijke setup ook in
> een heel ander vlan).

En dat is natuurlijk om allerlei redenen onzin of zinloos om te gebruiken,
als icmp source.
(Want de kans is heel groot dat zo'n adres er toch niet door komt, om
allerlei redenen. Hoe beter je netwerk in elkaar zit, des te kleiner die
kans)

>
>> Een redelijke keuze zou het IP adres van het upstream (qua
>> richting van het ontvangen verkeer) device zijn, maar dat kan natuurlijk
>> verwarring geven nadat de volgende hop (dat upstream device) dan
>> hetzelfde
>> antwoord geeft.
>
> Hmm, unreachables sturen met een IP adres dat niet aan jou toebehoort?
> Dat lijkt me niet wenselijk.

Normaal niet, maar _als_ je hier iets moet sturen, is dit beter dan het
mgmt adres. En al helemaal als dat mgmt ip in een veilige, gefilterde,
rfc1918 etc etc reeks zit.
Een firewall die reject ipv dropt doet niets anders, een rst terug sturen
met als source het adres van de bedoelde destination.
Weet niet zeker wat een fw doet als hij icmp terug moet sturen; port
unreachable van de destination of admin prohibited van zichzelf.
Maar een firewall in een L2 setup heeft weinig keus, die moet ook alles
"spoofen" aan rejects.
Nu maakt de gemiddelde fw admin het v???l veiliger door drop ipv reject te
kiezen, en is het voor hen uberhaupt geen vraag, maar dat is weer een
andere discussie.


>
>> Anyway, in dit geval is dus geen TTL decrement m.i. de betere keuze.
>> (wel zou het ding spanning-tree moeten [kunnen] doen... ).
>
> Waarom? In de onderhavige setup is daar totaal geen noodzaak voor noch
> is het wenselijk.

Ok, ik ken die setup niet. Maar als ik L2 bridge hoor, dan denk ik aan
"moet loopfree zijn", met als extra reminder de context van TTL decrement,
die op L3 loopend verkeer uiteindelijk moet stoppen.
Maar inderdaad, in een pure PtP setup is het niet nodig.

Boudewijn


>
> Arjan
>