Umstieg Frame Relay auf VPN

[WebSorcerer]

Hallo,

ich habe nach Infos gesucht, die Frame Relay und VPN gegenüberstellen, besonders in Hinsicht auf die Sicherheit und die "Garantie" der Datenübertragung.

Einige Seiten habe ich im Internet gefunden, aber keine Gegenüberstellungen und eher allgemeine Infos. Suche da eher nach konkreten Vor- und Nachteilen der beiden Techniken.

Hintergrund ist folgender: Ein Kunde nutzt Frame Relay und wir wollen ein VPN aufbauen, auf Grund der Kostenersparnisse, aber der Kunde wird viel daran legen, das bestehende Frame Relay zu "verteitigen", weil ein VPN nicht sicher genug ist. Daher suche ich speziel Infos, um auf evtl. Argumente vom Kunden vorbereitet zu sein.

Besten Dank im Voraus.

[dummabua]

Hallo,

was meint er mit "nicht sicher genug"?

1. Meint er damit die Verfügbarkeit? (Welche aber meiner Meinung nach nicht ein VPN sondern eher ein Provider Problem sein dürfte)

2. oder meint er die "sichere" bzw. "unsichere" Verschlüsselung der Daten über das VPN? Das ist meiner Meinung nach haltlos, denn in Zeiten von 4096 Bit beim Schlüsseltausch etc... sollte das als sicher angesehen werden. Eine 100%tige Sicherheit gibt es nicht, aber das weiss er sicher, wenn er schon das know how hat, die "Unsicherheit" von VPN`s anzukreiden . Solange das ganze Rechnungssicher ist, sehe ich darin kein Problem. Welche Art von Daten will er denn übertragen?

cu

dummabua

PS:

http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci980439,00.html

http://www.tecchannel.de/telko/daten/402336/

http://www.sprintworldwide.com/english/contact/pdf/frame_relay_vs_ip_vpns.pdf

[cane]

FrameRelay hat ersteinmal nichts mit Verschlüsselung zu tun sondern ist eine Datenübertragungstechnik: http://de.wikipedia.org/wiki/Frame_Relay

Es kann sein das man die Pakete verschlüsseln kann - da müsstest Du mal im Inet suchen.

Ein VPN ist aber in meinen Augen noch sicherer da Du Algorithmen, Authentifizierungsverfahren und Schlüssellänge selbst wählen kannst - Von der Kostenersparnis ganz zu schweigen.

mfg

cane

[jomama]

http://global.mci.com/de/data/framerelay/

"Frame Relay ist ein vollständig privates Netzwerk, so dass Sie sich keinerlei Gedanken über Sicherheit oder Firewalls machen müssen."

Soviel zur Sicherheit.

Klar is Frame Relay sicherer. Aber auch erheblich teurer.

Du kannst dem netten Kunden ja mal vor Augen führen, wie lange ein Bruteforce Hack brauchen würde, um z.B. einen 1024 Bit Schlüssel, der mit nahezu jeder VPN Verbindung möglich ist, zu entschlüsseln, da gibt es im Netz diverse Berechnungen.

Größter Vorteil der VPN Verbindung ist halt der Kostenfaktor.

Besonders schnell ist das aber auch nicht, da man durch de vorherige Verschlüsselung und komprimierung der Pakete Zeit verliert.

[giftclown]

Durch welche Übertragungstechnik möchtest Du das Frame Relay ersetzen?

Und wie realisierst Du damit eine "garantierte Bandbreite"?

Und wie stellst Du sicher, daß Pakete zugestellt werden (kann Frame Relay das überhaupt?)? Es soll ja Protokolle geben, die verbindungslos arbeiten, meine ich mich dunkel zu erinnern.

Das sind so Knackpunkte, die ich als Kunde auch gerne beantwortet hätte

Kompromisslösung: IPSec als Payload im Frame Relay.

Grüße

giftclown

[cane]

Durch welche Übertragungstechnik möchtest Du das Frame Relay ersetzen?

Ich denke er will auf TCP/IP hinaus.

Und wie realisierst Du damit eine "garantierte Bandbreite"?

QoS kennt doch mittlerweile jeder DSL-Router

Es soll ja Protokolle geben, die verbindungslos arbeiten, meine ich mich dunkel zu erinnern.

Alles UDP-basierte zum Beispiel...

mfg

cane

[nic_power]

Hallo,

FR ist eine Technik die von vielen Kunden gerne verwendet wird, um geschlossene Netzes aufzubauen (VPN). D.h. man realisiert sein VPN direkt über FR, benötigt dazu aber keinerlei Verschlüsselung usw., da die Sicherheit auf dem Vertrauensverhältnis zwischen Provider und Kunden basiert (der selbe Ansatz wird auch bei MPLS basierten VPNs verwendet). Hinzu kommt, dass FR üblicherweise mit garantierten Bandbreiten verkauft wird.

Wenn Ihr jetzt FR mit einem VPN vergleichen sollt/wollt muss erstmal geklärt werden, von was für einem VPN die Rede ist. Möglichkeiten gibt es ja viele. Recht naheliegend wäre der Umstieg auf ein MPLS VPN, da hier die Vorteile von FR erhalten bleiben (wie beispielsweise QoS, etc.). Eine andere Möglichkeit wäre der Umstieg auf ein VPN über public Internet; aber in der Regel ist das nicht wirklich eine Alternative, wenn man die Qualitätsansprüche beibehalten möchte, die einem FR bietet.

Hinzu kommt der oben angesprochene Punkt der Verfügbarkeit. Bei FR oder auch einem MPLS VPN habe ich eine feste Schnittstelle zu meinem Provider. Bei Problemen im Netz kann ich mich an diesen wenden und es gibt feste Zeiträume in denen die Probleme beseitigt werden (müssen, da im SLA festgehalten). Bei einem VPN übers öffentliche Internet sieht das anders aus.

QoS kennt doch mittlerweile jeder DSL-Router

Das bringt aber nichts, wenn Das Netz kein QoS unterstützt. Und das ist in der Regel immer noch der Fall. D.h. wenn Du von FR auf ein VPN über ein öffentliches Netz umsteigst, geht dir dein QoS verloren, egal ob das dein Router kann oder nicht.

Es kann sein das man die Pakete verschlüsseln kann - da müsstest Du mal im Inet suchen.

Genauso gut/schlecht wie bei allen anderen Technologien auch. Üblicherweise wird man über ein FR Netzwerk TCP/IP fahren.

Nic

[cane]

Hallo,

FR ist eine Technik die von vielen Kunden gerne verwendet wird, um geschlossene Netzes aufzubauen (VPN). D.h. man realisiert sein VPN direkt über FR, benötigt dazu aber keinerlei Verschlüsselung usw., da die Sicherheit auf dem Vertrauensverhältnis zwischen Provider und Kunden basiert (der selbe Ansatz wird auch bei MPLS basierten VPNs verwendet).

Naja - bei vertraulichen Daten würd ich mich nicht drauf verlassen, bei einem Provider arbeiten mir zu viele Personen die trotzdem Zugriff auf die Daten haben. Ausserdem ist ja hinreichend bekannt wieviel momentan von ausländischen Organisationen in Wirtschaftsspionage investiert wird. Gerade im innovativen Bereich oder in der Forschung muss daher in meinen Augen zusätzlich verschlüsselt werden.

Wenn Ihr jetzt FR mit einem VPN vergleichen sollt/wollt muss erstmal geklärt werden, von was für einem VPN die Rede ist. Möglichkeiten gibt es ja viele.

Ich präferiere OpenVPN oder IPSEC.

Hinzu kommt der oben angesprochene Punkt der Verfügbarkeit. Bei FR oder auch einem MPLS VPN habe ich eine feste Schnittstelle zu meinem Provider. Bei Problemen im Netz kann ich mich an diesen wenden und es gibt feste Zeiträume in denen die Probleme beseitigt werden (müssen, da im SLA festgehalten). Bei einem VPN übers öffentliche Internet sieht das anders aus.

Man kann zwei DSL-Leitungen bei verschiedenen Providern mieten und bei nichtverfügbarkeit umschalten.

Das bringt aber nichts, wenn Das Netz kein QoS unterstützt. Und das ist in der Regel immer noch der Fall. D.h. wenn Du von FR auf ein VPN über ein öffentliches Netz umsteigst, geht dir dein QoS verloren, egal ob das dein Router kann oder nicht.

Das Netz muss kein QoS unterstützen - ich habe eine zugeteilte Bandbreite die meine Router aufteilen können. Wo soll das Problem sein?

mfg

cane

[nic_power]

Hallo,

Naja - bei vertraulichen Daten würd ich mich nicht drauf verlassen, bei einem Provider arbeiten mir zu viele Personen die trotzdem Zugriff auf die Daten haben.

Die Praxis sieht anders aus. Ein Grund für viele Firmen MPLS VPN zu verwenden ist der hohe Trustlevel zum Provider.

Man kann zwei DSL-Leitungen bei verschiedenen Providern mieten und bei nichtverfügbarkeit umschalten.

Ja, kann man. Hat aber nichts damit zu tun, dass man keinerlei Ansprechpartner hat, wenn irgendwo zwischen A und B ein Router runterfällt.

Das Netz muss kein QoS unterstützen - ich habe eine zugeteilte Bandbreite die meine Router aufteilen können. Wo soll das Problem sein?

Wenn Du Ende-zu-Ende QoS nutzen möchtest, dann muss das Netz dies auch unterstützen. Dein Router kann QoS bestenfalls für die lokal angeschlossenen Systeme zur Verfügung stellen (in dem beispielsweise Pakete von bestimmten Rechner bevorzugt behandelt werden); er kann die Pakete auch nach lokale QoS-Regeln taggen. Sowie die Pakete aber Deinen Router in Richtung Provider verlassen, greifen diese QoS Mechanismen mehr. Beim Einsatz von FR sichert Dir Dein Provider eine feste Bandbreite zu (und zwar zwischen den Standorten die Du miteinander verbindest). Jetzt braucht man sich nur noch zu überlegen, was passiert, wenn man FR durch das Internet ersetzt. Wie willst Du denn da eine Zusicherung bzgl. QoS machen?

Beispiel: Du hast zwei Standorte A und B miteinander verbunden. Deine Router sind mit 2MBit/s an das Internet angeschlossen. Wie stellst Du sicher, dass diese zwei MBit/s auf der kompletten Strecke zwischen A und B zur Verfügung stellen? Da hilft es Dir wenig, wenn die 2MBit/s lokal aufteilt werden. Von anderen Parametern wie Packet-Loss und Jitter mal abgesehen.

Nic

[cane]

Die Praxis sieht anders aus. Ein Grund für viele Firmen MPLS VPN zu verwenden ist der hohe Trustlevel zum Provider.

In Hochsicherheitsbereichen kommt bei den Unternehmen die ich kenne entweder linecrypt oder ein selbstimplementiertes VPN zum Einsatz. Einem Provider zu trauen kann sich dort niemand leisten. Naja - muss jeder für sich selbst entscheiden. Wenn ich bei einem provider arbeite und mir jemand eine hohe Summe dafür bietet mal eben ein paar Daten mitzuschneiden... Das kann bei VPN nicht passieren.

Ja, kann man. Hat aber nichts damit zu tun, dass man keinerlei Ansprechpartner hat, wenn irgendwo zwischen A und B ein Router runterfällt.

Ist ja egal da die Roputer dann automatisch von provider X auf Provider Y schalten.

Wenn Du Ende-zu-Ende QoS nutzen möchtest, dann muss das Netz dies auch unterstützen. Dein Router kann QoS bestenfalls für die lokal angeschlossenen Systeme zur Verfügung stellen (in dem beispielsweise Pakete von bestimmten Rechner bevorzugt behandelt werden); er kann die Pakete auch nach lokale QoS-Regeln taggen. Sowie die Pakete aber Deinen Router in Richtung Provider verlassen, greifen diese QoS Mechanismen mehr.

Sehe ich ein - bin aber der meinung das die Bandbreite auch bei DSL so gut wie nie abfällt, oder? ich habs zumindest noch nie erlebt... Und dann reicht das tagging der beiden Endpunkte ja wieder aus...

[nic_power]

Hallo,

Sehe ich ein - bin aber der meinung das die Bandbreite auch bei DSL so gut wie nie abfällt, oder? ich habs zumindest noch nie erlebt... Und dann reicht das tagging der beiden Endpunkte ja wieder aus...

Das Tagging reicht nicht aus, da es vom Provider nicht ausgewertet wird. Es bringt also absolut nichts!

Auch die Tatsache dass Deine DSL-Leitung nie abfällt bedeutet nicht, dass es keine Abfälle gibt. Die Bandbreite wird Dir immer nur bis zum Einwahlpunkt zugesichert (uns selbst da gibt es Einschränkungen).

Ich denke die hohe Kostenersparnis von zwei DSL-Leitungen rechtfertigt kein MLPS...

DSL ist schon aufgrund der Tatsache das es sich um eine asymmetrische Technologie handelt nicht mit einer FR Lösung vergleichbar. Mit welcher DSL-Lösung ohne QoS willst Du beispielsweise eine 2MBit/s mit QoS ersetzen?

Auch das Umschalten von DSL-Routern sichert Dir kein QoS zu.

Ich denke die hohe Kostenersparnis von zwei DSL-Leitungen rechtfertigt kein MLPS...

Es ist leider ein weit verbreiteter Irrglaube, das man einfach alles über den Preis ohne Rücksicht auf die Leistungen die damit verbunden sind als einziges "Qualitätsmerkmal" verwenden kann. Versuch mal eine IP-Telefonie-Lösung zwischen zwei Standorten mit QoS zuverlässig über eine VPN über Internet über DSL zu realisieren (insbesondere wenn vorher FR im Einsatz war).

Nic

[BadDog]

Hallo,

was meint er mit "nicht sicher genug"?

1. Meint er damit die Verfügbarkeit? (Welche aber meiner Meinung nach nicht ein VPN sondern eher ein Provider Problem sein dürfte)

2. oder meint er die "sichere" bzw. "unsichere" Verschlüsselung der Daten über das VPN? Das ist meiner Meinung nach haltlos, denn in Zeiten von 4096 Bit beim Schlüsseltausch etc... sollte das als sicher angesehen werden. Eine 100%tige Sicherheit gibt es nicht, aber das weiss er sicher, wenn er schon das know how hat, die "Unsicherheit" von VPN`s anzukreiden . Solange das ganze Rechnungssicher ist, sehe ich darin kein Problem. Welche Art von Daten will er denn übertragen?

