giovedì 28 aprile 2016

Socket: processi server su uno stesso nodo

Si considerino 4 nodi diversi NSA, NSB, NX, NY.

Il processo server SA in esecuzione su NSA esegue il codice seguente:
int t; t=socket(…); bind(t,25,…); listen(t,…); ... interazione con processi client...

Il processo server SB in esecuzione su NSB esegue il codice seguente:
int t; t=socket(…); bind(t,110,…); listen(t,…); ... interazione con processi client...
Su NX sono in esecuzione processi client X1,X2,X3 e su NY sono in esecuzione processi client Y1,Y2,Y3.

All’istante t0 SA ha due connessioni aperte, una con X1 ed una con X2; SB ne ha aperte quattro: con X3, Y1, Y2, Y3.
1.       ....
2.       Si assuma adesso che SA ed SB siano in esecuzione sullo stesso nodo NSA invece che su due nodi diversi. Se lo scenario descritto è ancora possibile, allora elencare i numeri di porta delle due estremità di ogni connessione. Altrimenti spiegare perché lo scenario descritto non è realizzabile.

  • "Non realizzabile perché da come è scritto il codice i due processi server dovrebbero condividere lo stesso welcoming socket t su porte diverse, il che non è possibile". Questo non ha il minimo senso. "t" è il nome di una variabile. Non è il nome di un socket (nozione che peraltro non abbiamo mai definito: quando mai abbiamo parlato di nome di un socket?). Come certamente dovete sapere dai corsi precedenti, processi nello stesso nodo possono usare variabili con lo stesso nome, poiché le variabili di un processo sono visibili solo a quel processo (a meno di casi particolari che non avete visto in nessun corso). Staremmo freschi se quando si lancia un programma P dovessimo sempre incrociare le dita sperando che P non sia stato scritto usando nomi di variabile usati anche in altri programmi che in quel momento sono già in esecuzione.
  • "Non realizzabile perché due server non possono essere in esecuzione sullo stesso nodo". Per quale motivo? Chi l'ha mai detto? Non ha il minimo senso.
  • Non è uno scenario possibile in quanto ci può essere una o più richieste tra un dato client e un dato server". Testuale. A parte la sintassi traballante, qual'è la logica in questa affermazione?
  • "Lo scenario descritto non è più possibile: non ci possono essere due processi server con numeri di porta diversi su un unico nodo". E perché?
  • "Non realizzabile perché avrei due processi server su uno stesso nodo e i processi client possono invece connettersi con un unico server istante per istante" Qual'è la logica? In entrambi gli scenari ogni processo client è collegato con un solo processo server. Se avesse confuso "processo" con "nodo", allora il secondo scenario sarebbe stato con un solo (nodo) server invece che con due (nodi) server, per cui in base a quella spiegazione sarebbe stato realizzabile solo il secondo. A parte la logica che mi sfugge, il ragionamento è comunque sbagliato. Quando mai abbiamo detto che un client si può collegare con un unico server istante per istante? Abbiamo detto, nelle primissime slide del corso per fare una introduzione, che quello è il caso comune. Comune non significa l'unico che può esistere. Inoltre, quando un browser visualizza una pagina si collega a solo un server per volta? Abbiamo anche detto infinite volte che un browser esegue tante azioni parallele. E un browser può avere tanti tab aperti, per cui può avere tante connessioni aperte.
  • "Non realizzabile perché su un nodo tutti gli N+1 socket del server devono essere associati allo stesso numero di porta" Tralasciamo cosa sia N. Risposte di questo genere mi sorprendono completamente. Posso capire che uno non abbia capito un concetto, anche se si tratta di un concetto base. Ma faccio fatica a capire l'apparente assenza di logica (il che mi pare molto più grave). Se invece di un nodo si hanno più nodi allora gli N+1 socket del server non devono essere associati allo stesso numero di porta?
  •  "SA avrà impegnate due porte diverse tra di loro con port number maggior di 1024". Il testo dice che SA è un processo server. Quella affermazione, quindi, non ha il minimo senso. "mentre X1 e X2 avranno la connessione su un PN maggiore di 1024 ma non necessariamente diverso". Diverso rispetto a chi? X1 diverso da X2? o cosa? "Discorso simile per SB, avrà la connessione su 4 porte diverse tra loro (con PN>1024) mentre X3,Y1,Y2,Y3, avranno una connessione su una PN >1024". Evidentemente su questa parte di programma c'è il buio completo.
  • "Non è possibile in quanto su un nodo devo avere in esecuzione un (sottolineato un) processo server". Quando mai abbiamo fatto questa affermazione? Non è una domanda polemica, davvero non capisco da dove possa sorgere questo dubbio. Anche se fosse così, comunque, la frase sarebbe imprecisa: "devo" andrebbe sostituito da "posso" o qualcosa del genere. C'è poi un'apparente assenza di logica che non riesco a comprendere e che mi preoccupa (vedi anche il punto 24); la frase infatti termina con "è infatti il processo server a determinare il numero di porta del server". Come fa una delle due affermazioni a motivare l'altra?

IP: Firewall con mail server

Permettere alla organizzazione di "inviare e ricevere mail".
  • ricevere mail significa traffico smtp entrante ((ip-dst=IP-ms and port-dst=25) + (ip-src=IP-ms and port-src=25)) e traffico dns entrante ((ip-dst=IP-ns and port-dst=53) + (ip-src=IP-ns and port-src=53)).
  • il traffico dns entrante è necessario perché altrimenti dall'esterno non si riesce a trovare IP-ms.
  • NON significa traffico pop (se significasse traffico pop allora come si dovrebbe indicare il procedimento con cui dall'esterno si inviano email all'organizzazione?).
  • NON si deve permettere traffico a tutta l'organizzazione, ma solo agli indirizzi IP di mail server e name server (i vincoli richiesti nell'esercizio sono molto più ristretti).
  • inviare email significa traffico smtp uscente  ((ip-dst=IP-ms and port-src=25) + (ip-src=IP-ms and port-dst=25)) e traffico dns uscente  ((ip-dst=IP-ns and port-src=53) + (ip-src=IP-ns and port-dst=53)).
  • il traffico dns uscente è necessario perché altrimenti dall'interno non si riesce a trovare i mail server delle altre organizzazioni. 
  • più chiaro di così non lo so spiegare

Risposte narrative



