Am Tue, 23 Jun 2009 20:03:01 +0000 (UTC) schrieb Juergen P. Meier:

> Das hat lediglich was mit Anonymitaet innerhalb des LANs zu tun - das
> LAN als ganzes ist natuerlich nicht anonym. D.h. wenn du privacy
> extensions in deinem eigenen /48 Prefix fuer zuhause verwendest, kann
> man trotzdem jede noch so zufaellige Adresse aus diesem Netz dir ganz
> persoenlich zuordnen.

Privatkunden-ISPs sind in Zukunft hoffentlich so freundlich und vergeben
bei jeder Trennung ein neues Netz. Sonst ist IPv6 der absolute Privacy-GAU.
Der "DSL-Router" sollte dann in Zukunft nicht NAT machen sondern alle 24
Stunden trennen und die öffentlichen IP-Adressen Paketfiltern.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/

Am 23 Jun 2009 13:01:43 GMT schrieb Juergen Ilse:

> Das "generische Connection-Tracking" bei TCP und UDP reicht aber oftmals
> nicht aus,

Das Connection-Tracking bei TCP reicht völlig aus, wenn das
Anwendungsprotokoll halbwegs primitiv ist, z.B. http(s), smtp(s), pop3(s),
imap(s), nntp(s), ssh.
Problematisch ist nur so ein Husten wie FTP wo die Protkollayer miteinander
vermixt werden oder Sachen die UDP "ungeschickt" verwenden.

> und bei allem was darueber hinausgeht, hat man wieder mindestens
> ein zusaetzliches Stueck Software (den passenden "NAT-Helper"), der ggfs.

Nö, braucht man nur für so kaputte Sachen wie FTP, DCC, H234 etc.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/

Hallo,

Carsten Krueger <cakruege*gmail.com> wrote:
> Am 23 Jun 2009 13:01:43 GMT schrieb Juergen Ilse:
>> Das "generische Connection-Tracking" bei TCP und UDP reicht aber oftmals
>> nicht aus,
> Das Connection-Tracking bei TCP reicht völlig aus, wenn das
> Anwendungsprotokoll halbwegs primitiv ist, z.B. http(s), smtp(s), pop3(s),
> imap(s), nntp(s), ssh.

Aha. Jedes "nicht kaputte Protokoll" ist TCP ueber eine einzige Connection.
Alles andere ist per Definition kaputt ...
Schoen dass wir drueber geredet haben, aber manche Leute haben auch ein
etwas komplexeres Weltbild.

> Problematisch ist nur so ein Husten wie FTP wo die Protkollayer miteinander
> vermixt werden oder Sachen die UDP "ungeschickt" verwenden.

FTP ist noch vergleichsweise trivial, es gibt noch erheblich schlimmeres.

>> und bei allem was darueber hinausgeht, hat man wieder mindestens
>> ein zusaetzliches Stueck Software (den passenden "NAT-Helper"), der ggfs.
> Nö, braucht man nur für so kaputte Sachen wie FTP, DCC, H234 etc.

Nicht alles, was dir nicht in den KRam passt, ist auch kaputt.

