+ All Categories
Home > Documents > 01 Protocoale Ciclu Ex

01 Protocoale Ciclu Ex

Date post: 26-Dec-2015
Category:
Upload: valentin-daschevici
View: 298 times
Download: 8 times
Share this document with a friend
Description:
a
79
1.1 Protocolul IPX (prescurtare din engleză de la Internetwork Packet Exchange, care s-ar traduce „comutare de pachete între rețele”) este un protocol de rețea bazat pe datagrame și lipsit de conexiuni. Termenul „fără conexiuni” înseamnă că atunci când o aplicație folosește IPX pentru a comunica cu alte aplicații din cadrul rețelei, între cele două aplicații nu se stabilește nicio conexiune la nivelul „Legătură de date” (OSI , nivel 2). Pachetele IPX sunt trimise către destinațiile lor, dar nu se garantează și nici nu se verifică dacă acestea ajung sau nu la destinație. Termenul „datagramă” (în engleză datagram) desemnează faptul că fiecare pachet este tratat ca o entitate individuală care nu are nicio relație secvențială cu alte pachete. IPX execută funcții echivelente nivelului rețea (nivelul 3) din modelul OSI. Aceste funcții includ adresare, rutare și transfer de pachete pentru schimburi de informație, funcțiile IPX fiind dedicate transmisiei de pachete în cadrul rețelei. Mod de funcționare Un mesaj se poate trimite folosind IPX prin plasarea sa în porțiunea de date a pachetului IPX, la fel ca și punerea unui mesaj într-un plic. Header-ul (capul, preambulul) pachetului IPX trebuie să conțină adresa rețelei destinație și numerele de nod și soclu (adică adresa la care trebuie trimis pachetul). IPX trimite fiecare pachet individual, eventual prin diferite subrețele, deci pe rute diferite - pentru a profita de rutele cu trafic momentan mai scăzut, până când pachetul atinge destinația. Deoarece fiecare pachet este o entitate individuală, rutarea și secvențierea pachetelor poate să varieze de la aplicație la aplicație. Când pachetul ajunge la destinație, sursa nu primește nici o informație automată privind livrarea cu succes a pachetului. Doar dacă destinația ia hotărârea să trimită un pachet de confirmare înapoi către sursă, sursa poate fi sigură de livrarea cu succes a pachetului. Când se folosește protocolul IPX, în rețelele actuale sunt trimise cu succes în mod tipic 95 % din pachete. Avantaje și dezavantaje Deoarece IPX execută doar sarcinile nivelului rețea din modelul OSI, încărcarea produsă pe rețea este mică, iar viteza de transmisie (performanța) este bună. Totuși, atunci când sunt necesare garanțiile nivelului transport, serviciile IPX sunt insuficiente. De aceea IPX poate fi folosit doar când se potrivește cu tipul particular de aplicație, alegând în funcție de caz între IPX și SPX . Principalele avantaje și dezavantaje ale IPX sunt: Ca un avantaj, nu este necesară disponibilitatea simultană a sursei și destinației, deoarece nu există o conexiune predeterminată. Totuși, sursa nu primește nici o confirmare a faptului că destinația a primit datele;
Transcript
Page 1: 01 Protocoale Ciclu Ex

1.1 Protocolul IPX (prescurtare din engleză de la Internetwork Packet Exchange, care s-ar traduce „comutare de pachete între rețele”) este un protocol de rețea bazat pe datagrame și lipsit de conexiuni. Termenul „fără conexiuni” înseamnă că atunci când o aplicație folosește IPX pentru a comunica cu alte aplicații din cadrul rețelei, între cele două aplicații nu se stabilește nicio conexiune la nivelul „Legătură de date” (OSI, nivel 2). Pachetele IPX sunt trimise către destinațiile lor, dar nu se garantează și nici nu se verifică dacă acestea ajung sau nu la destinație. Termenul „datagramă” (în engleză datagram) desemnează faptul că fiecare pachet este tratat ca o entitate individuală care nu are nicio relație secvențială cu alte pachete.

IPX execută funcții echivelente nivelului rețea (nivelul 3) din modelul OSI. Aceste funcții includ adresare, rutare și transfer de pachete pentru schimburi de informație, funcțiile IPX fiind dedicate transmisiei de pachete în cadrul rețelei.

Mod de funcționareUn mesaj se poate trimite folosind IPX prin plasarea sa în porțiunea de date a

pachetului IPX, la fel ca și punerea unui mesaj într-un plic. Header-ul (capul, preambulul) pachetului IPX trebuie să conțină adresa rețelei destinație și numerele de nod și soclu (adică adresa la care trebuie trimis pachetul). IPX trimite fiecare pachet individual, eventual prin diferite subrețele, deci pe rute diferite - pentru a profita de rutele cu trafic momentan mai scăzut, până când pachetul atinge destinația. Deoarece fiecare pachet este o entitate individuală, rutarea și secvențierea pachetelor poate să varieze de la aplicație la aplicație.

Când pachetul ajunge la destinație, sursa nu primește nici o informație automată privind livrarea cu succes a pachetului. Doar dacă destinația ia hotărârea să trimită un pachet de confirmare înapoi către sursă, sursa poate fi sigură de livrarea cu succes a pachetului. Când se folosește protocolul IPX, în rețelele actuale sunt trimise cu succes în mod tipic 95 % din pachete.

Avantaje și dezavantajeDeoarece IPX execută doar sarcinile nivelului rețea din modelul OSI, încărcarea

produsă pe rețea este mică, iar viteza de transmisie (performanța) este bună. Totuși, atunci când sunt necesare garanțiile nivelului transport, serviciile IPX sunt insuficiente. De aceea IPX poate fi folosit doar când se potrivește cu tipul particular de aplicație, alegând în funcție de caz între IPX și SPX.

Principalele avantaje și dezavantaje ale IPX sunt: Ca un avantaj, nu este necesară disponibilitatea simultană a sursei și destinației,

deoarece nu există o conexiune predeterminată. Totuși, sursa nu primește nici o confirmare a faptului că destinația a primit datele;

Flexibilitatea în rutarea pachetelor este mare, deoarece nu este necesară o rută a pachetelor predeterminată, fixă;

Pachetele pot fi trimise către destinații multiple pur și simplu prin duplicarea pachetului și schimbarea adresei destinație.

Protocolul IPX (alta sursa)Netware IPX este un protocol bazat pe datagrame (fara conexiune). Termenul fara

conexiune inseamna ca atunci cand o aplicatie foloseste IPX pentru a comunica cu alte aplicatii din cadrul retelei, nu este stabilita nici o conexiune sau cale de date intre cele doua aplicatii. Deci, pachetele IPX sunt trimise catre destinatiile lor, dar nu se garanteaza si nici nu se verifica faptul ca acestea ajung sau nu la destinatie. Termenul datagrama (datagram) desemneaza faptul ca un pachet este tratat ca o entitate individuala, care nu are nici o legatura sau relatie secventiala cu alte pachete.

Page 2: 01 Protocoale Ciclu Ex

IPX executa functii echivelente nivelului retea din modelul OSI. Aceste functii includ adresare, rutare si transfer de pachete pentru schimburi de informatie, functiile IPX fiind dedicate transmisiei de pachete in cadrul retelei.

Avantaje si dezavantajeDeoarece IPX executa doar sarcinile nivelului retea din modelul OSI, ofera

beneficiile vitezei si performantei care rezulta din incarcarea mica pe care o produce. Totusi, serviciile IPX sunt insuficiente daca sunt necesare garantiile nivelului transport. IPX este deci folosit in cazul in care este potrivit tipului particular de aplicatie, alegand in functie de caz IPX sau SPX.

Principalele avantaje si dezavantaje ale IPX sunt:• Disponibilitatea simultana a sursei si destinatiei nu este necesara, deoarece nu

exista o conexiune predeterminata. Totusi, sursa nu primeste nici o confirmare a faptului ca destinatia a primit datele;

• Flexibilitatea in rutarea pachetelor este mare, deoarece nu este necesara o ruta predeterminata a pachetelor;

• Pachetele pot fi trimise catre destinatii multiple pur si simplu prin duplicarea pachetului si schimbarea adresei destinatie.

Un mesaj se poate trimite folosind IPX prin plasarea mesajului in portiunea de date a unui pachet IPX, la fel ca si punerea unui mesaj intr-un plic. Headerul pachetului IPX trebuie sa contina reteaua destinatie, numerele de nod si soclu (adica adresa la care trebuie trimis pachetul). IPX trimite fiecare pachet individual prin diferite subretele (posibil pe diferite rute pentru a profita de traficul mai scazut) pana cand pachetul atinge destinatia. Deoarece fiecare pachet este o entitate individuala, rutarea si secventierea pachetelor poate sa varieze.

Cand pachetul ajunge, sursa nu primeste nici o informatie privind livrarea cu succes a pachetului. Doar daca destinatia ia hotararea sa trimita un pachet catre sursa, sursa poate fi sigura de ajungerea pachetului la destinatie. Oricum, IPX trimite cu succes aproximativ 95% din numarul pachetelor.

Structura pachetului IPXPachetul IPX este identic din punct de vedere al structurii cu un pachet Xerox IDP.

El are doua parti: un header de 30 de octeti si o portiune de date cu o lungime intre 0 si 546 octeti. Lungimea minima a pachetului este 30 octeti (doar headerul), iar lungimea sa maxima este 576 octeti (30+546). Structura pachetului IPX este prezentata in tabelul 1.

Toate campurile sunt structurate high-low, adica cel mai semnificativ octet al campului este primul.

Offset

Continut Tip

0 Checksum BYTEs2t2 Length BYTEs2t4 Transport Control BYTE5 Packet Type BYTE6 Destination Network BYTEs4t10 Destination Node BYTEs6t16 Destination Socket BYTEs2t18 Source Network BYTEs4t22 Source Node BYTEs6t28 Source Socket BYTEs2t30 Data Portion bytes0¸5

46t

Page 3: 01 Protocoale Ciclu Ex

Tabelul 1. Structura pachetului IPX.Semnificatia campurilor headerului este urmatoarea:Checksum (Suma de control)Acest camp a fost inclus pentru conformitate cu headerul original Xerox. IPX il

incarca totdeauna cu valoarea 0FFFFh. Cartelele de retea aplica sume de control intregului pachet IPX, deci acest camp nu este necesar.

Length (Lungime)Acest camp contine lungimea intregului pachet (header+date). Valoarea lui

minima este 30, iar cea maxima 576. IPX seteaza acest camp.Transport Control (Controlul transportului)Acest camp este folosit de bridge-urile inter-retea NetWare. IPX il incarca cu

valoarea 0.Packet Type (Tipul pachetului)Acest camp indica tipul de serviciu oferit sau cerut de catre pachet. Xerox a definit

urmatoarele valori (totusi, utilizatorii IPX trebuie sa seteze valoarea acestui camp la 0 sau 4):

• 0 - Pachet necunoscut;• 1 - Pachet care contine informatii de rutare;• 2 - Pachet in ecou;• 3 - Pachet de eroare;• 4 - Packet Exchange Packet (pachet IPX);• 5 - Sequenced Packet Protocol Packet (pachet SPX);• 16¸31 - Protocoale experimentale;• 17 - Protocol NetWare Core (Core = miez).Utilizatorii IPX trebuie sa seteze tipul pachetului la 0 sau 4, iar utilizatorii SPX

trebuie sa-i dea valoarea 5.Destination Network (Reteaua destinatie)Acest camp contine numarul retelei careia ii apartine nodul destinatie. in cazul

NetWare, retelele din cadrul unei retele globale primesc de la administratorul retelei globale un numar unic de 4 octeti. Cand acest camp este 0, nodul destinatie este in aceeasi retea ca si nodul sursa, pachetul nefiind procesat de un bridge inter-retea.

Destination Node (Nodul destinatie)Acest camp contine adresa fizica a nodului destinatie. Lungimea acestui camp este

variabila in functie de topologia retelei. Un nod din cadrul unei retele Ethernet va avea o adresa fizica de 6 octeti, pe cand un nod din cadrul unei retele Omninet va avea o adresa de un octet. Daca o adresa fizica are lungimea mai mica de 6 octeti, adresa trebuie sa ocupe cea mai putin semnificativa pozitie in cadrul campului, prima parte a acestuia trebuind completata cu zero. O adresa de nod egala cu 0FFFFFFFFFFFFh (6 octeti formati numai din biti unu) identifica un pachet broadcast.

Destination Socket (Soclul destinatie)Acest camp contine adresa soclului procesului destinatie a pachetului. Soclurile

ruteaza pachetele catre diferite destinatii in cadrul aceluiasi nod. Xerox a rezervat urmatoarele numere de socluri:

• 1 - Routing Information Packet;• 2 - Echo Protocol Packet;• 3 - Error Handler Packet;• 20h¸03Fh - Experimental;• 1¸0BB8h - Registered with Xerox;Xerox a asignat pentru Novell un set de socluri pentru folosirea de catre NetWare:• 451 - File Service Packet;• 452 - Service Advertising Packet;• 453 - Routing Informaton Packet;

Page 4: 01 Protocoale Ciclu Ex

• 455 - NetBIOS Packet;• 456 - Diagnostic Packet.De exemplu, serverele NetWare accepta cereri adresate soclului 451.Source Network (Reteaua sursa)Source Node (Nodul sursa)Source Socket (Soclul sursa)Aceste trei campuri au semnificatii similare cu cele corespunzatoare destinatiei.

1.3 Protocolul SPXSPX este identic cu IPX cu exceptia faptului ca ofera servicii suplimentare conferite de

faptul ca se afla la nivelul transport din modelul OSI, spre deosebire de IPX, aflat la nivelul retea. Aceste functii suplimentare fac din SPX un protocol orientat catre conexiune. Aceasta inseamna ca inainte ca un pachet SPX sa fie trimis, se stabileste o conexiune intre sursa si destinatie. SPX garanteaza livrarea datelor, secventierea pachetelor, detectarea si corectarea erorilor si suprimarea pachetelor duplicate.

Avantaje si dezavantajeIn schimbul acestor garantii, SPX nu are viteza si performantele IPX. Proiectantul de

aplicatii trebuie sa determine ce este mai important pentru aplicatiile sale: viteza sau siguranta livrarilor. Astfel, el va alege IPX sau SPX. Iata in continuare cateva dintre avantajele si dezavantajele folosirii SPX:

• Livrarea garantata a datelor; conexiunea este stabilita inainte ca informatia sa fie trimisa si la sursa se intorc informatii privind livrarea cu succes. Trimiterea de pachete broadcast este greoaie, deoarece trebuie stabilita o conexiune cu fiecare potential receptor inainte. De asemenea, unele aplicatii nu au nevoie de garantarea livrarii fiecarui pachet;

• Secventiere garantata a pachetelor; deci, oricate pachete ar cere transmiterea unui flux de date, acestea vor ajunge in ordine;

• Suprimarea pachetelor duplicat; in timpul procesului de garantare a livrarii (care include retransmiterea pachetelor considerate pierdute), este posibila aparitia unor pachete duplicat care ajung ambele la nodul destinatie; SPX elimina astfel de pachete, deci aplicatia primeste doar o copie a datelor trimise de catre partenerul de comunicatie.

2.1 Structura pachetelor SPXUn pachet SPX este identic ca structura cu un pachet IPX, cu exceptia faptului ca are

12 octeti suplimentari in header. Pachetul SPX consta din doua parti: un header de 42 de octeti si un camp de date care poate contine intre 0 si 534 octeti. Lungimea minima a pachetului este de 42 octeti (doar headerul), iar cea maxima de 576 octeti (42+534).

Campurile pachetului SPX care au aceeasi denumire ca si cele din cadrul pachetelor IPX au si aceeasi semnificatie ca si acestea, cu specificarea ca niciodata in cadrul unui pachet SPX nu se permite o valoare 0FFFFFFFFFFFFh a adresei nodului destinatie (nu sunt permise broadcast-uri), iar SPX incarca totdeauna valoarea 5 in campul Packet Type. In tabelul 2 este prezentata structura pachetului SPX:

Offset

Continut Tip

0 Checksum BYTE[2]2 Length BYTE[2]4 Transport Control BYTE5 Packet Type BYTE

6 Destination Network BYTE[4]10 Destination Node BYTE[6]16 Destination Socket BYTE[2]

18 Source Network BYTE[4]22 Source Node BYTE[6]

Page 5: 01 Protocoale Ciclu Ex

28 Source Socket BYTE[2]

30 Connect. Control BYTE31 Data Stream Type BYTE32 Source Connect. ID BYTE[2]34 Dest. Connect ID BYTE[2]36 Sequence Number BYTE[2]38 Acknowledge Number BYTE[2]40 Allocation Number BYTE[2]

42 Data Portion BYTE[0¸534]

 Tabelul 2. Structura pachetului SPX.

Ordinea octetilor in cadrul campurilor este high-low, ca si in cazul IPX. Semnificatiile campurilor suplimentare fata de cele din cadrul headerului IPX sunt:

Connection Control (Controlul conexiunii)Acest camp contine 4 indicatori de 1 bit folositi de SPX si clientii sai pentru a controla

fluxul bidirectional de date de-a lungul unei conexiuni:• 1¸8 - Valori nedefinite de catre Xerox Sequenced Packet Protocol. SPX ii ignora;• 10h - Sfarsitul unui mesaj; clientul seteaza acest bit pentru a semnala sfarsitul

mesajului partenerului sau; SPX ignora acest bit si il livreaza neschimat partenerului;• 20h - Atentie; clientul seteaza acest indicator daca pachetul este un pachet de

atentionare; aceasta facilitate nu a fost implementata; SPX ignora acest bit si il livreaza neschimat partenerului;

• 40h - Se cere confirmare; SPX seteaza acest bit daca este necesar un pachet de confirmare; deoarece SPX controleaza cererile si raspunsurile de confirmare, clientul trebuie sa ignore acest indicator;

• 80h - Pachet sistem; SPX seteaza acest bit daca pachetul este un pachet sistem; aceste pachete sunt folosite intern si nu sunt livrate clientilor.

 Clientii nu trebuie sa foloseasca sau sa modifice niciodata bitii nedefiniti, de

confirmare sau sistem. Acestia sunt rezervati pentru folosirea de catre SPX.Data Stream Type (Tipul fluxului de date)Acest camp este un indicator de un octet care arata tipul datelor care au fost gasite in

cadrul pachetului. Valorile posibile sunt aratate in continuare:• 0¸0FDh - Definit de client; SPX ignora aceste valori;• 0FEh - Sfarsitul conexiunii; cand un client executa un apel pentru a termina o

conexiune activa, SPX va genera un pachet de terminare a conexiunii. Acesta va fi ultimul pachet trimis partenerului in cadrul conexiunii;

• 0FFh - Confirmarea sfarsitului conexiunii; SPX genereaza un pachet de confirmare a sfarsitului conexiunii automat; acest pachet este marcat sistem si nu este livrat clientilor.

 Source Connection ID (Identificatorul sursei)Acest camp contine un numar de identificare asignat de catre SPX sursei pachetului.Destination Connection ID (Identificatorul destinatiei)Acest camp contine un numar de identificare asignat de catre SPX destinatiei

pachetului si folosit pentru demultiplexarea pachetelor sosite in cadrul multiplelor conexiuni care ajung la acelasi soclu; demultiplexarea este necesara deoarece conexiunile active concurente de pe orice masina pot folosi acelasi numar de soclu.

Sequence Number (Numarul de secventa)Acest camp retine numarul pachetelor schimbate intr-o directie a conexiunii. Fiecare

parte a conexiunii tine propriul contor. Numarul ia valoarea zero dupa ce depaseste 0FFFFh. Deoarece SPX controleaza acest camp, clientii nu sunt interesati de valoarea lui.

Acknowledge Number (Numar de confirmare)

Page 6: 01 Protocoale Ciclu Ex

Acest camp indica numarul de secventa al urmatorului pachet pe care SPX se asteapta sa il receptioneze. Orice pachet cu un numar de secventa mai mic decat valoarea acestui camp este in secventa corecta si nu trebuie retransmis. Deoarece SPX controleaza acest camp, clientii nu sunt interesati de valoarea lui.

Allocation Number (Numar de buffere alocate)Acest camp indica numarul de buffere de ascultare disponibile intr-o directie a

