Diskussion:IPsec

message: Überschriften der Kapitel stimmen in diesem Beitrag nicht mit dem Inhalt überein, was es sehr erschwert, den Artikel zu verstehen.
Beispiel: Das Kapitel "Verbindungsaufbau" beschreibt nicht den Verbindungsaufbau, sondern zunächst erstmal Datenbanken, in denen Konfigurationen und Daten vorgehalten werden.Im ersten Satz steht dann auch folgerichtig "IpSec verwaltet Verbindungen".
Unter Verbindungsaufbau würde wohl die weit überwiegende Zahl der Leser erst einmal einen definierten Ablauf verstehen, durch den eine Verbindung hergestellt wird. Ein solcher Ablauf wird aber erst an ganz anderer Stelle ansatzweise beschrieben.
Dann wird gleich mal ein Begriff "die zu erstellenden SAs" ververwendet, der noch gar nicht erklärt ist oder durch Referenzierung erklärbar würde. 
Dieser Artikel ist nach wie vor wirr und unverständlich.
--ADie 11:12, 2. Apr. 2009 (CEST)
thread_title:  Überschriften und Inhalt der Kapitel in Gleichklang bringen! 

message: Im Keepalives Abschnitt wird mehrfach CheckPoint erwaehnt.
Offenbar handelt es sich um eine bestimmte Implementierung eines Herstellers.
Bitte klarstellen. 
Gut waere eine Tabelle populaerer Implementierungen und deren Features.
--78.53.188.8 19:56, 14. Mai 2008 (CEST)
replies: text: Die Erwähnungen von "CheckPoint" sind anscheinend entfernt worden, aber der Ausdruck "keepalives" selbst ist Cisco-Jargon für "Dead Peer Detection" und IKEv2 verwendet inzwischen einen anderen Mechanismus namens "liveness checks". --2001:638:401:102:226:55FF:FE4F:9BB6 15:45, 5. Feb. 2013 (CET)
thread_title:  Keepalives Abschnitt 

message: Der Artikel beschreibt überwiegend die alte IPsec-Version. Auch, wenn korrekt erwähnt wird, daß z.B. RFC 2401 durch RFC 4301 abgelöst wurde, tut der Rest des Artikels so, als sei die vorherige Version noch aktuell. Schaut man sich die Versionsgeschichte des Artikels an, gewinnt man den Eindruck, daß die aktuelle IPsec-Version hier nicht erwünscht ist -- vielleicht weiß jemand eine Lösung, wie man beide Versionen darstellen kann, ohne dabei die Übersichtlichkeit des Artikels zu gefährden? --87.178.106.50 23:28, 19. Mai 2007 (CEST)
replies: text: Nochmal: Die alte Version wird breit eingesetzt und ist daher relevant. Deine(?) Aenderung damals hat die Informationen zur alten Version weitgehend entfernt. Das ist nicht akzeptabel. Daher an dieser Stelle nochmal die Aufforderung an Dich: Bitte ergaenze (nicht ersetze) den Artikel. Danke! -- Wikifh 09:41, 21. Mai 2007 (CEST)
thread_title:  Veraltete Version 

message: Zieht die Integrität (wie im Wiki-Artikel beschrieben) nicht einen Replay-Schutz nach sich? Man könnte denken, es gebe neben den 3 genannten Schutzzielen, noch den Schutz vor Replay-Attacken.
D.h. sollte es nicht besser heißen: "Im Speziellen soll es also auch vor so genannten Replay-Angriffen bzw. einer Replay-Attacke schützen [...]" statt
"Daneben soll es vor so genannten Replay-Angriffen bzw. einer Replay-Attacke schützen [...]"  87.185.211.57 21:30, 8. Mai 2007 (CEST)
thread_title:  Integrität vs. Replay-Schutz 

message: Ich finde die Inkonsistenz von RfC vs. RFC innerhalb der Wikipedia nicht schön.
Vom englischen Original ("Request for Comments") klingt es nach RfC, allerdings findet man im Netz (und in de- und en-Wikipedia) nur "RFC" erklärt.
Also muss entweder alles in der Wikipedia auf "RfC" umgestellt werden (oder zumindest eine Weiterleitung eingerichtet werden) oder dieser Artikel sollte konsequenterweise auch RFC verwenden.
kklklk
Die einzige Schreibweise, die mir in meinem Studium begegnet ist: RFC
--Mheinrich (Diskussion) 13:02, 16. Feb. 2013 (CET)
thread_title: Inkonsistenz RFC