cu

dummabua

PS:

http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci980439,00.html

http://www.tecchannel.de/telko/daten/402336/

http://www.sprintworldwide.com/english/contact/pdf/frame_relay_vs_ip_vpns.pdf

Die Bitlänge (allein) sagt aber noch nichts über die Sicherheit der Verschlüsselung aus.

Gruss

BadDog

[dummabua]

hi,

damit hast du natürlich recht, wenn der Algorithmus fehlerhaft ist, bringt der ganze Schlüssel (egal wie lang) nichts. Ich meine nur dass die meisten VPN Lösungen, egal ob Open Source oder nicht, mit etablierten Algorithmen arbeiten.

du

dummabua

[cane]

Das Tagging reicht nicht aus, da es vom Provider nicht ausgewertet wird. Es bringt also absolut nichts!

Auch die Tatsache dass Deine DSL-Leitung nie abfällt bedeutet nicht, dass es keine Abfälle gibt. Die Bandbreite wird Dir immer nur bis zum Einwahlpunkt zugesichert (uns selbst da gibt es Einschränkungen).

Sehe ich anders - wenn ich von meinen 2 Mbit 1 Mbit an beiden Routern für Protokoll XY freihalte stegt es nur für dieses Protokoll zur verfügung. Pakete anderer Protokolle landen in einer anderen Queue und müssen warten bis sie verarbeitet werden. Das Tagging braucht so nicht vom Provider ausgewertet zu werden da meine Router die Pakete je nach Tagging in die entsprechenden Queues schieben...