Questo è un esempio da manuale del perché dico che non si devono dare risposte narrative ma si devono dare descrizioni schematiche esaurienti.

Che significa "nel server di webhosting ci sarà un record di tipo CNAME"?

Il record si trova in un name server, non nel server di web hosting. Inoltre, quali sono name e value di quel record? La frase indica solo il tipo. Inoltre, di record CNAME ce ne sarà uno, come indicato nella narrazione, o ce ne saranno due (come deve essere)? Inoltre, il fatto che il record CNAME "sarà" nel server, non c'entra nulla con le request e le response DNS richieste dall'esercizio: un RR può essere in un name server e non essere mai tornato in nessuna risposta. Inoltre, quel RR viene tornato come response a quale request? A una request CNAME? o a una request NS? o a una request A? E qual'è il nome in quella request? E quando è tornato un record CNAME, cosa se ne fa il browser di quel record, cioè quali request invia successivamente (se ne invia)?

Notate, qui non si tratta (solo) di mia pignoleria, si tratta di leggere il compito. Il compito contiene una descrizione ambigua di una minima parte delle informazioni necessarie. Che ipotesi deve fare chi legge sulle informazioni non scritte nel compito? Sono presenti nella testa di chi ha scritto o no? Purtroppo non si possono assegnare voti per via telepatica.

Altro esempio. "Karl, da PC, invia un GET per http://bayern.de/index.html la request non appartiene a nessuna sessione lui è configurato per generarla ed utilizza la tecnica dei cookie. Il server manda la risposta con un 200 ok, se tutto è andato bene, e dopo la linea vuota sopra il documento richiesto. Il browser di Karl riceve la risposta e se la memorizza nella sua cache. Nella home page c'è un documento htm che il server non vuole che sia memorizzato e si realizza con un response header del tipo cache-control no store e due jpg che il server vuole che si memorizzino".

Solo in queste due frasi il lettore si pone un numero altissimo di domande:
  • "lui è configurato...". chi è "lui"?
  • "utilizza la tecnica dei cookie". cioè? come funziona questa tecnica? chi la realizza e come?
  • "manda la risposta con un 200 ok". che significa "con un 200 ok"? 200 ok è la parte iniziale della risposta, non è un non meglio definito qualcosa che viaggia "con" la risposta.
  • "dopo la linea vuota sopra il documento richiesto". "dopo" che cosa? dopo il 200 ok? e non ci sono header? e che significa "sopra"? casomai sarà prima, non sopra.
  • "non vuole che sia memorizzato e si realizza con un response header..." response header inserito dove? in quale response?
  • "e due jpg che vuole che si memorizzino" dove sono quei jpg? come descrive la sua volontà di memorizzarli e dove? nel documento html? come fa il browser a capire se sta ricevendo un documento html o un documento jpg?
  • "nella home page c'è un documento html"; la home page E' un documento html.

Lista di errori (provetta 1)


Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.

  • L'URL relativo sports/newIndex.html contenuto in www.org.com/sports/index.html equivale a www.org.com/sports/sports/newIndex.html; non equivale a www.org.com/sports/newIndex.html.
  • Qualcuno ha inserito nel conteggio delle connessioni TCP anche quelle che il browser apre con il server DNS. Ho considerato queste risposte corrette, anche se non avrei dovuto. Le interazioni DNS avvengono praticamente sempre su UDP, le interazioni TCP sono usate solo per (alcune) interazioni primario-secondario. Inoltre, noi non abbiamo visto come DNS usa TCP: non abbiamo cioè detto che DNS usi una connessione TCP per ogni coppia request-response.
  • Request "www.org.com A ?", Response "www.org.com NS ns.org.com"+"ns.org.com A IP1". Bene, adesso con chi si collega il browser? Con IP1? Uno svolgimento di questo genere, specialmente con la premessa "suppongo che il server supporti risposta ricorsiva" (cioè, il server trova il RR che mi occorre), significa non avere capito nulla del DNS.
  • Testo: "Per ogni pagina menzionata nell'esercizio, fornire il conteggio al termine dell'interazione". Svolgimento "Riceve 5 HTTP request, una per ogni documento html visualizzato". Ma quanti caspita sono questi documenti? 1? 2? o 5? E' evidente che la risposta non contiene questa informazione, richiesta nel testo. Inoltre, se ad esempio i documenti fossero 3, il conteggio è 3+1+1 oppure 1+3+1 oppure 1+1+3? Quando dico che è fondamentale leggere il testo probabilmente risulto pedante e antipatico, ma se lo dico un motivo c'è.
  • Testo "Descrivere tutta la sequenza di richieste e risposte DNS inviate e ricevute dal browser". Svolgimento: 