message: ESP: "Im Unterschied zu AH wird der Kopf des IP-Paketes nicht mit berücksichtigt."
Wenn ESP im Tunnel-Modus läuft wird sehr wohl der Kopf vom IP Paket berücksichtig, oder?!
Hier sieht das jedenfalls so aus.
Ja, aber nur das Header des gekapselten Paketes, der äußere nicht.
(Vorstehender nicht signierter Beitrag stammt von 213.39.132.157 (Diskussion • Beiträge) 12:27, 13. Jul 2006)
ISAKMP: "ISAKMP, auch als IKE bezeichnet"
Diese Behauptung ist schlichtweg falsch. Während ISAKMP ein grundsätzliches Vorgehen zum Schlüsseltausch darstellt, ist IKE eine konkrete Implementierung. (vgl: Schäfer: Netzsicherheit)
"Masquerading-Firewall": 
Gemeint ist NAT? Ich bin es inzwischen ja schon gewohnt, von Hardware-Herstellern NAT als 
Firewall verkauft zu bekommen, aber hier in einem sicherheits-bezogenem Artikel...? 
Update: Ich bin mir auch nicht ganz sicher, ob der Schreiber dieses Absatzes 
unter einer DMZ das versteht, was darunter üblicherweise verstanden wird. IMHO 
gehört der Absatz ganz gestrichen, bzw. er muss neu formuliert werden. --128.7.3.55 10:30, 3. Feb. 2009 (CET)
thread_title:  Sachlicher Fehler? 

message: * Zertifikate kann man selbst erzeugen (z.B. mit openssl), muss sie nicht von eTrust o.ae. kaufen. Auch eine Root-CA/PKI kann man selbst betreiben - das duerfte sich erst ab ca. 1000 Endpunkten lohnen. Meist werden daher self-signed Zertifikate verwendet.
* Bei PSK muessen nicht alle Endpunkte neu konfiguriert werden, wenn ein Freund nichtmehr vertrauenswuerdig ist. Das passiert nur, wenn fuer alle Verbindungen der selbe Key verwendet wird - das muss (und soll) man aber nicht tun. 
=== pro Zertifikat ===
* Software-Clients lassen sich mit Zertifikaten im p12-Format leichter konfigurieren lassen als von Hand mit PSK. 
* Auf einem Tunnelendpunkt koennen nicht mehrere Tunnel zu Gegenstellen mit unbekannter (dynamischer) IP und mit verschiedenen PSKs verwendet werden. Das duerfte der Hauptgrund sein, PSK nicht einzusetzen. Als Abhilfe muss man nicht unbedingt Zertifikate einsetzen, man kann auch einfach den Tunnelendpunkten festen IPs verpassen.
Das stimmt so nicht! Es funktioniert nur dann nicht, wenn alle Systeme auch die gleiche Identity nutzen.
=== contra Cert ===
* In der Praxis werden haeufig keine Zertifikate eingesetzt, da dies bei ettlichen Endgeraeten Probleme bereitet (Erzeugung oder Import, z.B. wg. Case-sensitivity der Distinguished Names, ...). 
* Die Kunden scheuen die Kosten der offiziellen Zertifikate (eTrust und Co.)
* Die Provider scheuen Kosten/Aufwand, eine eigene RootCA zu betreiben
Comments? -- Wikifh 00:38, 23. Dez 2005 (CET)
thread_title:  Ein paar Worte zu Zertifikaten und PSK 

message: * In der Praxis werden haeufig keine Zertifikate eingesetzt, da dies bei ettlichen Endgeraeten Probleme bereitet (Erzeugung oder Import, z.B. wg. Case-sensitivity der Distinguished Names, ...). 
* Die Kunden scheuen die Kosten der offiziellen Zertifikate (eTrust und Co.)
* Die Provider scheuen Kosten/Aufwand, eine eigene RootCA zu betreiben
Comments? -- Wikifh 00:38, 23. Dez 2005 (CET)
thread_title:  contra Cert 