Tschuess,
Juergen Ilse (juergen*usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Am 23 Jun 2009 21:36:47 GMT schrieb Juergen Ilse:

> Aha. Jedes "nicht kaputte Protokoll" ist TCP ueber eine einzige Connection.

Für die meisten Anwendungsfälle ist das sinnvoll. Außer Filesharing und
VoIP fällt mir wenig ein wo man mehr Verbindungen wirklich braucht.

> Nicht alles, was dir nicht in den KRam passt, ist auch kaputt.

Nenne doch mal ein Protokoll was einen NAT-Helper braucht aber bei IPv6
bequem statefull zu Filtern ist.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/

Juergen P. Meier <nospam-1984*jors.net> wrote:
> Das hat lediglich was mit Anonymitaet innerhalb des LANs zu tun - das
> LAN als ganzes ist natuerlich nicht anonym. D.h. wenn du privacy
> extensions in deinem eigenen /48 Prefix fuer zuhause verwendest, kann
> man trotzdem jede noch so zufaellige Adresse aus diesem Netz dir ganz
> persoenlich zuordnen.

Um zu ergaenzen: es ist nicht nur Anonymitaet innerhalb eines LANs sondern
auch bei Roaming/Einsatz in mehreren LANs bleibt bei der traditionellen
Addressvergabe der lokale Teil gleich. D.h. ein Client ist auf einem Server
Track bar egal über welchen ISP er (mit v6) online ist. Dieser Fall ist für
die anonyme Vergabe auch ein wichtiger Grund.

Gruss
Bernd

Carsten Krueger <cakruege*gmail.com>:
> Am Tue, 23 Jun 2009 20:03:01 +0000 (UTC) schrieb Juergen P. Meier:
>
>> Das hat lediglich was mit Anonymitaet innerhalb des LANs zu tun - das
>> LAN als ganzes ist natuerlich nicht anonym. D.h. wenn du privacy
>> extensions in deinem eigenen /48 Prefix fuer zuhause verwendest, kann
>> man trotzdem jede noch so zufaellige Adresse aus diesem Netz dir ganz
>> persoenlich zuordnen.
>
> Privatkunden-ISPs sind in Zukunft hoffentlich so freundlich und vergeben
> bei jeder Trennung ein neues Netz.

Aeh, das wuerde gegen die aktuellen Vergaberichtlinien verstossen.

> Sonst ist IPv6 der absolute Privacy-GAU.

Nur solange man sich weiterhin stoisch weigert, NAT nicht zu machen,
weil es so Boese!!!1elf ist. Ein dynamisches nicht-bijektives Mapping
von PA Adressen (egal ob global unicast oder unique local) auf einen
Pool von globalen Unicastadressen wuerde dieses Problem ohne
Policyaenderungen sofort beseitigen. Ganz ohne Zwangstrennungen.

Aber NAT ist Boese!!!1elf

Fuer die ISPs ware das im Gegenteil sogar ein moeglicher Aspekt eines
finanziell lukrativen Geschaeftsmodells: Normaler Zugnag = NAT vs.
Premium/Business-Zugang = eigenes festes /48 (gemaess Vergaberichtlinien).

Aber das ware ja mal eine sinnvolle Idee, und sinnvolle Ideen sind in
diesen Zeiten scheinbar nicht besonders in Mode.

> Der "DSL-Router" sollte dann in Zukunft nicht NAT machen sondern alle 24
> Stunden trennen und die öffentlichen IP-Adressen Paketfiltern.

Diese daemliche Erfindung der Zwangstrennung ist ein schlimmerer
Unfall als NAT es je sein koennte.

Ausserdem hat das auch ueberhaupt gar nichts mit Privacy/Anonymity zu
tun. Schliesslich haelt der ISP per Protokollierung fest, wer genau
wann welche Adressen zugewiesen bekommen hatte. Muss er schlisslich um
den aktuell geltenden Gesetzen zu genuegen.

Wer glaubt nur weil er taeglich eine andere IP Adresse zugewiesen
bekommt irgendwie anonymer sein zu koennen, als jemand, der eine
solche IP Adresse fuer so lange wie sein DSL-Router laeuft bekommt,
ist einem gefaehrlichen Irrglauben unterlegen.

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)

Bernd Eckenfels <bernd-09*eckenfels.net>:
> Juergen P. Meier <nospam-1984*jors.net> wrote:
>> Das hat lediglich was mit Anonymitaet innerhalb des LANs zu tun - das
>> LAN als ganzes ist natuerlich nicht anonym. D.h. wenn du privacy
>> extensions in deinem eigenen /48 Prefix fuer zuhause verwendest, kann
>> man trotzdem jede noch so zufaellige Adresse aus diesem Netz dir ganz
>> persoenlich zuordnen.
>
> Um zu ergaenzen: es ist nicht nur Anonymitaet innerhalb eines LANs sondern
> auch bei Roaming/Einsatz in mehreren LANs bleibt bei der traditionellen
> Addressvergabe der lokale Teil gleich. D.h. ein Client ist auf einem Server
> Track bar egal über welchen ISP er (mit v6) online ist. Dieser Fall ist für
> die anonyme Vergabe auch ein wichtiger Grund.

Ja, und die, die auf privacy extensions bestehen, machen dann gleichzeitig
mobile IP... BTST.