DSL ist schon aufgrund der Tatsache das es sich um eine asymmetrische Technologie handelt nicht mit einer FR Lösung vergleichbar. Mit welcher DSL-Lösung ohne QoS willst Du beispielsweise eine 2MBit/s mit QoS ersetzen?

DSL ist keine asymmetrische Technologie - es existiert auch SDSL, VDSL, HDSL und andere die eben nicht ADSL sind.

Auch das Umschalten von DSL-Routern sichert Dir kein QoS zu.

Richtig, aber zusätzlich zu den Queues des QoS habe ich dann eine Failover-Lösung und meine Verbindung bleibt bestehen auch wenn ein ganzer Provider "vom Netz geht". Man kann sogar beide leitungen gleichzeitig nutzen und im Falle eines failout eines Providers auf andere QoS-Queues umschalten die dann den gesammten verkehr auf die dann nur noch vorhandenen, halbe Bandbreite aufteilen.

Es ist leider ein weit verbreiteter Irrglaube, das man einfach alles über den Preis ohne Rücksicht auf die Leistungen die damit verbunden sind als einziges "Qualitätsmerkmal" verwenden kann. Versuch mal eine IP-Telefonie-Lösung zwischen zwei Standorten mit QoS zuverlässig über eine VPN über Internet über DSL zu realisieren (insbesondere wenn vorher FR im Einsatz war).