conexiunii. SPX poate sa trimita pachete doar pana cand numarul de secventa devine egal cu numarul de buffere alocate la celalalt capat al conexiunii. Deoarece SPX controleaza acest camp, clientii nu sunt interesati de valoarea lui.

1.5 Protocolul Internet[1] (sau IP din engl. Internet Protocol) este un protocol prin care datele sunt trimise de la un calculator la altul prin intermediu Internetului. Fiecare calculator (cunoscut sub denumirea de „gazdă”), are pe Internet cel puțin o adresă IP unică, care îl identifică între toate computerele din rețea. Când cineva trimite sau primește informații (de ex.: poștă electronică, pagini web) mesajul este împărțit în blocuri de mici dimensiuni denumite pachete. Fiecare pachet cuprinde adresa expeditorului și pe cea a destinatarului. Fiecare pachet este trimis, prima dată la un calculator-pasarelă, care înțelege o mică parte din internet.

Calculatorul pasarelă citește destinația pachetelor și trimite pachetele către o altă pasarelă, și așa mai departe, până ce pachetul ajunge la pasarela vecină cu computerul destinatar.

Adresa IP este utilizată la nivelul programelor de prelucrare în rețea. În schimb, la nivelul utilizatorilor cu acces la Internet, identificarea calculatoarelor se face printr-un nume de gazdă gestionat de sistemul DNS.

Funcționare IPComunicația în Internet funcționează după cum urmează: nivelul transport preia

șiruri de date și le divide în datagrame. Teoretic, datagramele pot avea fiecare până la 64 KO, dar în practică ele nu depășesc 1500 de octeți (pentru a intra într-un cadru Ethernet). Fiecare datagramă este transmisă prin Internet, fiind eventual fragmentată în unități mai mici pe parcurs. Când toate aceste „fragmente” ajung la mașina destinație ele sunt reasamblate de nivelul rețea în datagrama originală. Datagrama este transparentă nivelului transport, care o inserează în șirul de intrare al procesului receptor. Cea mai mică adresă este 0.0.0.0, iar cea mai mare 255.255.255.255. Adresa IP 0.0.0.0 este folosită de gazde atunci când sunt pornite. Adresele IP cu 0 ca număr de rețea se referă la rețeaua curentă. Aceste adrese permit ca mașinile să acceseze propria rețea fără a cunoaște numărul de rețea (dar trebuie cunoscută clasa rețelei pentru a ști câte zerouri trebuie introduse). Adresele care constau numai din 1-uri permit difuzarea în rețeaua curentă, în mod uzual o rețea locală. Toate adresele de forma 127.xx.yy.zz sunt rezervate pentru testări în buclă locală. Pachetele trimise către această adresă nu sunt trimise prin cablu ele sunt prelucrate local și tratate ca pachete sosite.

O datagramă IP (un pachet) constă dintr-o parte de antet și o parte de text. Antetul are o parte fixă de 20 octeți și o parte opțională de lungime variabilă.

Fiecare gazdă și ruter din internet are o adresă IP, care codifică adresa sa de rețea și de gazdă. Combinația este unică: în principiu nu există două mașini cu aceeași adresă IP. Toate adresele IP sunt de 32 biți și sunt folosite în câmpurile „Adresă sursă” și „Adresă destinație” a pachetelor IP. Este important de observat că o adresă IP nu se referă la o gazdă. Se referă, de fapt, la o interfață de rețea. Cu alte cuvinte, dacă o gazdă este în două rețele, trebuie să folosească două adrese IP .

Page 7: 01 Protocoale Ciclu Ex

Rețelele sunt dinamice și este posibil ca 2 pachete IP de la aceeași sursă să plece pe căi diferite (BGP – protocolul porților de graniță) și să ajungă la aceeași destinație. Pachetele IP (dupa cum s-a mai spus) nu au garanția că vor ajunge la destinație, acest lucru fiind lăsat în seama protocoalelor adiacente (TCP UDP etc).

Antetul IP

Versiune

IHLTip

serviciuLungime totală

IdentificatorDelimitato

riDecalaj de

fragmentare

Durata de viață Protocol Suma de control a antetului

Adresa expeditorului

Adresa destinatarului

Opțiuni Spațiere

Antentul IP: Versiune – versiunea pachetului IP (curentă este 4) IHL – lungimea antetului IP de ieșire Tip serviciu – permite gazdei să comunice ce tip de serviciu dorește Lungimea totală – lungimea pachetului Identificator – identificarea pachetului Delimitatori – conține 1 bit nefolosit 1 bit DF (fără fragmentare) și unul MF (non-

fragment) Decalaj fragmentare – indică unde este locul fragmentului în datagramă Durata de viață – timpul de viața al pachetului (secunde), care se decrementeaza

la fiecare HOP (trecere dintr-un router în altul) Protocol – indică cărui proces de transport să-l predea (TCP, UDP, etc.) Suma de control a antetului Adresa de expediție Adresa de destinație Opțiuni – opțiuni ale pachetului (securitate, dirijare strictă pe baza sursei, dirijare

aproximativă pe baza sursei, înregistrare cale, amprenta de timp) Niciunul din câmpurile IP nu sunt criptate și niciunul nu necesită autentificare.

Protocolul pentru transfer de fișiere (are responsabilitate pentru a transporta datele) (în engleză File Transfer Protocol, abreviat FTP) este un protocol (set de reguli) utilizat pentru accesul la fișiere aflate pe servere din rețele de calculatoare particulare sau din Internet

Protocolul de Acces la Mesaje Internet (în engleză Internet Message Access Protocol, abreviat IMAP) permite accesul la mesaje din foldere de e-mail de pe un server. (are responsabilitate pentru a manipula căsuța poștală)

POP3 sau Protocolul Post Office – Versiunea 3 este, alături de IMAP, unul din protocoalele utilizate de un calculator gazdă pentru recepționarea poștei electronice (e-mail). (are responsabilitate pentru a „scoate” scrisorile din căsuța poștală)

HTTP (Hypertext Transfer Protocol) este metoda cea mai des utilizată pentru accesarea informațiilor în Internet care sunt păstrate pe servere World Wide Web (WWW).

HTTP oferă o tehnică de comunicare prin care paginile web se pot transmite de la un computer aflat la distanță spre propriul computer. Dacă se apelează un link sau o

Page 8: 01 Protocoale Ciclu Ex

adresă de web cum ar fi http://www.example.com, atunci se cere calculatorului host să afișeze o pagină web (index.html sau altele).

SMTP (Simple Mail Transfer Protocol) este un protocol simplu, folosit pentru transmiterea mesajelor în format electronic pe Internet. SMTP folosește portul de aplicație 25 TCP și determină adresa unui server SMTP pe baza înregistrării MX (Mail eXchange) din configurația serverului DNS. (are responsabilitate pentru a trimite scrisorile în căsuța poștală)

+Protocolul Internet (Internet Protocol-IP)Intre protocoalele de nivel 3 (nivelul REtEA) documentate de Departamentul de

Aparare al Statelor Unite (DoD - Department of Defense), Internet Protocol este cel mai important. Principalul sau scop este de a interconecta mai multe retele bazate pe schimbul de pachete intr-o supra-retea (internet - in continuare vom intelege prin internet (scris cu litere mici) orice supraretea (retea globala). Atunci cand este nevoie sa se specifice in mod explicit ca este vorba despre reteaua Internet initiata de catre DoD, cuvantul Internet se va scrie cu prima litera capitalizata). IP isi ofera serviciile diferitelor protocoale de pe nivelele superioare (Upper Layer Protocols - ULP) prin asistarea livrarii datelor ULP prin internet in cadrul unuia sau mai multor blocuri de date (datagrams).

Figura 1. O privire din punct de vedere logic asupra structurii Internet la nivelul IPArhitectura internet permite o ierarhie de retele independente logic pe doua

nivele. Nivelul cel mai de sus este conexiunea intre retele pereche. O retea poate sa contina o colectie de subretele pereche. Retelele si subretelele pot sa contina hosturi atasate direct, dupa cum se poate observa in figura 1.

Singura diferenta intre retele si subretele consta in modul in care sunt interpretate adresele IP si depinde de localizarea modulului IP specificat de adresa. In majoritatea cazurilor, subretelele pot fi numite pentru simplitate retele. In general, termenul "subretea" este folosit doar in cazul in care este necesar sa se faca distinctia intre diferitele nivele ierarhice ale internet.

IP este limitat la functiile de baza necesare transmisiei unui bloc de date (datagram) prin internet. Fiecare bloc de date este o entitate independenta, nefiind legata de alte "datagrame" (traducerea, poate putin fortata, a termenului "datagram" este preluata din cartea "Retele de calculatoare", cu semnificatia "mesaj fara confirmare"). Nivelul IP al hostului asigura servicii protocoalelor de la nivelul transport si foloseste serviciile nivelului legaturii de date pentru a transmite datagramele hostului destinatie. IP nu pretinde ca ar oferi servicii sigure. Calculatoarele gazda (hosts) vor ignora datagramele atunci cand nu au resurse suficiente pentru procesare si nu vor detecta datagramele pierdute sau ignorate de catre nivelul legaturii de date.

IP izoleaza protocoalele de pe nivelele superioare de caracteristicile specifice retelei. Serviciile aditionale furnizate de catre IP includ diferite nivele de comportare a transmisiei, implicand caracteristici ca: precedenta, nivel de incredere, intarzieri. IP permite de asemenea etichetarea datelor, necesara in medii sigure, pentru a asocia datelor informatii de securitate.

Transmisia incepe atunci cand un protocol de pe nivelul superior transmite date catre IP pentru livrare. IP impacheteaza datele in format internet datagram si le transmite protocolului de pe nivelul legaturii de date pentru transmisie prin reteaua locala. Daca hostul destinatie se afla legat direct in reteaua locala, IP trimite pachetul direct acestui host. Daca destinatia se afla intr-o alta retea, IP trimite pachetul unui gateway IP local pentru transmisie. Acest gateway va trimite pachetul prin urmatoarea retea hostului destinatie sau unui alt gateway. Astfel, datagrama se propaga prin setul de retele interconectate de la un modul IP la altul, pana cand aceasta ajunge la

Page 9: 01 Protocoale Ciclu Ex

destinatie. Pachetele transmise de catre hostul numarul 1 pot sa circule pe una dintre cele doua cai prezentate. (figura 2)

Figura 2. Transmisia datelor prin intermediul IPGateway-urile, uneori numite "Routere IP" (sau "Local Bridges" ori "Remote

Bridges") sunt de fapt un fel de "relee de pachete" care interconecteaza doua sau mai multe retele sau subretele. Fiecare gateway contine un modul IP aflat deasupra a doua sau mai multe procese bazate pe protocoale aflate la nivelul legaturii de date.

Modulele IP folosesc reguli comune pentru interpretarea adreselor internet necesare in procesul stabilirii traseului pe care pachetul trebuie sa-l urmeze pentru a ajunge la destinatie. Rutarea executata de catre un gateway se bazeaza pe campul network/subnetwork al adresei internet de destinatie.

Un gateway atasat mai multor retele trebuie sa decida care este reteaua urmatoare prin care trebuie sa treaca pachetul pe care l-a primit pentru a ajunge la destinatie. De asemenea, trebuie sa decida daca hostul destinatie se afla in cadrul urmatoarei retele (caz in care pachetul poate fi trimis direct acestui host) sau daca cel putin un alt gateway este necesar pentru a trimite pachetul catre reteaua destinatie aflata la distanta.

Pentru a determina care este urmatorul gateway caruia trebuie sa-i fie transmis pachetul, echipamentul gateway curent trebuie sa cunoasca optiunile pe care le are la dispozitie si modul de alegere a urmatorului gateway dintre cele disponibile. Echipamentul gateway curent trebuie sa fie capabil sa achizitioneze intr-un fel oarecare informatii despre alte echipamente gateway si despre caile disponibile pentru ca un pachet sa poata atinge reteaua destinatie. Cel mai bine ar fi ca aceste informatii privind posibilitatea atingerii de catre un pachet a unei retele indepartate sa poata fi achizitionata si mentinuta dinamic, in acord cu conectivitatea instantanee asigurata de toate celelalte echipamente gateway ale retelei globale (internet). Pentru a putea fi atins acest scop, echipamentele gateway trebuie sa fie capabile sa schimbe intre ele informatii asupra posibilitatii de a trimite un pachet catre diferite retele. De-a lungul anilor, au fost dezvoltate mai multe protocoale gateway-gateway, protocoale care cauta sa furnizeze acest schimb de informatii.

Echipamentele gateway care conecteaza un set de retele private din punct de vedere al proprietatii si administrarii pot sa foloseasca orice protocol, fara restrictii. De obicei, un asemenea protocol privat se numeste Interior Gateway Protocol (IGP). In termeni IP, fiecare astfel de retea administrata independent este numita sistem autonom (Autonomous System).

Pe de alta parte, toate echipamentele gateway care fac legatura intre retele private si retele publice de date (DDN, Digital Data Networks) trebuie sa foloseasca un protocol oficial simplu si bine definit numit Exterior Gateway Protocol.

Headerul IPPachetele (datagramele) IP au un antet (header) bine definit, header definit de

standardele DoD (U.S.A. Department of Defense). Acest header are structura prezentata in figura 3.

In continuare sunt prezentate campurile care compun acest header: Version (Versiune)Abreviere: VERLungimea campului: 4 bitiCampul Version indica formatul headerului IP. Va fi prezentata in continuare

versiunea 4, ultima pana la data aparitiei materialului bibliografic avut la dispozitie (1988). Versiunile 1¸3 nu mai erau deja folosite inca la acea data.

Page 10: 01 Protocoale Ciclu Ex

Campul Version indica versiunea protocolului careia ii apartine pachetul. Includerea versiunii protocolului in fiecare pachet face posibila dezvoltarea de noi protocoale si testarea acestora fara a afecta buna functionare a retelei.

Internet Header Length (Lungimea headerului Internet)Abreviere: IHLLungimea campului: 4 bitiUnitate: Grupe de cate 4 octetiGama: 5¸15 (implicit 5)Campul Internet Header Length indica lungimea headerului IP exprimata in multipli

de unitati de 32 biti. Acest camp este necesar deoarece headerul IP are o lungime variabila datorita faptului ca lungimea campului Options nu este constanta.

Figura 3. Headerul IPType of Service (Tipul de serviciu)Abreviere: TOSLungimea campului: 8 bitiCampul Type of Service contine parametrii IP care descriu calitatea serviciului

dorita pentru prezentul pachet transmis. Campul permite calculatorului gazda sa specifice retelelor de tranzit tipul de serviciu pe care il doreste. Campul permite specificarea precedentei pachetului, nivelul dorit de incredere si nivelul presupus de consumare a resurselor, dupa cum se va arata mai jos.

Tipul de serviciu se foloseste pentru a specifica retelelor de tranzit ce serviciu se doreste de la acestea. Retelele de tranzit decid daca pot sau doresc sa se achite de serviciile cerute.

Total Length (Lungimea totala)Abreviere: TLLungimea campului: 16 bitiTotal Length este lungimea pachetului, masurata in octeti, incluzand headerul IP si

zonele de date ale pachetului.Se observa ca lungimea campului Total Length permite o lungime totala maxima a

pachetului de 65.536 octeti.Identification (Identificare)Abreviere: IDLungimea campului: 16 bitiCampul reprezinta o valoare de identificare folosita pentru a asocia fragmentele

unui pachet. ULP (Upper Layer Protocol) care transmite de obicei genereaza aceasta valoare ca pe un parametru al interfetei. Altfel, IP genereaza acest camp in asa fel incat el sa fie unic pentru fiecare ULP care transmite.

Campul Identification indica numarul pachetului pentru a permite calculatorului gazda destinatie sa determine carui pachet ii apartine fragmentul care tocmai a sosit.

Flags (Indicatori)Abreviere: -Lungimea campului: 3 bitiAcest camp contine indicatorii de control Don't Fragment (a nu se fragmenta, care

inhiba fragmentarea pachetului de catre IP) si More Fragments(care ajuta la identificarea pozitiei unui fragment in pachetul original).

Indicatorul Don't Fragment este destinat pentru folosirea cu calculatoare gazda care nu sunt capabile sa reconstituie pachetul din fragmentele din care este format. De fapt, multe implementari ale TCP/IP nu permit fragmentarea si reconstituirea pachetelor.

Fragment Offset (Offsetul fragmentului)Abreviere: FOLungimea campului: 13 biti

Page 11: 01 Protocoale Ciclu Ex

Unitate: Grupe de cate 8 octetiGama: 0¸8191 (implicit 0)Campul indica pozitia fragmentului relativ la inceputul datelor in pachetul original.

Atat un pachet complet, cat si primul fragment al unui pachet au acest camp resetat.Fragment Offset localizeaza pozitia fragmentului curent intr-un pachet ca multiplu

de 8 biti. Pentru aceasta, lungimea campului este de 13 biti, deci sunt permise maximum 8.192 fragmente pentru fiecare pachet, in acest caz extrem, primele 8.191 fragmente vor avea lungimea de un octet.

Time-to-Live (Timp de viata)Abreviere: TTLLungimea campului: 8 bitiUnitate: secundeGama: 0¸255 (255=4,25 minute)Acest camp indica timpul maxim cat poate sa ramana pachetul in internet. Cand

valoarea acestui camp, dupa decrementare, ia valoarea zero, pachetul ar trebui distrus.Unitatea de timp utilizata pentru masurarea timpului de viata al pachetului este

secunda, deci timpul maxim de viata al unui pachet este 255 secunde (4,25 minute).Valoarea campului este scazuta cu cel putin 1 de catre fiecare router prin care

trece pachetul.Protocol (Protocol)Abreviere: PROTLungimea campului: 16 bitiAcest camp arata care ULP (Upper Level Protocol) trebuie sa receptioneze

portiunea de date a unui pachet. Numerele asignate ULP-urilor uzuale sunt disponibile de la DoD Executive Agent for Protocols. Unele vor fi aratate mai jos, in tabelul 3.

Campul Protocol specifica protocolul particular de la nivelul 4 caruia ii apartine pachetul (de exemplu, TCP sau alt protocol echivalent).

Numar (zecimal)

Prescurtare

Descriere

0   Reserved1 ICMP Internet Control Message5 ST Stream6 TCP Transmission Control Protocol8 EGP

1.6 IP (Internet Protocol) este un protocol care asigură un serviciu de transmitere a

datelor, fără conexiune permanentă. Acesta identifică fiecare interfață logică a

echipamentelor conectate printr-un număr numit „adresă IP". Versiunea de standard

folosită în majoritatea cazurilor este IPv4. În IPv4, standardul curent pentru comunicarea

în Internet, adresa IP este reprezentată pe 32 de biți (de ex. 192.168.0.1). Alocarea

adreselor IP nu este arbitrară; ea se face de către organizații însărcinate cu distribuirea de

spații de adrese. De exemplu, RIPE este responsabilă cu gestiunea spațiului de adrese

atribuit Europei.

Internetul este în proces de evoluție către versiunea următoare de IP, numită IPv6,

care practic așteaptă un utilizator major, care să oblige folosirea acestei versiuni superioare

Page 12: 01 Protocoale Ciclu Ex

și de către alții. Ramurile Ministerului Apărării al SUA (DoD) au anunțat ca în decursul

anilor 2009 - 2011 vor înceta relațiile cu furnizorii de servicii Internet care nu folosesc IPv6.Adresele IPv4 au o lungime de 32 de biți (4 octeți). Fiecare adresă identifică o rețea

(network) și o stație de lucru (work station) din cadrul rețelei. Notația obișnuită este obținută prin scrierea fiecărui octet în formă zecimală, separați între ei prin puncte. De exemplu, 192.168.0.1(10) este notația folosită pentru adresa 11000000.10101000.00000000.00000001(2).

Clase de adreseLa începuturile Internetului, adresele IPv4 se împărțeau în 5 clase de adrese, notate de

la A la E. Împărțirea se făcea în funcție de configurația binară a primului octet al adresei,

astfel:

Cla

sa

Primul

octet în binar

Prima

adresă

Ultima

adresăObservații

A 0xxxxxxx 0.0.0.1127.255.255.

255

folosește 8 biți pentru

