A projekt kapcsán az a döntés született, hogy az implementációk
konformancia tesztjét a TAHI teszt környezet segítségével teszteljük. A
PKI egy másik mérési eljárást fejlesztett ki, amely a Sun Microsystems által
kifejlesztett Packet Shell-en [SUNPKTSHELL] alapul. A sikeres TAHI tesztelés érdekében
több installációs és konfigurációs lépést kellett végrehajtani mindkét
operációs rendszer esetében. Ezeket röviden felsoroljuk, majd összefoglaljuk
a tesztek eredményeit. A tesztek részletes eredményei a http://tipster6.ik.bme.hu/tahi_tests/
címen érhetőek el.
A PKI tesztelésének eredményei a következő címen érhetőek el:
A tesztelés angolnyelvű összefoglalója elérhető:
A sikeres tesztelés érdekében egy frissen installált AIX 4.3.3-es
rendszer teleítése történt. A teszteléshez a tesztelő rendszert ki kellett
egészíteni AIX specifikus parancsok támogatásával ezeket a változtatásokat
elküldtük a TAHI fejlesztőinek és rendelkezésre állnak a tesztelési
oldalon is.
Az AIX 4.3.3-as operációs rendszer tartalmazza az IPv6-os támogatást,
amelyet az installálás során egyszerűen ki lehet választani, majd későbbiekben
a SMIT konzollal konfigurálni is lehet. Az IPSec támogatás is beépített, de
ezt nem teszteltük.
A TAHI teszteléshez a AIX-os gépet ún. nullmodem kábellel a soros porton
keresztül össze kell kötni a tesztelő géppel. Ahhoz hogy a tesztelő gép
be tudjon lépni az AIX-os gépre az AIX-on a csatlakoztatott soros porton engedélyezni
kell a belépést és a root felhasználónak is a belépését. Ezen túlmenően
az Ethernet interfészen le kellett tiltani a a sebesség megbeszélést
(autonegotiation), mivel csak egy egyszerű cross-link ethernet kábellel
csatlakoztattuk a két gépet egymáshoz
A tesztelések indítása előtt a TAHI leírásának megfelelően szükséges,
hogy a default route-ot és a DNS címfeloldást letiltsuk.
Az IPv6 specifikációjának tesztjében kisebb hiányosságok mutatkoznak.
Az AIX nem kezeli a szabványnak megfelelően a hibás következő fejléceket:
15, 22, 30-es teszt. Parameter invalid ICMP üzenet helyett elfogadja a
csomagokat. Nem kezeli tökéletesen 65536 méretű csomagokat (42) valamint a
csomagok sorrendhelyes kezelése (52, 57) és a hibás fregmes méret kezelése
sem helyes (56). Az ICMPv6 specifikációknak való megfelelésben több hiba is
található. Ezek a hibák elsősorban a link-local címeknél jelentkeznek, de
mindenféle ICMPv6 paraméter hibák kezelése elég gyenge. Az alapvető
funkcionalitás ICMPv6 echo, destination unreachable mindazonáltal jól működik.
Az implementációk robusztusságának a tesztjei hibátlanul lefutottak.
A Neighbor Discovery tesztelése megmutatta, hogy az általunk vizsgált AIX
:
- szinte éppen hogy teljesíti a kívánalmakat. Képes router solicitation
(RS) üzeneteket küldeni fogadni, azonban Neighbor Solicitation (NS)
csomagokat nem küld, csak a legszükségesebb esetekben. Több esetben a
Neighbour discovery cachet a beérkező csomagok alapján kitölti így nem
kell NS csomagokat küldenie.
- A nem működik átirányítások (Redirect) kezelése.
- Éppen csak müködik a router advertisementek (RA) kezelése. Ez érdekes
mert AIX alapjául szolgáló INRIA implementációnak ez egy igen nagy erőssége
volt még 1998-ban.
A Path MTU felderítése csak az inicializálás szintjén működik. Ez is
furcsa, mert az előbb említett INRIA implementáció szintén teljeskörűen támogatta.
Az állapot-nélküli címkonfigurálás alapszinten működik. Rendkívül
sok probléma van vele.
Az IPv4-es tunnelek kezelése tesztek szerint nem működik, de jobban
megvizsgálva küldött csomagokat és a kapott válaszokat látható, hogy
alapvető módon működnek a funkciók csak a tesztelő rendszer nem teljesen
úgy várja a válaszokat ahogy azok érkeznek.
A tesztek érdekesek, főleg annak tükrében, hogy az INRIA implementáció
amely az AIX-os IPv6 alapja az egyik legteljesebb és kiforrottabb implementáció
volt 1997-98 folyamán, amikor átemelték az AIX-be.
A sikeres tesztelés érdekében egy frissen installált FreeBSD 4.2-es
rendszerrel történt. A sikeres teszteléshez lényegi változtatásokat nem
kellett végrehajtani, csak apróbb módosításokat. Ezeket részletesen
felsoroljuk, majd összefoglaljuk a tesztek eredményeit.
A FreeBSD 4.x-as operációs rendszer tartalmazza az IPv6-os támogatást,
amelyet az installálás során egyszerűen ki lehet választani. Az IPSec támogatás
is beépített, de ezt nem teszteltük.
A TAHI teszteléshez a FreeBSD-s gépet ún. nullmodem kábellel a soros
porton keresztül össze kell kötni a tesztelő géppel..
A tesztelések indítása előtt a TAHI leírásának megfelelően szükséges,
hogy a default route-ot és a DNS címfeloldást letiltsuk ehhez az /etc/rc.conf
es /etc/resolv.conf fajlokat megfelelően módosítani kellett.
A FreeBSD tesztelését a következő verziókon végeztük el:
- FreeBSD 4.2 RELEASE, amely az installálási CD-n érkezett
- FreeBSD 4.3 STABLE
Az IPv6 és ICMPv6 specifikációk, valamint az implementációk robusztusságának
a tesztjei hibátlanul lefutottak egyetlen tesztet kivéve. A Routing Header
kezelése a végponton teszt nem futott le hibátlanul. Tcpdump-al megvizsgálva
futást azt tapasztaltuk, hogy a tesztelt számítógép kiadta a ICMP echo
reply üzenetet, de ezt valamiért a tesztelő eszköz nem érzékelte.
A Neighbor Discovery tesztelése megmutatta, hogy az általunk vizsgált
FreeBSD 4.2 verziók
- hibás Neighbor Solicitation (NS) csomagok hatására a
router/neighbourdiscovry-cache bejegyzések módosulhatnak
- az Router Solicitation (RS) csomagok küldése nem működik helyesen, ha
nincsen kijelölve default interfész. A KAME implementációkon, fontos,
hogy defináljuk, hogy melyik a default interfész, mert gazdagép módban
csak ezen küld RS üzeneteket.
- Neigbor Advertisement csomagok fogadása kisebb hibával működik. Ismételten
a IsRouter flag, nem működik helyesen, mint a NS csomagok esetén.
- A meglehetősen hibásan működik Router Advertisement (RA) csomagok
kezelése.
- A nem működik tökéletesen átirányítások (Redirect) kezelése.
A FreeBSD 4.3-ban jelentős haladást értek el a környezetfelmérő
protokoll hibáinak javításában
Ez utóbbi kettő működése megjavul, ha default interfészt definiáljuk.
A Path MTU felderítése csak alapszinten működik. A FreeBSD 4.3 ismét
javulást jelentett.
Az állapot-nélküli címkonfigurálás alapszinten működik. Alapvetően a
Duplicate-Address-Detection (DAD) mechnanizmusokkal vannak problémák.
Az IPv4-es tunnelek kezelése nem működik tökéletesen. A konfigurált
tunnel-ek helyesen müködnek a FreeBSD 4.3-ban.
A tesztek érdekesek, főleg annak tükrében, hogy a TAHI “hivatalos”
tesztjei szerint a BSD implementációk szinte teljesen teljesítik a KAME
teszteket, csak a automatikus tunnelekkel van probléma, mivel azokat a KAME nem
implementálja.
Mivel a különböző Linux disztribúciók azonos kernelre épülnek, és a
TAHI tesztek a kernelben lévő IPv6-os támogatást vizsgálják, ezért a
teszteléshez az általunk jobban megszokott Debian disztribúciót választottuk.
A tesztelő géppel való soros porti kapcsolathoz szükséges, hogy a kernel
tartalmazza a soros porti konzol támogatást. Természetesen a kernelnek
tartalmazni kell az IPv6-os támogatást is, esetünkben ezért mindkét
funkcionalitás érdekében újra kellett fordítani a kernelt. A soros porti
konzol az /etc/inittab file-ban kikommentezve megtalálható és könnyen
bekapcsolható. Mivel a TAHI tesztelés során a soros konzolon root-ként
jelentkezik be a tesztelő program, ezért az /etc/securetty file-ba az adott
soros porti terminált is fel kell sorolni.
A Linux IPSec támogatás a http://www.freeswan.org/
lapról letölthető, de létezik hozzá tesztelés alatt álló kész Debian
csomag is (pl. ftp://ftp.kfki.hu/pub/linux/debian-non-US/pool/non-US/main/f/freeswan).
Sajnos a 2.4-es kernel tesztelése során fölmerült és a teszt ereményeknél
részletezett nehézségek miatt a Linux/FreeSwan vizsgálatát nem tudtuk végrehajtani.
A tesztelések indítása előtt a TAHI leírásának megfelelően szükséges,
hogy a default route-ot és a DNS címfeloldást letiltsuk:
#
# mv /etc/resolv.conf /etc/resolv.conf.off
# ifdown eth0
# ifup eth0
A Linux kernel tesztelését a következő verziókon végeztük el:
- 2.2.19-es kernel az alap-beállításokkal:
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.router_solicitations = 3
- 2.2.19-es kernel a javasolt beállításokkal (2.2.19-2):
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.router_solicitations = 0
(A javasolt beállítások lényegében az autokonfiguráció, a router
hirdetések, az átirányítások és az automatikus router-kérés letiltását
jelentik.)
- (javított) 2.4.3-as kernel az alapbeállításokkal
- (javított) 2.4.3-as kernel a javasolt beállításokkal (2.4.3-2)
A TAHI tesztelés során vizsgáltuk a 2.4.0, 2.4.1, 2.4.2 és a hivatalos
2.4.3-as kerneleket is, azonban az IPv6-os implementáció a fragmentkezelés
területén mindegyik verzió esetében tartalmazott két igen súlyos hibát:
- Ha a fragment hasznos részének a mérete nem egy oktet egész számú többszöröse
volt, a megfelelő ICMP hibaüzenet küldése helyett a kernel lefagyott.
- Ha a fragmentekből helyreállított csomag mérete meghaladta a maximális
65535 oktetet, a megfelelő ICMP hibaüzenet küldése helyett a kernel
lefagyott.
A Linux kernel hálózati részének fejlesztői listáján keresztül (netdev@oss.sgi.com)
felhívtuk a fejlesztők figyelmét a súlyos hibákra, és a javított 2.4.3-as
kernellel a TAHI tesztelést el tudtuk végezni. A hibák végleges javítása a
később megjelenő 2.4.4-es kernel verzión keresztül vált publikussá.
A TAHI tesztelések eredménye a két fő kernelverzió és a beállítások
esetén igen különböző volt.
Az IPv6 és ICMPv6 specifikációk tesztjei a javított 2.4.3-as kernel ajánlott
kernel-paraméterek melletti beállítása esetén adták a legjobb eredményt,
csupán néhány kisebb, multicasttal és nagyméretű csomagok kezelésével
kapcsolatos hiba maradt benne.
A Neighbor Discovery kezelést szintén a 2.4.3-2 végezte a legjobban, de a
funkcionalitás gyakorlatilag alig működőképes. Az állapotnélküli címkonfigurálás
nem működik.
A Path MTU felderítés alapszinten működikszerepelt.
Az IPv4 tunnelek kezelése és a robusztusság vizsgálata hibátlan eredményekkel
szolgált.
A Solaris 8-as operációs rendszer tartalmazza az IPv6-os támogatást,
amelyet az installálás során egyszerűen ki lehet választani. Az IPSec támogatás
a http://www.sun.com/software/solaris/encryption
weblapról szabadon letölhető és a Solaris megszokott pkgadd parancsával
könnyen installálható.
A TAHI teszteléshez a Solaris 8-as gépet ún. nullmodem kábellel a soros
porton keresztül össze kell kötni a tesztelő géppel. A Solaris operációs
rendszerek alatt a soros portok kezelése meglehetősen bonyolult. Egy soros
portra kapcsolt terminál konfigurálásához igen nagy segítséget nyújt a http://www.stokely.com/unix.serial.port.resources/modem.html
lapon elérhető "Celeste's Tutorial On Solaris 2.x Modems &
Terminals" leírás és az abban található add_terminal shell
script. A script-ben - a helyes port és portsebesség megadása mellett - a
TAHI-val való együttműködés érdekében a LOGINMSG változó értékét
"login: "-ra kell változtatni.
A tesztelések indítása előtt a TAHI leírásának megfelelően szükséges,
hogy a default route-ot és a DNS címfeloldást letiltsuk:
# mv /etc/defaultrouter /etc/defaultrouter.off
# mv /etc/resolv.conf /etc/resolv.conf.off
#
A Solaris 8-as tesztelését a következő verziókon végeztük el:
- 108528-03-as kernel patch verzió, amely az installálási CD-n érkezett
- 108528-06-os kernel patch verzió
- 108528-06-os kernel patch verzió IPSec-el kiegészítve
Az IPv6 és ICMPv6 specifikációk, valamint az implementációk robusztusságának
a tesztjei hibátlanul lefutottak.
A Neighbor Discovery tesztelése megmutatta, hogy az általunk vizsgált
Solaris 8-as verziók
- nem küldenek Neighbor Solicitation (NS) csomagokat
- az NS csomagok fogadása kisebb hiányosságokkal működik
- Neigbor Advertisement csomagok fogadása kisebb hibával működik
- A meglehetősen hibásan működő Router Advertisement (RA) csomagok
kezelését a 108528-06-os verzióban csaknem teljesen kijavították
- A nem működő átirányítások (Redirect) kezelésében a 108528-06-nál
kisebb haladást értek el.
A Path MTU felderítése alap-szinten működik.
Az állapot-nélküli címkonfigurálás és az IPv4-es tunnelek kezelése
nem működik.
A tesztelési vizsgálatok során kiderült, hogy a Solaris 8 IPSec tesztelése
a jelenlegi TAHI tesztkészlettel nem lehetséges: a TAHI tesztkészlet
aszimetrikus ICMP policy-ra épül, amelyet a Solaris 8-as IPSec nem támogat.
|
Copyright
|
$Id: 7.tahi.html 55 2001-07-25 16:55:22Z mohacsi $ |