message: Mir fehlt hier noch ein wenig der rote Faden. Im Detail würde ich gerne etwas zum "zustandslosen" bzw. "stateful" Zustand erfahren - ein wahres Wortungeheuer, vielleicht nur noch übertroffen von der "verbindungslosen" Verbindung im Zusammenhang mit UDP. Weiters ist mir unklar geblieben, was "security associations" sind und wie das mit der Verschlüsselung, die anscheinend symmetrisch sein kann, genau ist. Gibt es auch asymmetrische Verschlüsselung hier?
Meine Kritik hat keinesfalls die Absicht, die Autoren zu diskreditieren - schließlich ist eine große Menge an Details ausgebreitet worden, deren Zusammenstellung sicher mühsam war. Jetzt fehlt nur noch die Krönung des Ganzen, der oben eingeforderte rote Faden. Danke!
--82.139.211.25 21:24, 5. Mär. 2009 (CET)
thread_title:  Wider die unbeabsichtigte Vertreibung interessierter Leser! 

message: :Keepalives sind nur bedingt bidirektional, da es aufgrund mangelhafter Asymmetrie im IP-Header häufig zu Kollisionen im ISAKMP-Protokoll kommt.
Der Satz ist irgendwie unverständlich. Symmetrie ist schlecht? Was genau ist das Problem? ISAKMP-Protokoll ist ein Pleonasmus. --Poc 16:31, 24. Jun. 2009 (CEST)
thread_title:  Keepalives 

message: So eine Liste wäre nicht schlecht, ich bin hier gelandet weil ich mehr darüber wissen wollte und eine Implementierung für LINUX suche. Im englischen Teil ist eine Liste vorhanden und es wurde schon mal 2007 danach gefragt (siehe oben), spricht etwas dagegen im deutschen Teil eine zu haben?
--84.46.37.96 01:15, 1. Aug. 2009 (CEST)
thread_title:  Liste mit Implementierungen? 

message: Was im Artikel irgendwie etwas zu kurz kommt: Wie gestaltet sich die Anwendung von IPsec in der Praxis?
Also das Ganze verschüsselt alles oberhalb von Ebene 3, aber funktioniert das automatisch?
Worauf ich hinaus will: Wenn eine Anwendung sagt: Ich will eine TCP-Verbindung nach Rechner X, Port 110 (z.B.), wird dann automatisch mit X ein Schlüsselaustausch initiert und die Verbindung verschlüsselt, oder muß von Seiten der Anwendung her ersteinmal dafür gesorgt werden, dass Verschlüsselung verwendet wird?
(Vorstehender nicht signierter Beitrag stammt von 212.201.78.97 (Diskussion • Beiträge) 22:49, 13. Jul 2006)
Es funktioniert in der Praxis vollautomatisch und für die Anwendung transparent.
Probleme gibt es ab und an wenn die IPsec-Verbindung erst noch initiiert werden muss und die Timeout-Werte in der Applikation zu knapp bemessen sind.
:Ich würde es (im Artikel) gern _noch_ praktischer lesen: Welche Software für mein OS (Windows, Linux, MacOS) gibt es? Was muss man tun, um damit zB VoIP verschlüsselt zu betreiben? ( s.a. heise-Diskussion hierzu). --195.33.166.40 19:16, 11. Jan. 2007 (CET)
thread_title:  Anwendung in der Praxis 

message: Leider wird nach wie vor aus dem Artikel nach meiner Meinung unzureichend deutlich, für welche Anwendungsfälle IPsec eigentlich konzipiert ist - zum Beispiel im Vergleich zum aus dem Web wesentlich bekannteren HTTPS (TLS). Ich habe deswegen den dazu passenden Abschnitt hier noch mal an die aktuellste Stelle gesetzt und setze auch noch einen Überarbeitungsbaustein.--Hamburger 15:38, 15. Nov. 2011 (CET)
thread_title: Aktueller Stand der Beschreibung des Praxisbezugs

message: Gem. RFC sind die Header nur 32 bit lange (z.B. f. ESP: https://tools.ietf.org/rfc/rfc4303.txt suche nach Data* )!!!! und nicht 38 bit! (nicht signierter Beitrag von Laura huber (Diskussion | Beiträge) 14:44, 1. Apr. 2014 (CEST)
thread_title:  AH+ ESP-Header zu lange 

message: Das Bild rechts oben suggeriert, dass IPsec eigenständig zu IPv4 ist. Besser fände ich die Darstellung wie bei icmp, die klar macht, dass es zu Layer 3 gehört, aber direkt auf IPv4 aufsetzt. (nicht signierter Beitrag von 178.192.33.196 (Diskussion) 06:25, 25. Jul 2015 (CEST)
thread_title:  Protokoll Layer Bild rechts irreführend