rețea și 24 pentru stația de

lucru

B 10xxxxxx128.0.0.

0

191.255.255.

255

folosește 16 biți pentru

rețea și 16 pentru stație

C 110xxxxx192.0.0.

0

223.255.255.

255

folosește 24 biți pentru

rețea și 8 pentru stație

D 1110xxxx224.0.0.

0

239.255.255.

255

folosită pentru

adresarea de tip multicast

Page 13: 01 Protocoale Ciclu Ex

E 11110xxx240.0.0.

0

255.255.255.

255

utilizată în scopuri

experimentale

Adresele rețelelor au toți biții de stație 0 și nu pot fi folosite pentru o stație. În plus,

mai există și adrese de difuzare, care au toți biții de stație 1.

Pentru identificarea stațiilor se folosesc numai adresele de clasă A până la C. În plus,

există două intervale de adrese de clasă A nefolosite în Internet:

Intervalul 0.0.0.0 - 0.255.255.255 nu se folosește, pentru a nu fi confundat cu ruta

implicită;

Intervalul 127.0.0.0 - 127.255.255.255 este folosit numai pentru diagnosticarea

nodului local (întotdeauna acesta va fi cel care va răspunde la apelul unei adrese din

aceasta clasă).

Din păcate, această metodă risipea multe adrese IP, iar odată cu răspândirea

Internetului a apărut pericolul epuizării spațiului de adrese. Pentru a soluționa această

problemă, la începutul anilor '90 au fost concepute mai multe soluții:

adrese private

CIDR

VLSM

Metodele de mai sus aveau rolul de a prelungi viața lui IPv4. În plus, a fost conceput și

un nou protocol, IPv6.

Adrese privateDispozitivele neconectate la Internet nu au nevoie de o adresă IP unică. Pentru aceste

dispozitive au fost standardizate adresele private. Aceste adrese nu sunt unice la nivelul

Internetului și de aceea nu sunt rutate de dispozitivele de nivel 3. În RFC 1918 au fost

definite trei intervale rezervate pentru adresare privată:

Adrese rezervate pentru clasa A: 10.0.0.0 - 10.255.255.255

Adrese rezervate pentru clasa B: 172.16.0.0 - 172.31.255.255

Adrese rezervate pentru clasa C: 192.168.0.0 - 192.168.255.255

Nu este obligatoriu ca fiecare bloc de adrese să fie alocat unei singure rețele. De

obicei, administratorul de rețea va împărți un bloc în subrețele; de exemplu, multe rutere

pentru uz personal folosesc subrețeaua 192.168.0.0 - 192.168.0.255 (192.168.0.0/24).

SubrețeleAtât adresele IPv4 cât și cele IPv6 folosesc subnetarea, care constă în împărțirea

adresei IP în două părți: adresa de rețea și adresa de stație. Folosind o mască de rețea,

calculatorul poate determina unde să împartă adresa IP (conform standardului RFC 950).

Subnetarea a apărut ca soluție pentru problema epuizării spațiului de adrese IP. Odată

cu subrețelele a apărut distincția între adresarea "classfull" (care ține cont de clasele de

adrese) și adresarea "classless" (care oferă suportul pentru câmpul de subrețea).

În 1992 au fost introduse și mecanismele de rutare pentru adresarea classless. Aceste

mecanisme vizau atât protocoalele de rutare (CIDR), cât și protocoalele rutate (VLSM).

Page 14: 01 Protocoale Ciclu Ex

VLSM

VLSM (Variable Length Subnet Mask) este un procedeu care presupune precizarea unei

măști de rețea pentru fiecare adresă asociată unei interfețe. Acest lucru permitea

împărțirea unei clase de adrese în mai multe rețele de dimensiuni diferite, micșorând astfel

irosirea de adrese IP.

De exemplu, pentru o rețea de 20 de calculatoare (stații) se puteau folosi acum doar

32 de adrese (o rețea /27), față de 256 de adrese (o rețea de clasă C, /24).

CIDR

CIDR (Classless InterDomain Routing) se referă la modul de reprezentare a adreselor

IP în tabela de rutare și la modul de trimitere a mesajelor de actualizare. În notația CIDR,

adresa IP este reținută întotdeauna împreună cu masca de rețea. De exemplu, o adresă IP

de tipul 192.0.2.1, cu masca 255.255.255.0, ar fi scrisă în notația CIDR ca 192.0.2.1/24,

deoarece primii 24 de biți din adresa IP indică subrețeaua.

Faptul că în tabela de rutare este precizată și masca de rețea permite agregarea

(unirea) rețelelor vecine, reducând dimensiunea tabelei de rutare. De exemplu, rețelele

192.0.2.0/24 și 192.0.3.0/24 vor fi reținute ca 192.0.2.0/23:

192.0.2.0/24 = 11000000.00000000.00000010. / 00000000

192.0.3.0/24 = 11000000.00000000.00000011. / 00000000

-----------------------------------------------------

192.0.2.0/23 = 11000000.00000000.0000001 / 0.00000000

IPv6Pentru mai multe detalii, vedeți  IPv6.

O adresă IPv6 în binar și hexazecimal

IPv6 este un protocol dezvoltat pentru a înlocui IPv4 în Internet. Adresele au o lungime

de 128 biți (16 octeți), ceea ce este considerat suficient pentru o perioadă îndelungată.

Teoretic există 2128, sau aproximativ 3,403 × 1038 adrese unice. Lungimea mare a adresei

permite împărțirea în blocuri de dimensiuni mari și implicit devine posibilă introducerea

unor informații suplimentare de rutare în adresă.

Windows Vista, Mac OS X, toate distribuțiile moderne de Linux [1] , precum și foarte

multe alte sisteme de operare includ suport "nativ" pentru acest protocol. Cu toate acestea,

IPv6 nu este încă folosit pe scară largă de către furnizorii de acces și servicii Internet,

numiți Internet Service Providers sau ISP.

Page 15: 01 Protocoale Ciclu Ex

NotațieAdresele IPv6 sunt scrise de cele mai multe ori sub forma a 8 grupuri de câte 4

cifre hexazecimale, fiecare grup fiind separat de două puncte (:). De

exemplu, 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 este o adresă IPv6 corectă.

Dacă unul sau mai multe din grupurile de 4 cifre este 0000, zerourile pot fi omise și

înlocuite cu două semne două puncte(::). De

exemplu,2001:0db8:0000:0000:0000:0000:1428:57ab se prescurtează 2001:0db8::1428:57ab.

Această prescurtare poate fi făcută o singură dată, altfel ar putea apărea confuzii cu privire

la numărul de câmpuri omise. Plecând de la

adresa 2001:0000:0000:ffd3:0000:0000:0000:57ab, prescurtarea 2001::ffd3::57ab ar putea să

însemne2001:0000:0000:0000:0000:ffd3:0000:57ab, 2001:0000:ffd3:0000:0000:0000:0000:57a

b, sau altă combinație similară. Zerourile de la începutul unui grup pot fi de asemenea

omise, ca de exemplu în adresa localhost ::1.

Toate adresele de mai jos sunt corecte și echivalente:

2001:0db8:0000:0000:0000:0000:1428:57ab

2001:0db8:0000:0000:0000::1428:57ab

2001:0db8:0:0:0:0:1428:57ab

2001:0db8:0:0::1428:57ab

2001:0db8::1428:57ab

2001:db8::1428:57ab

Ultimii 4 octeți ai unei adrese IPv6 pot fi scriși în zecimal, folosind ca separator un

punct. Această notație este folosită în adresele IPv6 compatibile IPv4 (vezi mai jos). Forma

generală este x:x:x:x:x:x:d.d.d.d unde x reprezintă cifre hexazecimale din primele 6 grupuri,

iar d corespunde unei număr zecimal (între 0 și 255), ca și în adresele IPv4. De

exemplu, ::ffff:12.34.56.78 este aceeași adresă cu ::ffff:0c22:384e și

cu 0:0:0:0:0:ffff:0c22:384e. Acest mod de scriere este învechit și nu este folosit decât de

unele aplicații.

Mai multe informații pot fi găsite în RFC 4291 - IP Version 6 Addressing Architecture.

Adrese de rețeaAdresele de rețea IPv6 sunt scrise folosind notația CIDR. O rețea (sau subrețea) IPv6

este un grup continuu de adrese IPv6 a cărui mărime trebuie să fie putere a lui 2; primii biți

ai adreselor, identici pentru toate adresele din rețea, formează prefixul rețelei.

O rețea este reprezentată de prima adresă din rețea și de mărimea prefixului în biți,

separate de "/". De exemplu, 2001:0db8:1234::/48 este rețeaua cu

adresele2001:0db8:1234:0000:0000:0000:0000:0000 până la 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff

Deoarece un calculator poate fi văzut ca o rețea cu prefixul 128, adresele sunt

câteodată urmate de /128.

Adrese publice]

Adrese unicast

Adresele unicast IPv6 folosite pentru adresarea pe Internet trebuie să aibă prefixul

2000::/3, adică sunt cuprinse între 2000:: și 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.

Page 16: 01 Protocoale Ciclu Ex

Adrese multicast

Adrese anycast

Adrese privateAsemenea rezervărilor IPv4 pentru adrese private sau rețele interne închise, există și

adrese IPv6 rezervate pentru spațiul privat de adresare. În IPv6, acestea se numesc Adrese

Local Unice (engleză Unique Local Addresses - ULA). RFC 4193 rezervă prefixul fc00::/7 în

acest scop, împărțindu-l în 2 spații /8 cu politici implicite diferite pentru fiecare spatiu (cfm.

IPv6). Adresele includ un număr aleator de 40 de biți care minimizează riscul unei coliziuni

de adrese în cazul conectării a 2 spații private sau pachetele sunt rutate greșit.

Proiectele inițiale (RFC 3513) foloseau alt bloc de adrese în acest scop (fec0::),

denumite și adrese specifice unei locații. Din păcate definiția a ceea ce sunt reprezintă

locațiile (engleză site) a ramas neclară și politicile de adresare prost definite creau

ambiguități în algoritmul de rutare. Blocul respectiv de adrese a fost abandonat și trebuie

să nu mai fie utilizat în sistemele noi.

Adresele ce încep cu fe80: - numite adrese link-local - sunt atribuite în zona local link.

Adresele sunt generate automat de către nivelul IP al sistemului de operare pentru fiecare

interfață de rețea. Aceasta asigură conectivitate la rețea automată și instantanee pentru

orice host IPv6 și semnifică faptul că mai multe host-uri conectate la un hub sau switch

comun au o cale de comunicare garantată prin adrese local-link. Această funcționalitate

este utilizată extensiv și invizibil pentru majoritatea utilizatorilor, în nivelele inferioare ale

administrării rețelelor IPv6 (Neighbor Discovery Protocol).

Toate prefixele atribuite adreselor private nu sunt rutate pe Internet.

Adrese locale]Adrese IPv6 mapate peste IPv4Pentru a permite trecerea fără probleme de la IPv4 la IPv6, au fost imaginate diferite

metode de alocare automată a unor adrese IPv6 plecând de la adrese IPv4:

::ffff:0:0/96 — acest prefix este folosit pentru adrese IPv4 mapate.

2001::/32 — folosit pentru Tunelare Teredo.

2002::/16 — folosit pentru adresare 6to4.

În plus, mai exista și prefixul ::/96 (adresă cu primii 96 de biți 0). Adresele din acest

spațiu erau cunoscute inițial ca „adrese compatibile IPV4" și aveau ultimii 32 de biți egali cu

adresa IPv4 a gazdei. IETF a declarat aceast bloc de adrese depășit prin publicarea RFC

4291. Singura utilizare a acestui prefix rămâne reprezentarea unor adrese IPv4 și Pv6 într-

un același tabel sau bază de date cu coloane de dimensiune fixă.Adrese statice și dinamiceNAT (engleză network address translation - translatarea adresei de rețea) este un

procedeu prin care antetul pachetelor IP este modificat pentru a transforma adresa IP sursă sau destinație într-o alta.

În prezent, cea mai frecventă utilizare pentru NAT este maparea mai multor adrese

private pe o singură adresă publică. Această utilizare este cunoscută ca PAT (engleză port

address translation) sau NAPT (engleză network address port translation).

Page 17: 01 Protocoale Ciclu Ex

1.7 ICMP Internet Control Message Protocol  este un protocol din suita TCP/IP care folosește la semnalizarea și diagnosticarea problemelor din rețea. Protocolul este definit in RFC792. Mesajele ICMP sunt încapsulate în interiorul pachetelor IP. Versiunea ICMP ptr IPv4 este adesea cunoscuta ca ICMPv4; in schimb IPv6 dispune de un protocol similar cunoscut sub abrevierea ICMPv6.Exemple de utilizare

Probabil cele mai utilizate programe care se bazează pe ICMP sunt ping și traceroute.

Ping trimite mesaje ICMP de tip echo request ("cerere de ecou") către calculatorul țintă și

așteaptă de la acesta mesaje ICMP de tip echo reply ("răspuns de tip ecou"). Dacă acestea

nu sunt primite, se poate presupune că ceva este în neregulă cu conexiunea dintre cele

două calculatoare.

Toate pachetele IP au în antet un câmp special numit TTL (Time To Live). Acest câmp este

decrementat de fiecare dată când trece printr-un ruter. Pentru a evita buclele de routare, în

momentul în care câmpul TTL ajunge la zero pachetul nu este trimis mai departe. În

această situație, router-ul care a decrementat câmpul TTL la zero trimite către calculatorul-

origine al pachetului (adresa acestuia se află tot în prologul IP) un mesaj ICMP de tip time

exceeded. Programul traceroute profită de acest mecanism și trimite către calculatorul

țintă, pachete UDP cu valori ale câmpului TTL din ce în ce mai mari, cu scopul de a obține

mesaje time exceeded de la toate routerele aflate pe traseu.

Structura segmentului ICMPAntetulAntetul (header) ICMP începe imediat după antetul IPv4. Toate pachetele ICMP dispun de un

antet de 8 octeți și de o secțiune de date de lungime variabila. Structura antetului ICMP

este redata în figura de mai jos:

Biti 0-7 8-15 16-23 24-31

0 Tip Cod Suma de control

32 Restul antetului

Tip - tipul pachetului ICMP

Cod - subtipul pachetului ICMP în funcție cu tipul selectat anterior

Suma de control - Suma de control calculata în funcție de câmpurile antet ICMP + sir

de date și este descrisa în RFC 1071.

Restul antetului - câmp de 4 octeți ce variază ca și conținut pe baza tipului/codului

antetului ICMP.

In continuare este redata lista mesajelor de control (incompleta):

TipCo

dDescriere

0 - Echo Reply 0 Răspuns de tip ecou (utilizat pentru ping)

1 si 2 Rezervat

Page 18: 01 Protocoale Ciclu Ex

3 - Destinație de neatins

(Destination

Unreachable)

0 Retea destinație indisponibila

1 Gazda-destinație indisponibila

2 Protocol destinație indisponibil

3 Port destinație indisponibil

4 Solicitare fragmentare

5 Sursa de rutare eșuata

6 Retea destinație necunoscuta

7 Gazda destinație necunoscuta

8 Gazda sursa izolata

9 Acces rețea interzis

10 Acces gazda interzis

11 Retea inadmisibila pentru TOS

12 Gazda inadmisibila pentru TOS

13 Acces comunicație interzisa

14 Prioritate gazda încălcata

15 Prioritate interzisa

4 - Sursa ICMP "potolita" 0

Mesaj ICMP transmis inițiatorului, solicitând scăderea ratei

de mesaje ICMP către un anumit ruter/gazda (datorita

problemelor de congestie).

5 - Redirectare mesaje

ICMP0 Redirectare datagrama pentru rețea

6 Adresa gazda alternativa

7 Rezervat

8 - Echo Request 0 Cerere de ecou (echo request) utilizata în ping

... ... ...

11 - Expirare timer (time

exceeded)

0 TTL expirat în timpul tranzitului

1 Timpul de reasamblare a fragmentelor expirat

... ... ...

30 - Traceroute Solicitare informații

... ... ...

1.8 TCP pdf

1.9 UDP Protocolul Datagramelor Utilizator[1] (sau UDP de la

engl. User Datagram Protocol) este un protocol de comunicație pentru calculatoare ce

aparține nivelului Transport (nivelul 4 ) al modelului standard OSI.

Page 19: 01 Protocoale Ciclu Ex

Împreună cu Protocolul de Internet (IP), acesta face posibilă livrarea mesajelor într-o rețea.

Spre deosebire de protocolul TCP, UDP constituie modul de comunicație fără conexiune.

Este similar cu sistemul poștal, în sensul că pachetele de informații (corespondența) sunt

trimise în general fără confirmare de primire, în speranța că ele vor ajunge, fără a exista o

legătură efectivă între expeditor și destinatar.[2] Practic, UDP este un protocol ce nu oferă

siguranța sosirii datelor la destinație (nu dispune de mecanisme de confirmare); totodată

nu dispune nici de mecanisme de verificare a ordinii de sosire a datagramelor sau a

datagramelor duplicate. UDP dispune, totusi, în formatul datagramelor, de sume de control

pentru verificarea integrității datelor sau de informații privind numărul portului pentru

adresarea diferitelor funcții la sursa/destinație.

Caracteristicile de baza ale UDP îl fac util pentru diferite aplicații.

orientat către tranzacții - util în aplicații simple de tip întrebare-răspuns cum ar

fi DNS.

este simplu foarte util în aplicații de configurări, precum DHCP sau TFTP (Trivial FTP).

lipsa întârzierilor de retransmisie îl pretează pentru aplicații în timp real ca VoIP,

jocuri online.

lucrează excelent în medii de comunicații unidirecționale precum furnizarea de

informații broadcast, în servicii de descoperire (discovery services), sau în partajarea de

informații către alte noduri (RIP).Formatul pachetului

Antetul UDP este alcătuit din 4 câmpuri fiecare având lungimea de 2 octeți.

Bi

ti0 - 15 16 - 32

0 Portul sursa Portul destinație

3

2Lungime Suma de control

6

4Date

Portul sursa - în adresarea bazata pe IPv4 acest câmp este opțional. Daca nu este

utilizat acest câmp, are valoarea zero; când reprezinta informație semnificativa, el va

indica portul inițiator al procesului de transmisie a datagramelor.

Portul destinație - spre deosebire de portul sursa, câmpul este obligatoriu și indica

portul de recepție

Page 20: 01 Protocoale Ciclu Ex

Lungime - acest câmp indica lungimea în octeți a datagramei: antet plus secțiune de

date (valoarea minima a lungimii este 8).

Suma de control - asigura imunitatea la erori; se calculează ca fiind complementul

fata de 1 (pe 16 biți) a pseudo-antetului cu informații extrase din antetul IP, antetului

UDP și a câmpului de date, eventual se completează cu zerouri pentru a atinge

lungimea stabilita.Pseudo-anteturi

Pseudo-antetul prefixează antetul UDP și va conține, printre altele, adresele sursa,

destinație, lungimea pachetului UDP.

Pseudo-antetul IPv4Atunci când UDP rulează sub IPv4, pseudo-antetul este utilizat în calcularea sumei de

control; formatul acestuia va arata astfel (s-a prezentat situatia reala cu antetul UDP în

continuarea pseudo-antetului).

Bi

ți0 - 7 8 - 15 16 - 23 24 - 31

0 Adresa sursa

32 Adresa destinație

64 Zero Protocol Lungime UDP

96 Portul sursa Portul destinație

12

8Lungime Suma de control

16

0Date

Campul Protocol are valoarea 17 (hexazecimal 0x11) specifica protocolului UDP.

Pseudo-antetul IPv6Atunci cand UDP ruleaza sub IPv6, suma de control este obligatorie. Metoda de calcul este

descrisa in RFC 2460.

Biț 0 - 7 8 - 15 16 - 23 24 - 31

Page 21: 01 Protocoale Ciclu Ex

i

0

Adresa sursa

32

64

96

12

8

Adresa destinație

16

0

19

2

22

4

25

6Lungime UDP

28

8Zero

Antetul

următor

32

0Portul sursa Portul destinație

35 Lungime Suma de control

Page 22: 01 Protocoale Ciclu Ex

2

38

4Date