Kenne mehrere Projekte grosser Unternehmen die das so realisieren - es kommen bei Heimarbeitsplätzen meist Linksys WRT54G Router mit angepasster Firmware die QoS unterstützt zum Einsatz. Die VoIP Pakete werden so priorisiert. Zwischen kompletten Standorten wird meist mit Asteriks gearbeitet und das QoS über zwei Linux-Router realisiert...

Zur ganzen Thematik QoS und den verwendeten Implementierungen und Algorithmen waren vor einiger Zeit übrigens mehrere hervorragender Artikel im Linux-Magazin: http://www.linux-magazin.de/Artikel/ausgabe/2005/02

mfg

cane

[nic_power]

Hallo,

Sehe ich anders - wenn ich von meinen 2 Mbit 1 Mbit an beiden Routern für Protokoll XY freihalte stegt es nur für dieses Protokoll zur verfügung. Pakete anderer Protokolle landen in einer anderen Queue und müssen warten bis sie verarbeitet werden. Das Tagging braucht so nicht vom Provider ausgewertet zu werden da meine Router die Pakete je nach Tagging in die entsprechenden Queues schieben...

Irgendwie beschleicht mich das Gefühl, dass wir entweder aneinander vorbeireden oder Dir nicht klar ist, was QoS für ein Netz bedeutet. Es geht hier nicht darum, dass Du lokal Pakete markieren und in bestimmte Queues einsortieren kannst. Für QoS muss diese Markierung auch ausgewertet werden. Wie sicherst Du in Deinem Beispiel zu, dass die vom Router "freigehaltene" Bandbreite vom Netzwerk auch zugesichert werden kann, wenn Du keine Kontrolle über dieses Netz hast und keinerlei QoS vom Netz bereit gestellt wird? Zwischen Deinem Router und dem Egress-Punkt liegen in diesem Szenario noch die Router deines Providers, die die Pakete transportieren müssen. Kannst Du garantieren, dass auf dieser Strecke 1MBit/s für deine Pakete ("Protokoll A") zur Verfügung stehen?

