Im Rahmen einer Diplomarbeit an der Universität Tübingen wird das
Verhalten verschiedener NATs bezüglich existierender NAT-Traversal
Methoden untersucht. Leider verhalten sich aktuelle NATs sehr
verschieden und es ist deshalb hilfreich, möglichst viele
unterschiedliche NATs zu testen.

Dafür steht ein Testclient bereit, der (hinter einem NAT gestartet) die
Eigenschaften des NATs ermittelt und die Möglichkeit bietet, diese über
eine web-basierte Oberfläche direkt in eine Datenbank einzutragen.

Ich bitte Sie deshalb den Testclient herunterzuladen und ihn hinter
einer NAT zu starten (dauert ca. 2 Minuten). Der Tesclient läuft unter
Linux und Windows.

Der Testclient, der Quellcode, die Testergebnisse sowie detaillierte
Informationen sind auf der Homepage

http://gex.cs.uni-tuebingen.de

verfügbar.


Vielen Dank!
Andreas Klenk und Andreas Müller

Andreas Klenk <andreas.klenk*uni-tuebingen.de> wrote:

> Im Rahmen einer Diplomarbeit an der Universität Tübingen wird das
> Verhalten verschiedener NATs bezüglich existierender NAT-Traversal
> Methoden untersucht.

Was ist "ein NAT"?

--
Christian "naddy" Weisgerber naddy*mips.inka.de

Christian Weisgerber <naddy*mips.inka.de>:
> Andreas Klenk <andreas.klenk*uni-tuebingen.de> wrote:
>
>> Im Rahmen einer Diplomarbeit an der Universität Tübingen wird das
>> Verhalten verschiedener NATs bezüglich existierender NAT-Traversal
>> Methoden untersucht.
>
> Was ist "ein NAT"?

Ein Network Address Translator.

Strenggenommen sind handelsuebliche Uebersetzer ja NAPTs, da sie idR.
auch Ports uebersetzen.

Nur verstehe ich den Hintergrund des OP nicht: Alle NAPTs arbeiten
nach dem gleichen Prinzip: sie ersetzen die IP Adresse und/oder den
Port im Quellpart bzw. Zielpart eines Paketes (je nach Richtung).

Applikationsprotokollsensitive NAPTs modifizieren ggf. auch noch
Referenzen zu IP Adressen oder Portnummern innerhalb von
Applikationsprotokolldatenstrukturen, aber dazu muesste der OP schon
sagen, welche Protokolle ihn denn da so interessieren.

Christian Weisgerber schrieb:
> Andreas Klenk <andreas.klenk*uni-tuebingen.de> wrote:
>
>> Im Rahmen einer Diplomarbeit an der Universität Tübingen wird das
>> Verhalten verschiedener NATs bezüglich existierender NAT-Traversal
>> Methoden untersucht.
>
> Was ist "ein NAT"?
>
Ein "Network Address (Port) Translator" ist in den allermeisten Heim
(DSL) Routern integriert und erlaubt es mehreren Computer im
Heimnetzwerk mit dem Internet zu kommunizieren. Das geschieht durch
Masquerading, indem mehrere IP-Adressen und Ports aus dem privaten
Bereich des Heimnetzwerks auf (in der Regel eine) öffentliche IP-Adresse
und geeignet gewählte Ports auf der NAT abgebildet werden. Hierfür
werden die Header der einzelnen IP Pakete umgeschrieben und die
Quelladresse und der Quellport für ausgehende Pakete und Zieladresse und
Zielport für eingehende Pakete ersetzt. Eine umfangreiche Erklärung gibt
es hier:
http://de.wikipedia.org/wiki/Network_Address_Translation

Juergen P. Meier schrieb:

> Nur verstehe ich den Hintergrund des OP nicht: Alle NAPTs arbeiten
> nach dem gleichen Prinzip: sie ersetzen die IP Adresse und/oder den
> Port im Quellpart bzw. Zielpart eines Paketes (je nach Richtung).
Das ist richtig, führt aber je nach Umsetzung zu unterschiedlichem
Verhalten. Das wird wichtig, wenn man nun versucht NAT Traversal zu
betreiben und von außen eine Adresse im privaten Netzwerk anzusprechen.
Je nach Typ: Full Cone NAT, Port Restricted Cone NAT, oder Symmetric NAT
muss man andere Strategien anwenden. Interessant ist hier schon mal,
dass Symmetric NATs selten und Restricted Cone NATs bisher gar nicht
vorkommen. UPnP kamm ein statisches Port-Forwarding einrichten, hat aber
ein Sicherheitsproblem und wird nicht von allen NATs unterstützt.

> Applikationsprotokollsensitive NAPTs modifizieren ggf. auch noch
> Referenzen zu IP Adressen oder Portnummern innerhalb von
> Applikationsprotokolldatenstrukturen, aber dazu muesste der OP schon
> sagen, welche Protokolle ihn denn da so interessieren.

Application Layer Gateways sind problematisch, weil man eine
Implementierung für jedes zu unterstützende Protokoll braucht (FTP,
SIP,...). Deshalb unterstützen ALGs heute nur wenige Protokolle.

Andreas Klenk schrieb:

>> Was ist "ein NAT"?
>>
> Ein "Network Address (Port) Translator" ist in den allermeisten Heim
> (DSL) Routern integriert und erlaubt es mehreren Computer im
> Heimnetzwerk mit dem Internet zu kommunizieren.

Es dürfte den meisten hier geläufig sein, was man unter NAT zu verstehen
hat (ich habe darunter allerdings bisher kein eigenständiges Gerät
namens "Network Address (Port) Translator" verstanden).
Möglicherweise hat Christian ebenso wie ich und vielleicht mancher
andere hier lediglich ein Problem mit dem angegebenen Zweck
eures "Testprogramms". Da die Adreß- und Portzuordnung, wie sie dort
stattfindet, wohl überall gleichartig implementiert sein dürfte, fragt
es sich, was dieses "Testprogramm" ermitteln soll und ob es sich denn
wirklich auf den behaupteten Zweck beschränkt...

MfG
Rupert

> Es dürfte den meisten hier geläufig sein, was man unter NAT zu verstehen
> hat (ich habe darunter allerdings bisher kein eigenständiges Gerät
> namens "Network Address (Port) Translator" verstanden).
> Möglicherweise hat Christian ebenso wie ich und vielleicht mancher
> andere hier lediglich ein Problem mit dem angegebenen Zweck
> eures "Testprogramms". Da die Adreß- und Portzuordnung, wie sie dort
> stattfindet, wohl überall gleichartig implementiert sein dürfte, fragt
> es sich, was dieses "Testprogramm" ermitteln soll und ob es sich denn
> wirklich auf den behaupteten Zweck beschränkt...

Schön wenn das so wäre. Warum stellen wir dann so deutlich
unterschiedliches Verhalten fest!?!!
http://gex.cs.uni-tuebingen.de/?mod=results

Rupert Haselbeck <Rupert.Haselbeck*gmx.de> wrote:

> >> Was ist "ein NAT"?
> >>
> > Ein "Network Address (Port) Translator" ist in den allermeisten Heim
> > (DSL) Routern integriert und erlaubt es mehreren Computer im
> > Heimnetzwerk mit dem Internet zu kommunizieren.
>
> Es dürfte den meisten hier geläufig sein, was man unter NAT zu verstehen
> hat

Network Address Translation. Aber das ist ein unzählbares Wort.

--
Christian "naddy" Weisgerber naddy*mips.inka.de

to Andreas Klenk <andreas.klenk*uni-tuebingen.de>:
>
>> Es dürfte den meisten hier geläufig sein, was man unter NAT zu verstehen
>> hat (ich habe darunter allerdings bisher kein eigenständiges Gerät
>> namens "Network Address (Port) Translator" verstanden).
>> Möglicherweise hat Christian ebenso wie ich und vielleicht mancher
>> andere hier lediglich ein Problem mit dem angegebenen Zweck
>> eures "Testprogramms". Da die Adreß- und Portzuordnung, wie sie dort
>> stattfindet, wohl überall gleichartig implementiert sein dürfte, fragt
>> es sich, was dieses "Testprogramm" ermitteln soll und ob es sich denn
>> wirklich auf den behaupteten Zweck beschränkt...
>
> Schön wenn das so wäre. Warum stellen wir dann so deutlich
> unterschiedliches Verhalten fest!?!!
> http://gex.cs.uni-tuebingen.de/?mod=results

