BGP
Transcription
BGP
T-110.4100 Tietokoneverkot: Reititys autonomisten järjestelmien välillä, ryhmälähetyksen reititys Teemu Kiviniemi Funet-verkko CSC – Tieteen tietotekniikan keskus Oy Luento pohjautuu Sanna Suorannan aiempaan materiaaliin. 14.2.2012 Luennon sisältö Autonomiset järjestelmät ja niiden väliset yhteydet BGP – iBGP, eBGP, toiminta IGP:n kanssa – BGP:n turvallisuus – Multiprotocol BGP (MBGP) Ryhmälähetys – osoitteet – IGMP, MLD – Reititysprotokollat DVMRP, CBT, MOSPF, PIM – AS:ien välinen ryhmälähetys 2 Funet Suomen korkeakoulujen ja tutkimuksen tietoverkko Yli 80 organisaatiota – Yliopistoja – Ammattikorkeakouluja – Tutkimuslaitoksia Noin 350 000 käyttäjää 3 Internetin rakenne AS2 R R R R R R R R R AS1 R R R R AS4 AS3 R R Internet koostuu itsenäisistä verkoista, autonomisista järjestelmistä: autonomous systems (AS). 4 Autonominen järjestelmä (Autonomous System, AS) Autonomiset järjestelmät ovat itsenäisiä verkkoja, joilla on oma hallittu reitityssäännöstö. – Muiden AS:ien näkökulmasta AS on sisäisesti yhtenäinen verkko. – AS:ien välillä käytetään reititykseen BGP-4:ää (Border Gateway Protocol). Jokaisella AS:llä on uniikki 32-bittinen tunniste. – Alun perin AS-numerot olivat 16-bittisiä. 32-bit ASnumerolaajennus BGP:hen tuli RFC 4893:ssa. – Verkossa on edelleen laitteita jotka tukevat vain 16-bit AS-numeroita. – Myönnettyjä AS-numeroita on noin 58000. 5 Miksi AS:ien välinen ja AS:n sisäinen reititys tehdään erikseen? Internet on liian iso yhdelle reititysprotokollalle – Kaikki reitittimet eivät ole samassa verkossa, joten ne eivät voi kommunikoida suoraan keskenään. – AS:n sisäistä topologiaa ei tarvitse levittää koko Internetiin. Yhteenveto AS:n verkoista ja Internetin AS-poluista riittää. AS:n sisäinen rakenne huomioidaan IGP:ssä. AS:illä on omat hallinnolliset linjauksensa – Aina ei käytetä lyhintä reittiä vaan esim. halvimman sopimuskumppanin tarjoamaa verkkoyhteyttä. – BGP-politiikkojen avulla voidaan valita käyttöön muitakin kuin lyhimpiä reittejä. Myös mainostettavat verkot voidaan rajata. 6 Erilaisia AS:ia 7 Transit vs. peeraus Transit – Alemman kerroksen operaattori (tier-[n+1]) tai stubAS maksaa transitoperaattorille (tier-n) Internetliikennöinnistä. – Transit-operaattori mainostaa BGP:llä täyden Internettaulun. – Pienempi operaattori mainostaa omat verkot ja omien asiakkaiden verkot. Peeraus – Tyypillisesti rahaa ei vaihdeta. – Kahden tier-n –operaattorin tai stub-AS:n välillä. – Molemmat mainostavat BGP:llä toisilleen omat ja asiakkaittensa verkot. – Operaattoreiden välinen liikenne ei tarvitse kulkea enää transitin kautta. – Julkinen peeraus: yhdysliikennepisteessä (IXP): esim. FICIX, TREX, AMS-IX – Privaattipeeraus: suora yhteys operaattoreiden välillä. 8 BGP 9 Border Gateway Protocol 4 (BGP-4, RFC 4271) Välittää reittejä verkkojen saavutettavuustietona (Network Layer Reachability Information, NLRI) – NLRI:stä kerrotaan AS-polku, jota kautta saavutettavuustieto on saatu: polkuvektori. AS-polulle voi olla määritelty myös attribuutteja. AS-polkutiedon avulla voidaan välttää reitityssilmukat. – Reittien tarkkaa metriikkaa ei ole tiedossa, vain ASpolku jota kautta reitti on vastaanotettu. – BGP:llä mainostetaan yleensä vain sellaisia reittejä joita mainostava reititin käyttää itse. BGP käyttää TCP:tä portissa 179. 10 BGP-protokollan viestit OPEN (Type = 1) – Ensimmäinen BGP-sessiossa lähetettävä viesti. Sisältää mm. AS-numeron, BGP-tunnisteen (Identifier), tuetut BGP-lisäominaisuudet, ym. – Jos naapurit avaavat TCP-yhteydet yhtä aikaa, se yhteys katkaistaan jonka avasi reititin jolla on pienempi BGP Identifier. UPDATE (Type = 2) – Viesti jossa välitetään mainostettavat reitit NLRI-tietueina. Viestillä voidaan myös vetää pois aiempia mainostuksia (WITHDRAW). KEEPALIVE (Type = 3) – Lähetetään aika-ajoin jotta varmistetaan että naapurireititin on edelleen hengissä. Viestillä kuitataan myös vastaanotettu ja hyväksytty OPEN-viesti. NOTIFICATION (Type = 4) – Viesti jolla lähetetään virheilmoitus naapurireitittimelle. NOTIFICATION-viestin jälkeen BGP-sessio suljetaan. ROUTE-REFRESH (Type = 5): laajennus, RFC 2918 – Viesti jolla pyydetään naapuria mainostamaan kaikki reititit uudelleen UPDATEviesteillä. 11 BGP-viestin otsikko 0 8 16 24 31 Marker Length Type Marker: käytetään synkronointiin: viestin alku – Käytettiin aiemmin myös autentikointiin, RFC 4271:n myötä ei enää. Length: BGP-viestin pituus tavuina, ml. otsikot. – Viestin maksimipituus on 4096 tavua. Type: BGP-viestin tyyppi 12 BGP OPEN-viesti (Type = 1) 0 8 16 24 31 Version = 4 My autonomous system Hold Time BGP Identifier Opt Parm Len Optional Parameters (variable) 13 BGP OPEN-viesti (2) My autonomous system: AS-numero (16-bit) – 32-bit AS-numero välitetään optioissa. Hold Time: aika sekunteina jonka jälkeen BGP-sessio katkaistaan jos naapurilta ei ole vastaanotettu yhtään viestiä – Käyttöön valitaan pienempi naapureiden Hold Time-arvoista. – Minimiarvo on 3 sek. BGP Identifier: tunniste jota reititin käyttää kaikissa BGPsessioissaan: yksi sen IP-osoitteista Opt Parm Len + Optional Parameters: valinnaiset optiot. Esimerkiksi tuetut BGP:n lisäominaisuudet (Capabilities, RFC 5492): – RFC 2918: Route Refresh – RFC 4893: 32-bittiset AS-numerot – RFC 4760: multiprotocol-laajennus (mm. IPv6) 14 BGP UPDATE-viesti (Type = 2) 0 8 Withdrawn Routes Length 16 24 Withdrawn Routes (variable) Total Path Attribute Length Path Attributes (variable) Network Layer Reachability Information (variable) Lähetetään kun BGP-yhteys on avattu tai kun verkon tila muuttuu. Viesti sisältää joko sekä poistuneita (withdrawn) reittejä että uusia reittejä, tai vain jompia kumpia. Yhdessä UPDATE-viestissä mainostettavien uusien reittien polun attribuutit on oltava samat. 31 15 BGP UPDATE-viesti (2) Poistuneet (withdrawn) reitit ja uudet reitit (NLRI) kuvataan pareina: Length Prefix (variable) – Length: prefiksin pituus bitteinä (1 tavu) – Prefix: itse prefiksi, joka on lopusta jatkettu lähimmälle tavurajalle NLRI-osion koko lasketaan vähentämällä UPDATE-viestin kokonaispituudesta aiemmin esiintyneet kentät. 16 BGP UPDATE - Polkuattribuutit 0 OTPE 16 8 31 24 0000 Attr. Type Code Attr. Data Length1 (…Length2) Attribute Data UPDATE-viestissä mainostettavien uusien reittien polkuattribuutit. – Sisältää lisätietoa mainostettavista reiteistä. Polkuattribuutit jakautuvat neljään eri kategoriaan – Tunnetut (well-known) attribuutit: pakolliset (mandatory) ja harkinnanvaraiset (discretionary) – Valinnaiset (optional) attribuutit: transitiiviset ja ei-transitiiviset OTPE-flagit: – (O)ptional: 1 = valinnainen, 0 = tunnettu – (T)ransitive: 1 = transitiivinen, 0 = ei-transitiivinen – (P)artial: 1 = partial, 0 = complete: jos 1, jokin polulla olevista reitittimistä ei ole ymmärtänyt valinnaista transitiivistä attribuuttia. – (E)xtended length: Attr Data Length-kentän pituus. 1 => 2 tavua, 0 => 1 tavu 17 BGP - Polkuattribuutit (2) 1 = ORIGIN (tunnettu, pakollinen) – reitin lähde – 0 = IGP, 1 = EGP (RFC 904), 2 = INCOMPLETE (jokin muu lähde) 2 = AS_PATH (tunnettu, pakollinen) – reitin AS-polku <tyyppi, pituus, arvo> -tripletteinä tyyppi 1 = järjestämätön ja 2 = järjestetty lista AS:ista pituus = AS:ien lukumäärä arvo = AS:t 3 = NEXT_HOP (tunnettu, pakollinen) – Sen reitittimen IP johon NLRI:ssä määriteltyihin verkkoihin kohdistuva liikenne tulisi välittää 18 BGP - Polkuattribuutit (3) 4 = MULTI_EXIT_DISC (valinnainen, ei-transitiivinen) – MED-arvo: metriikka jonka avulla voidaan iBGP:ssä erotella muuten samanarvoiset reitit AS:n ulkopuolelle. – MED-arvoja käytetään vertaillessa reittejä jotka on vastaanotettu samasta AS:stä. – Jos MED-arvoa ei ole määritelty, reitillä on paras mahdollinen metriikka. 5 = LOCAL_PREF (tunnettu, pakollinen iBGP:ssä) – AS:n sisällä reiteille valittu paikallinen preferenssi. – Paikallinen preferenssi ohittaa esimerkiksi AS-polun pituuden tarkastelun, joten paikallisessa politiikassa voidaan käyttää ASpolultaan pidempiä, mutta muilla tavoin parempia reittejä (esimerkiksi halvempi transit-sopimus). 19 BGP - Polkuattribuutit (4) Useiden reittien tiedoista voidaan yhdistää (aggregate) yksi reitti. Yhdistäminen vähentää BGP:ssä välitettävän tiedon määrää. Reittien yhdistämiseen liittyvät attribuutit: – 6 = ATOMIC_AGGREGATE (tunnettu, harkinnanvarainen) Attribuuttia käytetään jos reittejä on yhdistetty niin, että yhdistetyllä AS-polulla ei mainittu ole kaikkia alkuperäisten reittien AS-poluilla listattuja AS:iä. – 7 = AGGREGATOR (valinnainen, transitiivinen) Reittejä yhdistäneen reitittimen AS-numero ja IP-osoite 20 BGP NOTIFICATION-viesti (Type = 3) 0 16 8 Error Code Error subcode 24 Data (variable) 31 Virheistä ilmoittaminen BGP-naapurille. Viestin lähettämisen jälkeen BGP-sessio katkaistaan. Error Code Symbolic Name 1 Message Header Error 2 OPEN Message Error 3 UPDATE Message Error 4 Hold Timer Expired 5 Finite State Machine Error 6 Cease 21 BGP KEEPALIVE-viesti (Type = 4) Viesti lähetetään jotta BGP-naapuri tietää että paikallinen reititin on edelleen elossa. Viesti lähetetään jos edellisestä lähetetystä BGP-viestistä on kulunut tarpeeksi. – RFC 4271 suositus: 1/3 * Hold Time – Jos Hold Time on 0, KEEPALIVE-viestejä ei lähetetä. – Korkeintaan yksi KEEPALIVE-viesti/sek. KEEPALIVE-viesti ei sisällä tietoa reiteistä. – BGP lähettää NLRI-reittitietoja vain kun niissä on tapahtunut muutoksia. 22 BGP:n reititystaulut (Routing Information Base, RIB) BGP kerää reittitietoa kolmeen erilaiseen tietokantaan. – Periaatteellisella tasolla. Käytännön toteutus voi olla toisenlainen. Adj-RIBs-In – Muilta reitittimiltä UPDATE-viesteissä vastaanotettu reititystieto sellaisenaan. Loc-RIB – Reitit jotka on paikallisesti määriteltyjen politiikkojen perusteella tuotu Adj-RIBsIn-taulusta. – Sisältää paikallisesti käytetyt BGP-reitit. Kaikkia reittejä ei välttämättä silti käytetä, eli kaikki reitit eivät aina ole aktiivisia reitittimen reittitaulussa. Esim. IGP-reittejä tai paikallisesti konfiguroituja staattisia reittejä suositaan usein parhaiden BGP-reittien sijaan. Adj-RIBs-Out – Reitit jotka on paikallisesti määriteltyjen politiikkojen perusteella valittu mainostettaviksi BGP-naapureille UPDATE-viesteillä. 23 BGP - reitin valinta Ennakkovaatimukset: – Reitin Next Hop-osoitteeseen on oltava toimiva reitti. – AS_PATH ei saa sisältää silmukoita. Valintakriteerit, järjestyksessä (eniten merkitsevä ensin): – Tarkin reitti: suurempi prefiksin pituus on parempi – LOCAL_PREF: AS:n sisällä valittu paikallinen preferenssi: korkeampi preferenssi on parempi – AS-polun pituus: lyhyempi polku on parempi – ORIGIN-attribuutin arvo: IGP > EGP > INCOMPLETE – MULTI_EXIT_DISC: reitin MED-metriikka: pienempi metriikka on parempi – Suositaan eBGP:stä saatua reittiä iBGP-reittien sijaan. – IGP-metriikka reitin Next Hop-osoitteeseen: pienempi on parempi – Reitin mainostaneen reitittimen BGP Identifier: valitaan pienin – BGP-naapurin IP-osoite: valitaan pienin. 24 BGP - Communities Attribute (RFC 1997 ja RFC 4360) BGP Community-attribuuttien avulla AS voi leimata ja ryhmitellä reittejä haluamallaan tavalla esimerkiksi vastaanotettaessa reittejä AS:n ulkopuolelta. – Community-attribuuttien avulla reittejä voidaan käsitellä muilla AS:n BGPreitittimillä toisistaan poikkeavalla tavalla. – Community-arvot, ja se, mitä arvoilla tehdään on paikallisen ylläpidon päätettävissä. Muutamia tunnettuja Community-arvoja: – NO_EXPORT: reittiä ei mainosteta BGP-konfederaation ulkopuolelle – NO_ADVERTISE: reittiä ei mainosteta BGP-naapureille – NO_EXPORT_SUBCONFED: reittiä ei mainosteta AS:n ulkopuolelle Community-attribuutit ovat 32-bittisiä arvoja, joista ensimmäiset 16 bittiä sisältää AS-numeron (RFC 1997). Extended Community-attribuutit voivat perustua 16-bittisen ASnumeron lisäksi IPv4-osoitteeseen tai IANA:n varauksiin (RFC 4360). 25 Internal BGP (iBGP) AS:n reunareitittimet keskustelevat keskenään AS:n sisäisellä iBGP:llä. – AS:n pitää antaa itsestään ulos konsistentti kuva. Kaikkien AS-reunareitittimien on muodostettava iBGP-sessio kaikkien muiden reunareitittimien kanssa (full mesh) – RFC 4456 määrittelee Route Reflection-ominaisuuden. Kaikki verkon reitittimet muodostavat iBGP-sessiot vain BGPreflektoreina toimiviin reitittimiin (vrt. OSPF transit-verkon Designated Router) Kaikki reittitieto leviää kaikille verkon reitittimille reflektoreiden kautta. 26 iBGP (Full Mesh) IGP 27 iBGP (Route Reflector) 28 BGP-naapuruuksien muodostamiseen käytettävät IP-osoitteet iBGP-sessiot muodostetaan yleensä reitittimien loopback-osoitteiden välille. – Paras reitti muiden reititinten loopbackeihin saadaan IGP:llä. – iBGP-sessioiden ei pitäisi katketa koskaan. eBGP-sessiot muodostetaan yleensä sen linkkiverkon linkkiosoitteiden välille, jonka yli liikennettä vaihdetaan. – eBGP-naapuruus katkeaa heti kun toiseen AS:ään yhdistävä verkkolinkki katkeaa. Tällöin toiselta AS:lta vastaanotetut reitit poistetaan käytöstä. 29 Linkkiverkot ja loopbackit 30 IGP:n ja iBGP:n yhteistoiminta IGP:ssä reitititettävien reittien määrää kannattaa suuremmissa verkoissa pyrkiä minimoimaan. – IGP:n reittilaskenta nopeutuu, kun reittejä on vähemmän. Riittää että IGP:ssä mainostetaan: – reititinten loopbackit iBGP-sessioiden muodostamiseen – BGP-reittien Next Hop-osoitteet Kaikki loput reitit voidaan mainostaa iBGP:llä. Mahdollinen työnjako korkealla tasolla: – IGP:llä reititetään välttämättömät reitit iBGP-sessioiden muodostamiseen (loopback-osoitteet). – iBGP:llä kerrotaan mitä verkkoja reitittimen takaa on saavutettavissa ja reittien Next Hopit. – IGP:llä kerrotaan miten kuhunkin reitittimeen (BGP Next Hop) voidaan liikennöidä. 31 Multiprotocol Extension for BGP-4 (RFC 4760) Alun perin BGP tuki vain IPv4:ää. Multiprotocol-laajennus mahdollistaa myös muiden kuin IPv4-reittien mainostamisen: Address Family Identifier (AFI) – Esim. IPv6 Yhden osoiteperheen sisällä voidaan välittää myös erilliset multicast-saavutettavuustiedot – Subsequent Address Family Identifier (SAFI) BGP OPEN-viestin Capability-tiedoissa kerrotaan mitä AFI/SAFI-yhdistelmiä reititin tukee. 32 MBGP - uudet attribuutit Valinnaisia ei-transitiivisia attribuutteja – MBGP:tä osaamaton reititin jättää attribuutit huomioimatta. Reittien mainostus ja reittien poistuminen tehdään uusilla polkuattribuuteilla. – Multiprotocol Reachable NLRI (MP_REACH_NLRI) Uusien ja muuttuneiden reittien mainostaminen. – Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) Poistuneiden reittien tiedot. – Molemmissa attribuuteissa kerrotaan AFI ja SAFI, jota päivitys koskee. 33 BGP ja turvallisuus BGP:tä vastaan voidaan hyökätä useilla eri keinoilla. Man in the middle: hyökkääjä mainostaa BGP:llä verkkoja jotka kuuluvat jollekin muulle. – Liikenne ohjautuu hyökkääjälle. Hyökkääjä voi edelleenohjata liikenteen lopulliseen kohde-AS:ään. – BGP-naapuruuksissa tulisi varmistaa että naapuri-AS mainostaa vain sellaisia verkkoja jotka kuuluvat naapuri-AS:lle ja sen asiakkaille. – 2008: Youtube oli saavuttamattomissa väärien BGP-mainostusten vuoksi. Palvelunestohyökkäys: jos BGP-sessio reititinten välillä katkeaa, kyseisen BGP-session yli vaihdetut reitit poistuvat käytöstä – BGP-liikenne priorisoidaan reitittimissä normaalisti muuta liikennettä tärkeämmäksi. – TCP-autentikoinnin avulla (RFC 5925) yhteyden resetointi TCPsekvenssinumeroita voidaan estää. 34 Reittimainostusten turvallisuus Millä AS:lla on oikeus mainostaa BGP:llä verkkoa X? – Tarvitaan jonkinlainen tapa sitoa verkkoprefiksit ASnumeroihin. Mitä kautta AS:ään Y voidaan liikennöidä? – Tarvitaan jonkinlainen tapa jolla voidaan varmistua AS-polun tiedon oikeellisuudesta. Secure Inter-Domain Routing (SIDR)-työryhmä IETF:ssä on kehittämässä ratkaisuja. 35 Route Origin Authorization (ROA, RFC 6483) Kun IP-osoitteita ja AS-numeroita jaetaan (IANA, RIR:t, LIR:t), omistusoikeus (delegointi) julkaistaan digitaalisesti allekirjoitettuna. – Sertifikaattihierarkia noudattaa samaa hierarkiaa kuin IP-osoitteiden ja AS-numeroinen jakaminen muutenkin. IP-prefiksin omistaja voi delegoida omistusoikeutta eteenpäin, tai kertoa mitkä AS:t saavat mainostaa kyseistä prefiksiä. Allekirjoitukset julkaistaan hajautetussa Resource Public Key Infrastructure –tietokannassa (RPKI) Allekirjoitukset voidaan hakea RPKI-tietokannasta paikalliseen välimuistiin, josta AS:n BGP-reitittimet käyvät hakemassa tietoja joiden avulla voidaan varmistaa reittien lähteet. – Välimuistin ja reitittimien välille on oma protokolla: RPKI/Router Protocol (draft-ietf-sidr-rpki-rtr). – BGP-reititin voi käsitellä allekirjoitettua tietoa paikallisten politiikkojen avulla. Voidaan asettaa esimerkiksi local preference. 36 BGPSEC (draft-ietf-sidr-bgpsec) RPKI-tietokantaan lisätään sertifikaatti, jossa on AS:n BGP-reitittimien käyttämä julkinen avain. – Avaimella allekirjoitetaan BGP:hen mainostettujen reittien AS-polku. Kun reititin AS:sta X mainostaa reitin AS:ään Y, reititin luo BGP-attribuutin ”reitti mainostettiin AS:stä X AS:lle Y”, ja allekirjoittaa sen AS X:n avaimella. – Sama toistuu AS:ssä Y mainostettaessa AS:lle Z – Attribuutin avulla reitittimet voivat tarkistaa AS-polun aitouden. 37 RYHMÄLÄHETYS 38 Ryhmälähetys (multicast, monilähetys) Liikenne jota lähetetään ryhmälle vastaanottajia – Vastaanottajat voivat olla eri puolilla verkkoa. – Verkko huolehtii viestin monistamisesta ja kuljettamisesta kaikille ryhmään liittyneille vastaanottajille. Multicast-ryhmiin voi liittyä ja niistä voi poistua dynaamisesti. – Muutokset vaikuttavat kyseisen ryhmän reititykseen. Ryhmälähetys on tehokas tapa viestiä suuremmalle vastaanottajajoukolle. 39 Ryhmälähetys Internetissä Ryhmälähetys toimii kattavasti akateemisissa verkoissa, kuten Funetissa. – Mbone, M6bone Kaupallisten operaattoreiden välillä ryhmälähetyksen välittäminen ei ole kovin yleistä. – Operaattorit käyttävät ryhmälähetystä kuitenkin omien IPTV-palveluiden toteuttamiseen oman verkon sisällä. 40 Esimerkkejä ryhmälähetyksen käytöstä IPTV Muu video- ja audiostreamaus Pörssi-informaation jakaminen Linkin paikallinen käyttö, mm. – Reititysprotokollat – IPv6: reitittimien ja naapureiden löytäminen 41 Ryhmälähetysosoitteet Ryhmälähetysosoite toimii ryhmän tunnisteena – Ei kerro, missä ryhmän jäsenet sijaitsevat. Kuka tahansa voi lähettää paketteja ryhmäosoitteeseen. On sekä pysyviä (well-known) että vapaasti käytettäviä ryhmäosoitteita. – IANA allokoi pysyvät. Osa ryhmäosoitteista on varattu liikennöintiin paikallisella linkillä. Liikenne ei leviä linkin ulkopuolelle. 42 Ryhmälähetyksen kaksi eri palvelumallia Any-Source Multicast (ASM): lähderiippumaton ryhmälähetys – Pelkästään ryhmäosoite (*, G) toimii ryhmän tunnisteena. – Verkko tietää lähteet ja huolehtii siitä että kaikkien lähteiden paketit kulkevat vastaanottajille. Source-Specific Multicast (SSM): lähdekohtainen ryhmälähetys (RFC 4607) – SSM-kanavan tunnisteena toimii lähettäjän IP-osoite ja SSM-ryhmäosoite (S,G) – Vastaanottaja on tiedettävä lähettäjän IP etukäteen. 43 IPv4-ryhmälähetysosoitteet 0 1110 31 Group Identification 224.0.0.0/4, eli 224.0.0.0 - 239.255.255.255 Vapaasti käytettäviä: – 233.0.0.0/8: RFC 3180: GLOP Addressing: 16-bit AS-numeroon perustuva osoitteiden jaottelu. – 234.0.0.0/8: RFC 6034: IP-prefiksiin perustuva osoitteiden jaottelu. – 239.0.0.0/8: organisaation sisäiseen käyttöön Sovelluskehittäjät voivat varata ryhmäosoitteita IANA:lta. 44 IPv4-ryhmälähetysosoitteet (2) Paikallisen linkin protokollaliikennöintiin: 224.0.0.0/24 – Liikennettä ei välitetä ulos linkiltä. – Esim. OSPF 224.0.0.5 Session Announcement Protocol (RFC 2974): 224.2.0.0/16 – Ryhmälähetyssessioden julkaisemiseen Esim. videokonferenssit, audio- ja videolähetykset Source-Specific Multicast (SSM): 232.0.0.0/8 45 IPv6-ryhmälähetysosoitteet (RFC 4291) 0 8 16 11111111 0RPT scope 128 group ID Scope rajoittaa viestin leviämistä verkkoon – 1 = Interface-Local, 2 = Link-Local – 4 = Admin-Local, 5 = Site-Local, – 8 = Organization-Local, e = Global R (RFC 3956): Embedded-RP P (RFC 3306): Unicast-prefixiin perustuva ryhmäosoitteiden allokointi T: 0 = IANA:n allokoima, 1= dynaamisesti varattu 46 IPv6-ryhmälähetysosoitteet (2) Link-Local: ff02::/16 – Ei leviä paikalliselta linkiltä – esim. OSPFv3: ff02::5 Source-Specific Multicast: ff3x::/32 – Käytetään SSM-kanavien ryhmäosoitteina Embedded-RP: ff7x::/16 – Ryhmäosoitteet joihin on määritelty RP-reitittimen osoite. 47 Ryhmälähetys yhdellä linkillä: lähettäjän näkökulma Ryhmälähetysosoitteeseen lähetetty IP-paketti kehystetään linkkikerroksen kehykseen. – Jos linkkikerros tukee ryhmälähetystä, käytetään linkkikerroksen ryhmälähetysosoitteita linkkikerroksen kohdeosoitteena. Linkkikerroksen kohdeosoite voidaan valita IP-ryhmäosoitteen perusteella (esim. RFC 2464) – Muuten käytetään yleislähetystä (broadcast). Jos ryhmälähetys ei ole kohdistettu vain linkille (link-local), verkkoa palveleva reititin välittää ryhmälähetyksen eteenpäin muualle verkkoon. Samalla linkillä olevat vastaanottajat näkevät ryhmälähetyksen suoraan. 48 Ryhmälähetys yhdellä linkillä: vastaanottajan näkökulma Kun sovellus sitä pyytää, laite liittyy haluttuun multicastryhmään. Ryhmään liittyminen, siitä poistuminen tehdään IGMP:n (IPv4) tai MLD:n (IPv6) avulla. – Jos linkkikerros tukee ryhmälähetystä, laite alkaa kuuntelemaan myös IP-ryhmälähetysosoitetta vastaavaa linkkikerroksen ryhmälähetysosoitetta. – Muuten kuunnellaan linkkikerroksen yleislähetysosoitetta (broadcast). Haluttuun ryhmälähetysosoitteeseen saapuneet paketit välitetään sovellukselle. 49 Internet Group Management Protocol IGMPv3 (RFC 3376) Käytetään IPv4-verkossa multicast-ryhmiin liittymiseen. IGMP on oma protokolla IP:n päällä. IGMP-viestit lähetetään ryhmälähetyksellä. IGMP-viestit eivät koskaan leviä linkin ulkopuolelle. 50 IGMPv3 - Viestityypit Version 3 Membership Report – viesti jonka avulla laite ilmoittaa mihin ryhmiin se kuuluu Membership Query – viesti jonka avulla verkon laite (yleensä reititin) pyytää ryhmien jäseniä lähettämään Membership Reportviestin. Lisäksi, vanhojen IGMP-versioiden viestit: – Version 1 Membership Report, Version 2 Membership Report, Version 2 Leave Group 51 IGMP – versioiden olennaisimmat erot IGMPv1 – alkuperäinen versio – Ryhmästä ei voinut poistua – poistuminen vaati sen että (softa)tila reitittimestä vanheni. IGMPv2 – Uutena ominaisuutena tuki ryhmistä poistumiselle. – Laajimmin tuettu IGMPv3 – Mahdollisuus lähteiden suodattamiseen Lähteiden suodattamisen myötä tukee Source-Specific Multicastia (SSM) Kaikki IGMP-versiot ovat taaksepäin yhteensopivia: jos verkossa näkyy vanhan IGMP-version viestejä, laitteet käyttävät IGMP:n vanhaa versiota. – Ongelmallista SSM:lle. 52 Reitittimen tehtävä ryhmien hallinnassa Linkillä voi olla useampi ryhmälähetysreititin. Se reititin, jolla on pienin IP-osoite valitaan kyselijäksi (querier). – Kyselijä valitaan jokaisella linkillä erikseen. – Kyselijä vastaa Membership Query-viestien lähettämisestä verkkoon. – Jos linkillä näkyy Membership Query-viesti reitittimeltä jolla on pienempi IP-osoite, kyselijä vaihtuu. Kaikki linkin IGMP:tä tukevat reitittimet pitävät kirjaa linkillä olevista vastaanottajista. 53 IGMPv3 Membership Query 0 8 16 31 Type =0x11 Max Resp Code Checksum Group Address Resv S QRV QQIC Number of Sources (N) Source Address [1] ... Source Address [N] IP-paketin TTL=1, Router Alert-optio on päällä General Query: kohdeosoitteena 224.0.0.1 (kaikki laitteet) Group-Specific Query ja Group-and-Source-Specific Query: kohdeosoitteena ryhmän osoite 54 IGMPv3 Membership Query (2) Olennaisimmat otsikon kentät: – Max Resp Code: kuinka nopeasti kyselyyn on vastattava – Group Address: ryhmä jonka tietoja pyydetään 0.0.0.0 = kaikki ryhmät, General Query – Number of Sources (N): viestissä listattujen lähteiden lukumäärä käytetään kun halutaan rajata kyselyä lähteiden mukaan (Group-and-Source-Specific Query) 55 IGMPv3 Membership Report 0 16 31 Type=0x22 Reserved Checksum Reserved # of Group Records (M) Group Record [1] … Group Record [M] Laite voi kertoa kaikki kuuntelemansa ryhmät yhdellä viestillä Raportin otsikko kertoo kuinka monta ryhmäraporttitietuetta viesti sisältää. 56 IGMPv3 Group Record 0 8 16 31 Record Type Aux Data Len Number of Sources (N) Multicast Address Source Address [1] ... Source Address [N] Auxiliary Data 57 IGMPv3 Group Record (2) Record Type: – MODE_IS_INCLUDE ja MODE_IS_EXCLUDE Kerrotaan vastaanottotila ja halutut tai hylättävät lähteet – INCLUDE: halutaan lähetys vain mainituista lähteistä – EXCLUDE: halutaan lähetys kaikista paitsi mainituista lähteistä – CHANGE_TO_INCLUDE_MODE ja CHANGE_TO_EXCLUDE_MODE Vastaanottotilan vaihtaminen. – ALLOW_NEW_SOURCES ja BLOCK_NEW_SOURCES Uusien lähteiden vastaanottaminen tai vastaanoton lopettaminen. 58 Multicast Listener Discovery v2 (MLDv2, RFC 3810) IGMP:tä vastaava ryhmien hallintaprotokolla IPv6:lle. MLDv2 vastaa IGMPv3:a. MLDv1 vastaa IGMPv2:ta. – Muutettu IPv6:ta varten. MLD ei ole kokonaan erillinen protokolla IP:n päällä kuten IGMP, vaan MLD-viestit välitetään ICMPv6-viestien sisällä – MLD on ICMPv6:n aliprotokolla 59 RYHMÄLÄHETYKSEN REITITTÄMINEN 60 Yksinkertainen tapa ryhmälähetyksen reitittämiseen: Reverse Path Forwarding Käytetään hyväksi lähettäjän osoitetta ja unicast-reititystaulua. – Jos paketti saapuu lähettäjän osoitteen osoittamasta suunnasta, se lähetetään kaikille muille linkeille. Typistävä versio (Truncated Reverse Path Broadcasting, TRPB) – Kuten edellä, mutta lähetetään paketti vain sellaisille reunalinkeille joissa on kyseisen ryhmän vastaanottajia. – Jokaiselta linkiltä valitaan linkkiä palveleva reititin. Reverse Path Multicasting (RPM) – Kuten edellä, mutta tarpeettomat ryhmälähetykset karsitaan (Prune) myös reititinten välisiltä linkeiltä. Reitittimet ilmoittavat toisilleen jos ryhmää ei tarvita. 61 Kaksi tapaa luoda ryhmälähetyspuu Datalähtöinen (data-driven) – Ryhmälähetys välitetään aluksi kaikille linkeille. – Välitys linkille lopetetaan kun saadaan tieto ettei kyseistä ryhmää tarvita sillä linkillä. Tarvelähtöinen (demanddriven) – Ryhmälähetys välitetään vain sellaisille linkeille joilla tiedetään olevan ryhmään kuuluvia vastaanottajia. 62 Distance Vector Multicast Routing Protocol (DVMRP, RFC 1075) Pohjautuu RIP-protokollaan. – IGP-protokolla, soveltuu vain AS:n sisäiseen käyttöön. Reitit lähteisiin välitetään samalla tavalla kuin RIP. Multicast-reititykseen käytetään Truncated Reverse Path Broadcasting-algoritmia. – Datalähtöinen Aiheuttaa turhaa liikennettä verkossa jossa vastaanottajia on harvassa. Käyttää IGMP:tä viestintään muiden reitittimien kanssa – Uusi IGMP-viestityyppi. 63 Core Based Trees (CBT, RFC 2189) Tarvelähtöinen reititysprotokolla Verkossa on core-reititin jokaiselle ryhmälle. – Core-reitittimessä lähettäjät ja vastaanottajat kohtaavat. Reitittimet lähettävät ryhmälähetykset tunneloituna corereitittimelle. Kun ryhmään liitytään, liittymispyyntö välitetään askel askeleelta kohti core-reititintä. – Jatketaan kunnes saavutetaan core-reititin, tai reititin joka on jo liittynyt haluttuun ryhmään. – Kun välityspuu tai core-reititin on saavutettu, lähetetään kuittaus. 64 Multicast OSPF (MOSPF, RFC 1584) OSPFv2:n laajennus ryhmälähetystä varten. Käyttää tarvelähtöistä reititystapaa. Ryhmän vastaanottajat mainostetaan verkkoon LSAtietueilla. Lähettäjän päässä oleva reititin laskee lyhimmän reitin jokaiseen ryhmän vastaanottajaan. – Laskettu tieto talletetaan välimuistiin seuraavia paketteja varten. Paketit välitetään lyhimpää puuta vastaanottajille. 65 Protocol Independent Multicast (PIM) PIM Dense Mode (PIM-DM, RFC 3973) – Tarkoitettu verkkoon, jossa paljon (tiheästi) vastaanottajia. – Käytetään datalähtöistä reititystapaa. PIM Sparse Mode (PIM-SM, RFC 4601) – Tarkoitettu verkkoon, jossa vastaanottajia on harvassa. – Käytetään tarvelähtöistä reititystapaa. Tukee sekä IPv4:ää että IPv6:tta. 66 PIM – reititystaulu PIM käyttää olemassa olevaa unicastreititystaulua verkkojen sijainnin selvittämiseen. – Mitä kautta on lyhin reitti IP-osoitteeseen X? PIM voi käyttää myös erillistä reittitaulua, jossa on ryhmälähetystä tukevan verkon unicast-reitit. – Kaikki osat verkosta eivät välttämättä tue ryhmälähetystä. MBGP:ssä ryhmälähetystä tukevan verkon saavutettavuustiedot kuljetetaan erikseen SAFI=2 –reitteinä. 67 PIM - erityiset reitittimet Rendezvous Point (RP) – PIM-reititin, jonne ASM-ryhmään kohdistuva liikenne lähetetään, ja jonka kautta ryhmään liitytään – vrt. Core Based Trees Designated Router (DR) – Linkkiä palveleva PIM-reititin. – DR huolehtii ryhmälähetyksen välittämisestä linkiltä RP:lle, ja ryhmälähetyksen välittämisestä muualta verkosta linkille. – DR valitaan jokaiselle linkille erikseen. 68 PIM – RP-puu 69 PIM Register-Stop 70 Tilanne Register-Stop-viestin jälkeen 71 PIM Shortest Path Tree 72 PIM – lähdekohtainen ryhmälähetys (SSM) Lähdekohtaisessa ryhmälähetyksessä lähettäjä on oltava vastaanottajan tiedossa. Etuja: – RP:tä ei tarvita. – Vastaanottajan Designated Router voi tehdä (S,G) Joinin suoraan lähettäjälle. SSM on yksinkertaisin ryhmälähetysmenetelmä. – Myös AS:ien välillä Haasteena IGMPv3- ja MLDv2-tuen puute. 73 Autonomisten järjestelmien välinen ASM-reititys Tyypillisesti jokaisessa AS:ssä on oma PIM RP. – RP tietää kaikki AS:n lähteet. Tarvitaan menetelmä jonka avulla saadaan selville muissa AS:issa olevat lähteet. 74 Multicast Source Discovery Protocol (MSDP, RFC 3618) Protokolla aktiivisten multicast-lähteiden mainostamiseen PIM RP:iden välillä. RP:t välittävät Source Active-viestejä (SA) aktiivisista lähteistä. – SA-viestit välitetään AS:ien välillä kaikkialle Internetiin. – Viestien sisältö: Lähteen IP-osoite S Ryhmäosoite G RP:n IP-osoite RP voi tehdä (S,G) Joinin halutun ryhmän AS:n ulkopuolisiin lähteisiin. MSDP toimii TCP:n yli portissa 639. MSDP on toteutettu vain IPv4:lle. 75 Embedded-RP (RFC 3956) Menetelmä jonka avulla ASM saadaan toimimaan AS:ien välillä IPv6-verkossa. Sen sijaan että jaetaan tietoa aktiivisista lähteistä RP:iden välillä, käytetään tietylle ryhmäosoitteelle samaa RP:tä globaalisti. RP:n IP-osoite on upotettu ryhmäosoitteeseen – Esim: ff7e:140:2001:db8:ab:cd::1 40 on prefiksin pituus heksana (64) RP:n osoite: 2001:db8:ab:cd::1 76 RP:n kahdentaminen Kaikki ASM-ryhmälähetys riippuu RP:n toiminnasta. AS:n sisällä RP voidaan kahdentaa anycast-reitityksen avulla. Verkkoon asennetaan kaksi RP:tä. Molemmilla on uniikin IP-osoitteen lisäksi anycast-osoite, joka mainostetaan verkkoon. – – DR:iin konfiguroidaan RP:ksi anycast-osoite. DR:t käyttävät aina verkossa lähempänä olevaa RP:tä. Anycast RP mechanism using PIM and MSDP (RFC 3446) – – PIM RP:iden välille muodostetaan MSDP-sessio, jonka kautta RP:t jakavat tietoa aktiivisista lähteistä. Tukee vain IPv4:ää. Anycast-RP Using PIM (RFC 4610) – – RP:t välittävät vastaanottamansa PIM Register-viestit myös toiselle RP:lle Toimii myös IPv6:lla. Molemmissa vaihtoehdoissa molemmilla RP:illä on sama tieto lähteistä. Kun toinen RP:istä hajoaa, jäljelle jää vain toinen anycast-reitti, ja liikenne ohjautuu kaikkialta verkosta toimivaan RP:hen. 77 DVMRP vs. PIM-SM Rakentaa itse unicastreititystaulun. – Kärsii samoista ongelmista kuin RIP. IGP-protokolla AS:n sisäiseen käyttöön. Datalähtöinen reititystapa Ei juurikaan enää käytössä. Käyttää muiden reititysprotokollien rakentamaa reititystaulua. Voidaan käyttää sekä AS:n sisällä että AS:ien välillä. Tarvelähtöinen reititystapa Laajasti käytössä. Kehitetään aktiivisesti IETF:n PIM-työryhmässä 78 Lähteet Deering, S. "Multicast Routing in Internetwork and Extended LANs", SIGCOMM Summer 1988 Proceedings, August 1988. RFC 1075 Distance Vector Multicast Routing Protocol, 1988 RFC 1584 Multicast Extensions to OSPF, 1994 RFC 1585 MOSPF: Analysis and Experience, 1994 RFC 1773 Experience with the BGP-4 protocol, 1995 RFC 1774 BGP-4 Protocol Analysis, 1995 RFC 1997 BGP Communities Attribute, 1996 RFC 2113 IP Router Alert Option, 1997 RFC 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification, 1997 RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture, 1997 RFC 2918 Route Refresh Capability for BGP-4, 2000 RFC 2974 Session Announcement Protocol, 2000 RFC 3180 GLOP Addressing in 233/8, 2001 RFC 3376 Internet Group Management Protocol, Version 3, 2002 RFC 3446 Anycast Rendezvous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP), 2003 RFC 3618 Multicast Source Discovery Protocol (MSDP), 2003 79 Lähteet (2) RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6, 2004 RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address RFC 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised), 2005 RFC 4271 A Border Gateway Protocol 4 (BGP-4), 2006 RFC 4272 BGP Security Vulnerabilities Analysis, 2006 RFC 4291 IP Version 6 Addressing Architecture, 2006 RFC 4360 BGP Extended Communities Attribute, 2006 RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP), 2006 RFC 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), 2006 RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast, 2006 RFC 4607 Source-Specific Multicast for IP, 2006 RFC 4760 Multiprotocol Extensions for BGP-4, 2007 RFC 4893 BGP Support for Four-octet AS Number Space, 2007 RFC 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM), 2008 RFC 5065 Autonomous System Confederations for BGP, 2007 80 Lähteet (3) RFC 5396 Textual Representation of Autonomous System (AS) Numbers, 2008 RFC 5492 Capabilities Advertisement with BGP-4, 2009 RFC 5519 Multicast Group Membership Discovery MIB, 2009 RFC 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey, 2010 RFC 5771 IANA Guidelines for IPv4 Multicast Address Assignments, 2010 RFC 5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages, 2010 RFC 5925 The TCP Authentication Option, 2010 RFC 6034 Unicast-Prefix-Based IPv4 Multicast Addresses, 2010 RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet, 2011 RFC 6480 An Infrastructure to Support Secure Internet Routing, 2012 RFC 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs), 2012 draft-ietf-sidr-rpki-rtr The RPKI/Router Protocol, 2012 How Pakistan knocked Youtube offline (and how to make sure it never happens again), http://news.cnet.com/8301-10784_3-9878655-7.html 32-bit Autonomous System Number Report, http://www.potaroo.net/tools/asn32/ 81