1.10 ARP - Address Resolution Protocol, RARP, DHCPPentru ca doua dispozitive de retea sa poata comunica este necesara cunoasterea

atat a adresei MAC, cat si a celei logice. In cazul in care numai una dintre adrese este disponibila se apeleaza la un protocol dedicat care pe baza acesteia va determina cealalta adresa.

Stiva de protocoale TCP/IP conti doua protocoale de nivel retea pentru a servi acest scop: ARP (Address Resolution Protocol) si RARP (Reverse Address Resolution Protocol). ARP este protocolul ce va oferii adresa MAC a unui dispozitiv de retea, data fiind adresa sa IP.

ARP se bazeaza pe construirea si mentinerea unei tabele ARP. O tabela ARP are rolul de a oferii o corespondenta intre adresele IP si cele MAC. Acestea sunt construite dinamic si sunt stocate in memoria RAM. Desi exista mecanisme pentru adaugarea sau eliminarea unei intrari intr-o tabela ARP acestea sunt rareori folosite.

Fiecare computer sau dispozitiv de retea isi pastreaza propria sa tabela ARP.

Cum functioneaza ARP? Cum este construita tabela ARP?

Fie reteaua din figura. 

Toate statiile sunt tocmai pornite, astfel tabelele ARP sunt vide. Presupunem ca statia A1 vrea sa comunice cu statia A2, cunoscand doar adresa IP a acesteia. La nivelul retea datele venite de la nivelurile superioare vor fi encapsulate si vor primi un antet ce va contine in campul adresa destinatie 193.23.1.7, iar ca adresa sursa 193.23.1.4. Inainte de trecerea la nivelul legatura e date adresa IP destinatie va fi cautata in tabela ARP si nefiind gasita se va crea un cadru special (ARP request) ce va avea in campul adresa destinatie din antet adresa de difuzare: FF.FF.FF.FF.FF.FF, iar in campul adresa sursa adresa MAC a statiei A1.

Daca vom considera ca reteaua din figura foloseste Ethernet drept protocol de nivel MAC datele vor fi difuzate si vor ajunge la A2 si la interfata ruterului conectata la segmentul A.

La nivelul legatura de date va fi analizat antetul cadrului. Campul destinatie fiind o adresa de difuzare cadrul va fi trimis la nivelul superior. Totodata pe baza continutului campului sursa de nivel 2 si 3 va fi creata prima intrare in tabela ARP a statiei A2. Ajuns la nivelul 3 cadrul este identificat drept o cerere ARP si se initiaza un raspuns transmis ca unicat atat la nivel retea cat si la nivel legatura de date. Dupa primirea raspunsului A1 va putea insera in tabela sa ARP adresa MAC a lui A2, iar comunicatia din acest moment va avea loc fara probleme.

Page 23: 01 Protocoale Ciclu Ex

Fiind pe un segment Ethernet toate cadrele schimbate de A1 si A2 vor ajunge la toate statiile de pe segment, astfel ca desi nu au emis nici un cadru atat A3 cat si ruterul vor avea cate o tabela ARP cu 2 intrari. Aceste intrari expira dupa o perioada de timp, fiind inlaturate din tabela ARP.

Cum are loc comunicatia intre statii aflate in retele diferite?

Am vazut ca protocolul de rezolutie a adresei se bazeaza pe difuzari la nivel legatura de date. Ruterele in schimb nu propaga pachetele de difuzare de nivel legatura de date in afara retelei din care provin.

Exista doua modalitati prin care statii aflate in retele diferite pot comunica: default gateway si proxy ARP.

Proxy ARP este o extensie a protocolului de rezolutie a adresei. Pornind de la faptul ca ruterul nu va transfera pachetele de difuzare Proxy ARP va determina ruterul sa raspunda la toate cererile ARP destinate unor adrese in afara retelei cu propria sa adresa MAC.

In cazul retelei de mai sus sa consideram ca statia A1 vrea sa comunice cu B1. Dupa ce nu va gasi adresa MAC a statiei B1 in tabela ARP va trimite o cerere ARP. Cadrul se va fi receptionat de catre toate dispozitivele de retea aflate pe acest segment. Statiile A2 si A3 deja au in tabela ARP informatii despre A1, astfel incat vor reseta timpul de viata al acestei intrari. Ruterul va reseta si el acest timp, iar apoi analizand adresa IP destinatie va concluziona ca destinatia nu se afla in acelasi segment. Daca acesta ar fi fost un cadru obisnuit ruterul ar fi luat o decizie pe baza tabelei sale de rutare. Fiind totusi o cerere ARP ruterul va genera un raspuns ARP ce va contine propria sa adresa MAC. Raspunsul ARP va fi incapsulat, iar antetul va avea atat la nivelul legatura de date cat si la nivelul retea adresa sursa adresa interfetei ruterului ce se afla conectata la retea. Ruterul va determina pe ce interfata trebuie sa trimita pachetele destinate pentru 24.8.17.2 si va trimite pe aceasta interfata o noua cerere ARP. B1 va raspunde la aceasta.

In final toate statiile din reteaua A isi vor adauga o noua intrare in tabela ARP ce va face corespondenta intre 193.23.1.1 si adresa MAC a interfetei routerului: 00.48.0C.18.7A.A2. In plus statia A1 va mai adauga o intrare ce va mapa 24.8.17.2 cu adresa 00.48.0C.18.7A.A2. Statiile din reteaua B vor insera doua intrari in tabelele ARP propri: 24.8.17.1 - 00.48.0C.18.7A.A3 si 24.8.17.1 - 00.01.9A.11.71.11.

Din acest moment statia A1 va incapsula transmisia destinata statiei B1 folosind adresa IP a lui B1 si adresa MAC a ruterului. Ruterul va primi cadrele va inlocui adresa sursa din antetul de nivel legatura de date cu adresa sa: 00.48.0C.18.7A.A3 si le va trimite mai departe catre B1.

Pentru o statie data default gatewayeste adresa IP a interfetei de pe ruter ce conecteaza reteaua din care face parte respectiva statie. Odata precizat un default gateway nivelul retea al statiei va mai capata o noua atributie, trebuind sa determine daca destinatia este sau nu in accesi retea. Daca nu este atunci nu va mai fi initiata ci se va folosi adresa IP destinatiei finale si adresa MAC a default gateway. Astfel in tabela ARP va fi cautata adresa interfetei ruterului.

Încapsularea pachetului ARP într-un cadru Ethernet sau 802.2 SNAP este exemplificată în figură:

Page 24: 01 Protocoale Ciclu Ex

Structura unei cereri ARP este:

În cele ce urmează vom da o scurtă descriere a câmpurilor:

Tipul hardware-ului: tipul de hardware al interfeţei;

Tipul protocolului: tipul de protocol pe care emiţătorul îl foloseşte;

Lungimea adresei MAC: lungimea fiecărei adrese hardware din cadru, dată în octeţi;

Lungimea adresei de protocol: lungimea adresei de protocol din datagramă dată în octeţi;

Cod operaţie (Op Code) indică: tipul de datagramă, cerere ARP sau răspuns la aceasta. Dacă datagrama este cerere valoarea acestui câmp este 1, iar dacă este răspuns valoarea este 0;

Adresa MAC sursă: adresa hardware a dispozitivului transmiţător;

Adresa IP sursă: adresa IP a dispozitivului transmiţător;

Page 25: 01 Protocoale Ciclu Ex

Adresa IP a destinaţiei: adresa IP a dispozitivului destinaţie;

Adresa MAC a destinaţiei: adresa hardware a dispozitivului destinaţie.

Câmpul "Tipul hardware-ului"

Acest câmp identifică tipul interfeţei hardware folosit:

Tip Descriere

1 = Ethernet

2 = Ethernet experimental

3 = X.25

4 = Proteon ProNET (Token Ring)

5 = Chaos

6 = IEEE 802.x

7 = ARCnet

16 = ATM

Câmpul "Tipul de protocol"

Tipul de protocol identifică, aşa cum îi spune şi numele, tipul de protocol de nivel reţea pe care dispozitivul transmiţător îl foloseşte. Aceasta astfel indică, în mod implicit, şi tipul de adresă de nivel reţea folosit. Cu TCP/IP, aceste protocoale sunt de obicei EtherType. Câteva exemple de valori ale acestui câmp:

În zecimal Descriere

2048 = Internet Protocol (IP)

2049 = X.75

2053 = X.25 Level 3

2054 = ARP

2055 = XNS

32821 = Reverse ARP

32824 = DEC LANBridge

32823 = Apple Talk

Dacă protocolul nu este EtherType, vor fi folosite alte valori.

 

2. RARP Protocolul de rezoluţie inversă a adresei

RARP - Reverse ARP

ARP rezolvă problema aflării adresei MAC corespunzătoare unei adrese IP date. Uneori însă se cere rezolvarea problemei inverse: dându-se o adresă MAC, trebuie găsită adresa IP corespunzătoare.

Aceasta problemă apare în particular când se porneşte o staţie de lucru fără disc. O astfel de maşină încarcă nucleul sistemului de operare de la un server de fişiere la distanţă. Soluţia este folosirea protocolului RARP. Acest protocol permite unei staţii de lucru să difuzeze adresa sa MAC şi să solicite o adresă IP.

Serverul RARP este responsabil de tratarea acestei cereri şi furnizarea unui răspuns. El deţine de obicei tabele de corespondenţă adresă MAC - adresă IP, caută adresa IP ce corespunde adresei MAC a solicitantului şi transmite un răspuns acestuia.

Un dezavantaj al protocolului RARP constă în faptul că pentru a ajunge la server-ul RARP, staţia sursă foloseşte o adresă MAC de difuzare. Asemenea difuzări nu sunt propagate prin router-e şi deci este necesar să existe un server RARP în fiecare LAN.

Pentru a rezolva această problemă a fost inventat un protocol alternativ, protocolul BOOTP.

Page 26: 01 Protocoale Ciclu Ex

Spre deosebire de RARP, BOOTP este un protocol de nivel aplicaţie ce foloseşte pachete UDP pentru transfer-ul mesajelor. Mesajele UDP fiind bazate pe IP, sunt propagate peste router-e. În plus BOOTP este capabil să furnizeze unei staţii fără disc şi informaţii suplimentare ca: adresa IP a serverului de fişiere ce deţine imaginea nucleului SO, adresa IP a router-ului implicit şi masca de subreţea folosită.

3. DHCP (prescurtat de la Dynamic Host Configuration Protocol) este un protocol de rețea de calculatoare folosite de gazde (clienți DHCP) care atribuie adrese IP și alte informații de configurare de rețea importante în mod dinamic.Istoric

RFC 1531 a definit inițial DHCP ca protocol standard în octombrie 1993, urmând Bootstrap

Protocol (BOOTP). Următorul update, RFC 2131, lansat în 1997, este definiția DHCP curenta

pentru rețele Internet Protocol version 4 (IPv4). Extensiile DHCP pentru IPv6 (DHCPv6) au

fost publicate în RFC 3315.Privire de ansamblu

Dynamic Host Configuration Protocol automatizează alocarea parametrilor de rețea la

dispozitive de către unul sau mai multe fault-tolerant servere DHCP. Chiar și în rețele mici,

DHCP este folositor, deoarece simplifica adăugarea unor noi echipamente în rețea.

Când un client configurat (un computer sau orice alt dispozitiv de rețea) se conectează la

rețea, clientul DHCP trimite o broadcast interogare în ce privește informația necesară la

serverul DHCP. Serverul DHCP gestionează o rezervă de adrese IP și informații despre

configurarea parametrilor clientului, ca gateway-ul implicit, numele domeniului,serverul

DNS, alte servere ca serverul de timp, ș.a.m.d. La primirea unei cereri valide, serverul

atribuie calculatorului o adresă de IP, un contract de leasing (perioada de validitate a

alocării respective), precum și alți parametri de configurare de IP, cum ar fi masca de

subrețea și gateway-ul implicit . Interogarea este de obicei inițiată imediat dupăboot, și

trebuie să fie completată, înainte ca clientul să poată iniția comunicarea IP cu alte gazde.

Funcție de implementare, serverul DHCP poate avea trei metode de alocare a adreselor IP:

alocare dinamică: Un administrator de rețea atribuie o serie de adrese IP la DHCP, și

fiecare computer din LAN este configurat să ceară o adresa de IP de la serverul DHCP în

timpul inițializării de rețea. Procesul de cerere și aprobare folosește un concept ca un

contract de leasing pe o perioada determinată, permițând serverului DHCP să revendice

(și să realoce) adrese IP disponibile (refolosirea dinamică de adrese de IP).

alocare automată: Serverul DHCP alocă în permanență o adresă de IP disponibilă, din

gama definită de administrator, către un client. Acest proces este asemănător alocării

dinamice, dar serverul DHCP păstrează un tabel cu alocările de IP anterioare, astfel

încât să poată atribui preferențial pentru un client aceeași adresă de IP pe care acesta a

avut-o anterior.

alocare statică: Serverul DHCP alocă adresa de IP în baza unui tabel cu perechi adresa

MAC/adresa IP, acestea fiind completate manual (probabil de către administratorul

rețelei). Numai clienții care au adresa MAC lisată în acest tabel vor primi o adresă de IP.

Această caracteristică (care nu e suportată de orice router) este denumită Static DHCP

Page 27: 01 Protocoale Ciclu Ex

Assignment (by DD-WRT), fixed-address (by the dhcpd documentation), DHCP

reservation or Static DHCP (by Cisco/Linksys), și IP reservation sau MAC/IP binding(de

către diverși alți producători de routere).

Închirierea adreselor DHCP

Închirierea este fundamentală pentru procesul DHCP. Fiecare adresă oferită de un server

DHCP are o perioadă de închiriere asociată, perioadă în care clientul are permisiunea să

folosească adresa. Perioada de închiriere este denumită ”lease time” și poate avea orice

valoare, de la câteva minute până la câteva luni, ani sau chiar pentru totdeauna. Închirierea

pe perioadă nelimitată de timp transformă adresarea dinamică în adresare statică.

Dacă s-a scurs peste 50% din timpul de închiriere al adresei, clientul trimite serverului care

i-a închiriat adresa, o cerere de prelungire a perioadei de utilizare a adresei (”renew”). Dacă

acest client nu a reușit prelungirea perioadei de închiriere de la serverul de la care a primit

inițial închirierea (”lease-ul”) la scurgerea a 87,5% (7/8) din timp, clientul trimite un

”broadcast packet”, încercând să închirieze o adresă IP de la orice server existent în rețea.

Procesul de închiriere poate fi anulat atât de client cât și de server înaintea perioadei

stabilite inițial. De asemenea, serverul DHCP are posibilitatea de a trimite mesaje clienților

obligându-i să înnoiască contractul de închiriere înainte de terminarea lui.

Confirmarea cererilor DHCP

Când serverul DHCP primește mesajul DHCPREQUEST de la client, procesele de configurare

intră în faza finală. Faza de confirmare presupune trimiterea unui pachet DHCPACK

clientului. Acest pachet include durata contractului de leasing, precum și orice alte

informații de configurare pe care clientul le-ar putea fi solicitat. În acest moment, procesul

de configurare IP este finalizat.

Protocolul așteaptă ca clientul DHCP să-și configureze interfața de rețea cu parametri

negociați.

DHCPDISCOVER

UDP Src=0.0.0.0 sPort=68Dest=255.255.255.255 dPort=67

OP HTY HLE HO

DHCPOFFER

UDP Src=192.168.1.1 sPort=67Dest=255.255.255.255 dPort=68

DHCPREQUEST

UDP Src=0.0.0.0 sPort=68Dest=255.255.255.255 dPort=67

OP HTY HLE HO

DHCPACK

UDP Src=192.168.1.1 sPort=67Dest=255.255.255.255 dPort=68

Page 28: 01 Protocoale Ciclu Ex

PE N PS

0x01

0x010x06

0x00

XID

0x3903F326

SECS FLAGS

0x0000 0x0000

CIADDR

0x00000000

YIADDR

0x00000000

SIADDR

0x00000000

GIADDR

0x00000000

CHADDR

0x00053C04

OPHTYPE

HLEN

HOPS

0x02

0x010x06

0x00

XID

0x3903F326

SECS FLAGS

0x0000 0x0000

CIADDR

0x00000000

YIADDR

0xC0A80164

SIADDR

0xC0A80101

GIADDR

0x00000000

CHADDR

0x00053C04

PE N PS

0x01

0x010x06

0x00

XID

0x3903F326

SECS FLAGS

0x0000 0x0000

CIADDR

0x00000000

YIADDR

0xC0A80164

SIADDR

0xC0A80101

GIADDR

0x00000000

CHADDR

0x00053C04

OPHTYPE

HLEN

HOPS

0x02

0x010x06

0x00

XID

0x3903F326

SECSFLAGS

0x0000 0x0000

CIADDR (Client IP Address)

0x00000000

YIADDR (Your IP Address)

0xC0A80164

SIADDR (Server IP Address)

0xC0A80101

GIADDR (Gateway IP Address

switched by relay)

0x00000000

Page 29: 01 Protocoale Ciclu Ex

0x8D590000

0x00000000

0x00000000

192 octets of 0's. BOOTP legacy

Magic Cookie

0x63825363

DHCP Options

DHCP option 53: DHCP Discover

DHCP option 50: 192.168.1.100 requested

DHCP option 55: Parameter Request List:

Request Subnet Mask (1), Router (3), Domain Name (15), Domain Name Server (6)

0x8D590000

0x00000000

0x00000000

192 octets of 0's. BOOTP legacy

Magic Cookie

0x63825363

DHCP Options

DHCP option 53: DHCP Offer

DHCP option 1: 255.255.255.0 subnet mask

DHCP option 3: 192.168.1.1 router

DHCP option 51: 86400s (1 day) IP lease time

DHCP option 54: 192.168.1.1 DHCP server

DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18

0x8D590000

0x00000000

0x00000000

192 octets of 0's. BOOTPlegacy

Magic Cookie

0x63825363

DHCP Options

DHCP option 53: DHCP Request

DHCP option 50: 192.168.1.100 requested

DHCP option 54: 192.168.1.1 DHCP server.

CHADDR (Client Hardware Address)

0x00053C04

0x8D590000

0x00000000

0x00000000

192 octets of 0's. BOOTP legacy

Magic Cookie

0x63825363

DHCP Options

DHCP option 53: DHCP ACK

DHCP option 1: 255.255.255.0 subnet mask

DHCP option 3: 192.168.1.1 router

DHCP option 51: 86400s (1 day) IP lease time

Page 30: 01 Protocoale Ciclu Ex

DHCP option 54: 192.168.1.1 DHCP server

DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18

1.11 Telnet este un protocol de rețea care se folosește în Internet precum și în rețele de calculatoare tip LAN la comunicația textuală, bidirecțională și interactivă, bazată pe realizarea unei conexiuni virtuale cu stația de lucru destinatară. Datele ce urmează a fi transmise celeilalte stații de lucru sunt întâi întrețesute cu informațiile de control ale telnet-ului și apoi transmise împreună cu acestea, folosind nivelul de protocol „legătură de date” pe 8 biți al protocolului TCP.

Tot „telnet” se mai numesc și programele, în general simple, care implementează partea client a acestui protocol de rețea. Ele permit utilizatorului unei stații de lucru (numită atunci „locală”) să se conecteze virtual la alt computer sau stație de lucru din același LAN / WLAN sau și din Internet. La început este nevoie de o autentificare sau logon precum și de specificarea celeilalte stații de lucru din rețea cu care comunică. Apoi programul acceptă comenzi de tip command line interface (CLI) sau text, introduse local, însă pentru a accesa programe și servicii de pe computerul la distanță. Astfel de servicii sunt de exemplu poșta electronică, accesul la baze de date și alte fișiere etc. Computerul de la distanță poate fi de același gen, dar și total diferit de stația locală de lucru, necesitând atunci alte comenzi decât aceasta. Rezultatul, în formă de text, al fiecărei comenzi este apoi returnat calculatorului local, creându-se astfel impresia unei sesiuni de lucru direct pe calculatorul aflat la distanță.