Ora, tralasciamo pure il fatto che se si chiede una sequenza allora si vuole vedere l'ordine dei messaggi e in questo disegno questa informazione è completamente assente; tralasciamo anche che abbiamo detto e ripetuto una infinità di volte che in questi esercizi occorre fornire i RR e in questo disegno questa informazione è completamente assente. Facciamo l'interpretazione più plausibile: browser invia una request di tipo A a www.org.com per trovare l'indirizzo di quest'ultimo (?????): ma se dovete chiedere il numero telefonico a un amico telefonate a quell'amico????
  • "Suppongo main.gif sia un URL relativo al server www.org.com". Esempio di confusione tra mele e scarpe: Un URL relativo a un server? Un URL relativo è relativo ad un altro URL. 
  • Non so quante volte l'ho ripetuto: se devo trovare l'indirizzo associato al nome sgddhshfk allora faccio una domanda " sgddhshfk  A ?". NON faccio la domanda "sgddhshfk NS ?". Non ha alcun senso. Peggio ancora, qui termino con l'indirizzo del name server della zona a cui appartiene sgddhshfk, NON termino con l'indirizzo di sgddhshfk. Con chi si collega adesso il browser?
  • Lo header Referrer deve essere presente anche nelle richieste inviate a causa della pressione di un link. Non solo in quelle inviate per prelevare immagini o iframe.
  • "Non realizzabile perché due server non possono essere in esecuzione sullo stesso nodo". Per quale motivo? Chi l'ha mai detto? Non ha il minimo senso. Devo ancora decidere come valutare questo caso. Correggerò il resto del compito e poi deciderò.
  • Se il sito adclick.com è sul sito di web hosting catchit.net, perché mai il browser deve di sua spontanea iniziativa inviare la DNS request "catchit A ?" ? Come fa il browser a sapere che adesso c'è di mezzo catchit.net? Inoltre, perché mai il valore dello header Host adesso dovrebbe essere catchit.net? Se così fosse allora tutti gli URL cambierebbero (il sito non potrebbe cioè chiamarsi adclick.com).
  • Web hosting, custom domain: se un sito di nome N1 viene ospitato dal servizio di web hosting di nome N2, nel DNS viene inserito il record N1 CNAME N2. Ma gli header Host continuano ad avere N1. Non hanno N2. Se avessero N2 allora gli URL assoluti non avrebbero nulla a che vedere con N1.
  • Request per URL main.gif?ID=3456abc e response contiene l'immagine richiesta. "Qui la sessione scade perché si trasporta un documento senza link da modificare" E perché mai? Una sessione scade se l'applicazione decide di farla scadere oppure se non si ricevono request con l'id di quella sessione per un intervallo di tempo predefinito. Non scade perché non si è avuta l'opportunità di scrivere l'id di quella sessione nel documento. Inoltre, ammettiamo pure che la sessione scada; le richieste successive inviate dal browser seguendo link già presenti sul browser, conterranno comunque l'id della sessione. Non è che il browser modifica gli URL che si trovano nei documenti che sta visualizzando (oltretutto in base a funzionalità telepatiche: come farebbe il browser a sapere che il server ha deciso di fare scadere la sessione?)
  • Set-Cookie nelle request e non nelle response lo dovevo ancora vedere.
  • Response con header, LV e poi "documento che dice al browser che la cache è validated quindi non necessita di reinviarlo". Quando mai abbiamo visto un documento che fornisce informazioni al browser? Sono i response header che forniscono informazioni al browser, e possono farlo perché hanno nomi predefiniti, valori predefiniti, significato predefinito. Come fa un documento ad informare il browser di qualcosa? In quale lingua dovrebbe essere scritto? Che parole dovrebbe usare?
  • Come fa una response ad avere Content-type: "Img" e a trasportare un documento "<iframe SRC="...">"? E perché mai poi non viene prelevato il documento riferito dall'attributo SRC dell'iframe?
  • "La BASIC authentication non permette il mantenimento delle sessioni con URL rewriting". Perché mai? L'unica cosa di cui abbiamo parlato e che gli assomiglia lontanamente è questa: la BASIC authentication si può usare con o senza sessioni (non perché lo dico io, ma perché è così); e che negli esami deve essere usata con le sessioni, a meno che sia impossibile (perché lo dico io). Cosa c'entra questo con la impossibilità di mantenere le sessioni con URL rewriting?
  • Si scrive cache. Non cash. Si pronunciano più o meno nello stesso modo (io non sono in grado di pronunciarli in modo diverso). Ma sono cose molto diverse. Ai fini degli esami faccio finta di nulla, ma scrivere una cosa del genere in un documento tecnico importante può avere effetti spiacevoli (= farsi ridere dietro; le cache sono un concetto usato in moltissimi settori dell'informatica radicalmente diversi tra loro; noi ne abbiamo visti solo due ma sono tanti, date un'occhiata a Wikipedia).
  • Stime per il numero di connessioni TCP che hanno solo il minimo o solo il massimo sono da considerarsi, nel migliore dei casi, solo parzialmente corrette.

  • Come interpretare questo disegno? Mi pare ci sia una sola interpretazione possibile: per trovare il numero di telefono di un amico devo telefonare a quell'amico. (www.org.com era disegnato nello stesso modo).
  • Una quantità incredibile di persone ha scritto la response alla get della home page con solo uno dei due header necessari: Cache-control: must-revalidate; Etag: qualche-id; Capisco che uno non li metta tutti, ma metterne solo uno dei due ha davvero poco senso.

Lista di errori (provetta 2)


  1. Se un nodo ha configurazione IP dinamica, come fa ad inviare il gratuitous ARP prima della DHCP discover? nel gratuitous ARP quale indirizzo dichiara di avere?
  2. Che significa mettere come payload di IP scritte come "traceroute", "traceroute reply" (senza specificare il protocollo del payload; e addirittura scrivendo DOPO queste stringhe "TTL=2": dove si trova il TTL? nel payload o nello header? oppure IP ha un trailer?)
  3. Se il testo dell'esercizio dice che un nodo è stato appena acceso, che senso ha ipotizzare che la sua cache arp contenga già l'indirizzo fisico del router? ci sono 3 opzioni per interpretare:
    • è stato assegnato l'esercizio X ma lo studente ha deciso di inventarsi un esercizio Y diverso da X e di risolvere Y 
    • il nodo ha capacità telepatiche
    • il nodo ha configurazione arp statica (questa opzione potrebbe essere corretta ma se uno non ha scritto che siamo in questo caso allora lo svolgimento non è credibile...le altre due opzioni sono molto più credibili)
  4. Mettere come azione "instrada 140.140.100.7/27" non ha senso. Si instrada verso un indirizzo IP. Non verso un indirizzo IP ed un network number (il network number del destinatario in questo caso è noto, ma ciò è irrilevante).
  5. Il collegamento tra ISP1 e ISP2 è "evidentemente" un collegamento PPP, non Ethernet. Non l'ho considerato come errore "grave".
  6. Che senso ha inviare una ARP request per trovare l'indirizzo fisico di un nodo in un'altra network? E che senso ha inviarla all'indirizzo fisico del router?
  7. Che senso ha fare un traceroute in cui i messaggi ICMP di request sono diretti ai router intermedi? a parte il fatto che sarebbe bello sapere come faccio a conoscerne l'indirizzo IP, ma se ne conosco l'indirizzo allora a che serve traceroute?
  8. "R1 non può eseguire traceroute perché non sa com'è ORG è organizzata al proprio interno" cosa c'entra? per inviare un pacchetto verso una destinazione devo conoscere com'è organizzata la org. a cui appartiene la destinazione?????
  9. Un frame Ethernet non può trasportare il protocollo ICMP. Deve trasportare sempre IP (che a sua volta trasporta IP). Se un frame Ethernet traspostasse ICMP allora ICMP coinvolgere solo nodi nella stessa network.
  10. Una ARP request contiene l'indirizzo IP da trovare (esempio: 140.140.100.62). NON contiene l'indirizzo IP e la subnet mask (esempio: 140.140.100.62/27). A parte il fatto che sarebbe una info inutile, dove sarebbe memorizzata visto che i messaggi ARP contengono delle quadruple (e non delle sestuple)?

