Bei der Telekom ist das dann - zumindest nach dem Zitat - eine Entscheidung auf der Basis der eigenen Ressourcen (falls sich das auf "outgoing keep-alives" wie beim "qualify" im Asterisk beziehen sollte). Das Vorgehen der Telekom mag zwar dann (als immer noch größter Provider in D) etwas mit der "normativen Kraft des Faktischen" zu tun haben (wenn man das tatsächlich auch für UDP-Registrierungen machen sollte und EXAKT um solche (UDP over IPv6) geht es nach den Angaben in #1 ja), ist aber dennoch bei UDP (ich wiederhole das von oben jetzt nicht noch einmal) ein Verstoß gegen das SIP-Protokoll ... auch den Hinweis, daß sich AVM wohl nicht an diese "Technische Richtlinie" (ich nehme jedenfalls mal an, daß das aus einer TR stammt - gibt's keinen öffentlich erreichbaren Link, damit man selbst nachlesen kann?) hält (wenn das nicht ohnehin für den SIP-Trunk der Telekom noch etwas anderes ist, als für "normale" Registrierungen), denn dort sendet man (nachprüfbar) eben kein CRLF, sondern binäre Nullen - auch hier wieder "per UDP", WEIL das eben auch wieder einen Unterschied macht (komme ich gleich noch drauf).
Im Extremfall könnte man das "Beschäftigen" eines SIP-Parsers (der bei einer "leeren" UDP-Nachricht ja trotzdem erst mal feststellen muß, daß diese NICHT den Protokollvorgaben entspricht) sogar als mutwilligen Ressourcenverbrauch und als "Angriff" bewerten - zumal die einzige "verläßliche" Angabe, wer da mit dem Parser eigentlich gerade Haschmich spielt, die Absenderadresse im UDP-Paket wäre, die man bekanntlich auch leicht fälschen kann - daher ist das für UDP (und ich erinnere gerne auch noch mal daran, daß es hier von Beginn an nur um UDP ging, falls man nicht die Angaben von
@81Tom in #1 wieder komplett in Zweifel ziehen will und dafür gibt es in meinen Augen KEINEN Grund) eben auch NICHT SPEZIFIZIERT, daß man mit "ping" und "pong" (die Antwort - auf die ja der zitierte Telekom-Text auch nicht weiter eingeht - spielt für "echtes" Keepalive ja auch noch eine Rolle (sonst soll die Verbindung ja als "failed" angesehen werden) und so muß der Client auf der anderen Seite das dann auch noch implementieren - obwohl er nach dem SIP-RFC auch nicht zur Benutzung von Keepalive-Mechanismen "verpflichtet" ist ... wenn das jemand als Provider "fordert", dann vielleicht wieder wegen der erwähnten "normativen Kraft", aber nicht basierend auf RFCs, zumindest nicht nach RFC 3261.
Und das bringt mich dann wieder zu der Feststellung, daß im zitierten Text aus der TR explizit auch wieder von TCP die Rede ist (ob der Kontext stimmt, kann man eben ohne Quellenangabe nicht erkennen), wo es andere Mechnismen gegen solche "Angriffe" gibt ... es wäre jetzt spannend zu wissen, ob diese "Empfehlung" (man sollte ein "sollte vermieden werden" auch nicht mit einem "darf nicht" verwechseln) auch für UDP gilt (RFC 5626 sagt: nein). Auch ist es natürlich der Telekom überlassen, was sie gerne (von ihren Kunden) als "keep-alive" sehen MÖCHTE ... wenn deren Parser sich an der - ich hoffe mal, auch von Dir (
@chrsto) nicht bestrittenen - Verletzung des Protokolls nicht stören, ist das deren Problem.
Denn gleichzeitig steht da eben auch nichts davon, daß die Telekom ihrerseits selbst solche Pakete als Keepalive SENDEN würde (erst recht nicht abseits von TCP), wie es hier ja für sipgate behauptet wurde ... was angesichts der "Unkenntnis" der Telekom-Registrare, wie sich die jeweiligen Implementierungen der SIP-Stacks auf der Kundenseite bei einer solchen Verletzung des Protokolls verhalten würden, sicherlich auch besser ist ... und auch hier noch mal: Bei UDP könnte man - wenn ein Parser/SIP-Stack darauf allergisch ist und "zumacht", auch wieder wunderbar DoS-Angriffe auf einen SIP-"Anschluß" fahren - bei TCP ist das Problem automatisch geringer, weil nur der richtige Absender sein Paket durch den vorgelagerten TCP-Stack bis zum SIP-Parser kriegen sollte. Wenn die Telekom-Implementierung ihrerseits mit "pong" auf ein "ping" von einem Client reagieren sollte, ist das natürlich in Ordnung - zumindest innerhalb einer TCP-Verbindung und auch dann ist so eine Antwort (zumindest nach RFC 5626) eben NICHT 2x CRLF, sondern das "pong" ist nur noch als einmal CRLF spezifiziert.
Man sollte eben auch WISSEN, daß in RFC 5626 das Senden von 2x CRLF wieder GANZ EXPLIZIT auf "connection-oriented transports" beschränkt wird - da ist dann auch wieder der "threat"-Aspekt nicht weiter zu berücksichtigen:
https://datatracker.ietf.org/doc/html/rfc5626#section-3.5.1 und damit sind wir wieder beim SIP-RFC, wo zwar auch geregelt ist (
https://datatracker.ietf.org/doc/html/rfc3261#section-7.5):
Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line.
- aber da ist auch nicht genau festgelegt, wie damit umzugehen wäre, wenn es dann gar keine "start-line" danach mehr gibt. Es hat ja auch seine Gründe (man kann sich ja auch noch mal die "Security considerations" zum SIP-Protokoll ansehen), warum das als Technik NUR für TCP (oder STCP) zugelassen ist - bei UDP kann ein Angreifer den Registrar einfach mit Paketen mit gefälschter Absenderadresse "flooden" und wenn der dann (oder ein vorgelagertes IPS/IDS) den vermeintlichen Absender aussperrt, ist das exakt ein Beispiel für "tearing down sessions" - auch ohne dafür eine BYE-Message zu brauchen. Bei TCP-Verbindungen kann man sich (in gewissen Grenzen) zumindest sicher sein, daß man die richtige Adresse "aussperrt".
Ich habe ja nicht umsonst auch mehrmals versucht, immer wieder "nachzufassen" und eine "echte Antwort" zu provozieren, in der dann auch GENAU enthalten sein sollte, was da wo und von wem gesendet wird und welche "Rahmenbedingungen" dafür zutreffen müssen. Angesichts vergangener Versuche, mich von der Seite "anzupflaumen" (vielleicht hier noch ein Beispiel:
https://www.ip-phone-forum.de/threa...liche-sicherheitsprobleme.307255/post-2376841), fühle ich mich eben (erst recht dann, wenn so eine Antwort direkt im Widerspruch zu meiner davor steht) manchmal versucht (aber nur selten, üblicherweise versinkt das im Rauschen), meinerseits zu "challengen", was da tatsächlich an "Wissen" hinter solchen Angaben steckt ... und ich finde die "Fragen", die ich dann meinerseits aufgeworfen habe hinsichtlich der Thesen, jetzt nicht sooo abwegig und bin sogar der Ansicht, sie hätten beim Versuch einer korrekten Antwort auch "auf die richtige Spur" geführt - höchstens noch meine Annahme, ich würde tatsächlich mal eine "ernsthafte" Antwort mit Begründungen und Quellenangaben erhalten, war da offensichtlich erneut "zu naiv".
Ja, ich halte Portweiterleitungen bei VoIP für falsch.
Nehme ich zur Kenntnis, aber mit welcher Begründung? Denn jetzt stehe ja auch ich mit meiner Ansicht, daß es - in einigen Szenarien, ich habe das ja auch nicht pauschal als Lösung für
jeden Fall und alles "beworben" - auch Fälle gibt, wo das notwendig sein kann (wenn es denn machbar ist), nicht alleine und falls es noch einen Link braucht:
https://www.voip-info.org/nat-and-voip/.
Wenn es keine Option GIBT, einen Keepalive-Mechanismus nach RFC5626 zu aktivieren (und noch mal: Das ist eine optionale(!) Erweiterung des Protokolls und NICHT Bestandteil von RFC3261.), dann bleibt am Ende gar nichts anderes - wie gesagt, wenn die restliche Technik das auch noch unterstützt.
Hinzu kommt noch, daß auch die Keepalive-Mechanismen nach RFC5626 eigentlich noch keine "reliable connection" garantieren - denn in der Zeit, die zwischen zwei Keepalive-Aktionen vergeht, kann die Verbindung aus vielen anderen Gründen auch noch abreißen (nur ein UA, der auch auf dem Edge-Router läuft, würde das direkt "erfahren" können) und daher ergeben sich da dann auch immer noch "Lücken" in der Erreichbarkeit des SIP-UA. Dagegen spezifiziert dann RFC5626 als eine Option die Verwendung von MEHREREN Registrierungen ... ich weiß selbst auch nicht, welche Provider (in D) da tatsächlich so weit mit dem RFC konform sind, daß sie auch das klaglos akzeptieren.
Was wurden denn hier bisher für "Postulate" niedergeschrieben, denen ich nicht folgen will (ich nehme jetzt nur mal die letzten)?
- Sipgate müsste ein Keep-Alive machen, also dürfte das Problem nicht auftreten.
- PhonerLite müsste ein Keep-Alive machen, also dürfte das Problem nicht auftreten.
- PhonerLite bietet keine Einstell-Möglichkeit, also müsste es das egal bei welchen IP-Version/Router tun.
- Wir wissen nicht einmal über welche IP-Version es bei 81Tom passiert.
Gehen wir das doch mal der Reihe nach durch ... wo steht denn, daß sipgate das machen MÜSSE? Die einzige "Quelle" dafür ist ein acht Jahre alter Blog-Eintrag bei sipgate, daß man das 2014 so machen wollte oder gemacht hat. Wie genau, steht da auch nicht, die 2x CRLF sind ja nicht im Blog zu lesen - und auch kein Bezug auf RFC5626, wobei dessen Spezifikation ja ohnehin NICHT für ein Keepalive seitens des Registrars gilt. Dort ist zwar auch desöfteren nur von "UA" (und nicht explizit von "UAC") die Rede, aber ein Registrar ist dort auch kein "UAS", sondern eben "registrar". Und dann wäre da noch eine vermeintliche (aber "unbelegte" - auch das hätte ja schnell wieder "zeigen" können, ob das nun UDP oder TCP war) Beobachtung, daß es irgendwann mal so gewesen sein soll.
Der Registrar kann zwar einen UA zu Keepalives auffordern (dafür gibt es den "Flow-Timer"-Header:
https://datatracker.ietf.org/doc/html/rfc5626#section-10 und der gilt auch für beide Keepalive-Techniken in RFC5626), aber er selbst sendet (jedenfalls nach der Spezifikation) nicht aktiv irgendwelche Keepalives aus. Wenn das sipgate also tatsächlich 2014 selbst so gemacht haben SOLLTE (ich glaub's ja immer noch nicht, erst recht nicht per UDP), dann ist das auch durch RFC 5626 "nicht gedeckt" ... aber ich lasse mich ja mit entsprechender Quellenangabe auch vom Gegenteil überzeugen - RFC5626 ist ja auch schon von 2009 und war 2014 "in Kraft".
Aber auch die "Beobachtung", daß sipgate da 2x CRLF senden würde, ist ja "alt" (irgendwo steht noch, daß das mindestens ein Jahr her ist, seitdem das "geprüft" wurde) und dennoch soll dann irgendwie aus einem Mitschnitt zwischen Router und SIP-Client (also auf der LAN-Seite der - vermuteten - IPv6-Firewall) erkannt werden, wo da ein Problem besteht, wenn diese Pakete "nicht ankommen"? Wie ich oben gezeigt habe, stimmt - zumindest in meiner Konstellation, die mit der in #1 beschriebenen übereinstimmt - schon die Annahme nicht, daß seitens sipgate irgendwelche "keep-alives" gesendet werden müßten ... was soll dann deren Fehlen in dem "vorgeschlagenen" WireShark-Mitschnitt am Ende beweisen?
Insofern hat sich auch Punkt 4 erledigt, denn es steht ja explizit in #1, daß nur IPv6 aktiviert ist ... angesichts der "vollständigen" Aufzählung aller anderen Checkboxen, kann man sicherlich auch getrost ausschließen, daß da "Dual-Stack" ebenfalls gewählt wurde und dann bleibt bei aktiviertem "IPv6" nicht mehr so viel übrig als Alternative.
Oder, wenn man das auch noch in Zweifel ziehen will, man kann ebenso gut auch eine komplette Unterbrechung der Internet-Verbindung als "Problem" postulieren, die dann eingehende Anrufe blockiert ... nein, stimmt nicht ganz, denn der SIP-Client auf dem Smartphone signalisiert den ja noch - wenn der dann auch in demselben (W)LAN ist ... und so weiter - DAS ist es dann, was ICH "vom Hölzchen aufs Stöckchen" nennen würde, wenn man anstelle der wahrscheinlichsten Ursachen eines Problems (siehe "Occam's razor"), erst mal klären will, ob die Elektronen vom Anbieter beim Stromfluß auch den richtigen Spin haben.
Punkt 2 - Phoner Lite "müsste" ein Keepalive senden? Ja, aber ein solches Keepalive ist eben - wenn es der Spezifikation in RFC5626 entsprechen soll - nicht automatisch auch "2x CRLF" - erst recht nicht, wenn hier UDP verwendet wird (und erneut: Exakt das steht so in #1.). Aus dem verlinkten Post im Phoner-Forum geht jedenfalls auch wieder nicht hervor, was da tatsächlich geschieht - hier wäre dann vielleicht wieder eine Überlegung (beim Leser bzw. bei demjenigen, der das als "Quelle" nutzen wollte) angebracht gewesen, daß RFC5626 erst 2009 festgeklopft wurde, obwohl der Draft dafür schon aus 2005 stammt - aber auch mein "Hinweis" auf das Alter des Beitrags hat ja offenbar nichts gebracht, zumindest nichts "Sichtbares" in der Reaktion.
Obendrein beschreibt der Autor von Phoner da ja auch noch explizit, daß das nur aktiviert wird, wenn ein NAT-Gateway im Verbindungsweg erkannt wird. Wo das NAT hier beim IPv6 sein soll, ist immer noch unbeantwortet (komme ich aber auch wieder später drauf zurück).
Auch Punkt 3 ist "zweideutig" ... am Ende läßt der sich sogar als "Forderung" an den Autoren von Phoner Lite interpretieren, der solle doch bitte gefälligst sein Programm entsprechend ändern, falls RFC5626 (noch) nicht unterstützt wird. Ich persönlich würde hier ja erst mal hingehen und mir das Programm und seine Dokumentation ansehen - man erlebt manche Überraschung. Ich habe jedenfalls auf der Suche nach einer Beschreibung, was der STUN-Server in Phoner Lite denn nun genau macht (wenn das nach dem Eintragen eines Namens jetzt funktioniert, macht mich das neugierig), auch noch das hier gefunden:
https://lite.phoner.de/config_de.htm - ich zitiere mal:
Selbst die Verwendung von STUN garantiert jedoch nicht immer eine reibungslose Kommunikation. Restriktive
Firewalls muss man im Fehlerfall also so konfigurieren, dass auf den
UDP -Ports 5060 und 5062 eine
Portweiterleitung zu dem PC mit PhonerLite erfolgt.
Nun bezieht sich das zwar (vermutlich) auch eher auf IPv4, wobei es bei IPv6 (und wieder: sofern der Router es zuläßt) auch verwendet werden kann ... aber ich finde es auch reichlich "kühn", wenn ein Dritter (obendrein ohne den Willen oder vielleicht ja doch auch ohne die Fähigkeit, das dann entsprechend zu begründen) auch noch mit dem Autoren einer Software "streiten" will, was denn nun das "richtige Vorgehen" wäre. Wenn Phoner Lite tatsächlich nicht die Keepalives nach RFC 5626 implementiert haben SOLLTE (wie geschrieben, komme ich später noch mal drauf zurück), dann "müßte" das Programm auch keine Keepalives senden. Der Webseite kann man leider nicht entnehmen, was da konkret an Standards unterstützt wird - oder ich habe das auch nicht finden können.
Aber schon die Beschäftigung mit Phoner (und ich selbst habe mir Phoner Lite auch tatsächlich erst erneut angesehen, als ich es "ganz genau" wissen wollte - aber immerhin kannte ich Phoner und dessen Konfigurationsmöglichkeiten und Anzeigen wenigstens ... und da hat sich nach meiner Erinnerung ja tatsächlich vieles geändert) hätte wieder eine viel einfachere Methode, die SIP-Dialoge zu verfolgen, aufgezeigt - die "Debug-Ausgabe" (die auch schon im Thread von 2008 erwähnt wird - man KONNTE also ohne weiteres auch wissen, daß es diese Ausgaben gibt) zeigt ja die SIP-Messages (Requests und Responses) an und wenn man tatsächlich "Zweifel" daran haben sollte (worauf gründen die sich eigentlich genau?), was da verwendet wird, dann reicht ein Blick ins Fenster und man braucht immer noch keinen WireShark-Mitschnitt, um solche "basics" zu prüfen - die Begründung, warum man den Aussagen in #1 und/oder den Einstellungen im Programm nicht trauen will, fehlt ja weiterhin.
Mich würde ja schon mal "aus Prinzip" interessieren, WIE GENAU eigentlich jetzt ein Programm auf einem Rechner mit einer öffentlichen IPv6-Adresse ermitteln soll, ob da irgendwo noch eine IPv6-Firewall im Weg steht, die den Empfang von beliebigen(!) Paketen aus dem Internet auf diesem Rechner ver- oder behindert. Ich wüßte keinen zuverlässigen Weg ... denn hier (UDP, IPv6, Rechner mit öffentlicher Adresse) gibt es meines Wissens keinen Grund für irgendein "NAT" (und ein Mitschnitt auf dem PC oder irgendwoanders auf der LAN-Seite des Routers würde das auch immer noch nicht zeigen können) und da stellt sich dann die Frage, warum man dort eines entdecken und damit definierte Keep-Alive-Mechanismen aktivieren sollte.
Was könnte man also noch machen? Man könnte an einen Server im Internet eine Aufforderung senden, seinerseits einen Verbindungsversuch zu einer angegebenen IP-Adresse, einem vorgegebenen Port und mit einem vorgegebenen Protokoll zu starten. Nur wie sollte das bei UDP wieder so funktionieren, daß damit KEIN (D)DoS-Angriff möglich wird, bei dem einfach ein Client (bzw. natürlich eine entsprechende Meute, denn Wölfe jagen nun mal im Rudel) solche Verbindungsversuche auslöst, die aber gar nicht an seine eigene Adresse gehen (die bei UDP ja auch gefälscht sein kann)?
Da müßte man (wenn man eine Firewall für UDP-Pakete "entdecken" wollte auf diesem Weg) also erst mal eine TCP-Verbindung aufbauen, in der dann so ein "Request" gesendet werden kann und dürfte dann auch nur wieder dahin senden, wo diese TCP-Verbindung ihren Ursprung hatte (einen zufälligen UDP-Port sollte man beim
bind() ja "reservieren" können) - allerdings könnte man das Ergebnis dann wieder über die TCP-Verbindung an den Absender übermitteln.
Gibt es so einen Service (als Implementierung) irgendwo und/oder ist das irgendwo in einer Spezifikation oder einem Draft aufgetaucht? Ich kenne so etwas nicht, das muß aber noch lange nicht heißen, daß es so etwas auch nicht gibt - wie gesagt, ich "merke" mir nur die wichtigen RFCs (und auch nicht im Kopf, sondern in entsprechenden Notizen), die mich bei meinen Tätigkeiten auch tatsächlich tangieren.
Zurück zum Phoner Lite ... wenn der Code für Keepalives in Phoner Lite (ich hoffe mal, daß der Autor dann schlauer ist als
@sonyKatze und bei UDP-Verbindungen auch STUN-Requests verwendet anstelle von "2x CRLF") tatsächlich nur dann "anspringen" sollte, wenn ein NAT-Gateway im Weg ist, dann wäre das ja auch wieder eine Erklärung, warum irgendwann keine INVITE-Messages mehr angekommen sind. Da kann man dann darüber NACHDENKEN, ob das nun mit Keepalives oder mit Portfreigaben besser geregelt wäre - wenn tatsächlich Phoner Lite RFC5626 korrekt umsetzen soll(te), wäre das natürlich die "optimale" Lösung.
Aber das würde noch nicht erklären, warum es mit eingetragenen STUN-Server nun nicht mehr auftritt - zumindest nicht dann, wenn das TATSÄCHLICH ein STUN-Server nach RFC 5389 sein sollte, der auf Port 3478 auf eingehende Request wartet (
https://datatracker.ietf.org/doc/html/rfc5389#section-18.4), denn so eine Abfrage würde ja nicht dazu führen, daß die Verbindung zum SIP-Registrar wieder neuen Traffic registriert und daher das Timeout neu startet.
Was vielleicht noch sein KANN ... wenn die Angabe eines STUN-Servers in Phoner Lite tatsächlich einen Mechanismus nach RFC 5626 aktiviert, dann würde das zumindest erklären, wieso die Angabe eines STUN-Servers vielleicht/wohl geholfen hat, aber dafür sollte eigentlich gar keine "Adresse" erforderlich sein (erst recht nicht, wenn die noch von der des Registrars abweicht), denn dann sollen diese STUN-Requests ja INNERHALB desselben "Flows" abgearbeitet werden:
To detect this, STUN requests are sent over the same flow that is being used for the SIP traffic.
Wenn das hingegen ein "externer" STUN-Server sein soll, der nur der Feststellung, ob da tatsächlich NAT verwendet wird, dienen würde, dann dürfte dieser (und natürlich auch die STUN-Requests innerhalb derselben "UDP connection", die für die SIP-Registrierung verwendet wird) gar kein NAT FESTSTELLEN können und es gäbe somit auch keine Notwendigkeit, irgendein Keepalive zu aktivieren. DAS ist dann (in meinen Augen, diese Ansicht muß ja auch niemand teilen) tatsächlich eine "Unklarheit", die man eventuell in der Beschreibung zu Phoner Lite noch berücksichtigen sollte ... aber auch nur dann, wenn das tatsächlich parallel auch "STUN keep-alives" nach RFC 5626 aktiviert und das so beabsichtigt ist.
Soweit ich das kenne, sendet sipgate auch keine eigenen "Flow-Timer"-Header mit (zumindest nicht an meine FRITZ!Box mit IPv6 und UDP) ... damit sollte (wenn man RFC 5626 unterstützen WILL) das Berechnen der Keepalive-Intervalle dann wieder komplett in den Händen des UA liegen:
https://datatracker.ietf.org/doc/html/rfc5626#section-4.4
EDIT: Ach so ... eins noch zur Frage, ob man nun RFC 5626 unterstützen MUSS oder nicht - man kann ja auch mal bei sipgate in die Hilfen schauen:
https://teamhelp.sipgate.de/hc/de/articles/204546511-Einseitige-Sprachübertragung-nicht-erreichbar- ... und ich werde bei Gelegenheit auch mal prüfen, was eigentlich AVM in den FRITZ!Boxen GENAU macht (auch mal bei neueren Versionen des FRITZ!OS), wenn man kein "Portweiterleitung offenhalten" eingestellt hat. Nach der Theorie, daß man RFC 5626 unterstützen MÜSSE, sollten dann ja auch von einer FRITZ!Box mit aktueller Firmware bei IPv6 und UDP entsprechende STUN-Requests INNERHALB der UDP-Connection gesendet werden - ich denke mal, die wären mir aufgefallen. Allerdings gebe ich hierbei dann auch zu, daß ich das mit neueren Firmware-Versionen meinerseits nicht getestet habe. Ich bin ja mal gespannt ...
Und als (vorläufig) letztes ... mittlerweile habe ich dann durch Internet-Suche auch selbst die 1TR-114 und 1TR-119 gefunden - letztere ist es dann vermutlich, aus der oben zitiert wurde.
EDIT: Und als wirklich "allerletzte Anmerkung", falls jemand Zweifel haben sollte, ob ich RFC 5626 auch wirklich schon kannte, als ich immer wieder nach "Quellen" fragte:
https://www.ip-phone-forum.de/threads/informationen-zum-einsatz-vom-pfsense.283317/post-2171606 - mittlerweile auch schon wieder sechs Jahre her (und nein, es ist kein Alzheimer diagnostiziert bei mir).