DSL ist keine asymmetrische Technologie - es existiert auch SDSL, VDSL, HDSL und andere die eben nicht ADSL sind.

D.h. SDSL, VDSL und HDSL sind allesamt symmetrisch?! Oder wie ist die Aussage jetzt zu verstehen?

Man kann sogar beide leitungen gleichzeitig nutzen und im Falle eines failout eines Providers auf andere QoS-Queues umschalten die dann den gesammten verkehr auf die dann nur noch vorhandenen, halbe Bandbreite aufteilen.

Du beschreibst hier eine Failover Lösung bzw. eine redundante Anbindung. Wie siehts denn in dem Szenario aus, wenn Dein Netz 2MBit/s per "QoS" zugesichert bekommt (wobei 1MBit/s über Provider A und 1MBit/s über Provider B läuft) und einer der Provider ausfällt? Dann hast Du 2MBit/s Verkehr aber nur eine 1MBit/s Leitung.

Kenne mehrere Projekte grosser Unternehmen die das so realisieren - es kommen bei Heimarbeitsplätzen meist Linksys WRT54G Router mit angepasster Firmware die QoS unterstützt zum Einsatz. Die VoIP Pakete werden so priorisiert. Zwischen kompletten Standorten wird meist mit Asteriks gearbeitet und das QoS über zwei Linux-Router realisiert...

Das funktioniert nur, weil innerhalb des Backbones ausreichend Bandbreite zur Verfügung steht. Sowie dies nicht der Fall ist wirst Du keinerlei zufriedenstellende Qualität bei der Sprache erreichen, da QoS nicht (!) unterstützt wird und Pakete verworfen werden müssen. Da der Router nicht entscheiden kann, welche Pakete wichtig sind und welche nicht, nützt es überhaupt nichts, wenn Du irgendwann mal auf Deinem Router bestimmte Pakete bevorzugt behandelt hast.

Über welche der von Dir genannten zahlreichen DSL-Technologien sind die die Linksys Router ans Netz angeschlossen (providerseitig)?

Wenn Du dich für QoS und die Möglichkeiten/Voraussetzungen auf Netzwerkebene interessierst, solltest Du dich intensiver mit den DiffServ und IntServ Ansätzen der IETF beschäftigen. Dort läuft die Standardisierung in diesem Bereich.

Nic