Ich halte dien Ergebnisse in der Spalte "preserves ports" fuer
unvollstaendig.

Hast du bei den Tests Portkollisionen erzeugt?

Also zwei connections mit gleichem Source-Port zum gleichen Ziel?
Ich wette mit dir um ein Bier, dass mindestens die haelfte der "yes"
NAT-implementierungen hier auch PAT machen.

Desweiteren fehlt die Erklaerung, was genau du unter "full-cone",
"hairpinning" "hole-punching", "relay" etc. verstehst. Das sind
keineswegs eindeutig festgelegte Begriffe.

Fuer eine wissenschaftliche Arbeit muesstest du diese verwendeten
Begriffe eindeutig erklaeren.

--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Rupert Haselbeck wrote:
> Andreas Klenk schrieb:
>
>>> Was ist "ein NAT"?
>>>
>> Ein "Network Address (Port) Translator" ist in den allermeisten Heim
>> (DSL) Routern integriert und erlaubt es mehreren Computer im
>> Heimnetzwerk mit dem Internet zu kommunizieren.
>
> Es dürfte den meisten hier geläufig sein, was man unter NAT zu verstehen
> hat (ich habe darunter allerdings bisher kein eigenständiges Gerät
> namens "Network Address (Port) Translator" verstanden).
> Möglicherweise hat Christian ebenso wie ich und vielleicht mancher
> andere hier lediglich ein Problem mit dem angegebenen Zweck
> eures "Testprogramms". Da die Adreß- und Portzuordnung, wie sie dort
> stattfindet, wohl überall gleichartig implementiert sein dürfte, fragt
> es sich, was dieses "Testprogramm" ermitteln soll und ob es sich denn
> wirklich auf den behaupteten Zweck beschränkt...
>
> MfG
> Rupert

Die Zuordnung oder das "Binding" ist leider nicht eindeutig
implementiert, Man unterscheidet zwischen verschiedenen Binding- und
Filtering Strategien von denen dann der NAT-Typ abgeleitet wird. (siehe
RFC 3489 (STUN) und RFC4787). Wir wollen mit der ersten Spalte (NAT-Typ)
eine Statistik erstellen, wieviel % z.B. Full-Cone sind, und wieviele
eine restriktivere Filtering-Strategie implementieren. Das ist für
verschiedene Service-Kategorien wichtig: z.B: für Globales NAT-Traversal
eignet sich Full-Cone, Restricted eben nicht. Andersrum verhält es sich
für Secure-NAT-Traversal.

Juergen P. Meier wrote:
> Ich halte dien Ergebnisse in der Spalte "preserves ports" fuer
> unvollstaendig.
>
> Hast du bei den Tests Portkollisionen erzeugt?
>
nein, weil wir nicht Port-Overloading sondern Port Preservation testen.
Eigentlich ist der dieser Testes nicht so wichtig, weil es für
NAT-Traversal egal ist ob der Port umgesetzt wird oder nicht. Ausserdem
kann Port-Preservation interessant sein, wenn ein globaler Service
angeboten wird, da man diesen dann erstmal von aussen über denselben
Port erreichbar machen kann. Was passiert wenn ein 2. Rechner den selben
Port nimmt haben wir nicht getestet, aus der Literatur entnimmt man
allerdings, dass dann meist einfach ein beliebiger anderer Port genommen
wird. ("they don't do port preservation anymore" (RFC4787)). Andere
Verhalten wie Port Overloading... wären interessant zu testen aber
irgendwo muss man halt aufhören.