Aplicații client de tip telnet există pentru aproape toate platformele de calcul actuale. Protocolul Telnet este suportat de cele mai multe dispozitive de rețea și sisteme de operare care dispun de o stivă de protocoale TCP. De exemplu Windows NT poate fi configurat de la distanță de pe alt calculator, chiar de tip diferit, dacă suportă și el Telnet și este legat printr-o rețea. Totuși, din cauza aspectelor legate de de securitatea comunicației, Telnet a pierdut mult teren în favoarea protocolului SSH.

Protocolul Telnet a fost introdus în SUA în 1969 drept standardul RFC 15, apoi RFC 854, apoi IETF Internet Standard STD 8, unul din primele standarduri pentru Internet(IETF este abrevierea de la Internet Engineering Task Force).

+++Telnetul (Terminal NETwork) est eun protocol de reaţea destinat pentru realizarea interfeţei textuale în reţea (în prezent cu ajutorul lui TCP). Numele de telnet îl au şi unele utilităţi, care realizează partea protocolului ce revine clientului. Standardul contemporan al acestui protocol este descris în RFC854.

Scopul principal al Telnetului este de a permite dispozitivelor terminale şi proceselor terminale de a interacţiona unul cu altul. Se presupune că acest protocol poate fi utilizat pentru legătura de tipul terminal-terminal sau pentru conexiunea proces-proces.

Cu toate că în sesiunea Telnet este subliniată partea clientului şi cea a serverului, în realitate protocolul este complet simetric. După stabilirea conexiunii de

Page 31: 01 Protocoale Ciclu Ex

transport (de obicei TCP), ambele capete ale sale joacă rolul Terminalelor Virtuale de Reţea (NVT), care fac schimb cu două tipuri de date:

Date aplicate (datele care pleacă de la utilizator la aplicaţia textuală către server şi invers);

Comenzile protocolului Telnet, de obicei care sunt opţiunile, ce servesc pentru determinarea posibilităţilor şi dorinţelor părţilor.

Telnet-ul oferă acces la un protocol aflat la distanţă, rulînd peste TCP. El permite unui utilizator de a stabili un circuit de conexiune virtuală la un sistem aflat la distanţă şi introducerea intrărilor de la tastatura locală către calculatorul aflat la distanţă. Utilizînd Telnetul, un utilizator de la un host se poate loga la alt host, de parcă acesta s-ar afla chiar direct în faţa sistemei aglate la distanţă; aceasta şi reprezintă o definiţie TCP/IP a terminalelor virtuale.

Figura 2.1.1 Interacţiunea clientului şi serverului prin intermediul protocolului Telnet

Telnet-ul utilizează o structură client-server şi oferă trei servicii de bază. Mai întîi de toate, el defineşte un terminal vitual de reţea (NVT), care asigură interfaţa sistemului aflat la distanţă unde procesul de aplicaţie rezidă. În al doilea rînd el oferă un mecanism care permite clienţilor şi serverilor să facă negocieze parametrii. Şi în final, Telnet tratează ambele capete ale conexiunii în mod simetric, adică orice capăt a conexiunii poate servi ca utilizator sau ca host.

Modelul client-server a Telnet-ului este foarte simplu. Clientul interacţionează cu terminalul utilizatorului pentru a converta caracteristicile fizice a terminalului în NVT. Serverul (host) interaţionează cu procesul aplicaţiei la sistemul gazdă. Acesta interacţionează ca un terminal de manipulare de schimb, aşa că terminalul de la distanţă apare ca terminalul local la sistemul gazdă.

Utilizează Port/ID-ul 23/TCP.

Utilizarea Telnet-ului

După cum am menţionat şi mai sus protocolul telnet permite unui utilizator de a se loga la un sistem aflat la distanţă şi de a rula la acesta de parcă ar fi un utilizator local.

Deci un utilizator Telnet iniţiază o conexiune către un host aflat la distanţă, tastînd Telnet şi oferind deasemenea numele hostului sau adresa IP a acestuia.

Page 32: 01 Protocoale Ciclu Ex

Figura 2.2.1 Utilizarea protocolului Telnet

Opţional, utilizatorul poate introduce aplicaţia, utilizînd comenzile Telnet şi apoi să furnizeze numele host-ului ca amintire. În exemplul prezentat mai sus, un utilizator a Internetului utilizează telnet-ul pentru a se conecta la hostul 200.1.1.1, un ipotetic ruter Cisco în reţea. Odată conectat prin Telnet, utilizatorul poate face orice ce pot face şi ei, dacă ei ar fi conectaţi printr-un link direct EIA-232, sau dacă erau conectaţi prin modem. Motivul pentru care Telnet-ul este considerat o potenţială gaură a securităţiieste destul de clar: observăm că prin conectarea la ruter prin Telnet, un utilizator are accesul deplin la configurările sistemului, la fel ca şi la cele de securitate şi informaţia de reţea topoogică.

Cînd utilizatorul doreşte să încheie sesiunea, el poate utiliza comanda logout, şi să se deconecteze de la host. Procesul Telnet va inchide conexiunea cu hostul aflat la distanţă şi controlul se întoarce la sistemul local.

Figura 2.2.2 Iniţierea unei conexiuni prin intermediul protocolului Telnet

Comenzile Telnet

Fiecare comandă Tlenet reprezintă o secvenţă de mulţi octeţi, care se începe cu codul \377 (255 zecimal) «Interpret as Comand» IAC şi codul comenzii. Comenzile care răspund de înţelegerile între opţiuni, reprezintă o secvenţă de trei octeţi, unde al

Page 33: 01 Protocoale Ciclu Ex

treile aoctet este codul opţiunii. Codurile enumerate mai jos au sensul lor personal numai în cazul în care urmează nemijlocit după IAC.

Tabelul 2.3.1 Comenzile Telnet

Comanda Codul (zecimal)

Descrierea

SE 240 Încheie înţelegerea începută de comanda SB.

NOP 241 Lipsă de operaţiune.

Data Mark 242 Sincronizarea schimbului de date. Această comandă mereu este însoţită de TCP Urgent notification.

Break 243 Este apăsat butonul «Break» sau «Attention»

Interrupt Process

244 Suspendă, întrerupe, opreşte de urgenţă sau termină procesul.

Abort output

245 Suprimă procesul curent. DeasemeneaTrimite un semnal Sync utilizatorului.

Are you There

246 Trimite înapoi răspuns terminalului,ce constă din simboluri imprimate

Erase character

247 Recptorul trebuie să şteargă ultimul simbol

Erase Line 248 Ştergerea ultimului rînd introdus

Go ahead 249 Se aşteaptă transmisiunea de date

SB 250 Începutul cooperării opţiunilor,care necesită transmisiunea de parametri

WILL (opţiune)

251 Indică dorinţa de a realiza sau confirmă că acum se realizează opţiunea indicată

WON'T (opţiune)

252 Indică refuzul de a realiza sau de acontinua opţiunea indicată

DO (opţiune)

253 Cererea ca cealaltă partea să realizeze sau să confirme opţiunea indicată

DON'T (opţiune)

254 Cere ca cealaltă parte să oprească realizarea sau să confirme faptul că opţiunea dată nu se mai utilizează

IAC 255 Octetul datelor 255

Protocolul FingerFinger este un protocol simplu de tip serviciu Internet, bazat pe modelul client-

