Thema	Verfasser	Letzte Antwort
OpenVPN 2.Thread	tobias ( ---.emea.daimlerchrysler.com)	11 Sep 2008 21:44
Ich glaube ich kann in dem anderen Thread nichts mehr schreiben. Daher habe ich hier mal einen 2. eröffnet. edit: sorry, ich glaube die Fragen hat es doch in dem anderen Thread hinzugefügt. Nur sehe ich sie nicht. Falls ja sorry für den Doppelpost! vielen Dank. Jetzt noch für heute meine letzte Frage, da ich Sie heute ja schon sehr beansprucht habe. Da im PSK Modus Daten sofort zu fließen beginnen, reicht der ReplaySchutz mit Sequenznmmern nicht wirklich aus, daher wird in diesem Modus auch ein Zeitstempel eingefügt. Ist diese Argumentation richtig? Weil sonst könnte jmd einfach alle Daten nochmal senden, Da dann die Sequenznummer (wenn sie nicht ausgehandelt wird) jedesmal gleich anfängt und dadurch kein replay festgestellt werden kann. durch den Zeitstempel würde das verhindert werden. Sorry dass ich Sie mit solchen Fragen nerve. Aber ich habe sonst keinen Ansprechpartner :( edit: kennen Sie vll ein gutes Dokument das den TCP-over-TCP effekt betrachtet, vorallem in wireless Umgebungen Grüsse Tobias
RE: OpenVPN 2.Thread	Ralf ( ---.dip.t-dialin.net)	28 Aug 2008 06:46
Hallo Tobias, zunächst zum Thread-Problem. Es werden immer nur 20 Beiträge angezeigt. Unten kannst Du auf die nächste Seite wechseln. Zum Replay-Schutz. Es reichen Sequenznummern auch bei PSK. Sie müssen nur größer sein. Bei TLS wird die gesamte Sitzung vor einem Überlauf neu ausgehandelt. Das gibt es bei PSKs nicht. Daher dürfen die Nummern nicht überlaufen. Das sie immer gleich anfängt wird hier als weniger kritisch angesehen, da man nicht von mehreren kurzzeitigen Tunneln ausgeht. Der Empfänger prüft einfach, ob die Sequenznummer immer größer wird. packet_id (4 or 8 bytes, if not disabled by --no-replay). In SSL/TLS mode, 4 bytes are used because the implementation can force a TLS renegotation before 2^32 packets are sent. In pre-shared key mode, 8 bytes are used (sequence number and time_t value) to allow long-term key usage without packet_id collisions. Daher reichen in TLS 4 Bytes und werden in PSK 8 Bytes verwendet. Was als zusätzliche 4 Bytes genutzt wird, ist egal. Der Zeitstempel ist praktisch, da auch dieser monoton steigt ;-) Zum TCP/TCP Problem. Die erste Beschreibung des Problems, die ich im Internet kenne ist: http://sites.inka.de/bigred/devel/tcp-tcp.html Die einzige aktuelle wissenschaftliche Untersuchung ist: http://www.ispl.jp/~oosaki/papers/Honda05_ITCom.pdf Das hättest Du aber auch selbst finden müssen ;-) Viel Glück beim Schreiben der Arbeit. Ralf
RE: RE: OpenVPN 2.Thread	tobias ( ---.emea.daimlerchrysler.com)	28 Aug 2008 09:45
Hallo, dankeschön! das 2. Paper von Honda hatte ich schon gefunden gehabt Aber nochmal zu dem Replay-Schutz: wenn jmd den Anfang einer Verbindung aufzeichnet, dann könnte er immer wieder diese Pakete an den Gateway senden und er würde sie annehmen. oder lieg ich da falsch? Fangen die Sequenznummern dann immer bei 1 ein ? Grüsse Tobias
RE: RE: RE: OpenVPN 2.Thread	Ralf ( ---.dip.t-dialin.net)	28 Aug 2008 10:03
Hallo, kritisch ist das nur bei PSK. Der Replay kann nur funktionieren, wenn der Tunnel in dem Moment nicht aktiv ist. Ansonsten sind die Nummern zu klein und werden nicht akzeptiert. Damit auch nach einem Neustart von OpenVPN die alten Sequenznummern erkannt werden, kennt OpenVPN eine Option replay-persist. Bei PSK fangen sie nicht bei 1 an, da der Timestamp dazukommt. Bei TLS vermute ich es. Ist aber unproblematisch. Gruß, Ralf
RE: RE: RE: RE: OpenVPN 2.Thread	tobias ( ---.emea.daimlerchrysler.com)	4 Sep 2008 15:45
Hallo Ralf, ich lese gerade das VPN illustrated Buch. In dem Kapitel über OpenVPN steht, dass es ein sog. OCC Protocol gibt. OCC steht für OpenVPN Configuration control. Jedenfalls werden diese auch über den Datenkanal gesendet. Z.b. werden darüber glaube ich die keepalives gesendet. weiter steht dort: During tunnel initialization, the nodes exchange configuartion information, using the occ protocol. as with the ping packets, these messages are delivered on the data channel and are distinguished from normal traffic by a prefix.. Was werden denn für Konfiguartionen ausgehandelt? Ich dachte bei dem PSK Modus senden die peers einfach los. In dem Buch sind auch noch die op codes aufgelistet wo von einem option string die Rede ist: request for peers option string. Nur steht nirgends was dieser string beinhaltet. Wissen sie das? Gibt es dann doch im PSK Modus eine Tunnelaushandlung? Viele Grüsse Tobias
RE: RE: RE: RE: RE: OpenVPN 2.Thread	tobias ( ---.emea.daimlerchrysler.com)	11 Sep 2008 21:44
Hallo, ich dachte dass bei OpenVPN im P2P Mode kein Kontrollkanal existiert. Jedoch steht jetzt bei der ping Direktive folgendes: --ping n Ping remote over the TCP/UDP control channel if no packets have been sent for at least n seconds (specify --ping on both peers to cause ping packets to be sent in both directions since OpenVPN ping packets are not echoed like IP ping packets). Also dass der Ping doch über den Kontrollkanal gesendet wird. In anderen Büchern stand jedoch, dass er über den Datenkanal mit speziellem op code gesendet wird. Das würde implizieren, dass es im p2p mode entweder keine pings gibt oder dass doch ein Kontrollkanal existiert. Außerdem steht hier eigentlich, dass es den Kontrollkanal nur im TLS Modus gibt: Packet opcode/key_id (8 bits) -- TLS only, not used in * pre-shared secret mode. * packet message type, a P_* constant (high 5 bits) * key_id (low 3 bits, see key_id in struct tls_session * below for comment). The key_id refers to an * already negotiated TLS session. OpenVPN seamlessly * renegotiates the TLS session by using a new key_id * for the new session. Overlap (controlled by * user definable parameters) between old and new TLS * sessions is allowed, providing a seamless transition * during tunnel operation. * * Payload (n bytes), which may be a P_CONTROL, P_ACK, or P_DATA * message. außerdem, falls der ping über den Kontrollkanal gehen würde, würde der Sender ja ein Ack erhalten. Aber es wird ja so gemacht, dass der andere auch pings senden muss Ich verzweifel bald. Könnten Sie mir bitte helfen. edit: ich habe mal die logs angeschaut. es ist ziemlich sicher, dass die pings nicht über den Kontrollkanal gehen: Thu Sep 11 22:45:52 2008 us=524710 client/192.168.0.13:32780 UDPv4 WRITE [53] to 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len=52 Thu Sep 11 22:46:01 2008 us=981965 client/192.168.0.13:32780 UDPv4 READ [53] from 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len=52 Thu Sep 11 22:46:03 2008 us=194010 client/192.168.0.13:32780 UDPv4 WRITE [53] to 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len=52 Thu Sep 11 22:46:12 2008 us=258704 client/192.168.0.13:32780 UDPv4 READ [53] from 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len=52 Thu Sep 11 22:46:13 2008 us=454170 client/192.168.0.13:32780 UDPv4 WRITE [53] to 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len=52 Thu Sep 11 22:46:22 2008 us=721029 client/192.168.0.13:32780 UDPv4 READ [53] from 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len=52 Thu Sep 11 22:46:23 2008 us=978021 client/192.168.0.13:32780 UDPv4 WRITE [53] to 192.168.0.13:32780: P_DATA_V1 kid=0 DATA len P_DATA_V1 sind Datenkanal Pakete und es findet auch keine Bestätigung statt. Wird der ping eigentlich auch verwendet um NAT Tabellen am Leben zu erhalten (analog zu den keepalives bei NAT-T in ipsec) noch ne frage zu ipsec: die nat-t keepalives haben nichts mit den dpd keepalives zu tun, oder? Grüsse Tobias

[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.