> Also zwei connections mit gleichem Source-Port zum gleichen Ziel?
> Ich wette mit dir um ein Bier, dass mindestens die haelfte der "yes"
> NAT-implementierungen hier auch PAT machen.
Port Preservation heisst nichts anderes als dass der Port solange nicht
umgeschrieben wird solange es keine Kollision gibt. Wegen PAT: Ja
mindestens die Hälfte, aber bei PAT ist es beispielsweise vorstellbar,
dass der Port erstmal beibehalten wird und später dann doch geändert wird.

>
> Desweiteren fehlt die Erklaerung, was genau du unter "full-cone",
> "hairpinning" "hole-punching", "relay" etc. verstehst. Das sind
> keineswegs eindeutig festgelegte Begriffe.

Klar, auf der Result-Page fehlt eine Erklärung, ich werde dies ändern.
Die NAT-Typen sind allerdings eindeutig in RFC 3489 festgelegt.

>
> Fuer eine wissenschaftliche Arbeit muesstest du diese verwendeten
> Begriffe eindeutig erklaeren.
>
Geschenkt. Aber die wissenschaftliche Arbeit ist auch die Ausarbeitung :-)

Andreas Mueller <muellera*ri.uni-tuebingen.de>:
> Juergen P. Meier wrote:
> > Ich halte dien Ergebnisse in der Spalte "preserves ports" fuer
>> unvollstaendig.
>>
>> Hast du bei den Tests Portkollisionen erzeugt?
>>
> nein, weil wir nicht Port-Overloading sondern Port Preservation testen.
> Eigentlich ist der dieser Testes nicht so wichtig, weil es für
> NAT-Traversal egal ist ob der Port umgesetzt wird oder nicht. Ausserdem

Wenn deine Pakete ploetzlich beim falschen Rechner ankommen, ist das
alles andere als Egal.

> kann Port-Preservation interessant sein, wenn ein globaler Service
> angeboten wird, da man diesen dann erstmal von aussen über denselben
> Port erreichbar machen kann. Was passiert wenn ein 2. Rechner den selben
> Port nimmt haben wir nicht getestet, aus der Literatur entnimmt man
> allerdings, dass dann meist einfach ein beliebiger anderer Port genommen
> wird. ("they don't do port preservation anymore" (RFC4787)). Andere
> Verhalten wie Port Overloading... wären interessant zu testen aber
> irgendwo muss man halt aufhören.

Nicht Wirklich. Wenn man wissenschaftlich arbeitet, muss man bei sowas
schon die moglichkeiten Ausleuchten, die in der Praxis vorkommen koennen.
Das ist in diesem FAlle eine ueberschaubare, endliche Menge.

>> Also zwei connections mit gleichem Source-Port zum gleichen Ziel?
>> Ich wette mit dir um ein Bier, dass mindestens die haelfte der "yes"
>> NAT-implementierungen hier auch PAT machen.
> Port Preservation heisst nichts anderes als dass der Port solange nicht
> umgeschrieben wird solange es keine Kollision gibt. Wegen PAT: Ja
> mindestens die Hälfte, aber bei PAT ist es beispielsweise vorstellbar,
> dass der Port erstmal beibehalten wird und später dann doch geändert wird.

Es gibt auch kaputte NAT-implementirungen. Hast du das auch getestet?

>> Desweiteren fehlt die Erklaerung, was genau du unter "full-cone",
>> "hairpinning" "hole-punching", "relay" etc. verstehst. Das sind
>> keineswegs eindeutig festgelegte Begriffe.
>
> Klar, auf der Result-Page fehlt eine Erklärung, ich werde dies ändern.
> Die NAT-Typen sind allerdings eindeutig in RFC 3489 festgelegt.

Nur innerhalb dessen Kontexts. Ein Hinweis auf dieses RfC
waere demnach angebracht.

>> Fuer eine wissenschaftliche Arbeit muesstest du diese verwendeten
>> Begriffe eindeutig erklaeren.
>>
> Geschenkt. Aber die wissenschaftliche Arbeit ist auch die Ausarbeitung :-)

U.a.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)