Lista di errori (provetta 2)


  1. mettere nelle regole di firewall "IPdst = ISP" merita poco più di -infinito
  2. "decrittare la firma" ovviamente non significa nulla. la firma si verifica. non si decritta.
  3. dire che C1 non invia pacchetti verso IP-R1-right perché C1 ha indirizzo privato quindi non può comunicare con l'esterno, non ha senso. 1) il livello IP di un nodo non sa quali sono gli indirizzi IP della propria organizzazione di quel nodo; quindi non può sapere se tra sé stesso e la destinazione c'è un router di frontiera; IP-R1-right potrebbe stare "dentro" o "fuori", lui non può saperlo; quindi trasmette; 2) inoltre, il livello IP di un nodo non sa quanti dispositivi NAT ci sono tra sé stesso ed una data destinazione; il suo comportamento non dipende dalla presenza di un NAT altrove; quindi, C1 non può sapere che "non c'è NAT" e quindi non può contattare R1
  4. dire che l'affermazione "non contiene virus" è "vera, assumendo che il malintenzionato non lavori per Apple" denota un grande ottimismo. Apple potrebbe avere inserito malware senza esserne consapevole. Apple potrebbe anche inserire malware volutamente. La crittografia a chiave pubblica non ci fornisce nessuno strumento per escludere questa eventualità
  5. regole della forma "IP-dst \in org AND port-src=25" sono eccessivamente permissive; permettono il colloquio con qualsiasi indirizzo IP al quale ci sia un mail server; qui si vuole permettere solo il MS dell'organizzazione, è evidente che l'amministratore del firewall conosce l'indirizzo IP corrispondente (e quindi lo può inserire nelle regole)
  6. "per effettuare la verifica della firma occorre la chiave pubblica compagna della chiave privata usata per la firma". Falso, la verifica si può effettuare con qualsiasi chiave pubblica; se la chiave pubblica non è la compagna della chiave privata usata per la firma allora la verifica ha esito negativo; e comunque occorre chiarire dove si trova la chiave (in un certificato, che quindi ha uno issuer, che quindi deve stare in keyset e trustset)
  7. N1 usa indirizzi privati. Non metterla nelle tabelle di routing non ha alcun senso. Avere indirizzi privati permette di comunicare con i nodi interni all'organizzazione; se N1 non è nelle tabelle di routing i pacchetti diretti a network diverse da N1, ma interne all'organizzazione, sono scartati.
  8. i frame che trasportano messaggi DHCP non possono avere tipo IP. hanno tipo DHCP. se avessero tipo IP allora il codice che elabora quel frame interpreterebbe la sequenza di byte contenuta nel payload del frame come pacchetto IP, cioè header IP seguito da un payload
  9. un nodo che ha indirizzo privato può comunicare con i nodi della propria organizzazione. anche se si trovano in altre network. i pacchetti con src o dst privato sono scartati solo quando cercano di uscire dall'organizzazione; non sono scartati da ogni router, solo dai router di frontiera.
  10. come fa un nodo con configurazione IP dinamica ad inviare prima un gratuitous ARP e poi la richiesta DHCP ? quando invia il gratuitous ARP quale indirizzo IP dichiara di possedere ?
  11. se un nodo ha configurazione statica allora possiede indirizzo IP, subnet mask, indirizzo IP del gw non appena viene acceso. che senso ha contattare il server DHCP ? a quale scopo ? per farsi rispondere "dhcp non previsto per te" ? inoltre, visto che in N3 gli indirizzi sono allocati staticamente, perché mai dovrebbe esserci un server DHCP in quella network ?
  12. "per verificare la firma digitale abbiamo bisogno della CA che ha firmato il documento e ci dobbiamo fidare di essa". chi ha detto che il documento è stato firmato da una CA ? chi ha detto che per verificare una firma mi devo fidare di chi lo ha firmato ?
  13. "quando C1 viene acceso il server DHCP gli invierà automaticamente tutte le informazioni per ottenere connettività IP...": come fa il server a sapere che C1 è stato acceso ?
  14. quando mai abbiamo parlato di una coppia KPRIV-KPUB associata ad un file ? osservazione puramente didattica: questo è uno degli infiniti esempi che spiegano perché all'inizio del corso ho detto che la cosa più importante è imparare ad associare un tipo ad ogni entità; le coppie di chiavi sono associate a subject (scarpa) non a file (pera)
  15. "a N1 non posso assegnare indirizzi /26 perché usa indirizzi privati, quindi /16 o /8" non ha alcun senso. la dimensione di un range non ha nulla a che vedere con il fatto che gli indirizzi in quel range siano pubblici o privati.
  16. network number: 131.114.191.252/30; poi come azione instrada in una tabella di routing si mette l'indirizzo 131.114.191.252. è ovvio che il primo indirizzo di un range non deve mai essere utilizzato, perché ha host number 0
  17. come fa un messaggio DHCP discover inviato da C1 ad avere la forma "IP-C1, IP-server DHCP, DHCP, DHCP discover" ? come fa C1 ad indicare il proprio indirizzo IP ? invia questo messaggio proprio per acquisirne uno, se ce lo avesse già non lo invierebbe. Il fatto poi che quel messaggio sia indicato come "pacchetto IP" non so proprio come commentarlo.
  18. "per la verifica della firma sono necessari...e la coppia subject-KPUB corrispondente al subject che ha firmato il documento. quest'ultima informazione, perché la verifica abbia esito positivo, viene recuperata dal trustset" non ha senso: il fatto che un subject abbia firmato un documento non ha assolutamente nulla a che vedere con la presenza di quel subject in un trustset.
  19. "per poter verificare la firma...ha bisogno di un certificato generato da una CA che appartenga al suo trustset e keyset, che attesti l'attendibilità del signer apple.com"..." a parte che il concetto di "attendibilità del signer" non è mai stato definito, una CA attesta solo la verità di una associazione subject-KPUB; non attesta nessuna "qualità" o "caratteristica" del subject. se il subject è Stalin o Papa Francesco (intesi come esempi di "inattendibile" e "attendibile") per la CA è irrilevante.
  20. I messaggi ICMP sono uno dei numerosi protocolli trasportati da IP. Lo header IP permette ai nodi di cooperare per recapitare il payload ovunque, senza necessità di conoscere la struttura interna del payload. In questo caso IP ha un payload ICMP. Fare il contrario (messaggio ICMP il cui payload è un pacchetto IP) non ha il minimo senso; lo header IP è ciò che serve ai nodi e ai router per recapitare il payload IP; non per recapitare il messaggio in cui è contenuto l'intero pacchetto IP (!). Ethernet che trasporta ICMP non ha senso. ICMP che trasporta IP ne ha ancora meno.
  21. Un server DHCP non è necessariamente anche un router. Può esserlo e può non esserlo, dipende. L'unico caso in cui deve esserlo è quando in una network punto-punto uno dei due nodi ha indirizzo allocato dinamicamente. Ma in altre network, ad esempio Ethernet, il server DHCP può non essere un router.