Carsten Krueger <cakruege*gmail.com>:
> Am 23 Jun 2009 13:01:43 GMT schrieb Juergen Ilse:
>
>> Das "generische Connection-Tracking" bei TCP und UDP reicht aber oftmals
>> nicht aus,
>
> Das Connection-Tracking bei TCP reicht völlig aus, wenn das
> Anwendungsprotokoll halbwegs primitiv ist, z.B. http(s), smtp(s), pop3(s),
> imap(s), nntp(s), ssh.
> Problematisch ist nur so ein Husten wie FTP wo die Protkollayer miteinander
> vermixt werden oder Sachen die UDP "ungeschickt" verwenden.

Die gleiche Probleme, die ein NAT geraet hierbei hat, hat aber auch
ein Paketfilter.

Mit einem Unterschied: Bei NAT sieht die kanonische Loesung dieses
Problems idR. so aus: Geht halt nicht. Verzichte auf $PROTOKOLL.
Bei Paketfiltern hingegen sieht sie idR. so aus: Mach halt den
Paketfilter fuer $DYNAMISCHE_PORTRANGE komplett auf.

>> und bei allem was darueber hinausgeht, hat man wieder mindestens
>> ein zusaetzliches Stueck Software (den passenden "NAT-Helper"), der ggfs.
>
> Nö, braucht man nur für so kaputte Sachen wie FTP, DCC, H234 etc.

ACK.

Lustig wird es, wenn FTPS verwendet werden soll. Egal ob durch NAT oder
einfach nur Paketfilter. Oder SIP mit Verschluesselung.

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)

Juergen Ilse <juergen*usenet-verwaltung.de>:
> Aha. Jedes "nicht kaputte Protokoll" ist TCP ueber eine einzige Connection.
> Alles andere ist per Definition kaputt ...

Bei Punkt-zu-Punkt Protokollen, ja. FTP war urspruenglich kein P2P
Protokoll. Zudem ist es aelter als TCP/IP. Es ist also kaum
verwunderlich, dass es bezueglich TCP/IP "broken by design" ist.

> Schoen dass wir drueber geredet haben, aber manche Leute haben auch ein
> etwas komplexeres Weltbild.

Man kann es sich einfach machen.

>> Problematisch ist nur so ein Husten wie FTP wo die Protkollayer miteinander
>> vermixt werden oder Sachen die UDP "ungeschickt" verwenden.
>
> FTP ist noch vergleichsweise trivial, es gibt noch erheblich schlimmeres.

FTPS. Oder FTP ueber IPv4 mit einem dysfunktoinalen (sprich: in
Defaultkonfiguration) Linux Server mit IPv4/IPv6 Dualstack.
Hahahahaha. Viel Spass beim herausfutzeln der IPv4 adresse aus der
IPv6 Form (die Loesung lautet natuerlich: sysctl -w net.ipv6.bindv6only=1).

>>> und bei allem was darueber hinausgeht, hat man wieder mindestens
>>> ein zusaetzliches Stueck Software (den passenden "NAT-Helper"), der ggfs.
>> Nö, braucht man nur für so kaputte Sachen wie FTP, DCC, H234 etc.
>
> Nicht alles, was dir nicht in den KRam passt, ist auch kaputt.

FTP ist seit fruehestens HTTP/1.1 und spaetestens WebDAV obsolete.
DCC war schon mit Erfindung obsolete.
H.23x ist seit SIP obsolete.
SIP ist zwar nicht besser, aber es erlaubt wenigstens prinzipiell einen
ein-Kanal-Tunnel zu einem Tunnelbroker.
SOAP in oeffentlichen Datennetzen ist nur was fuer Vollidioten.
Gleiches gilt fuer RPC (both kinds) u.Ae.

Fuer LAN-LAN Kopplungen mit gleichem Sicherheitsnivaeu gibt es VPN,
das - welch wunder - in Form von IPSEC auch NAT-resistent getunnelt
werden kann. (Und die *Mehrzahl* der problematischen Protokolle ist
grundsaetzlich sowieso nur innerhalb eines gesicherten LAN sinnvoll
zu verwenden.)

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)

Carsten Krueger <cakruege*gmail.com>:
> Nenne doch mal ein Protokoll was einen NAT-Helper braucht aber bei IPv6
> bequem statefull zu Filtern ist.

Die Sache mit IPv6 und dem Filtern oberhalb von OSI-Layer 3 ist
sowieso eine Sache fuer sich, spaetestens wenn Client und Server IPv6
mit Transport-Mode IPSEC verwenden, hat es sich Ausgefiltert.

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)