Diskussion:IPsec

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „IPsec“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind.

Überschriften und Inhalt der Kapitel in Gleichklang bringen!

Ü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)

Keepalives Abschnitt

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)

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)

Veraltete Version

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)

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)

Integrität vs. Replay-Schutz

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) Bei einer Replay-Attacke werden Daten durch einen "man-in-the-middle" wiederholt gesendet - das hat nichts mit Integrität zu tun. Siehe: en.wikipedia.org/wiki/Replay_attack (nicht signierter Beitrag von 193.134.170.35 (Diskussion | Beiträge) 15:08, 19. Mai 2009 (CEST))

Inkonsistenz RFC

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)

Wenn ich RfC schon mal irgendwo gesehen hätte, könnte ich die Diskussion nachvollziehen. Das IETF benutzt RFC, auch innerhalb RFCs, also sollten wir uns dem konsequent/konsistent anschließen. --Kgfleischmann (Diskussion) 13:54, 16. Feb. 2013 (CET)

Sachlicher Fehler?

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)

Ein paar Worte zu Zertifikaten und PSK

• 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)

Main Mode + Aggressive Mode

Der Aggressive Mode ist afaik nicht korrekt beschrieben, bzw. die Unterschiede zwischen den beiden Modi. So heißt es: "Der Main Mode (dem Aggressive Mode vorzuziehen)[...]". Was ist, wenn die Gegenseite keine feste IP-Adresse hat? Die Anbindung von Clients mit dynamischer IP-Adresse ist afaik nur im Aggressive Mode möglich. Es klingt, als könnte man den Aggressive Mode ignorieren, da "[...]die Werte im Klartext übertragen[...]" werden.

Bedeutet das ich habe hier DAS inovative IPsec habe weil meine dynamischen DialUP Clients sich im Main Mode connecten?

Sven --89.53.112.104 13:22, 10. Aug. 2008 (CEST)

Wenn Zertifikate verwendet werden, ist auch mit dynamischer IP der Main Modus möglich

IPsec Gateways lehnen Dialup Clients mit dynamischer also im voraus unbekannter IP ab, weil sonst die Identität nicht klar ist. Rein von den Algorithmen müssten sie das aber nicht tun und somit würde der Main Mode auch mit Preshared Keys und dynamischer IP funktionieren. Ob diese Verhaltenswiese eine Verletzungs von IPsec darstellt ist nun die Frage ...

Anzahl der Nachrichten im Main Mode

So weit ich weiss sind es 6 Nachrichten im Main Mode, nicht 5. Siehe hierzu

http://net.cs.uni-tuebingen.de/fileadmin/RI/teaching/seminar_iit/ss03/ike.pdf http://www.nta-monitor.com/wiki/images/d/df/Ike-normal-main-mode-exchange.png

Aber das Bild im Artikel

http://upload.wikimedia.org/wikipedia/de/thumb/b/b5/Ipsec_ikev1.png/180px-Ipsec_ikev1.png

sagt es sind nur 5. Werde noch mal in der RFC nachschauen, aber auch mein IPSec Buch sagt es sind 6.

Wider die unbeabsichtigte Vertreibung interessierter Leser!

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) Sigrid

Keepalives

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)

Liste mit Implementierungen?

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)

Anwendung in der Praxis

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)

Praktische Anwendung

Kann mich dem Hinweis auf den Bezug zur Praxis nur anschließen, gerade bei so einem komplizierten Thema. Bevor ihr die internen Details ausbreitet fände ich persönlich es wünschenswert ein Art Zusammenfassung zu erhalten. Am besten so geschrieben das ein, zwei Abschnitte auch nicht Spezialisten verständlich ist (sein kann : ). --(nicht signierter Beitrag von 88.217.39.86 (Diskussion) 00:26, 18. Jun. 2008‎)

Aktueller Stand der Beschreibung des Praxisbezugs

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)

Wieso Konjunktiv?

„IPsec (Kurzform für Internet Protocol Security) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie das Internet ermöglichen soll.“

Wieso soll? IPsec ermöglicht eine gesicherte Kommunikation. Genau dafür ist es da und genau dafür wird es auch eingesetzt. --RokerHRO (Diskussion) 15:46, 24. Nov. 2012 (CET)

Ich kann dem Konjunktiv was abgewinnen.

Alle Techniken der IT-Sicherheit waren immer nur begrenzt wirksam, weil sich immer ein Weg fand, um in der Mitte, am Anfang oder am Ende der Leitung entweder direkt einzubrechen oder die bombensichere Festung zu umgehen. Und sei es, auf der menschlichen Ebene anzusetzen.

VG --PerfektesChaos 16:35, 24. Nov. 2012 (CET)

Die Sicherung der IP-Kommunikation klappt in der Praxis aber ausreichend gut. Auch ein abgeschlossenes Auto (=gesichert) kann aufgebrochen und geklaut werden. Trotzdem wird niemand sagen: "Ein Türschloss soll das Auto/das Haus absichern", sondern "Ein Tüschloss sichert das Auto/Haus gegen unerwünschte Besucher ab".

Und "gesichert" ist ja nicht gleich "100%ig sicher". Das ist etwa wie beim Bund, wo ein "gereinigtes" (="man hat durch Putzen den gröbsten Dreck entfernt") Gewehr nicht "sauber" (="da ist gar kein Dreck mehr") ist.

Der Konjunktiv klingt unnötig abschwächend, etwa: "War ne tolle Idee, funktioniert in der Praxis aber gar nicht". Und das ist ja wohl falsch.

--RokerHRO (Diskussion) 09:09, 25. Nov. 2012 (CET)

AH+ ESP-Header zu lange

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))

Protokoll Layer Bild rechts irreführend

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))