Lista di errori (provetta 1)

Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.
  1. I documenti il cui URL è negli attributi HREF dei tag A NON sono prelevati automaticamente (in parole più semplici: "i documenti linkati sono prelevati solo se qualcuno ci clicka sopra, non sono prelevati automaticamente"). Questo è vero anche quando il docmento è una immagine. <A HREF="url di immagine"> non è prelevato automaticamente. <IMG SRC="url di immagine"> è prelevato automaticamente.
  2. Risposte HTTP contenenti "immagine con URL modificati" non hanno alcun senso.
  3. Traffico HTTP con 1 request alla quale corrispondono 4 response non ha alcun senso
  4. Request HTTP della forma "GET *.gif, jpg, html" non hanno alcun senso
  5. Quando un browser preleva risorse da 2 server è impossibile che il numero di connessioni TCP sia al minimo 1.
  6. Se D1 contiene un IFRAME che linka D2 e D2 contiene una immagine, il prelievo della immagine ha come Referer D2. Non c'è motivo per cui il Referer dell'immagine sia D1 (notare che D1 potrebbe avere linkato D2 senza che il sito di D2 lo abbia autorizzato a farlo; pertanto se il Referer dell'immagine fosse D1 è come se D1 avesse "rubato" traffico a D2).
  7. Se una risposta contiene un documento HTML "con URL modificati" e una request successiva preleva dallo stesso server una immagine contenuta nel documento HTML, allora l'URL dell'immagine deve avere l'URL "modificato".
  8. (ancora sul punto 9)....mettere come Referer la concatenazione di D1 e (la terza parte di) D2 non ha alcun senso.
  9. Sia D l'URL del documento richiesto dalla request R; il Referrer contenuto in R ha come valore l'URL del documento in cui è stato trovato D; NON ha come valore D (che senso avrebbe "ripetere per intero" l'URL del documento che stiamo richiedendo ?)
  10. Mettere un Referer nella prima request, quella con la quale si richiede il documento il cui URL è stato inserito dall'utente, non ha senso
  11. Mettere come attributo ACTION di un FORM un URL che termina in HTML non ha senso (le credenziali vanno inviate ad un programma; in teoria il nome del programma potrebbe avere qualsiasi estensione, ma metterci HTM o HTML implica, con altissima probabilità, non avere capito).
  12. Il valore di Host è un nome di server. Quindi non deve iniziare con "http://"
  13. Il valore di Referer è un URL. Quindi deve iniziare con http:// e deve comprendere la terza parte (posso chiudere un occhio se manca la prima parte, ma non se manca la terza parte)

Liste di errori (provetta 1)

Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.

  1. Più studenti hanno creato una sessione per pagina invece che una sessione per sito. Che senso ha?
  2. DNS request "www.bayern.de A?" (= qual'è l'indirizzo IP associato al nome www.bayern.de?). DNS response "www.bayern.de NS ns.bayern.de, ns.bayern.de A IP1" (= www.bayern.de è un nome di zona; il nome del name server di quella zona è ns.bayern.de; l'indirizzo di quel server è IP1). Che senso ha???
  3. Che senso ha inviare una richiesta GET index.html contenente un request header "header cache con must-revalidate...max-age..."???
  4. Realizzare il conteggio "inserendo un link a track.com" non ha senso: un link viene prelevato solo se l'utente esegue un click sul corrispondente elemento; per fare un conteggio occorre l'invio di una request in modo automatico, che non richiede azioni dell'utente.
  5. Molti considerano le nozioni A) "documento" (o "pagina") e B) "server" (o "sito") del tutto equivalenti. Il valore dello header Host deve essere di tipo B. Il valore dello header Referer deve essere di tipo A. Non è una differenza trascurabile. Sono entità di tipo completamente diverso.
  6. Molti hanno fornito valori separati per i contatori di visite e di visite da smartphone (com'è giusto) ma non fornito nessuna indicazione su come può track.com capire se la request proviene da un pc o da uno smartphone. in assenza di tali indicazioni non si può che ipotizzare il possesso, da parte di track.com, di capacità telepatiche
  7. Ho detto più e più volte a lezione che le risposte narrative non sono accettabili in quanto non permettono di capire se uno ha capito. Riporto qui un esempio (mi dispiace veramente, ma uno svolgimento "romanzato" è proprio incomprensibile): "Karl, da PC, invia un GET per http://bayern.de/index.html la request non appartiene a nessuna sessione lui è configurato per generarla ed utilizza la tecnica dei cookie. Il server manda la risposta con un 200 ok, se tutto è andato bene, e dopo la linea vuota sopra il documento richiesto. Il browser di Karl riceve la risposta e se la memorizza nella sua cache. Nella home page c'è un documento htm che il server non vuole che sia memorizzato e si realizza con un response header del tipo cache-control no store e due jpg che il server vuole che si memorizzino". Solo in queste due frasi il lettore si pone un numero altissimo di domande:
    • "lui è configurato...". chi è "lui"?
    • "utilizza la tecnica dei cookie". cioè? come funziona questa tecnica? chi la realizza e come?
    • "manda la risposta con un 200 ok". che significa "con un 200 ok"? 200 ok è la parte iniziale della risposta, non è un non meglio definito qualcosa che viaggia "con" la risposta.
    • "dopo la linea vuota sopra il documento richiesto". "dopo" che cosa? dopo il 200 ok? e non ci sono header? e che significa "sopra"? casomai sarà prima, non sopra.
    • "non vuole che sia memorizzato e si realizza con un response header..." response header inserito dove? in quale response?
    • "e due jpg che vuole che si memorizzino" dove sono quei jpg? come descrive la sua volontà di memorizzarli e dove? nel documento html? e, per inciso, come fa il browser a capire se sta ricevendo un documento html o un documento jpg?
    • "nella home page c'è un documento html"; la home page E' un documento html.
    • mi dispiace veramente ma davvero uno svolgimento di questo genere non è accettabile
  8. Server che mantiene sessioni con URL rewriting: in ogni documento tornato dal server, gli URL delle immagini su quel server è modificato. Credo di averlo ripetuto dieci volte. Il contenuto delle immagini non si modifica, il nome (URL) si.
  9. Quando mai abbiamo visto una http response contenente uno header user-agent?
  10. "Il minimo numero di connessioni è 2 perché sono state aperte 2 sessioni". A parte il fatto che le sessioni sono 3, ma la giustificazione è sbagliata. Si può aprire una connessione senza aprire una sessione (in generale anche se non in questo caso). E si potrebbe aprire e chiudere più sessioni in una stessa connessione (in generale anche se non in questo caso). Il tempo di vita di una connessione non c'entra nulla con il tempo di vita di una sessione.
  11. Questi 3 contatori sono mantenuti in modo separato per ogni singola pagina ("pagina=documento html")". "Elencare i contatori e fornirne il valore". Perché uno risponde a questa domanda scrivendo un racconto in cui descrive cosa fa ogni utente? Racconto dal quale, peraltro, non si riesce a ricostruire l'elenco dei contatori e dei valori corrispondenti? Non è chiesto il contributo di ogni utente al valore finale di ogni contatore (che può eventualmente essere una informazione aggiuntiva)
  12. "Descrivere il traffico DNS trasmesso e ricevuto".
    1. Un elenco di RR è una descrizione di traffico DNS trasmesso e ricevuto?
    2. Una tabella con le colonne nome, tipo, indirizzo IP è ...?
    3. Un elenco di indirizzi IP è ...?
  13. Per quale caspita di motivo una DNS request contiene oltre al nome ed al tipo anche "port 80"????
  14. Per quale caspita di motivo un browser che deve localizzare il server su cui si trova http://bayern.de/index.html invia una DNS request "bayern.de NS ?" e, se possibile ancora peggio, perché si ritiene soddisfatto dalla coppia NS/A che riceve in risposta???
  15. Inserire in ogni pagina un documento di track.com diverso è una soluzione corretta, ma molto più complicata da realizzare praticamente della "vera" soluzione: lo stesso documento di track.com è inserito in tutte le pagine di uno stesso sito (nel qual caso la distinzione tra pagine diverse dello stesso sito si ottiene con lo header Referer)
    • ed usando opportunamente il valore di Referer si potrebbe anche usare lo stesso documento per tutti i siti...basterebbe isolare la seconda componente dell'URL contenuto nel Referer per capire da quale sito proviene la request...
  16. Scrivere un segmento HTML "<....link a server >" è inaccettabile: va bene non ricordarsi la sintassi esatta di ogni singolo costrutto html, ma almeno un link html bisogna saperlo scrivere; specialmente se uno, oltre a non sapere scrivere un link, descrive le immagini come "<IFRAME src: img2.jpg>".
  17. Nessuno pretende che uno si ricordi a memoria tutti gli header http. Ma è troppo chiedere che lo header "set-cookie:" non sia chiamato "id-set:"??? Ed è troppo chiedere che se proprio uno non si ricorda "Host:" usi un nome diverso da "Location:" (che significa tutt'altro)???
  18. Che senso ha fornire come stima del numero di connessioni ">=14"??? 87432 è un numero possibile? ammesso e non concesso che uno si sia confuso con il verso della disuguaglianza, allora 0 o 1 sarebbero stime possibili?
  19. Ogni anno, invariabilmente, c'è qualcuno che crea sessioni con URL rewriting scrivendo response contenenti header "SID=12150". Ormai non so più cosa fare. Esiste una slide con un response header di nome "SID"? Esiste una slide che dica che l'URL rewriting è realizzato inserendo un apposito response header?
  20. Per quale motivo se la home page di bayern.de contiene "<IFRAME src="wid">" il browser dovrebbe inviare una richiesta ad un server diverso da bayern.de per prelevare l'URL wid?
  21. Varie persone hanno fatto ragionamenti più o meno comprensibili per giustificare l'affermazione che quando si usa il proxy cambia il conteggio fatto da track.com in quanto cambia l'indirizzo IP di provenienza. I conteggi richiesti nell'esame sono fatti in base solo al contenuto delle request http (Referer, User-Agent, Cookie o altro, ci sono varie implementazioni possibili). Gli indirizzi IP non c'entrano nulla.

HTTP: Autenticazione su webmail di ateneo

ATTENZIONE: informazioni del 2010

Le riporto il traffico HTTP effettuato con il browser IE e con FIREFOX inerente l'accesso alla casella di posta universitaria sul web.

(riportati qui sotto, dopo la mia risposta)

qui purtroppo intervengono aspetti che a lezione non vediamo; si fanno a Reti II.

Il server risponde dicendo: ti devi autenticare, io supporto 3 meccanismi: "mettiamoci d'accordo" (negotiate), NTLM, Basic;

Firefox sceglie NTLM (che a reti non facciamo) e dopo uno scambio un pò intricato riesce ad autenticarsi

IE sceglie invece il "mettiamoci d'accordo" e non riescono a mettersi d'accordo (!). Il che è singolare perché il server è Microsoft ed il browser è Microsoft, pertanto dovrebbero essere in grado di mettersi d'accordo. Non so perché non riescano a mettersi d'accordo, sospetto che il motivo sia questo:

*) il client (per come è configurato) se gli viene proposto negotiate allora lo sceglie; 

*) il server è stato configurato in modo che quando il client chiede "negotiate", allora il server accetta solo un terzo meccanismo che a reti non si fa e che si chiama Kerberos;

*) questo particolare client non supporta Kerberos e quindi non si mettono d'accordo.

