ARGOMENTO:

Salve, la questione e' questa,
scenario pat,
se da due interfaccie di rete che stanno sulla stessa inside network partono delle richeste di connessione verso lo stesso host esterno e se queste hanno la stessa porta di origine secondo quanto scritto nel curriculum e' l'entita' pat ad aggiustare le cose cambiando, oltre all'indirizzo sorgente anche la porta sorgente nel messaggio che viene nviato nela outside network.
Riflettendo bene su questo aspetto mi viene in mente che una discriminante e' anche il protocollo a cui punta ip tramite il campo protocol descritto nella rfc 790 tools.ietf.org/html/rfc790, ed osservo che il nat sarebbe capace di discriminare in base a questo valore anche senza cambiare la porta, perche' il curriculum parla solo di porta ed ip e non aggiunge anche il campo protocol?
in questo modo e se cioe' fosse analizzato il campo protocol presente nel messaggio sarebbe facile discriminare e rattare senza troppi "magheggi" almeno la prima delle richieste in conflitto, cioe' se si dovesse verificare che ho una connessione tcp ed una udp verso lo stesso indirizzo outside ed anche la stessa porta di origine non ci sarebbe problema cosi come anche una eventuale ulteriore richiesta di icmp o uno qualunque dei protocolli indicati nella rfc 790.
Mi chiedo se sono io che non ho colto oppure se effetivamente i match he determinanol'evolversi della dinamica nat vengono effettuati slo su ip e porte senza considerare discriminante il protocol contenuto nell'header ip?

Assolutamente corretto, nel senso che in realtà il PAT tiene presente le traduzioni fatte per protocollo, quindi nel caso da te descritto non sarebbe necessario tradurre la porta sorgente.
Il nat tiene conto del protocollo, se pensi che una echo request ICMP, che nulla ha che fare con le porte in realtà viene pattata in modo ancora differente.

Poi c'è da tenere presenti le implementazioni, ad esempio un firewall come Cisco ASA traduce sempre la porta sorgente per motivi di sicurezza, in quanto se usi un Windows XP tenderai ad utilizzare la porta sorgente 1024 e questo potrebbe rendere facilmente noto il tuo sistema operativo ed quindi eventuali vulnerabilità.

Scusa Virgilio ma per come ho capito io del funzionamento del nat sia statico che dinamico non riesco a capire quale ruolo abbiano le porte ed anche il campo protocol contenuto nello header ip, sinceramente non riesco a capire perche' io mi sono fatto questa idea della dinamica NAT che ti espongo cosi mi serve per riorganizzare le idee e daro' a te la possibilita' di individuare dove commetto l'errore.
Per quanto ho capito io il NAT opera nel seguente modo :
premetto che la base dati su cui opera il processo nat la TABELLA NAT dovrebbe essere un array costituito da record i cui campi sono denominati INSIDE LOCAL ed INSIDE GLOBAL, le righe di detta base dati si costituiscono manualmente con il comando IP NAT INSIDE SOURCE STATIC ipinsidelocal ipinsideglobal oppure nel nat dinamico detta tabella viene costruita dinamicamente con una procedura simile a quella utilizzata dagli switch o dai bridge per costituire la loro mac address table.
La dinamica dovrebbe essere questa:
verso inside-->outside
All'evento (indicazione) di arrivo di un pacchetto ip sulla interfaccia inside il processo nat estrae l'indirizzo di sorgente ed esegue una ricerca tra le righe dell'array quando trova un match con il campo INSIDE LOCAL si ferma e legge quale e' il corrispondente campo INSIDE GLOBAL E sovrascrive questo valore nel campo source address del messaggio in questione, poi ricalcolera' anche il campo di check ed inoltrera' sulla interfaccia di outside il messaggio cosi modificato.
verso outside-->inside
All'evento (indicazione) di arrivo di un pacchetto ip sulla interfaccia inside il processo nat estrae l'indirizzo di destinazione ed esegue una ricerca tra le righe dell'array quando trova un match con il campo inside global si ferma e legge quale e' il corrispondente campo INSIDE LOCAL E sovrascrive questo valore nel campo destination address del messaggio in questione, poi ricalcolera' anche il campo di check ed inoltrera' sulla interfaccia di outside i messaggio cosi modificato.
Cosi come ho descritto io l'algoritmo esegue la funzione senza tirare in ballo nessun campo protocol e nessuna porta, il nat statico e dinamico per come la vedo io non ha nessuna necessita' di operare sulle porte quindi non riesco a capire cosa tu intenda dire quando scivi: "Il nat tiene conto del protocollo, se pensi che una echo request ICMP, che nulla ha che fare con le porte in realtà viene pattata in modo ancora differente." forse ti e' scappata una p al posto di una n e quindi invece intendevi scrivere che " Il nat tiene conto del protocollo, se pensi che una echo request ICMP, che nulla ha che fare con le porte in realtà viene pattata in modo ancora differente."
per il pat sto raccogiendo le idee c'e' ancora qualcosa che non quadra al 100%
ammi sapere se era un errore ortografico oppure se non e' quella che ho scritto io la dinamica delle operazioni sl nat statico e dinamico,
grazie.

