T-110.4100 tentti 26.10.2010
1
a) epätosi, arp on paikallisessa verkossa ip-fyysinen-osoiteparien
selvittämiseen, joka voidaan hoitaa vaikka kiinteillä
osoiteriippuvuuksilla tai IPv6ssa ICMP-viestein, ja riippuu lähinnä fyysisestä
verkkoteknologiasta, miten osoitteet ylipäänsä määritellään.
b) epätosi, reitityksen nopeus ei riipu yksin osoitteen pituudesta
c) epätosi, lähettävät ryhmähetyksellä (yleislähetystä vastaavaan
kaikki koneet ryhmä), muuten totta (ei tekemistä reitityksen kanssa)
d) tosi, perusotsikon jälkeen tulevat laajennusotsikot sopivat juuri
tähän, ja niitä on helppo määritellä lisää muuttamatta protokollaa
e) kyllä, alkuperäinen d-luokka, alkaa biteillä 1111.
f) epätosi, IPsec toimii sellaisenaan myös IPv4:n kanssa
tosi, IPsec on pakollinen toteuttaa IPv6:ssa, mutta vapaaehtoinen IPv4:ssä
Pahimmat mokat: toistaa kysymyksen väite perustelematta sitä mitenkään
2
a)
ip-otsikossa on kuljetuskerroksen protokollan tunnisteena sen numero (esim TCP=6).
kuljetuskerroksella päätetään porttinumeron perusteella: mahdollisuuksia
ovat tunnetut, rekisteröidyt ja valinnaiset portit, palvelusta riippuu miten
porttinumero varataan vai kuuluuko se tietylle sovellusprotokollalle (esim
DNS (53) , IRC (6667) tai joku omatekoinen (49152-65535)).
vastaanottajasovellus/palvelu kuuntelee porttia odottaen viestiä
+ esimerkki
b) sekvenssinumero + kuittausnumero; sekvenssinumero kertoo sovelluksen
datavirran paikan, ja kuittauksessa kerrotaan mitä sekvenssiä odotetaan
seuraavaksi. yleensä kuitataan useampi sekvenssi saapuneeksi kerralla,
kun kaikki välissä olevat sekvenssitkin ovat saapuneet perille.
c) ruuhkanhallinta on lähettäjäpään ominaisuus reagoida verkon ruuhkatilanteisiin
sen lähettäessä pakettia; vastaanottajan tai muiden yhtyeksien ei tarvi olla
käytetystä tavasta tietoisia, sillä ruuhkanhallinnalla vaikutetaan lähetysikkunan
kokoon (vastaanottajan vastaanottokyvyn lisäksi siis verkon ruuhka vaikuttaa)
Yleisimmät puutteet:
a) porttien jako
b) kuittausten kumulatiivisuus! sekvenssinumero ei ole pakettikohtainen
c) ruuhkanhallintaa ei osattu lainkaan
3
a) 13. kalvo dns-luennolta
b) paikallinen nimipalvelin katsoo osoitteen välimuististaan, jos
tiedon sai sinne tallettaa
c) 41. kalvo dns-luennolta: avaintenjako nimipalvelinpuusta + allekirjoitukset
Yleisimmät virheet:
Ei nimipalvelutietoja salata! salaus != allekirjoitus
c-kohdassa kysyttiin kyselyn tekoa, ei nimipalvelimien tapaa vaihtaa tietoaan
4
jotain seuraavanlaista + selitykset (pelkät nimet ei asioille riitä)
"tyyppi" algoritmi hyvää/huonoa
as:n välillä BGP4 polkuvektori pikemminkin hallinnollinen
as:n sisällä
- RIP etäisyysvektori bellman-ford
- OSPF linkkitila djikstra
yht 3p 3p 4p
2p luettavissa ja ymmärrettävissä kerralla, mm. jotain johdannoksi,
jotain yhteenvedoksi jotka yhdistävät kaiken kerrotun, ja jonkinlainen
rakenne.
- 4p jos muuten hyvä, mutta BGP puuttuu kokonaan (koska sillon
puuttuu myös osa johdannosta)
5
nat = sisäverkon osoitteistus piilotetaan ulkoverkolta, voi käyttää yhtä
Pv4-osoitetta koko verkolle
stun = tapa selvittää oma julkinen osoitteensa, kun on natin takana
turn = tapa saada selville oma julkinen osoite (stun) + relay-osoite itselleen, kun on
natin takana
ice = tapa kahdelle eri natin takana olevalle koneelle viestiä keskenään,
käyttää hyväkseen turnia
6
a) ip-osoitteet ja portit yhteydellä + muuta tietoa, esim protokolla
b) loopback-osoitteen hyväksikäyttö, suljetussa verkossa testaus
c) tarkistetaan syötteen tyyppi eikä hyväksytä mitä vaan
7
a) kts cloud computing -kalvot
b) katso protokollasuunnittelun kalvot. + tilanteen mukaan pitää valita
tilanteeseen sopiva tapa siten, että valinnan pystyy perustelemaan
8
fcaps-osa-alueet,
- palvelut
- laitteet
suunnitellut muutokset
virhetilanteet
hyökkäystilanteet