altro esempio di quello che dico spesso: per capire le reti bisogna sforzarsi di guardare alla realtà con molta elasiticità. altrimenti non si capisce nulla di nulla...la realtà è troppo complicata per la presenza di molti dettagli concettualmente irrilevanti.
INTERNET EXPLORER
GET http://webmail.ing.units.it/exchange HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: webmail.ing.units.it
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
 
HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:23 GMT
Proxy-Support: Session-Based-Authentication
 
<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>
 
GET http://webmail.ing.units.it/exchange HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Host: webmail.ing.units.it
 
HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAABAAEADgAAAAVgonieK1Rw6d8At8AAAAAAAAAAIAAgAA8AAAABQLODgAAAA9EAFMAAgAEAEQAUwABABAAUwBFAFIAVgBJAE4ARwA1AAQAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQAAwAoAHMAZQByAHYAaQBuAGcANQAuAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAAFABYAZABzAC4AdQBuAGkAdABzAC4AaQB0AAAAAAA=
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:49 GMT
Proxy-Support: Session-Based-Authentication
 
<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>
 
GET http://webmail.ing.units.it/exchange HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
Host: webmail.ing.units.it
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAIoAAAAoASgBogAAABIAEgBYAAAADgAOAGoAAAASABIAeAAAABAAEADKAQAAFYKI4gYBsB0AAAAPIsy0u8P/lxYEmbDGLaL7gEEAVABDAE8ATABEAC0AUABDAFMAMQA2ADQAOAA5ADkAQQBUAEMATwBMAEQALQBQAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANCk2viZwkvSHk8AbOtkAUgEBAAAAAAAAZuwxU4TLygFtPP91tzPSFAAAAAACAAQARABTAAEAEABTAEUAUgBWAEkATgBHADUABAAWAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAADACgAcwBlAHIAdgBpAG4AZwA1AC4AZABzAC4AdQBuAGkAdABzAC4AaQB0AAUAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQACAAwADAAAAAAAAAAAQAAAAAQAAA+miYJ4qikKJ0o7U6X5Ryt52Zp6HPnj1joaoPJKowOzwoAEAAAAAAAAAAAAAAAAAAAAAAACQAsAEgAVABUAFAALwBzAGUAcgB2AGkAbgBnADUALgB1AG4AaQB0AHMALgBpAHQAAAAAAAAAAACb9zENiofg6F4C/UqLme4C
 
HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:49 GMT
Proxy-Support: Session-Based-Authentication
 
<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>
FIREFOX
GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
 
HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication
 
<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>
 
GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
 
HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM TlRMTVNTUAACAAAABAAEADgAAAAFgomik7/eomb8S4kAAAAAAAAAAIAAgAA8AAAABQLODgAAAA9EAFMAAgAEAEQAUwABABAAUwBFAFIAVgBJAE4ARwA1AAQAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQAAwAoAHMAZQByAHYAaQBuAGcANQAuAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAAFABYAZABzAC4AdQBuAGkAdABzAC4AaQB0AAAAAAA=
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication
 
<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>
 
GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAuAS4BkAAAAAAAAABYAAAADgAOAFgAAAASABIAZgAAAAAAAAC+AQAABYKIogYBsB0AAAAPtdAL6R8OtcOJ2I7rO8AwzVMAMQA2ADQAOAA5ADkAQQBUAEMATwBMAEQALQBQAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgJ4MAUjYi3OHIWebOJCt/wEBAAAAAAAAZSUYNoXLygFx/gJjFIX+AAAAAAACAAQARABTAAEAEABTAEUAUgBWAEkATgBHADUABAAWAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAADACgAcwBlAHIAdgBpAG4AZwA1AC4AZABzAC4AdQBuAGkAdABzAC4AaQB0AAUAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQACAAwADAAAAAAAAAAAQAAAAAgAAA+miYJ4qikKJ0o7U6X5Ryt52Zp6HPnj1joaoPJKowOzwoAEAAAAAAAAAAAAAAAAAAAAAAACQAyAEgAVABUAFAALwB3AGUAYgBtAGEAaQBsAC4AaQBuAGcALgB1AG4AaQB0AHMALgBpAHQAAAAAAAAAAAA=
 
HTTP/1.1 302 Object MovedContent-Length: 160
Content-Type: text/html
Location: 
http://webmail.ing.units.it/exchange/
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
 
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="
http://webmail.ing.units.it/exchange/">here</a></body>
 
GET http://webmail.ing.units.it/exchange/ HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: 
http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
 
HTTP/1.1 200 OKDate: Wed, 24 Mar 2010 19:07:10 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 1168
MS-WebStorage: 6.5.7638
Cache-Control: no-cache
 
<!--Copyright (c) 2000-2003 Microsoft Corporation. All rights reserved.-->
<!--CURRENT FILE== "NON-IE5" "NON-WIN32" frameset -->
<!--CURRENT TEMPLATE == frameset.00000000 -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<TITLE>Microsoft Outlook Web Access</TITLE>
<BASE href="
http://webmail.ing.units.it/exchange/s164899/">
</HEAD>
<SCRIPT language="JavaScript">
var g_iNewWindowWidth = 700;
var g_iNewWindowHeight = 500;
var g_fWarnOnLogOff=false;
function WarnOnLogOff()
{
if (g_fWarnOnLogOff)
alert("Per evitare che utenti non autorizzati accedano alla cassetta postale, chiudere tutte le finestre del browser dopo aver utilizzato Outlook Web Access.");
}
</SCRIPT>
<FRAMESET OnUnload="WarnOnLogOff()" framespacing="3" cols="190,*"><FRAME bordercolor="#3D5FA3" name="navbar" title="Esplorazione" src="./?Cmd=navbar" marginheight="0" marginwidth="0" scrolling="auto" border="1"><FRAME name="viewer" title="Sommario" src="Posta%20in%20arrivo/?Cmd=contents" scrolling="auto">
<NOFRAMES>
<BODY><P>This page uses frames, but your browser doesn't support them.</P></BODY>
</NOFRAMES>
</FRAMESET>
</HTML>
 
GET http://webmail.ing.units.it/exchange/s164899/?Cmd=navbar HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: 
http://webmail.ing.units.it/exchange/
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
 
HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication
 
<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>
 
GET http://webmail.ing.units.it/exchange/s164899/Posta%20in%20arrivo/?Cmd=contents HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: 
http://webmail.ing.units.it/exchange/
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
 
HTTP/1.1 200 OKDate: Wed, 24 Mar 2010 19:07:10 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 64948
MS-WebStorage: 6.5.7638
Cache-Control: no-cache
 
// SEGUE DOCUMENTO HTML

HTTP: notazione da usare per URL rewriting

http://bartoli-alberto.blogspot.it/search?q=url+rewriting