Si diciamo che è facile creare confusione con i termini, nel senso che ad esempio se prendi la RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" questa parla in buona parte delle tecniche di port translation, quindi diciamo che non è per forza detto che parlando di NAT si intenda esclusivamente la traduzione degli indirizzi.
Ad esempio in Cisco il PAT viene chiamato NAT Overload contribuendo in qualche modo a possibili misinterpretazioni.

Fatta questa premessa, cerco di chiarire meglio. Il processo che descrivi, senza voler indicare come possa essere scritto il codice viste le mie skill di poco più che habbista in ambito programmazione, mi sembra assolutamente corretto per il NAT puro, cioè traduzione esclusiva degli indirizzi IP.

Nel momento in cui hai a che fare con il PAT o NAT Overload, puoi multiplare la traduzione tenendo conto di altri parametri che sono il campo protocol e la porta sorgente, o nel caso dell'icmp protocolo più sequence number.

Ad esempio se fai uno show ip nat translation in caso di nat statico vedraise fosse un nat dinamico vedresti anche valorizzati gli indirizzi Outside, ma il NAT puro dinamico non si utilizza quasi mai.

mentre nel caso di PAT (e nello specifico di port forwarding)Come vedi nella tabella si tiene conto sia delle porte che del protocollo. L'esempio precedente è riferito ad un PAT statico in cui la tripletta Protocollo-Indirizzo Pubblico-Porta inside global sono stati mappati sulla stessa tripletta Inside Local.

Da questo punto di vista sarebbe possibile in linea di principio fare contemporaneamente i seguenti mapping:

INSIDE_GLOBAL: TCP-100.0.2.10:23 verso INSIDE_LOCAL:TCP-192.168.0.10:23 (quindi mapping di un server telnet)
INSIDE_GLOBAL: UDP-100.0.2.10:23 verso INSIDE_LOCAL:UDP-192.168.0.11:23 (quindi mapping di un server UDP che opera sulla 23, che non ha senso nella realtà ma serve per fare un esempio di multiplazione)

Aggiungo un ultimo aspetto chiave, una volta avvenuta la traduzione, questa ha valore bidirezionale e quindi il NAT non è da considerarsi una feature di sicurezza, perchè in qualche modo la rete interna viene esposta all'esterno seppure con le limitazioni delle entry in tabella.

Brevemente, il meccanismo del PAT tiene conto nella tabella non solo degli indirizzi e delle porte ma anche del protocollo. Credo che mi stessi chiedendo questo, se ho misenterpretato la domanda, non esitare a farmi capire meglio quale sia il tuo dubbio.

Aggiungo la risposta alla tua domanda che mi è sfuggita nella risposta precedente, rispetto alla parola "PATTARE" per quanto riguarda l'icmp, effettivamente è più corretto parlare di "NATTARE" dove infatti la rfc 5508 " NAT Behavioral Requirements for ICMP" parla giustamente di NAT e non di PAT non essendo presenti porte in ICMP.