server, care permite unui client Finger să obţină de la un server Finger informaţii cu caracter public despre un anumit utilizator sau despre toţi cei activi în reţea, la un moment dat.Interogarea serverului Finger se face pe portul de protocol 79 şi se exprimă în formatul NVT ASCII definit de Telnet, având ca simbol de sfârşit de linie combinaţia de caractere CR-LF ('Carriage Return - Line Feeder).Serviciul Finger este orientat pe conexiunea dintre două socket-uri (prin socket, se înţelege un pointer la o structură de date memorată într-un buffer). După stabilirea conexiunii folosind TCP, se transmite cererea Finger.

Page 34: 01 Protocoale Ciclu Ex

Dacă apelul e realizat printr-o linie vidă (numai CR-LF), atunci serverul răspunde cu lista completă a tuturor utilizatorilor conectaţi la server în acel moment. Comanda folosită în acest caz este:

fingerDacă lista completă a utilizatorilor are o dimensiune care depăşeşte lungimea maximă a unităţii de transmisie din reţea (MTU), atunci TCP transmite datele în mai multe segmente de mesaj.Comanda de interogare Finger poate să includă numele real al unui utilizator conectat la server:finger {nume}sau ID-ul utilizatorului şi numele calculatoralui-gazdă, cu sintaxa: finger {nume_utilizator}@{nume_calculator_gazda}Răspunsul constă în informaţiile disponibile despre acesta: numele de utilizator, numele real al persoanei, contul curent al acesteia (home directory), ultima dată la care s-a conectat la reţea, numele staţiei la care s-a făcut conexiunea, informaţii privind folosirea serviciului de poştă electronică de către utilizator etc.Dacă serverul Finger recepţionează orice în afara unei linii vide, atunci acesta presupune că textul identifică un anumit utilizator şi returnează toate informaţiile publice despre utilizatorii cu numele sau ID-ul asemănător textului.Serverul Finger transmite mesajul de răspuns staţiei sau sesiunii Telnet de la care s-a iniţiat cererea. Clientul recepţionează datele fie sub forma unui şir de octeţi (byte stream), fie prin datagrame, şi le memorează într-un buffer local. în cazul în care volumul datelor depăşeşte capacitatea de memorare a acestuia, atunci datele se pierd şi se returnează un mesaj de eroare.

Clientul recepţionează un mesaj de eroare, prin intermediul ICMP, deşi conexiunea a funcţionat corect şi transmisia este considerată reuşită.

Serverul Finger închide automat conexiunea după ce a transmis toate datele solicitate.

Pe durata unei conexiuni active, este necesară aplicarea unor măsuri de securitate pentru a evita accesul nedorit al unui utilizator neautorizat la resursele unui calculator-gazdă implicat în acea conexiune. Un server Finger poate fi configurat astfel încât o cerere Finger adresată lui de la distanţă, să iniţieze pe server un fişier capabil să ruleze comenzi de sistem (scripting).

1.12 Simple Mail Transfer Protocol (prescurtat, SMTP; în traducere

aproximativă Protocolul simplu de transfer al corespondenței) este un protocol simplu,

folosit pentru transmiterea mesajelor în format electronic pe Internet. SMTP folosește portul

de aplicație 25 TCP și determină adresa unui server SMTP pe baza înregistrării MX (Mail

eXchange, „schimb de corespodență”) din configurația serverului DNS.

Protocolul SMTP specifică modul în care mesajele de poștă electronică sunt transferate

între procese SMTP aflate pe sisteme diferite. Procesul SMTP care are de transmis un mesaj

este numit client SMTP iar procesul SMTP care primește mesajul este serverul SMTP.

Protocolul nu se referă la modul în care mesajul ce trebuie transmis este trecut de la

utilizator către clientul SMTP, sau cum mesajul recepționat de serverul SMTP este livrat

utilizatorului destinatar și nici cum este memorat mesajul sau de câte ori clientul SMTP

încearcă să transmită mesajul.

Page 35: 01 Protocoale Ciclu Ex

Istoric

SMTP a inceput sa fie folosit mai des la inceputul anilor ‘80. La acea vreme era mai putin

folosit decat UUCP (Unix to Unix CoPy), care era mai potrivit pentru transmiterea e-mail-

urilor intre mașini ce nu erau conectate permanent. SMTP însa functionează mai bine când

atât expeditorul cât și destinatarul mesajului sunt legați in rețea tot timpul.Sendmail a fost

unul din primele programe care au implemetat acest protocol. Din 2001 au aparut încă cel

puțin 50 de programe care implementeaza SMTP( atat servere cat si clienti). Printre cele

mai cunoscute servere SMTP amintim Postfix, qmail, Novell GroupWise, Exim,

Novell NetMail si Microsoft Exchange Server.

Funcționare

Comunicarea intre client și server se realizeaza prin texte ASCII. Inițial clientul stabilește

conexiunea către server și așteaptă ca serverul să-i răspundă cu mesajul “220 Service

Ready” . Dacă serverul e supraîncărcat, poate să întarzie cu trimirea acestui raspuns. Dupa

primirea mesajului cu codul 220 , clientul trimite comanda HELO prin care isi va indica

identitatea. In unele sisteme mai vechi se trimite comanda EHLO, comanda EHLO indicand

faptul că expeditorul mesajului poate sa proceseze extensiile serviciului și dorește să

primească o listă cu extensiile pe care le suportă serverul. Dacă clientul trimite EHLO iar

serverul îi răspunde ca aceasta comandă nu e recunoscută, clientul va avea posibilitatea să

revină și să trimită HELO.

Odată ce comunicarea a fost stabilită, clientul poate trimite unul sau mai multe mesaje,

poate incheia conexiunea sau poate folosi unele servicii precum verificarea adreselor dee-

mail. Serverul trebuie să raspundă după fiecare comandă indicand astfel dacă aceasta a

fost acceptată, dacă se mai asteaptă comenzi sau dacă există erori în scrierea acestor

comenzi.

Pentru a trimite un mesaj se foloseste comanda MAIL prin care se specifica adresa

clientului. Dacă aceasta comanda este corecta serverul va raspunde cu mesajul “250 OK”.

Clientul trimite apoi o serie de comenzi RCPT prin care specifică destinatarii mesajului.

Serverul va raspunde cu “550 No such user here”, sau “250 OK”, in functie de

corectitudinea comenzii primite. După ce se specifică destinatarii, și serverul acceptă

comenzile, se trimite comanda DATA, prin care serverul e anunțat că expeditorul va incepe

sa scrie conținutul mesajului. Serverul poate răspunde cu mesajul "503 Command out of

sequence" sau "554 No valid recipients" dacă nu a primit comenzile MAIL sau RCPT sau

aceste comenzi nu au fost acceptate. Dacă serverul va raspunde cu mesajul “354 Start mail

input”, clientul va putea introduce textul mesajului. Sfarșitul mesajului e marcat cu

<CR><LF>.<CR><LF>.

Un server SMTP trebuie să cunoască cel putin urmatoarele comenzi :

HELO - identificare computer expeditor;

EHLO - identificare computer expeditor cu cerere de mod extins;

MAIL FROM - specificarea expeditorului;

Page 36: 01 Protocoale Ciclu Ex

RCPT TO - specificarea destinatarului ;

DATA - conținutul mesajului;

RSET – Reset;

QUIT - termină sesiunea;

HELP - ajutor pentru comenzi;

VRFY - verifica o adresa;

EXPN - expandează o adresa;

VERB - informatii detaliate.

Realizarea comunicației SMTP - exemplu

Funcționarea protocolului SMTP poate fi testată simplu prin inițierea unei

conexiuni TCP folosind un client de telnet.

telnet mailhost.domeniu.ro 25

Server: 220 mailhost.domeniu.ro ESMTP

Client: HELO host.domeniu.ro

Server: 250 Hello host.domeniu.ro

Client: MAIL FROM: [email protected]

Server: 250 Ok

Client: RCPT TO: [email protected]

Server: 250 Ok

Client: DATA

Server: 354 End data with <CR><LF>.<CR><LF>

Client: Subject: test

Client: un mesaj test

Client: .

Server: Mail queued for delivery.

Client: QUIT

Server: 221 Closing connection. Bye.

POP3 sau Protocolul Post Office – Versiunea 3 este, alături de IMAP, unul

din protocoalele utilizate de un calculator gazdă pentru recepționarea poștei electronice (e-

mail).

Cu siguranță, tipurile nodurilor mai mici în Internet deseori nu sunt practice să întrețină un

sistem de transport al mesajului (MTS). De exemplu, o stație de lucru este posibil să nu

dispună de suficiente resurse (spațiu pe disc) cu scopul de a permite un server SMTP RFC

821 și asociază un sistem local de trimitere mail pentru a fi ținut rezident și să ruleze

continuu. Similar, poate deveni costisitor (sau imposibil) să menții un computer

interconectat la un IP-style rețea pentru o perioadă mai mare de timp (nodul duce lipsă de

resursa cunoscută ca “conectivitate”). În ciuda acestora, deseori este foarte util să

deservești poșta acestor noduri mai mici și deseori sprijină un utilizator agent (UA) să ajute

la manipularea poștei electronice. Pentru a rezolva această problemă, un nod care întreține

Page 37: 01 Protocoale Ciclu Ex

o entitate MTS oferă un serviciu maildrop pentru aceste noduri înzestrate mai puțin. POP3 a

intenționat să permită unei stații de lucru acces dinamic la maildrop de pe un server gazdă

într-un mod util. De obicei, aceasta înseamnă că protocolul POP3 este utilizat pentru a

permite unei stații de lucru să primească poșta pe care serverul o stochează. POP3 nu a

intenționat să furnizeze operații extinse de manipulare a poștei de pe server; normal poșta

este descărcată de pe server și apoi ștearsă. Un protocol mai avansat (și mai complex),

IMAP4, a fost discutat în RFC 1730. În continuare, termenul “client gazdă” (client host) se

referă la o gazdă ce utilizează serviciul POP3, cât timp termenul “server gazdă” (server

host) se referă la o gazdă care oferă serviciul POP3.

Operația de bază

Inițial, serverul pornește serviciul POP3 ascultând TCP portul 110. Când clientul dorește să

utilizeze serviciul, este stabilită o conexiune TCP cu serverul. Când conexiunea s-a realizat,

serverul POP3 trimite un salut. Clientul și serverul POP3 schimbă comenzi și răspunsuri

până când conexiunea este închisă sau abandonată. Comenzile în POP3 sunt formate din

caractere (modul insenzitiv), posibil să fie urmate de unul sau mai multe argumente. Toate

comenzile sunt termintate prin perechea CRLF (\r\n). Șirul de caractere ce formează

comanda și argumentele sunt caractere ASCII. Comenzile și argumentele sunt separate

printr-un singur caracter SPACE. Comenzile au lungimea de 3 sau 4 caractere. Fiecare

argument poate avea lungimea până la maxim 40 de caractere. Răspunsurile în POP3

constau dintr-un indicator de status și o comandă, posibil urmată de informații adiționale.

Toate răspunsurile sunt terminate prin perechea CRLF. Răspunsurile pot fi de lungime de

până la 512 caractere, incluzând și CRLF. În mod curent, sunt doi indicatori de status: pozitv

(“+OK”) și negativ (“-ERR”). Serverul trebuie să trimită “+OK” și “-ERR” scrise cu litere mari

(upper case). Răspunsurile la comenzi sunt multi-linie. În aceste cazuri, care sunt clar

indicate mai jos, după trimiterea primei linii a răspunsului și a perechii CRLF , orice linie

adițională este trimisă și fiecare linie se termină cu perechea CRLF. Când toate liniile

răspunsului au fost trimise, este trimisă o linie finală, care formează un octet terminal (cod

zecimal 046, “.”) și perechea CRLF. Dacă orice linie a răspunsului multi-linie începe cu acest

octet terminal, linia este completată cu octeți terminali. Deci, un răspuns multi-linie se

termină cu 5 octeți “CRLF.CRLF”. Când examinează un răspuns multi-linie, clientul verifică

să vadă dacă linia începe cu octetul terminal. Dacă da și ceilalți octeți sunt CRLF, primul

octet al liniei (octetul terminal) este scos. Dacă da și dacă CRLF urmează imediat caracterul

terminal, atunci răspunsul de la serverul POP3 este terminat și linia ce conține “.CRLF” nu

este considerată parte a răspunsului multi-linie. O sesiune POP3 evoluează direct printr-un

număr de stări în timpul vieții ei. O dată ce conexiunea TCP a fost deschisă și severul POP3

a trimis salutul, sesiunea întră în stare de AUTHORIZATION. În această stare, clientul trebuie

să se identifice serverului POP3. O dată ce clientul a făcut acest lucru cu succes, serverul își

formează resursele asociate în funcție de maildrop-ul clientului, și sesiunea întră în starea

de TRANSACTION. În această stare, clientul cere acțiuni serverului POP3. Când clientul a

emis comanda QUIT, sesiunea întră în starea de UPDATE. În această stare, serverul POP3

eliberează orice resursă dobândită în timpul stării de TRANSACTION și spune “goodbye”.

Page 38: 01 Protocoale Ciclu Ex

Apoi conexiunea TCP este închisă. Serverul trebuie să răspundă la o nerecunoaștere,

neimplementare sau o comandă invalidă printr-un indicator de stare negativ. Serverul

trebuie să răspundă unei comenzi cerute când sesiunea este într-o stare incorectă, printr-un

indicator de stare negativ. Nu există o metodă generală pentru un client care să distingă un

server ce nu are implementată o comandă opțională, de un server care nu dorește sau nu

poate să proceseze o comandă. Un server POP3 poate avea timp de inactivitate

(autologout). Ca timp trebuie să fie cel puțin 10 minute. Primirea oricărei comenzi de la

client în timpul acelui interval, este de ajuns să reseteze “autologout timer”. Când timpul

expiră, sesiunea nu poate intra în starea de UPDATE – serverul ar trebui să închidă

conexiunea TCP fără a șterge nici un mesaj sau fără a trimite vreun răspuns clientului.

Starea AUTHORIZATION

O dată ce conexiunea TCP a fost deschisă de un client POP3, serverul POP3 emite o linie de

salut. Acesta poate fi orice răspuns pozitiv. Un exemplu poate fi:

S: +OK POP3 server ready

Sesiunea POP3 este acum în starea de AUTHORIZATION. Clientul trebuie acum să se

identifice și să se autentifice serverului POP3. Două mecanisme posibile pentru aceasta

sunt descrise în acest document, combinația comenzilor USER și PASS și comanda APOP.

Ambele mecanisme sunt descrise în acest document. Mecanisme suplimenatare de

autentificare sunt descrise în RFC 1734. Cât timp există mai multe mecansime de

autentificare acestea sunt cerute de toate serverele POP3, un server POP3 trebuie să

suporte, bineînțeles, cel puțin unul din aceste mecanisme. O dată ce serverul POP3 a fost

determinat complet, utilizarea oricărei comenzi de autentificare a clientului, ar trebui să-i

dea acces la maildrop-ul potrivit; serverul POP3 dobândește acces exclusiv pentru blocarea

maildrop-ului, fiind necesară prevenirea modificării și ștergerii mesajelor înainte ca

sesiunea să intre în starea UPDATE. Dacă blocajul este dobândit cu succes, serverul POP3

răspunde cu un indicator de stare pozitiv. Sesiunea POP3 intră acum în starea

TRANSACTION, cu nici un mesaj marcat pentru ștergere. Dacă maildrop-ul nu a putut fi

deschis din diferite motive (ex. blocajul nu a putut fi realizat, clientul nu are acces la

maildrop, sau maildrop-ul nu poate fi citit), serverul POP3 răspunde cu un indicator de stare

negativ. (Dacă s-a realizat blocajul și serverul POP3 intenționează să răspundă cu un

indicator de stare negativ, atunci el trebuie să se deblocheze înainte de respingerea

comenzii). După returnarea negativă a indicatorului de stare, serverul poate închide

conexiunea. Dacă serverul nu închide conexiunea, clientul poate emite fie o nouă comandă

de autenficare și să pornească din nou, fie poate emite comanda QUIT. După ce serverul

POP3 a deschis maildrop-ul, este asociat un număr fiecărui mesaj și se notează mărimea

fiecărui mesaj în octeți. Primului mesaj din maildrop îi este asociat numărul de mesaj “1”,

celui de-al doilea “2” și așa mai departe, astfel încât celui de-al n-lea mesaj îi este asociat

numărul de mesaj “n”. În POP3 comenzile și răspunsurile, toate numerele de mesaje și

Page 39: 01 Protocoale Ciclu Ex

mărimea mesajelor sunt exprimate în baza 10 (decimal). Iată un rezumat al comenzii QUIT

în starea AUTHORIZATION:

QUIT

Argumente: nici unul

Restricții: nici una

Răspunsuri posibile:

+OK

Exemple:

C: QUIT

S: +OK dewey POP3 server signing off

Starea TRANSACTION

O dată ce clientul s-a identificat cu succes serverului POP3 și serverul POP3 a fost blocat și

a deschis maildrop-ul corespunzător, sesiunea POP3 este acum în starea de TRANSACTION.

Clientul poate emite în acest moment oricare dintre următoarele comenzi POP3, în mod

repetat. Eventual, clientul emite comanda QUIT și sesiunea POP3 intră în starea de UPDATE.

STAT

STAT

Argumente: nici unul

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Serverul POP3 emite un răspuns pozitiv într-o linie care conține informații

pentru maildrop. Această linie este numită “drop listing” pentru acea casuță poștală.Cu

scopul de a simplifica analiza, toate serverele POP3 au nevoie să utilizeze un format sigur

pentru “drop listing”-s. Răspunsul pozitiv constă din “+OK” urmat de un singur spațiu,

numărul de mesaje din maildrop, un singur spațiu, mărimea maildrop-ului în octeți. Acest

memo nu determină nici o condiție ce urmează după mărimea maildrop-ului.

Implementările minimale ar trebui doar să sfârșească linia de răspuns cu lități opționale ce

permit clientului analiza mesajelor din maildrop sunt discutate mai târziu. De observat că

acele mesaje marcate pentru ștergere nu sunt numărate în total.

Răspunsuri posibile:

Page 40: 01 Protocoale Ciclu Ex

+OK nn mm

Exemple:

C: STAT

S: +OK 2 320

LIST[]

LIST [msg]

Argumente: Un număr de mesaj (opțional), care, dacă este prezent, nu poate să se refere

la un mesaj marcat pentru ștergere.

Restricții: Pot fi date doar în starea TRANSACTION

Comentariu: Dacă a fost dat un argument, serverul POP3 emite un răspuns pozitiv cu o

linie ce conține informații pentru acel mesaj. Această linie este numită “scan listing” pentru

mesajul respectiv. Dacă nici un argument nu a fost dat, serverul POP3 emite un răspuns

pozitiv, atunci răspunsul dat este multi-linie. După +OK inițial, pentru fiecare mesaj din

maildrop, serverul POP3 răspunde cu o linie ce conține informații despre acel mesaj.

Această linie mai este numită “scan listing” pentru acel mesaj. Dacă nu sunt mesaje în

maildrop, atunci serverul POP3 răspunde fără “scan listings” – emite un răspuns pozitiv

urmat de o linie conținând octetul terminal și perechea CRLF. În scopul simplificării analizei,

toate serverele POP3 sunt condiționate să utilizeze un format sigur pentru “scan listings”.

Un “scan listing” conține numărul de mesaj al mesajului, urmat de un singur spațiu și

mărimea exactă a mesajului în octeți. Metode pentru calcularea exactă a mărimii mesajului

sunt descrise în secțiunea Formatul Mesajului. Acest memo nu determină nici o condiție

referitoare la ce urmează după mărimea mesajului în “scan listig”. Implementările minimale

ar trebui să termine acea linie de răspuns cu perechea CRLF. Implementările mai avansate

pot include și alte informații, în urma analizei mesajului. Notă: Acest memo descurajează

puternic implementările ce furnizează informații suplimentare în “scan listing”. Alte facilitați

opționale ce permit clientului să analizeze mesajele din maildrop sunt discutate mai târziu.

De observat că mesajele marcate pentru ștergere nu sunt listate.

Răspunsuri posibile:

+OK scan listing follows

-ERR no such message

Exemple:

C: LIST

Page 41: 01 Protocoale Ciclu Ex

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

C: LIST 2

S: +OK 2 200

C: LIST 3

S: -ERR no such message, only 2 messages În maildrop

RETR

RETR msg

Argumente: Un număr de mesaj (obligatoriu) ce nu se referă la un mesaj marcat pentru

ștergere.

Restricții: Poate fi dată doar în faza de TRANSACTION

Comentariu: Dacă serverul POP3 emite un răspuns pozitiv, atunci răspunsul dat este multi-

linie. După +OK ințial, serverul POP3 trimite mesajul corespunzator numărului de mesaj,

fiind atent la completarea caracterului terminal.

Răspunsuri posibile:

+OK urmat de mesaj

-ERR no such mesaj

Exemple:

C: RETR 1

S: +OK 120 octets

S: <the POP3 server sends the entire message here>

S: .

DELE

DELE msg

Page 42: 01 Protocoale Ciclu Ex

Argumente: Un număr de mesaj (obligatoriu) care nu poate să se refere la un mesaj

marcat pentru ștergere.

Restricții: Poate fi dată doar în starea de TRANSACTION

Comentariu: Serverul POP3 marchează mesajele ca șterse. Orice viitoare referință la

numarul asociat mesajului într-o comandă POP3 generează eroare. Serverul POP3 nu șterge

efectiv mesajul până când sesiunea POP3 nu întră în starea UPDATE.

Răspunsuri posibile:

+OK message deleted

-ERR no such message

Exemple:

C: DELE 1

S: +OK message 1 deleted

C: DELE 2

S: -ERR message 2 already deleted

NOOP

NOOP

Argumente: nici unul

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Serverul POP3 nu face nimic, doar răspunde cu răspunsuri pozitive.

Răspunsuri posibile:

+OK

Exemple:

C: NOOP

S: +OK

RSET

RSET

Page 43: 01 Protocoale Ciclu Ex

Argumente: nici unul

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Orice mesaj marcat de serverul POP3 pentru ștergere este demarcat.

Serverul POP3 răspunde apoi cu un răspuns pozitiv.

Răspunsuri posibile:

+OK

Exemple:

C:RSET

S: +OK maildrop has 2 message (320 octets)

Starea UPDATE

Când clientul emite comanda QUIT din starea TRANSACTION, sesiunea POP3 intră în starea

UPDATE. (De observat că, dacă clientul emite comanda QUIT din starea AUTHORIZATION,

sesiunea POP3 se termină, dar nu intră în starea UPDATE). Dacă o sesiune se termină din

anumite motive, altele decât emiterea comenzii QUIT, sesiunea POP3 nu intră în starea

UPDATE și nu șterge nici un mesaj din maildrop.

QUIT

QUIT

Argumente: nici unul

Restricții: nici una

Comentariu: Serverul POP3 șterge toate mesajele marcate pentru ștergere din maildrop și

răspunde cu privire la starea acestei operații. Dacă există o eroare, ex. resursă lipsă,

întâmpinată în timpul ștergerii mesajelor, s-ar putea ca niște mesaje sau nici unul din cele

marcate pentru ștergere să nu fie șterse. Chiar dacă operația s-a realizat cu succes sau nu,

serverul eliberează orice acces exclusiv și închide conexiunea TCP.

Răspunsuri posibile:

+OK

-ERR some deleted message not removed

Exemple:

C: QUIT

Page 44: 01 Protocoale Ciclu Ex

S: +OK dewey POP3 server signing off (maildrop empty)

C: QUIT

S: +OK dewey POP3 server signing off (e messages left)

Comenzi POP3 opționale

Comenzile POP3 discutate mai sus trebuie să fie suportate de toate implementările

minimale de server POP3. Comenzile POP3 discutate mai jos permit clientului POP3 o mai

mare libertate în lucrul cu mesajele, păstrând o implementare simplă de server POP3. Notă:

Acest memo încurajează puternic implementări care să suporte aceste comenzi în locul

celor ce dezvoltă mărirea listelor “drop” și “scan”. În câteva cuvinte, filozofia acestui memo

este de a pune inteligența de partea clientului POP3 și nu a serverului POP3.

TOP

TOP msg n

Argumente: Un număr de mesaj (obligatoriu) care nu poate să se refere la un mesaj

marcat pentru ștergere și un numar pozitiv de linii (obligatoriu).

Restricții: Poate fi dată doar în faza TRANSACTION

Comentariu: Dacă serverul POP3 emite un răspuns pozitiv, atunci răspunsul dat este multi-

linie. După inițialul +OK, serverul POP3 trimite headerele mesajului, o linie goală separând

headerele de corp și apoi un număr de linii separate indicând corpul mesajului, fiind atent la

completarea caracterul terminal. De observat că dacă numărul de linii cerute de clientul

POP3 este mai mare decât numărul de linii ale corpului mesajului, atunci serverul POP3

trimite întregul mesaj.

Răspunsuri posibile:

+OK top of mesaage follows

-ERR no such message

Exemple:

C: TOP 1 10

S: +OK

Page 45: 01 Protocoale Ciclu Ex

S:<the POP3 server sends the headers of the message, a blank line, and the first 10 lines of

the body of message>

S: .

C: TOP 100 3

S: -ERR no such message

UIDL

UIDL [msg]

Argumente: Un număr de mesaj (optional), care, dacă e prezent, nu poate să se refere la

un mesaj marcat pentru ștergere.

Restricții: Poate fi dată doar în starea TRANSACTION

Comentariu: Dacă un argument a fost dat, serverul emite un răspuns pozitiv cu o linie

conținând acel mesaj. Această linie este numita “unique-id listing” pentru acel mesaj. Dacă

nu a fost dat nici un argument și serverul emite un răspuns pozitiv, atunci răspunsul dat

este multi-linie. După +OK inițial, pentru fiecare mesaj din maildrop, serverul POP3

răspunde cu o linie ce conține informații despre acel mesaj. În scopul simplificării analizei,

toate serverele POP3 sunt obligate să utilizeze un format sigur pentru “unique-id listing”. O

lista cu id-ul unic constă dintr-un număr de mesaj al mesajului, urmat de un singur spațiu și

de id-ul unic al mesajului. Nu urmează nici o informație id-ului mesajului din lista de Id-uri

unice. Id-ul unic al mesajului este un string determinat arbitrar de server, conținand 70 de

caractere între 0x21 – 0x7E, care identifică unic un mesaj în cadrul unui maildrop și care

persistă în timpul sesiunii. Această persistență este obligatorie chiar dacă o sesiune se

termină fară a intra în stare UPDATE. Serverul nu ar trebui să reutilizeze un Id unic într-un

maildrop anume, atât timp cât entitatea ce utilizează Id-ul unic respectiv există. De

observat că mesajele marcate pentru ștergere nu sunt listate. Deși, în general, este

preferabil ca implementările pentru server să păstreze Id-urile unice asignate arbitrar în

maildrop, această specificare intenționează să permită ca Id-urile unice să fie calculate ca a

hash of the message. Clienții ar trebui să poată trata situația în care două copii identice ale

unui mesaj din maildrop au acelasși Id unic.

Răspunsuri posibile:

+OK urmat de lista de id-uri unice

-ERR no such message

Exemple:

Page 46: 01 Protocoale Ciclu Ex

C: UIDL

S: +OK

S: 1 whqtswo00WBw418f9t5JxYwZ

S: 2 QhdPYR:00WBwPh7x7

S: .

C: UIDL 2

S: +OK 2 OhdPYR:00WBw1Ph7x7

C: UIDL 3

S: -ERR no such message, only 2 messages În maildrop

USER

USER nume

Argumente: Un șir de caractere identificând o casuță poștală (obligatoriu), care este

semnificativ doar serverului.

Restricții: Poate fi dată doar în starea de AUTHORIZATION după mesajul de salut al

serverului POP3 sau după una din comenzile USER sau PASS terminate cu eroare.

Comentariu: Pentru autentificare utilizând comenzile USER și PASS, clientul trebuie să

emită mai întâi comanda USER. Dacă serverul POP3 răspunde cu un indicator pozitiv

(“+OK”), atunci clientul poate emite fie comanda PASS să completeze autentificarea, fie

comanda QUIT să termine sesiunea POP3. Dacă serverul POP3 răspunde cu un indicator

negativ de stare (“-ERR”) pentru comanda USER, atunci clientul poate emite fie o comandă

nouă de autentificare, fie comanda QUIT. Serverul poate returna un răspuns pozitiv chiar

dacă nu există nici o casuță poștală. Serverul poate returna un răspuns negativ dacă căsuța

poștală există, dar nu permite autentificare de parolă tip plaintext.

Răspunsuri posibile:

+OK nume is a valid mailbox

-ERR never heard of mailbox nume

Exemple:

C: USER frated

Page 47: 01 Protocoale Ciclu Ex

S: -ERR sorry, no mailbox for frated here

C: USER mrose

S: +OK mrose is a real hoopy frood

PASS

PASS șir caractere

Argumente: O parolă de server/căsuță poștală(obligatoriu).

Restricții: Poate fi dată doar în starea de AUTHORIZATION imediat după o comandă USER

încheiată cu succes.

Comentariu: Când un client emite comanda PASS, serverul POP3 utilizează perechea de

argumente de la USER și comenzile PASS să determine dacă clientului ar trebui să i se

permită accesul la maildrop-ul respectiv. Deoarece comanda PASS are exact un argument,

serverul POP3 poate trata spațiile în argument ca parte a parolei, în loc de separatoare de

argument.

Răspunsuri posibile:

+OK maildrop locked and ready

-ERR invalid password

-ERR unable to lock maildrop

Exemple:

C: USER mrose

S: +OK mrose is a real hoopy frood

C: PASS secret

S: -ERR maildrop already locked

C: USER mrose

S: +OK mrose is a real hoopy frood

C: PASS secret

S: +OK mrose’s maildrop has 2 messages (320 octets)

APOP

Page 48: 01 Protocoale Ciclu Ex

APOP nume rezumat

Argumente: Un șir de caractere identificând căsuța poștală și un rezumat MD5 (amandouă

obligatorii).

Restricții: Poate fi dată doar în starea de AUTHORIZATION după salutul serverului POP3

sau după una din comenzile USER sau PASS terminate cu insucces.

Comentariu: În mod normal, fiecare sesiune POP3 începe cu USER/PASS. Aceasta sfârșește

serverul / id-ul user-ului specific, parola fiind trimisă în rețea. Multe implementări de client

POP3 se conectează la un server POP3 în mod obișnuit – pentru a verifica mail-ul nou. În

plus intervalul sesiunii inițiate poate fi de 5 minute. Deci, riscul capturării parolei este mare.

Este necesară o metodă alternativă de autentificare, care să furnizeze cele două metode

originale de autentificare și protejare a răspunsului, care să nu implice trimiterea parolei

neprotejate în rețea. Comanda APOP furnizează această funcționalitate. Un server POP3

care implementează comanda APOP va include o marcă de timp în banner-ul mesajului de

salut. Sintaxa acestei marcări a timpului corespunde lui “msg-id” din RFC 822 și trebuie să

fie diferită de fiecare dată când serverul POP3 emite un banner de salut. De exemplu, într-o

implementare UNIX în care sunt utilizate procese UNIX separate pentru fiecare instanță a

serverului POP3, sintaxa unei mărci de timp poate fi: process-ID.clock@hostname unde

“process-ID” este o valoare zecimală a PID-ului procesului, “clock” este o valoare zecimală

a timpului sistemului și “hostname” este numele complet al domeniului corespunzător

gazdei unde rulează serverul POP3. Clientul POP3 ia la cunoștință de această marcă de timp

și apoi emite comanda APOP. Parametrul “nume” are aceași semantică exact ca parametrul

“nume” din comanda USER. Parametrul “rezumat” este calculat prin aplicarea algoritmului

MD5 RFC 1321 unui șir de caractere compus din marca de timp (incluzând parantezele –

unghiulare) urmat de informația secretă. Informația secretă (shared secret) este un șir de

caractere cunoscut numai de clientul și serverul POP3. Mare atenție ar trebui acordată

pentru a împiedica o dezvăluire neautorizată a secretului, cunoașterea secretului va

permite oricarei entitați să se ascundă sub acel nume de user. Parametrul “rezumat” este o

valoare pe 16 octeți care este trimisă în format hexazecimal, utilizând caracterele ASCII

lower-case. Când serverul POP3 primește comanda APOP, verifică rezumatul furnizat. Dacă

rezumatul este corect serverul POP3 emite un răspuns pozitiv și sesiunea POP3 intră în

starea TRANSACTION. Altfel, un răspuns negativ este emis și sesiunea POP3 rămâne în

starea AUTHORIZATION. De observat că, lungimea informații secrete crește, deci și

dificultatea. Ca atare, informațiile secrete ar trebui să fie de lungime mare (mult mai mult

de 8 caractere ca în ex. de mai jos).

Răspunsuri posibile:

+OK maildrop locked and ready

-ERR permission denied

Page 49: 01 Protocoale Ciclu Ex

Exemplu:

S: +OK POP3 server ready <[email protected]>

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

S: +OK maildrop has 1 message (369 octetes)

În acest exemplu, informația secretă este șirul “tan-staaf”. Deci, algoritmul MD5 este

aplicat șirului: <[email protected]>tanstaaf care produce o valoare

rezumat a: c4c9334bac560ecc979e58001b3e22fb

Considerații

De când caracteristicile principale descrise mai sus au fost adăugate la protocolul POP3, s-a

acumulat experiență în utilizarea lor pe scară largă în operații de “post office” unde cei mai

mulți utilizatori nu se cunosc unii cu ceilalți. În aceste situații și altele, utilizatorii și

vânzătorii de clienți POP3 au descoperit că o combinație între comanda UIDL și neemiterea

comenzii DELE, poate furniza o versiune slabă de “depozit maildrop semi-permanent”

având o funcționalitate normală asociată cu IMAP. Desigur alte calităti IMAP, așa cum

verificând o conexiune existentă pentru mesajele noi sosite și suportând foldere multiple pe

server, nu sunt prezente în POP3. Când aceste facilități sunt utilizate ocazional de către

utilizatori, există o tendință de recitire a mesajelor acumulate pe server fară limită. Acesta

este clar un tip de comportament nedorit din punctul de vedere al operatorului de server.

Această situație este agravată de faptul că posibilitățile limitate ale POP3-ului nu permit

manipularea eficientă a maildrop-urilor care au mii de mesaje. În consecință, este

recomandat ca operatorii de servere multi-users la scară largă, în special cei care au acces

la maildrop doar via POP3, să considere următoarele alternative:

Impunând alocarea de spațiu de depozitare a maildrop-ului. Un dezavantaj al acestei

opțiuni este că acumularea de mesaje poate provoca neputința utilizatorului de a primi

noi mesaje în maildrop. În situațiile în care se alege această opțiune ar trebui să se

asigure informarea utilizatorilor asupra acestui impediment sau epuizarea spațiului,

poate prin inserarea unui mesaj potrivit în maildrop-ul userului.

Impunând o poliță de asigurare privind păstrarea pe server. Utilizatorii sunt liberi să

stabilească această poliță de asigurare privind depozitarea și păstrarea mesajelor pe

server, cele citite și cele necitite. De exemplu, un utilizator poate șterge mesajele

necitite de pe server după 60 de zile și pe cele citite după 7 zile. Ștergerile de mesaj

sunt în afara protocolului POP3 și nu sunt considerate o violare de protocol. Operatorii

de server impunând polițele de asigurare cu privire la ștergerea mesajelor ar trebui să

aibă grijă să facă toți utilizatorii conștienți de puterea acestora. Clienții nu trebuie să

presupună că o poliță va șterge automat mesajele și ar trebui să continue să șteargă

explicit mesajele utilizând comanda DELE când este cazul. De notat că impunerea

acestor polițe de asigurare de ștergere poate fi confuză pentru utilizatorii simpli,

Page 50: 01 Protocoale Ciclu Ex

deoarece clientul lor POP3 poate conține opțiuni de configurare de a șterge mail-ul de

pe server, care nu va fi de fapt suportat de server. Un caz special al polițelor este că

mesajele pot fi doar download-ate odată de pe server și sunt șterse după ce acesta a

terminat operația. Aceasta ar putea fi implementată de un server POP3 prin următorul

mecanism: ”urmărind un login de client POP3 care a terminat prin QUIT, șterge toate

mesajele download-ate în timpul sesiunii cu comanda RETR”. Este important să nu se

șteargă mesajele dacă conexiunea s-a încheiat printr-un eveniment anormal (ex. dacă

QUIT nu a fost primit de la client) deoarece clientul poate nu a primit sau nu a salvat cu

succes mesajele). Serverele ce implementează polițele downloadează-și-șterge pot de