IP: indirizzi Ethernet e frame Ethernet

non mi è chiaro come fa il router a ricavare l'indirizzo fisico dei nodi della sua rete o del router successivo a cui instradare i pacchetti. Per i vari host, la traduzione tra ip e mac address è eseguita dal modulo ARP, per il router? è un modulo analogo, è lo stesso o non l'abbiamo visto?
Il router traduce da IP a mac address tramite ARP. Esattamente come un nodo non router.

>Volendo banalizzare di molto i concetti della seconda parte del corso, si può dire che (per noi, per ora):
>gli host sono connessi alle varie network via RJ45. Su questo cavo, si usa il protocollo ethernet.
>Sopra il protocollo ethernet, posso implementare vari protocolli (a seconda di quello che metto nel payload).
>Se voglio comunicare dentro la mia network, uso ethernet.
>Altrimenti, tramite ethernt invio i pacchetti ad un router, che in base all'ip che trova nel payload invia quel pacchetto ad un altro host via ethernet (se anche l'altra network alla quale è connesso il router è una network ethernet)?
quello che dice è giusto se cerco di interpretare ciò che credo abbia voluto dire. preso alla lettera non è completamente giusto. cerco di riformularlo qui sotto.

abbiamo visto in dettaglio solo la network ethernet (che può usare vari mezzi di comunicazione fisici); sulla network ethernet si usa il protocollo ethernet;

un frame ethernet può trasportare informazioni di molti protocolli diversi; noi abbiamo visto solo ARP, DHCP e IP.

per comunicare tra nodi che possono essere collegati a network diverse devo creare una network virtuale (internetwork) e noi abbiamo visto solo un modo per crearla: IP;

se i nodi della network virtuale appartengono alla stessa network ethernet, allora si usa un pacchetto IP incapsulato in un frame ethernet, e il frame va direttamente da mittente a destinatario;

se i nodi della network virtuale appartengono a network diverse, allora si usa un pacchetto IP incapsulato in un frame ethernet, e il frame va ad un router; il router estrae il pacchetto e lo fa proseguire incapsulandolo in un altro frame.

DNS: tool per interrogare name server

Forse qualcuno di voi lo avrà già notato, ma vi segnalo che esistono alcuni servizi web che replicano le funzionalità dello strumento "dig"; alcuni quasi esattamente, altri con ottima approssimazione.

http://www.geektools.com/digtool.php sembra sostanzialmente identico a dig, sospetto che abbiano messo sul web server un dig e la pagina sia solo una sorta di intermediario grafico verso quello strumento. Pertanto si tratta di un client DNS in esecuzione sul server www.geektools.com; il client riceve input dal nostro browser e fornisce output sul nostro browser. Questo sarebbe molto utile per fare le prove che vi avevo suggerito alla fine dell'ultima lezione, aggirando quindi le limitazioni che gli Internet provider implementano sul traffico DNS uscente, normalmente autorizzato se originato dal solo name server dell'organizzazione. Solo che non mi sembra molto affidabile (dopo un pò ha smesso di rispondermi).

http://www.digwebinterface.com/ è simile da molti punti di vista ma anche molto diverso. Può collegarsi solo ad un insieme di name server predefiniti. Ha una funzionalità che chiama "trace" ed è molto interessante, ma non banale da descrivere. Se ho capito bene, selezionare "trace" significa "esegui risoluzione iterativa e mostrami tutte le risposte che hai ricevuto, indicandomi l'indirizzo IP da cui le hai ricevute".

Da notare che non mostra le request (mostra solo la prima) e non mostra il nome del name server che ha contattato ad ogni step (mostra solo il suo indirizzo IP; si può determinare il name server corrispondente facendo su qualche altro sito un whois: se la risposta al passo K è stata ricevuta dall'indirizzo IP-K, si fa il whois di IP-K e si scopre un nome che, nella risposta al passo K-1 era il nome di un name server; sembra intricato ma non lo è). Inoltre, la funzionalità trace usa delle cache senza dirlo: pertanto si vedono risposte che contengono una sfilza di record NS senza nessun record A, ma la procedura prosegue comunque; il motivo è che il record A "mancante" si trova nella cache del web server, oppure viene reperito con delle request (e response) che non sono mostrate.

Suggerisco di fare queste prove:

1) risolvere google.com A?
2) ripetere inviando la request ad un name server "lontano" dal precedente; quasi certamente si vedranno risposte diverse (aspetto che non vi ho detto a lezione: le grosse organizzazioni distribuiscono il carico tra i propri server in molti modi; uno è quello di tradurre uno stesso nome in modo diverso a seconda dell'indirizzo IP da cui proviene la request; per cui chi interroga il DNS dall'Europa di norma riceve risposte diverse da chi esegue la stessa query dalla Nuova Zelanda).
3) ripetere 1 selezionando "trace" e cercando di capire cosa è successo...

DNS: units.it

Mi sono state fatte domande su units.it, che effettivamente è una "brutta bestia" nel senso che può confondere molto le idee.

Su http://www.digwebinterface.com/ si vede infatti che:

units.it ANY ? (cioè "dammi qualsiasi RR trovi con questo nome") torna

però:
units.it NS ? torna 3 record NS che non c'entrano con l'altro:
units.it.  21599 IN NS ns1.units.it.
units.it.  21599 IN NS ns2.units.it. 




Ad aggiungere ulteriore confusione c'è il fatto che scrivendo nella barra del browser "units.it" ci si collega in realtà a "www.units.it". In generale, cioè per altri siti, questo può accadere per molti motivi:

1) il DNS contiene un A per entrambi i nomi ed un web server ad entrambi gli indirizzi IP; il browser si collega al server senza www e questo risponde con una "redirection HTTP" verso il server con www (vedremo le redirection HTTP più avanti).
2) il browser inserisce automaticamente "www" nel nome (quindi invia al DNS una richiesta www.units.it)
3) il DNS contiene un CNAME tra il nome senza www ed il nome con www

nel caso di units.it CREDO che si verifichi il caso 1 (infatti c'è un record di tipo A anche per il nome www.units.it, associato ad un indirizzo IP diverso da quello visto sopra associato a units.it) ma che alcuni browser, ad esempio Opera, si comportino come nel caso 3.

Un bel caos. Per rispondere con certezza nel caso di units.it occorrerebbe un network sniffer, in questi giorni non ho tempo....