Ancora una volta per Cisco che sia PAT o sia NAT per ICMP il tutto viene chiamato NAT Overload senza distinzioni.

Virgilo tu hai scritto: "Assolutamente corretto, nel senso che in realtà il PAT tiene presente le traduzioni fatte per protocollo, quindi nel caso da te descritto non sarebbe necessario tradurre la porta sorgente.", fammi capire meglio, mi spiego.
La mia ipotesi consisteva fondamentalmente nel considerare come discriminanti non piu' solamente ip sorgente (verso inside-->outside) ed ip destinazione (verso outside-->inside) ma il concatenamento di protocol+ip sorgente+porta (verso inside-->outside) e protocol+ip destinazione+porta (verso outside-->inside), PER I PROTTOCOL COME icmp he "vivono senza un livello superiore e quindi non hanno porte aperte verso il livello 4 il nat potrebbe assumere una unica porta fittizzia per tutti e quindi farli andare in conflitto sulla seconda "istanza" (la prima sarebbe disciplnata dal campo protocol; questo mia ipotesi non e' sufragata da nessuna slide e da nessuna frase, difatti le frasi che trattano del pat discutono solo di porte e manco di indirizzi.
p.s. nel mio primo intervento ho fatto un errore che e' dovuto proprio anche a questa incertezza,
ma in effetti probabilmente il nat puo' operare come vuole basta che raggiunga l'obiettivo e non faccia danni =D , come ho scritto io oppure anche secondo l'istinto degli spiriti ballerini , tanto e' un processo per cosi dire stand alone e non deve comunicare ma deve solo creare due immagini (outside vista da inside e viceversa) coerente e funzionante,
e' cosi' come ho scritto?

non avevo letto la tua risposta, avro' bisogno di tempo per riflettere, grazie, comunque il mio ultimo dovrebbe abìndare nella dirzione che hai indicato, ognuno fa come vuole specie su processi che non si interfacciano con altri ogni specifica implemetazione segue una filosofia arbitraria, ci sono dei limiti o no?
Grazie

Come detto anche nella RFC 3424 "NAT implementations vary widely in terms of how they handle different traffic", quindi bisognerebbe distinguere puntualmente tra
NAT puro (inteso come sola traduzione di indirizzi ip)
NAT Behavioral Requirements for ICMP
NAT Behavioral Requirements for UDP Unicast
NAT Behavioral Requirments for TCP
etc.etc...

Ad esempio per l'ICMP ci si basa sul "Query ID" e citando dalla RFC 5508 "A Query Id is used by Query senders and responders as the equivalent of a TCP/UDP port to identify an ICMP Query session."

Tuttavia volendo cercare di essere generali, credo che tu abbia centrato il punto, nel senso che per TCP e UDP è possibile tradurre basandosi sulla tripletta Protocollo-Indirizzo IP-Porta con le dovute distinzioni in dipendenza del verso.

Quindi per farla breve, direi che le cose stanno esattamente come da te indicato nel post precedente
"concatenamento di protocol+ip sorgente+porta (verso inside-->outside) e protocol+ip destinazione+porta (verso outside-->inside)"

roberto ulisse ha scritto: ogni specifica implemetazione segue una filosofia arbitraria, ci sono dei limiti o no?

Diciamo che probabilmente non sono la persona più indicata a risponderti nel senso che nel mio lavoro mi limito a progettare architetture sulla base di prodotti e implementazioni esistenti.

Tuttavia credo che il limite di libertà dovrebbe essere quello delle RFC e degli standard in generale che garantiscono interoperabilità e predicibilità dei comportamenti sostanziali.

E' anche vero che se ci si basasse sempre e solo sulle RFC l'innovazione sarebbe più lenta, poichè Cisco in particolare propone continuamente nuove tecnologie proprietarie che poi con il tempo possono diventare standard, magari con qualche variazione.

ritengo
che con queste tue ultime considerazioni io possa dire che la parte piu' ragionevole di me tifa per te! grazie di esistere e di resistere;
quelli come noi sono cosi,...
noi siamo cosi' ... ma adesso inizia la poesia.
grazie!

Contento tu abbia apprezzato