asemenea să dorească să dezactiveze sau să limiteze comanda TOP, deși ar putea fi

utilizată ca un mecanism alternativ pentru a downloada toate mesajele.

Exemplu de sesiune POP3

S: <wait for connection on TCP port 110>

C: <open connection>

S: +OK POP2 server ready <[email protected]>

C: APOP mrose c4c9334bac560ecc97e58001b3e22fb

S: +OK mrose’s maildrop has 2 messages (320 octets)

C: STAT

S: +OK 2 320

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

C: RETR 1

S: +OK 120 octets

S: <the POP3 server sends message 1>

S: .

C: DELE 1

S: +OK message 1 deleted

C: RETR 2

S: +OK 200 octets

S: <the POP3 server sends message 2>

S: .

C: DELE 2

S: +OK message 2 deleted

C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

C: <close connection>

S: <wait for next connection>

Page 51: 01 Protocoale Ciclu Ex

Formatul Mesajului

Toate mesajele transmise în timpul sesiunii POP3 sunt sumate conform standardului pentru

formatul textelor mesajelor pentru Internet RFC 822. Este important de observat că

numărarea octetului pentru un mesaj de pe un server gazdă poate diferi de numărarea

octetului asignat mesajului datorită convențiilor locale pentru desemnarea sfârșitului de

linie (end-of-line). De obicei, în timpul stării de AUTHORIZATION a unei sesiuni POP3,

serverul POP3 poate calcula mărimea fiecărui mesaj în octeți când deschide maildrop-ul. De

exemplu, dacă serverul gazdă POP3 numără fiecare apariție a acestui caracter ca doi octeți.

Acele linii din mesaj care încep cu octetul terminal nu au nevoie (și nu trebuie) numărate de

doua ori, deoarece clientul POP3 va șterge toate caracterele de terminale când primește un

răspuns multi-linie.

1.13 Protocolul FTP (File Transfer Protocol) este protocolul destinat transmiterii fişierelor în reţelele de calculatoare. FTP permite conectarea la serverele FTP, vizualizarea conţinutului cataloagelor, descărcarea şi încărcarea fişierelor de pe server şi pe server, fiind deasemenea posibil regimul de transmitere a fişierelor între servere.

FTP este unul din cele mai vechi protocoale a Nivelului Aplicaţie, apărînd cu mult înaintea lui HTTP în 1971. Pînă la începutul anilor '90, lui FTP îi revenea aproximativ jumate din traficul total a reţelei Internet. El şi acum este utilizat pe larg în răspîndirea deservirii software-ului şi accesul la hosturile îndepărtate. Pentru transmiterea de date FTP utilizează protocolul TCP. Comenzile şi datele spre deosebire de majoritatea altor protocoale se transmit prin porturi diferite. Portul 20 este utilizat pentru transmiterea de date, portul 21 pentru transmiterea de comenzi. În cazul în care transmiterea fişierului a fost întreruptă,din cauza oricărui motiv, protocolul dispune de mijloace pentru reluarea acestuia, fapt care este foarte comod în cazul transmiterii unor fişiere mari.

Figura 1.1.1 Protocolul FTP

Page 52: 01 Protocoale Ciclu Ex

Protocolul nu se criptează, în momentul autentificării, login-ul şi parola sunt transmise în mod deschis.În cazul în care în reţea se utilizează un hub, raufăcătorul cu ajutorul uni sniffer pasiv poate intercepta login-ul şi parola care se află în acelaşi segment de reţelei a utilizatorilor FTP, sau avînd anumite programe necesare să obţină datele transmise prin FTP fără autorizare. Pentru a evita interceptarea traficului, este necesară utilizarea unui protocol de criptare a datelor precum SSL, care este susţinut de multe servere FTP şi de către unii clienţi FTP. Procesul autorizării necriptate are loc prin mai multe etape. Dacă spre server este permis accesul anonim, atunci în calitate de login este utilizat cuvîntul cheie «anonymous» sau «ftp», iar în calitate de parolă – adresa poştei electronice.După autorizarea cu succes, la server pot fi transmise şi alte comenzi.

Figura 1.1.2 Setarea unei sesiuni FTP Comenzile de bază

ABOR– întreruperea transmiterii datelorCDUP– schimbarea directoriului pe unul care se află mai susCWD– schimbarea directorieiDELE– ştergerea fişieruluiEPSV– conectarea regimului pasiv de bandă largăHELP– arată lista de comenzi acceptată de serverLIST– întoarce lista de fişiere a directoriilor.Lista se transmite prin legătura datelor (portul 20)MDTM– întoarce timpul de modificare a fişieruluiMKD– crearea unei directoriiNLST – întoarce lista fişierelor directoare într-un format mai scurt decît LISTNOOP– operaţiune goalăPASV– intrarea în regimul pasiv.Serverul va întoarce adresa şi portul la care trebuie de conectat pentru a lua datele. Transmiterea va începe la introiducerea următoarelor comenzi RETR, LIST etc.PORT– intrarea în regimul activ. Spre exemplu PORT 12, 34, 56, 78, 89. Spre deosebire de regimul pasiv de transmitere adatelor, servereul face conectarea cu clientul singur.PWD– întoarce directoria curentăQUIT– deconectare

Page 53: 01 Protocoale Ciclu Ex

REIN– reiniţializarea conectăriiRETR– descărcarea fişierului. Înainte de RETR trebuie să fie comanda PASV sau PORT.RDM– ştergerea directorieiSIZE– întoarce mărimea fişieruluiSTOR– încărcarea fişierului.Înainte de STOR trebuie sa fie comanda PASV sau PORTSYST– întoarce tipul sistemei (UNIX,WIN... etc)TYPE– stabilirea tipului de transmitere a fişierului (binar, textual)USER– numele utilizatorului pentru intrarea pe server.

220 FTP server ready.USER ftp //Анонимус230 Login successful.PASV227 Entering Passive Mode (192,168,254,253,233,92)//Клиент должен открыть соединение на переданный IPLIST150 Here comes the directory listing. //Сервер передает список файлов в директории226 Directory send OK.CWD incoming250 Directory successfully changed.PASV227 Entering Passive Mode (192,168,254,253,207,56)STOR gyuyfotry.avi150 Ok to send data. //Клиент передает содержимое файла226 File receive OK.QUIT221 Goodbye.

Figura 1.2.1 Suita de comenzi FTP Argumentul 192, 168, 254, 253, 207, 56 înseamnă că legătura de la server este aşteptată la nodul cu adresa IP 192.168.254.253 pe portul 207*256+56=53048. Multe servere FTP dispun de un catalog (cu denumirea de incoming sau upload), deschis pentru scriere şi destinat petru încărcarea fişierelor pe server. Acest lucru permite utilizatorilor să completeze serverul cu date noi. ------------- |/---------\| || User || -------- ||Interface|<--->| User | |\----^----/| -------- ---------- | | | |/------\| FTP Commands |/----V----\| ||Server|<---------------->| User || || PI || FTP Replies || PI || |\--^---/| |\----^----/| | | | | | | -------- |/--V---\| Data |/----V----\| -------- | File |<--->|Server|<---------------->| User |<--->| File | |System| || DTP || Connection || DTP || |System| -------- |\------/| |\---------/| -------- ---------- -------------

Server-FTP USER-FTP

Figura 1.2.2 Pricipiul de lucru a protocolului FTP

Page 54: 01 Protocoale Ciclu Ex

Precum este arătat în diagrama de mai sus, FTP utilizează comenzi şi date de transfer separate. Interpretatorul de protocol (PI) implementează însăşi protocolul FTP, în timp ce Procesul de Transfer al Datelor (DTP) în realitate efectuează transferul de date. Protocolul FTP şi transferul de date utilizează sesiuni TCP complet diferite. Se ţine cont de faptul că conexiunile de date pot fi realizate în ambele direcţii şi că aceste conexiuni nu trebuie să existe permanent.

Utilizarea FTP

FTP este unul din cele mai utile aplicaţii TCP/IP, pentru un utilizator obişnuit. FTP-ul anonim este de obicei accesibil pe site-urile arhivelor de fişiere şi permite utilizatorilor să acceseze fişiere fără a avea un cont stabilit cu hostul. Cîndva, o sesiune FTP (actual , o conexiune ce control FTP), putea fi stabilită utilizînd un server FTP şi folosind comenzile de la FTP hostname. Opţional, adresa IP a hostului (în format zecimal) putea fi utilizată în loc de numele hostului. Hostul îndepărtat va cere un nume de utilizator şi o parolă. Dacă numele utilizatorului şi parola care au fost oferite sunt identificate ca un utilizator de încredere, utilizatorul va avea acces la orice fişiere la care are accesul acest nume de utilizator. Pentru acces FTP aninim este utilizat numele anonim al utilizatorului şi parola este deseori adresa de e-mail al utilizatorului. Vîrsta lui World Wide Web (WWW), poate crea impresia că FTP este ineficient, dar în realitate mulţi utilizatori încă mai utilizează acest protocol fără a realiza acest lucru. Imaginea de mai jos arată cum companiile precum Netscape, creatorii a multor browsere disponibile pe Internet, utilizează FTP pentru a distribui ultima versiune a produsului lor software.

Figura 1.3.1 Utilizarea FTP

Mai degrabă decît să utilizeze o interfaţă a liniei de comandă (CLI), Netscape profită de uşor utilizabila interfaţă grafică a utilizatorului (GUI) cu care oamenii sunt deja obişnuiţi. Cînd un utilizator face click pe fişierul pe care îl doreşte, browser-ul său este direcţionat la un server FTP în locul unui server Web. De fapt FTP-ul anonim este utilizat

Page 55: 01 Protocoale Ciclu Ex

automat cu browser-ul care transmite numele anonim al utilizatorului şi adresa de e-mail în calitate de parolă. În cazul transferurilor de fişiere la un alt server, conexiunile sunt direcţionate spre serverul Web, pentru a distribui informaţii care sunt mai potrivite pentru accesul Web.In plus, exista doua tipuri de conexiuni la un server de FTP : activ si pasiv.In modul FTP activ, clientul stabileste conexiunea de la un port neprivilegiat (AM023) la portul de comanda 21 al serverului FTP. Dupa aceea, clientul va incepe sa asculte la portul N+1 si trimite comanda FTP, PORT N+1 serverului FTP. La randul sau, serveral se va conecta de la portul de date local 20 la portul de date specificat anterior de client.

Passive mode

La început protocolul presupunea o legătură de întîlnire TCP de la server la client, pentru transmiterea de date sau conţinutului catalogului. Acest lucru făcea discuţia cu serverul foarte dificilă, dacă clientul se afla în afara IPNAT, cu atît mai mult deseori cererea de conexiune cu clientul este blocată de firewall. Pentru a evita acest lucru, a fost elaborată dezvoltarea protocolului FTP passive mode, atunci cînd conexiunea pentru transmiterea datelor tot are loc de la client la server. Un fapt important este că clientul stabileşte o conexiune cu adresa şi portul, indicat de server. Portul este ales de srever în mod aleator dintr-un diapazon determinat (49152-65534). De aceea în cazul aflării serverului FTP în afara NAT, trebuie cu siguranţă de indicat în setările serverului adresa lui.

In modul FTP pasiv, clientul va deschide aleator doua porturi neprivilegiate (AM023 si N+1). Primul din aceste porturi va contacta serverul pe portul 21 si trimite comanda FTP, PASV. Rezultatul acestei comenzi transmise de client, este deschiderea de catre serverul FTP unui port neprivilegiat aleator (P>1023) si trimiterea comenzii FTP, PORT P. In final, clientul va stabili o conexiune intre portul N+1 si portul P al serverului FTP pentra tranferal datelor.

Page 56: 01 Protocoale Ciclu Ex

FXP File eXchange Protocol este o metodă de transmitere directă a fişierelor între două servere FTP, fără a le downloada pe calculatorul personal. În cazul sesiunii FXP clientul deschide două conexiuni FTP, la două servere diferite, cerînd fişierul pe primul server, menţionînd în comanda PORT adresa IP a celui de al doilea server.

Un avantaj incontestabil în susţinerea standardului FXP este faptul că în cazul utilizatorilor finali care doresc să copie fişiere de pe un server pe altul, deja nu mai este valabilă limitarea lăţimii de bandă a conexiunii lor proprii. Nu este necesar de a copia fişierul pe calculatorul personal pentru că mai apoi să-l încarci pe alt server (totul se face direct). Astfel timpul de transmitere a fişierelor va depinde numai de viteza conexiunii între cele două servere îndepărtate, care de obicei este cu mult mai mare decît cea a utilizatorilor. Din păcate FPX a început a fi utilizat de către răufăcători pentru atacul la alte servere: în comanda PORT este indicată adresa IP şi portul serviciului atacat pe calculatorul jertfei, iar prin intermediul comenzilor RETR/STOR este realizată chemarea la acest port din partea serverului FTP, dar nu a atacantului, ce permitea crearea unor atacuri DDoS de scară largă cxu utilizarea concomitetă a mai multor servere FTP, sau de a ocoli sistema de siguranţă a jertfei, dacă el se bazează numai pe verificarea clientului IP şi serverul utilizat pentru atac se află în reţeaua de încredere sau în gateway. În cazul în care reţeaua este construită pe switch-uri (comutatoare), implicit acest lucru este exclus, dar atacatorul poate intercepta traficul, în cazul în care schimbă adresa mac a adaptorului său de reţea pe mac-ul victimei, deoarece comutarea are loc în cadrul celui de-al doilea nivel OSI (pe baza adreselor mac).

TFTP (англ. Trivial File Transfer Protocol — простой протокол передачи файлов) используется главным образом для первоначальной загрузки бездисковых рабочих станций. TFTP, в отличие от FTP, не содержит возможностей аутентификации (хотя возможна фильтрация по IP-адресу) и основан на транспортном протоколе UDP.Применение

Основное назначение TFTP — обеспечение простоты реализации клиента. В связи

с этим он используется для загрузки бездисковых рабочих станций, загрузки

обновлений и конфигураций в «умные» сетевые устройства, записи статистики

с мини-АТС (CDR) и аппаратных маршрутизаторов/файрволов.Безопасность

Page 57: 01 Protocoale Ciclu Ex

Поскольку протокол не поддерживает аутентификации, единственный метод

идентификации клиента — это его сетевой адрес (который может быть

подделан). Обычно в Unix-системах tftpd доступен только каталог /tftpboot.

Однако в старых TFTP-серверах было возможным получить файл паролей

командой RRQ ../etc/passwd.

Демон tftpd (одна из реализаций tftp-сервера) отказывается обрабатывать файлы,

содержащие в своём имени комбинацию «/../» или начинающуюся с «../». Запись

разрешается только в файлы, которые уже существуют (любого размера,

например нулевого), и доступны для публичной записи (права доступа: -rw-rw-

rw-). [1]

Дополнительная защита от доступа к произвольным файлам осуществляется с

помощью смены корневого каталога на каталог tftpd (обычно /usr/TFTPRoot).Типы пакета

Сначала в TFTP-пакете идет поле размером в 2 байта, определяющее тип пакета:

Read Request (RRQ, #1) — запрос на чтение файла.

Write Request (WRQ, #2) — запрос на запись файла.

Data (DATA, #3) — данные, передаваемые через TFTP.

Acknowledgment (ACK, #4) — подтверждение пакета.

Error (ERR, #5) — ошибка.

Error2 (ERR2, #6) — ошибка2.Запросы на чтение и запись

Для начала передачи данных клиент должен послать серверу WRQ или RRQ-

пакет. У обоих пакетов формат одинаковый:

0x01/0x02

(тип пакета)

Имя

файла

0x00 (конец

строки)

Режим

передачи

0x00 (конец

строки)

Опции…

(если есть)

2 байтастрока

в ASCII1 байт

строка в

ASCII1 байт См. «Опции»

В TFTP существует 2 режима передачи (режим Mail, определенный в IEN 133,

признан устаревшим):

netascii — файл перед передачей перекодируется в ASCII.

octet — файл передается без изменений.

После получения RRQ-пакета сервером, он сразу начинает передачу данных. В

случае с WRQ-запросом — сервер должен прислать ACK-пакет c номером пакета

0.Процесс передачи данных

После получения запроса RRQ, сервер сразу посылает в качестве подтверждения

пакет с данными и с ID пакета равным единице. В WRQ в качестве

подтверждения используется ACK с ID равным нулю. Всего по TFTP можно

передать 32 Мб (65536 * 512 / 1024²), однако из-за использования

знакового int вместо беззнакового, размер подтверждения ограничен 16

мегабайтами. Однако если клиент и сервер поддерживают расширения

Page 58: 01 Protocoale Ciclu Ex

протокола RFC 2347 и RFC 2348, то максимальный размер передаваемого файла

увеличивается до 4Gb.Опции TFTP

В RFC 2347 был предусмотрен формат опций, которые можно присоединять к

окончанию RRQ-пакета и WRQ-пакета:

Код

опции

0x00 (конец

строки)

Значение

опции

0x00 (конец

строки)

строка

в ASCII1 байт

строка в

ASCII1 байт

Опций может быть несколько. Тогда они будут следовать друг за другом.

Порядок опций не важен.

В ответ на RRQ (или WRQ) с опциями, сервер должен прислать OACK с списком

опций, которые сервер принял. Наиболее распространённые опции:

НазваниеОпредел

ена в

Код

опции

Размер блока RFC 2348 blksize

В качестве значения опции идёт число,

принимающее значение от 8 до 65464,

обозначающее размер блока.

Интервал

повторной

передачи

(Timeout)

RFC 2349timeou

t

В качестве значения опции идёт число,

принимающее значение от 1 до 255,

обозначающее время ожидания перед

повторной передачей блока в секундах.

Размер файла RFC 2349 tsize

В качестве значения опции идёт число,

обозначающее размер передаваемого файла

в байтах.Ошибки

В TFTP информация об ошибке имеет следующий формат:

0x05 (тип

пакета)

Код

ошибки

Описание

ошибки

0x00 (конец

строки)

2 байта 2 байта строка в ASCII 1 байт

Код ошибки может принимать одно из значений, перечисленных в STD 33 (за

исключением кода 8 — он описан в RFC 2347). Вот они:

Код

ошибкиОписание

0Нет определенного кода, см.

текст ошибки

1 Файл не найден

2 Доступ запрещен

3Невозможно выделить место на

диске

4 Некорректная TFTP-операция

Page 59: 01 Protocoale Ciclu Ex

5 Неправильный Transfer ID

6 Файл уже существует

7 Пользователь не существует

8 Неправильная опция

1.14 SSH (Secure Shell ― "membrană sigură") este un protocol de reţea a Nivelului Sesiune şi Aplicaţie, care permite gestionarea de la distanţă a sistemei de operare şi securizarea conexiunilor TCP cu ajutorul unui tunel (ex. în cazul transmiterii de date). Se aseamănă după funcţionalitate cu protocoalele Telnet şi rlogin, dar spre deosebire de ele criptează tot traficul, inclusiv şi parolele transmise.

Astfel SSH permite transmiterea sigură a datelor într-un mediu nesigur, practic oricărui protocol de reţea. În aşa mod este posibil nu numai lucru de la distanţă la calculator prin intermediul tunelului securizat, dar şi transmiterea prin acest canal a fluxului audio şi video. Deasemenea el ajută la comprimarea datelor pentru criptarea lor ulterioară. Portul/ID utilizat este 22/TCP.

SSH constă din trei componente majore:

Protocolul Nivelului Transport (SSH-Transport) asigură serverului autentificare, confidenţialitate şi integritate. Opţional poate oferi compresia datelor. Nivelul Transport va rula tipic peste o conexiune TCP/IP, dar poate fi deasemenea folosit în partea superioară a oricărui flux sigur de date.

Protocolul de autentificare a utilizatorului (SSH-UserAuth) autentifică partea de client a utilizatorului către server. Rulează peste Protocolul Nivelului de Transport.

Protocolul de conexiune (SSH-Connect) multiplexează tunelul criptat în mai multe canale logice. Rulează peste Protocolul de autentificare a utilizatorului.

Clientul transmite o cerere de serviciu de îndată ce a fost stabilită o conexiune sigură a nivelului transport. A doua cerere de serviciu este trimisă atunci cînd autentificarea utilizatorului este completă. Acest lucru permite protocoalelor noi să fie definite şi să coexiste cu protocoalele enumerate mai sus. Protocolul de conexiune oferă canalele care pot fi utilizate pentru o gamă largă de scopuri. Sunt oferite metode standard pentru setarea unor sesiuni interactive sigure şi pentru tunelarea arbitrară a porturilor TCP/IP şi a conexiunilor X11.

Arhitectura SSH

Protocolul SSH are următoare arhitectură:

1. Host Keys (cheia gazdă) ― fiecare server trebuie să aibă o cheie gazdă.Cheia gazdă a serverului este utilizată în timpul schimbului de chei pentru a verifica că clientul vorbeşte cu serverul corect(care trebuie).

Pot fi utilizate două modele diferite:

Clientul are o bază de date locală, care asociază fiecare nume a gazdei (host name) cu cheia publică corespunzătoare acestuia.

Asocierea numelui gazdei cu cheia este certificată de către o autoritate certificată de încredere (CA).

Page 60: 01 Protocoale Ciclu Ex

Figura 3.2.1 Arhitectura SSH

2. Extensibilitate ― noi credem că protocolul va evolua în timp şi unele organizaţii vor dori să utilizeze criptarea lor proprie şi metodele de schimb a cheilor. Înregistrarea centrală a tuturor extensiilor este greoaie, mai ales pentru elementele experimentale. Pe de altă parte, lipsa unei înregistrări centrale duce la conflicte în metodele de identificare, făcînd dificilă interoperabilitatea.

3. Policy Issues― protocolul permite negocierea deplină a criptării, integrităţii, schimbului de chei,compresiei şi algoritmele cheii publice. Următoarele trebuiesc incluse în mecanismul de configurare pentru fiecare implimentare:

Algoritmele de criptare, integritate şi compresie sunt separate pentru fiecare direcţie

Algoritmele heilor publice şi metoda schimbului de chei să fie utilizate pentru autentificare.

Metodele de autentificare existente să fie cerute de către server pentru fiecare utilizator.

4. Proprietăţile de securitate ― scopul principal al protocolului SSH este asigurarea securităţii în reţeaua Internet. El încearcă să facă acest lucru într-un mod uşor de implimentat, chiar şi la preţul siguranţei absolute.

Astfel toate algoritmele de criptare, integritate şi a cheii publice utilizate sunt bine cunsocute şi bine stabilite. Toate algoritmele utilizează chei criptografice, care oferă protecţie chiar şi celor mai puternice atacuri a timpului. Toate algoritmele sunt negociate şi în caz că un algoritm este distrus, este uşor de a realiza comutarea la alt algoritm, fără a modifica protocolul de bază.

5. Localizarea şi Suportul setului de caractere

Stabilirea conexiunii

Stabilirea unei conexiuni SSH decurge în urmatoarele etape:

1. Clientul şi serverul se înteleg asupra unei chei de sesiune, folosind în acest scop protocolul Diffie-Helman. În continuare, întreaga comunicaţie este criptată cu cheia de sesiune.

Page 61: 01 Protocoale Ciclu Ex

2. Clientul autentifică serverul. În acest scop, serverul trimite rezultatul semnării cheii de sesiune cu cheia sa secretă. Clientul verifica semnatura folosind în acest scop cheia publică a serverului.

Pentru uşurarea utilizării sistemului, serverul îşi trimite şi cheia publică. Dacă clientul nu are cheia publică a serverului, o poate folosi pe cea trimisă de server - evident opţiunea este nesigură, deoarece serverul înca nu a fost autentificat şi deci s-ar putea să fie un intrus. Utilizatorul este avertizat asupra acestui risc, şi cheia publică a serverului este înregistrată în baza de date a clientului, la urmatoarea conectare la acelaşi server cheia publică urmînd sa fie luată din baza de date.

3. Serverul autentifică clientul. În funcţie de configuraţia serverului, poate accepta autentificare cu criptografie asimetrică, folosind acelaşi protocol (dar bineînţeles fără posibilitatea trimiterii de către client a cheii sale publice), sau poate cere clientului o parola.

Figura 3.3.1 Conexiunea SSH

După stabilirea conexiunii, toate datele care circulă pe conexiune sunt împărţite în pachete, transmise în modul următor:

1. Mai întîi, se construieşte o suma de control, prin aplicarea unei funcţii de dispersie criptografică asupra rezultatului juxtapunerii pachetului de date cu numărul său de ordine şi cu cheia de sesiune.

2. Se formează un pachet din lungimea datelor, datele propriu-zise, suma de control calculată la pasul anterior, şi o completare cu biţi aleatori pînă la un multiplu al lungimii blocului acceptat de algoritmul de criptare

3. Pachetul format anterior se criptează cu cheia de sesiune, folosind un algoritm simetric pe bloc în modul CBC

Autentificarea clientului SSH

Autentificarea clientului se poate face prin parolă sau prin criptografie asimetrică. În cazul criptografiei asimetrice, cheia secretă trebuie memorată pe discul maşinii client (o cheie pentru criptografie asimetrică nu poate fi memorată rezonabil de om). Stocarea cheii secrete pe disc fiind un risc de securitate, SSH oferă posibilitatea stocării cheii secrete criptate folosind ca şi cheie o frază (memorabilă de om).

Page 62: 01 Protocoale Ciclu Ex

Figura 3.4.1 Autentificarea SSH utilizînd sistemul de autentificare Kerberos

Pentru ca clientul SSH să nu ceară fraza-cheie pentru decriptarea cheii secrete, SSH oferă următorul mecanism:

Se lansează o aplicaţie numită agent de autentificare. Aceasta citeşte cheia secretă criptată, cere fraza-cheie de decriptare şi decriptează cheia secretă, pe care o ţine în memoria RAM;

La lansarea unui client SSH, acesta încearca să contacteze agentul de autentificare - dacă agentul rulează în acel moment. Comunicaţia se face local prin primitive sigure oferite de sistemul de operare al maşinii client - de exemplu, prin FIFO UNIX. Clientul SSH trimite agentului cheia de sesiune, iar agentul îi returnează semnatura;

Opţional, la deschiderea unei sesiuni SSH, se poate forwarda conexiunea către agentul de autentificare.

Figura 3.4.2 Autentificarea SSH bazată pe chei

Comenzi SSH

Mai jos sunt prezentate doar cîteva comenzi a protocolului SSH:

ls – lista de fişiere şi cataloage

ls-al – lista formată ce conţine fişierele şi cataloagele secrete

Page 63: 01 Protocoale Ciclu Ex

cd dir – schimbarea directoriei în dir

pwd – cerere de a arăta catalogul current

rm file – ştergerea unui fişier

cp file1 file2 – copierea fişierului1 în fişierul2

touch file – crearea unui fişier

ssh user@host – conectarea la host ca utilizator

ssh-copy-id user@host – adăugarea cheii la host-ul utilizatorului pentru a conecta logarea fără parolă, însă după chei.

ping host– efectuarea comenzii ping pentru host şi afişarea rezultatului

wget – donloadarea fişierului

Serviciile SSH

SSH nu permite numai sesiuni de lucru prin reţea, ci şi alte aplicaţii. Astfel, o dată deschis un canal securizat, pachetele vehiculate pot fi destinate mai multor aplicaţii, lista celor mai importante fiind:

sesiune de lucru (în mod text);

transfer de fişiere (cunoscut şi ca sftp sau scp; există totuşi o mică diferenţă între cele două);

forwardarea unor porturi TCP;

forwardarea unui server X (clientul SSH acţioneaza ca server X pe maşina locală, dar cererile de la clienţii X le forwardează serverului X de pe maşina server SSH);

forwardarea unui agent de autentificare.

1.15 Protocolul SMTPProtocolul folosit pentru a trimite un mesaj de pe calculatorul unui client către un

server destinaţie (fie cel final, al destinatarului, fie unul intermediar) se numeşte SMTP (Simple Mail Transfer Protocol).

Primul set de specificaţii a fost documentat în RFC 821 (Request For Comment), de către Jonathan B. Postel, în 1982.

Portul TCP standard pentru protocolul SMTP este 25. Sarcina acestui protocol este de a permite transferul mesajelor într-un mod

eficient, şi este un sistem independent care necesită stabilirea unui canal de comunicaţie duplex între cele două calculatoare care participă la schimbul de mesaje (calculatorul care trimite mesajul şi cel care-l preia şi eventual il trimite mai departe).

Protocolul SMTP defineşte un limbaj de comunicare între echipamentul care transmite (client) şi echipamentul care primeşte mesajul electronic (server). Comunicaţia între echipamentul client şi echipamentul server se efectuează în modul următor: clientul trimite o comanda server-ului, acesta o execută şi o returnează clientului un cod numeric.

Comenzi SMTP Comenzile SMTP constă din codul comenzii format din patru litere si urmat

opţional de un parametru. Comenzile acestea pot fi scrise atît cu minuscule cît şi cu majuscule şi reprezintă o combinaţie de prescurtări de cuvinte specifice din limba engleză. Pentru a se trimite şi executa o comandă este necesar ca aceasta să fie urmată de secvenţa de caractere <CR><LF> (care se obţine prin apăsarea tastei ENTER).

Principalele comenzi definite de protocolul SMTP sunt:- HELO <hostname> - reprezintă comanda care iniţializează dialogul dintre

procesul client şi procesul server; procesul client va identifica server-ul cu numele calculatorului pe care rulează, specificat prin parametrul <hostname>;

Page 64: 01 Protocoale Ciclu Ex

- MAIL FROM: <expeditor> - informează procesului server că urmează să primească un

e-mail de la expeditor; - RCPT TO: <destinatar> - specifică procesului server adresa destinatarului (prin

parametrul <destinatar>) căruia îi este adresat mesajul e-mail care urmează a fi transmis;

- DATA – specifică procesului server că urmeaza să primeasca de la client conţinutul unui mesaj electronic (e-mail);

- QUIT - inchide canalul de comunicaţie dintre client şi server. Coduri SMTP returnate Pentru fiecare comandă trimisă de către clientul SMTP către serverul SMTP, acesta

din urmă returneaza un cod numeric care reprezintă codul rezultat în urma execuţiei operaţiei specificate de către client.

Principalele coduri numerice (şi semnificaţiile lor) returnate de procesul server sunt:

- 220 – Service ready, procesul server este disponibil pentru a prelua un mesaj; - 221 – Service closing transmission channel, procesul server urmează a închide

canalul de comunicaţie cu procesul client; - 250 – Request mail action okay, completed, specifică procesului client că

operaţia specificată de acesta a fost executată cu succes; - 251 – User not local, informează procesul client că nu cunoaşte adrea

destinatarului şi va redirecţiona mesajul respectiv către un alt calculator server; - 354 – Start mail input, specifică procesului client că acesta poate începe

transmisia conţinutului mesajului (e-mail-ului); - 502 – Command not implemented, cod de eroare returnat atunci cînd comanda

specificată de către procesul client nu este cunoscută / implementată de către procesul server.

Scenariu de transmitere a unui mesaj Pentru a testa comenzile şi a verifica codurile returnate pe parcursul unui dialog

utilizînd protocolul SMTP intre un proces client şi un proces server voi utiliza o aplicatie generică in linie de comandă, denumita telnet.

Scenariul urmator presupune: - conectarea la serverul calculatorului; - iniţierea dialogului cu procesul server; - identificarea expeditorului; - specificarea destinatarului; - transmiterea conţinutului mesajului; - închiderea conexiunii.

Page 65: 01 Protocoale Ciclu Ex

Figura 1 Dialogul SMTP pentru transferul unui mesaj de la client la server.

+++ Simple Mail Transfer Protocol (prescurtat, SMTP; în traducere aproximativă Protocolul simplu de transfer al corespondenței) este un protocol simplu, folosit pentru transmiterea mesajelor în format electronic pe Internet. SMTP folosește portul de aplicație 25 TCP și determină adresa unui server SMTP pe baza înregistrării MX (Mail eXchange, „schimb de corespodență”) din configurația serverului DNS.

Protocolul SMTP specifică modul în care mesajele de poștă electronică sunt transferate între procese SMTP aflate pe sisteme diferite. Procesul SMTP care are de transmis un mesaj este numit client SMTP iar procesul SMTP care primește mesajul este serverul SMTP. Protocolul nu se referă la modul în care mesajul ce trebuie transmis este trecut de la utilizator către clientul SMTP, sau cum mesajul recepționat de serverul SMTP este livrat utilizatorului destinatar și nici cum este memorat mesajul sau de câte ori clientul SMTP încearcă să transmită mesajul.Istoric

SMTP a inceput sa fie folosit mai des la inceputul anilor ‘80. La acea vreme era mai

putin folosit decat UUCP (Unix to Unix CoPy), care era mai potrivit pentru transmiterea

e-mail-urilor intre mașini ce nu erau conectate permanent. SMTP însa functionează mai

bine când atât expeditorul cât și destinatarul mesajului sunt legați in rețea tot

timpul. Sendmail a fost unul din primele programe care au implemetat acest protocol.

Din 2001 au aparut încă cel puțin 50 de programe care implementeaza SMTP( atat

servere cat si clienti). Printre cele mai cunoscute servere SMTP amintim Postfix, qmail,

Novell GroupWise, Exim, NovellNetMail si Microsoft Exchange Server.Funcționare

Comunicarea intre client și server se realizeaza prin texte ASCII. Inițial clientul

stabilește conexiunea către server și așteaptă ca serverul să-i răspundă cu mesajul

“220 Service Ready” . Dacă serverul e supraîncărcat, poate să întarzie cu trimirea

acestui raspuns. Dupa primirea mesajului cu codul 220 , clientul trimite comanda HELO

Page 66: 01 Protocoale Ciclu Ex

prin care isi va indica identitatea. In unele sisteme mai vechi se trimite comanda EHLO,

comanda EHLO indicand faptul că expeditorul mesajului poate sa proceseze extensiile

serviciului și dorește să primească o listă cu extensiile pe care le suportă serverul. Dacă

clientul trimite EHLO iar serverul îi răspunde ca aceasta comandă nu e recunoscută,

clientul va avea posibilitatea să revină și să trimită HELO.

Odată ce comunicarea a fost stabilită, clientul poate trimite unul sau mai multe mesaje,

poate incheia conexiunea sau poate folosi unele servicii precum verificarea adreselor

de e-mail. Serverul trebuie să raspundă după fiecare comandă indicand astfel dacă

aceasta a fost acceptată, dacă se mai asteaptă comenzi sau dacă există erori în

scrierea acestor comenzi.

Pentru a trimite un mesaj se foloseste comanda MAIL prin care se specifica adresa

clientului. Dacă aceasta comanda este corecta serverul va raspunde cu mesajul “250

OK”. Clientul trimite apoi o serie de comenzi RCPT prin care specifică destinatarii

mesajului. Serverul va raspunde cu “550 No such user here”, sau “250 OK”, in functie

de corectitudinea comenzii primite. După ce se specifică destinatarii, și serverul

acceptă comenzile, se trimite comanda DATA, prin care serverul e anunțat că

expeditorul va incepe sa scrie conținutul mesajului. Serverul poate răspunde cu mesajul

"503 Command out of sequence" sau "554 No valid recipients" dacă nu a primit

comenzile MAIL sau RCPT sau aceste comenzi nu au fost acceptate. Dacă serverul va

raspunde cu mesajul “354 Start mail input”, clientul va putea introduce textul

mesajului. Sfarșitul mesajului e marcat cu <CR><LF>.<CR><LF>.

Un server SMTP trebuie să cunoască cel putin urmatoarele comenzi :

HELO - identificare computer expeditor;

EHLO - identificare computer expeditor cu cerere de mod extins;

MAIL FROM - specificarea expeditorului;

RCPT TO - specificarea destinatarului ;

DATA - conținutul mesajului;

RSET – Reset;

QUIT - termină sesiunea;

HELP - ajutor pentru comenzi;

VRFY - verifica o adresa;

EXPN - expandează o adresa;

VERB - informatii detaliate.Realizarea comunicației SMTP - exemplu

Funcționarea protocolului SMTP poate fi testată simplu prin inițierea unei

conexiuni TCP folosind un client de telnet.

telnet mailhost.domeniu.ro 25

Server: 220 mailhost.domeniu.ro ESMTP

Client: HELO host.domeniu.ro

Server: 250 Hello host.domeniu.ro

Client: MAIL FROM: [email protected]

Page 67: 01 Protocoale Ciclu Ex

Server: 250 Ok

Client: RCPT TO: [email protected]

Server: 250 Ok

Client: DATA

Server: 354 End data with <CR><LF>.<CR><LF>

Client: Subject: test

Client: un mesaj test

Client: .

Server: Mail queued for delivery.

Client: QUIT

Server: 221 Closing connection. Bye.


Recommended