H.323-Netzwerke verfügen über unterschiedliche Konfigurationen und Anrufverläufe. In diesem Dokument werden die meisten Sicherheitsbedenken bei H.323-Netzwerken behandelt, die Gatekeeper betreffen. In diesem Dokument werden die Funktionsweise der einzelnen Funktionen und die Fehlerbehebung zusammengefasst, und es werden die meisten Fehlerbehebungen erläutert. In diesem Dokument wird nicht auf die allgemeine Sicherheit von VoIP eingegangen.
In diesem Dokument werden folgende Funktionen behandelt:
Intradomain Gateway to Gatekeeper Security (Intradomänen-Gateway zu Gatekeeper-Sicherheit): Diese Sicherheit basiert auf H.235, in dem H.323-Anrufe von einem Gatekeeper authentifiziert, autorisiert und weitergeleitet werden. Der Gatekeeper wird als bekannte und vertrauenswürdige Einheit angesehen, da er vom Gateway nicht authentifiziert wird, wenn das Gateway versucht, sich bei ihm zu registrieren.
Inter-Domain Gatekeeper to Gatekeeper Security (Domänenübergreifende Gatekeeper-zu-Gatekeeper-Sicherheit): Diese Sicherheit umfasst die Authentifizierung und Autorisierung von H.323-Anrufen zwischen den Verwaltungsdomänen von Internettelefondienstanbietern (ITSPs) mithilfe von InterZone Clear Token (IZCT). In diesem Dokument wird nur der Teil behandelt, in dem der abschließende Gatekeeper ein Token in seiner Standortbestätigungsnachricht (LCF) sendet, um die AnswerCall Admission Request (ARQ) zu authentifizieren. Die Validierung von Standortanforderungen (Location Request, LRQ) ist in dieser Funktion nicht enthalten. Die Validierung der Sprachqualität ist eine Funktion, die für eine zukünftige Cisco IOS® Software-Version geplant ist.
Definitionen
Abkürzung | Definition |
---|---|
ARQ | Zugangsanforderung - Eine RAS-Nachricht (Registration, Admission, and Status Protocol), die von einem H.323-Endpunkt an einen Gatekeeper gesendet wird, der eine Zugangsberechtigung zur Herstellung eines Anrufs anfordert. |
ACF | Zugangsbestätigung - Eine RAS-Nachricht, die vom Gatekeeper an den Endpunkt gesendet wird und die Annahme eines Anrufs bestätigt. |
ARJ | Zugangsverweigerung - Eine RAS-Nachricht vom Gatekeeper an den Endpunkt, der die Zugangsanfrage ablehnt. |
Katzenkatze | Cisco Access Token (Cisco Zugriffstoken): Das H.235 Clear Token. |
CHAP | Challenge Handshake Authentication Protocol - Ein Authentifizierungsprotokoll, bei dem eine Herausforderung verwendet wird. |
GCF | Gatekeeper Confirm (Gatekeeper-Bestätigung): Eine RAS-Nachricht, die von einem Gatekeeper an den H.323-Endpunkt gesendet wird und die Erkennung des Gatekeeper bestätigt. |
GRQ | Gatekeeper Request (Gatekeeper-Anforderung): Eine RAS-Nachricht, die von einem H.323-Endpunkt gesendet wird, um den Gatekeeper zu ermitteln. |
H,235 | ITU-Empfehlung für Sicherheit und Verschlüsselung für H-Serie (H.323 und andere H.245-basierte) Multimedia-Endgeräte. |
IZCT | InterZone Clear Token (InterZone Clear Token) - Ein IZCT wird im ursprünglichen Gatekeeper generiert, wenn eine LRQ initiiert wird oder eine ACF für einen Intra-Zone-Anruf innerhalb der ITSP-Verwaltungsdomäne gesendet wird. |
LRQ | Location Request (Standortanforderung) - Eine RAS-Nachricht, die von einem Gatekeeper an den nächsten Hop-Gatekeeper oder an den Anrufabschnitt gesendet wird, um den Anruf zu verfolgen und weiterzuleiten. |
RAS | Registration, Admission, and Status (Registrierung, Zulassung und Status): Ein Protokoll, das einem Gatekeeper die Durchführung von Registrierungs-, Zulassungs- und Statusüberprüfungen des Endpunkts ermöglicht. |
RCF | Registrierungsbestätigung - Eine RAS-Nachricht, die vom Gatekeeper an den Endpunkt gesendet wird, der die Registrierung bestätigt. |
RJ | Registration Reject (Registrierungsanforderung ablehnen) - Eine RAS-Nachricht, die vom Gatekeeper gesendet wird und die Registrierungsanforderung ablehnt. |
Anforderung | Registrierungsanforderung - Eine RAS-Nachricht, die vom Endpunkt an den Gatekeeper gesendet wird und eine Registrierung bei diesem anfordert. |
RIP | Request In Progress (Anforderung in Verarbeitung): Eine RAS-Nachricht, die von einem Gatekeeper an den Absender gesendet wird, der angibt, dass der Anruf in Bearbeitung ist. |
H.323 ist eine ITU-Empfehlung zur Sicherung der Echtzeitkommunikation über unsichere Netzwerke. Dies betrifft vor allem zwei Bereiche: Authentifizierung und Datenschutz. Gemäß H.235 gibt es zwei Authentifizierungstypen:
Symmetrische, verschlüsselungsbasierte Authentifizierung, die keinen vorherigen Kontakt zwischen den kommunizierenden Einheiten erfordert.
Je nachdem, ob Sie über einen früheren gemeinsamen geheimen Schlüssel verfügen (der zudem als abonnementbasiert bezeichnet wird), werden zwei Formen der abonnementbasierten Authentifizierung bereitgestellt:
Kennwort
Zertifikat
Ein Zeitstempel wird verwendet, um Wiederholungsangriffe zu verhindern. Daher ist es erforderlich, dass ein für beide Seiten akzeptabler Zeitbezug (aus dem Zeitstempel abgeleitet werden) verwendet wird. Der zulässige Zeitverzug ist eine Frage der lokalen Umsetzung.
Cisco verwendet ein CHAP-ähnliches (Challenge Handshake Authentication Protocol) Authentifizierungsschema als Grundlage für das Gateway zur H.235-Implementierung des Gatekeepers. Auf diese Weise können Sie die AAA-Funktion (Authentication, Authorization, and Accounting) nutzen und vorhandene Funktionen zur Durchführung der eigentlichen Authentifizierung nutzen. Dies bedeutet auch, dass der Gatekeeper nicht auf eine Datenbank mit Gateway-IDs, Benutzerkontonummern, Kennwörtern und PINs zugreifen muss. Das Schema basiert auf H.235, Abschnitt 10.3.3. Es wird als abonnementbasiertes Passwort mit Hashing beschrieben.
Statt H.225 cryptoTokens zu verwenden, verwendet diese Methode jedoch H.235 clearTokens mit entsprechenden Feldern zur Verwendung mit RADIUS. Dieses Token wird als Cisco Access Token (CAT) bezeichnet. Sie können die Authentifizierung immer lokal auf dem Gatekeeper durchführen, anstatt einen RADIUS-Server zu verwenden.
Die Verwendung von cryptoTokens erfordert, dass der Gatekeeper entweder Passwörter für alle Benutzer und Gateways verwaltet oder über eine Möglichkeit verfügt, diese zu erlangen. Dies liegt daran, dass das Tokenfeld des cryptoToken so festgelegt ist, dass die authentifizierende Entität das Kennwort benötigt, um ein eigenes Token zu generieren, mit dem das empfangene Token verglichen werden kann.
Die Gatekeeper von Cisco ignorieren CryptoTokens vollständig. VocalTek-Gatekeeper und andere, die H.235 Abschnitt 10.3.3 unterstützen, verwenden jedoch die cryptoTokens, um das Gateway zu authentifizieren. Cisco Gatekeeper verwenden den CAT zur Authentifizierung des Gateways. Da das Gateway nicht weiß, mit welchem Gatekeeper es kommuniziert, sendet es beide in die RRQ. Die authenticationCapability in der GRQ gelten für das cryptoToken und geben an, dass MD5-Hashing der Authentifizierungsmechanismus ist (obwohl die CAT auch MD5 verwendet).
Weitere Informationen finden Sie unter Cisco H.323 Gateway Security and Accounting Enhancements.
Sicherheit auf Endpunkt- oder Registrierungsebene
Wenn die Registrierungssicherheit auf dem Gatekeeper aktiviert ist, muss das Gateway eine CAT in alle RRQ-Nachrichten mit hohem Schweregrad aufnehmen. Der CAT enthält in diesem Fall Informationen, die das Gateway selbst gegenüber dem Gatekeeper authentifizieren. Der Gatekeeper formatiert eine Nachricht an einen RADIUS-Server, der die im Token enthaltenen Informationen authentifiziert. Er antwortet dem Gatekeeper entweder mit "Access-Accept" oder "Access-Reject". Diese wiederum antwortet dem Gateway entweder mit einem RCF oder einem RRJ.
Wenn ein Anruf von einem erfolgreich authentifizierten Gateway getätigt wird, generiert dieses Gateway eine neue CAT, sobald es vom Gatekeeper eine ACF mit dem Gateway-Passwort erhält. Diese CAT ist mit der bei der Registrierung generierten identisch, mit Ausnahme des Zeitstempels. Sie wird in die ausgehende SETUP-Nachricht eingefügt. Das Ziel-Gateway extrahiert das Token aus der SETUP-Nachricht und platziert es im ARQ auf der Zielseite. Der Gatekeeper verwendet RADIUS, um das ursprüngliche Gateway zu authentifizieren, bevor es die ACF auf der Zielseite sendet. Dadurch wird verhindert, dass ein nicht authentifizierter Endpunkt, der die Adresse eines Gateways kennt, dieses verwendet, um das Sicherheitsschema zu umgehen und auf das öffentliche Telefonnetz (PSTN) zuzugreifen.
Daher müssen in dieser Ebene keine Token in die ARQs mit Ursprung aufgenommen werden.
Geben Sie [no] security token required-for registration from the gatekeeper command-line interface (CLI) ein, um den gatekeeper zu konfigurieren. Die Option no des Befehls bewirkt, dass der Gatekeeper nicht mehr nach Token in RAS-Nachrichten sucht.
Geben Sie [no] security password <PASSWORD> level endpoint aus der Gateway-CLI ein, um das Gateway zu konfigurieren. Wenn Sie den Befehl no auswählen, generiert das Gateway keine Token mehr für RAS-Nachrichten.
Sicherheit auf Anrufebene
Die Sicherheit pro Anruf basiert auf der Sicherheit auf Registrierungsebene. Ein Gateway muss nicht nur die Sicherheitsanforderungen für die Registrierung erfüllen, sondern auch Zugriffstoken in alle ARQ-Nachrichten auf der Ursprungsseite einschließen, wenn auf dem Gatekeeper die anrufbasierte Sicherheit aktiviert ist. Das Token enthält dabei Informationen, die den Benutzer des Gateways zum Gatekeeper identifizieren. Diese Informationen werden mithilfe eines IVR-Skripts (Interactive Voice Response) am Gateway abgerufen. Daraufhin werden die Benutzer aufgefordert, ihre Benutzer-ID und ihre PIN über die Tastatur einzugeben, bevor sie einen Anruf tätigen.
Der in der ursprünglichen ARQ enthaltene CAT wird von RADIUS auf die gleiche Weise authentifiziert, wie zuvor unter Sicherheit auf Endpunkt- oder Registrierungsebene beschrieben. Nachdem das Gateway die ACF empfangen hat, generiert es mithilfe seines Kennworts einen neuen CAT und sendet diesen in der H.225 SETUP-Nachricht an das terminierende Gateway.
Geben Sie [no] security token required-for all aus der Gatekeeper-CLI ein, um den Gatekeeper zu konfigurieren. Die Option no des Befehls bewirkt, dass der Gatekeeper nicht mehr nach Token in RAS-Nachrichten sucht.
Geben Sie [no] security password <PASSWORD> level per call von der Gateway-CLI ein, um das Gateway zu konfigurieren. Wenn Sie den Befehl no auswählen, generiert das Gateway keine Token mehr für RAS-Nachrichten.
Sicherheit auf allen Ebenen
Auf diese Weise kann das Gateway eine CAT in alle RAS-Nachrichten integrieren, die für die Registrierung und für Anrufe benötigt werden. Daher ist es eine Kombination der beiden oben genannten Ebenen. Bei dieser Option basiert die Validierung von CAT in ARQ-Nachrichten auf der Kontonummer und PIN des Benutzers, der einen Anruf tätigt. Die Validierung der in allen anderen RAS-Meldungen gesendeten CAT-Meldungen basiert auf dem für das Gateway konfigurierten Kennwort. Daher ähnelt es der Ebene "Pro Anruf".
Geben Sie [no] security token required-for all aus der Gatekeeper-CLI ein, um den Gatekeeper zu konfigurieren. Die Option no des Befehls bewirkt, dass der Gatekeeper nicht mehr nach Token in RAS-Nachrichten sucht.
Geben Sie [no] security password <PASSWORD> level all from the gateway CLI (Sicherheitskennwort <PASSWORD>) ein, um das Gateway zu konfigurieren. Wenn Sie den Befehl no auswählen, generiert das Gateway keine Token mehr für RAS-Nachrichten.
H.235 kann nur auf Anrufebene ohne IVR verwendet werden. Wenn es keine IVR zum Sammeln eines Kontos und einer PIN gibt, muss das Gateway die ARQ ohne Clear Token (aber mit einem Crypto-Token) senden. Da der Cisco Gatekeeper nur Clear Tokens akzeptiert, wird der Anruf vom Gatekeeper mit einem Grund für die Verweigerung der Sicherheit abgelehnt.
Dieses Beispiel zeigt das h225 asn1-Debugging, das von einem ursprünglichen Gateway (OGW) gesammelt wurde, das nicht für ein IVR zum Erfassen des Kontos und der PIN konfiguriert ist. Die RRQ-Nachricht weist ein Clear Token auf, das ARQ jedoch nicht. Eine ARJ-Nachricht wird an das Gateway zurückgesendet.
Mar 4 01:31:24.358: H235 OUTGOING ENCODE BUFFER::= 61 000100C0 2B955BEB 08003200 32003200 32000006 006F0067 00770000 Mar 4 01:31:24.358: Mar 4 01:31:24.358: RAS OUTGOING PDU ::= value RasMessage ::= registrationRequest : { requestSeqNum 29 protocolIdentifier { 0 0 8 2250 0 3 } discoveryComplete FALSE callSignalAddress { } rasAddress { ipAddress : { ip 'AC100D0F'H port 57514 } } terminalType { mc FALSE undefinedNode FALSE } gatekeeperIdentifier {"ogk1"} endpointVendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } } timeToLive 60 tokens !--- Clear Token is included in the RRQ message. { { tokenOID { 1 2 840 113548 10 1 2 1 } timeStamp 731208684 challenge 'F57C3C65B59724B9A45C93F98CCF9E45'H random 12 generalID {"ogw"} } } cryptoTokens { cryptoEPPwdHash : { alias h323-ID : {"ogw"} timeStamp 731208684 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "D7F85666AF3B881ADD876DD61C20D5D9" } } } keepAlive TRUE endpointIdentifier {"81F5E24800000001"} willSupplyUUIEs FALSE maintainConnection TRUE } Mar 4 01:31:24.370: RAS OUTGOING ENCODE BUFFER::= 0E 40001C06 0008914A 00030000 0100AC10 0D0FE0AA 0003006F 0067006B 003100B5 00001212 EF000200 3B2F014D 000A2A86 4886F70C 0A010201 C02B955B EB10F57C 3C65B597 24B9A45C 93F98CCF 9E45010C 06006F00 67007700 002A0104 02006F00 670077C0 2B955BEB 082A8648 86F70D02 05008080 D7F85666 AF3B881A DD876DD6 1C20D5D9 0180211E 00380031 00460035 00450032 00340038 00300030 00300030 00300030 00300031 01000180 Mar 4 01:31:24.378: h323chan_dgram_send:Sent UDP msg. Bytes sent: 173 to 172.16.13.35:1719 Mar 4 01:31:24.378: RASLib::GW_RASSendRRQ: 3640-1#debug RRQ (seq# 29) sent to 172.16.13.35 Mar 4 01:31:24.462: h323chan_chn_process_read_socket Mar 4 01:31:24.462: h323chan_chn_process_read_socket: fd (2) of type CONNECTED has data Mar 4 01:31:24.462: h323chan_chn_process_read_socket: h323chan accepted/connected Mar 4 01:31:24.462: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on so ck[2] Mar 4 01:31:24.466: RAS INCOMING ENCODE BUFFER::= 12 40001C06 0008914A 00030006 006F0067 006B0031 1E003800 31004600 35004500 32003400 38003000 30003000 30003000 30003000 310F8A01 0002003B 01000180 Mar 4 01:31:24.466: Mar 4 01:31:24.466: RAS INCOMING PDU ::= value RasMessage ::= registrationConfirm : { requestSeqNum 29 protocolIdentifier { 0 0 8 2250 0 3 } callSignalAddress { } gatekeeperIdentifier {"ogk1"} endpointIdentifier {"81F5E24800000001"} alternateGatekeeper { } timeToLive 60 willRespondToIRR FALSE maintainConnection TRUE } Mar 4 01:31:24.470: RCF (seq# 29) rcvd Mar 4 01:32:00.220: H225 NONSTD OUTGOING PDU ::= value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } callingOctet3a 129 interfaceSpecificBillingId "ISDN-VOICE" } Mar 4 01:32:00.220: H225 NONSTD OUTGOING ENCODE BUFFER::= 80 000008A0 01810B12 4953444E 2D564F49 4345 Mar 4 01:32:00.220: Mar 4 01:32:00.220: H235 OUTGOING ENCODE BUFFER::= 61 000100C0 2B955C0F 08003200 32003200 32000006 006F0067 00770000 Mar 4 01:32:00.224: Mar 4 01:32:00.224: RAS OUTGOING PDU ::= value RasMessage ::= admissionRequest : { requestSeqNum 30 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"81F5E24800000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "5336", h323-ID : {"ogw"} } bandWidth 1280 callReferenceValue 5 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008A001810B124953444E2D564F494345'H } conferenceID 'E1575DA6175611CC8014A6051561649A'H activeMC FALSE answerCall FALSE canMapAlias TRUE callIdentifier { guid 'E1575DA6175611CC8015A6051561649A'H } cryptoTokens !--- Only cryptoTokens are included, no clear ones. { cryptoEPPwdHash : { alias h323-ID : {"ogw"} timeStamp 731208720 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "105475A4C0A833E7DE8E37AD3A8CDFF" } } } willSupplyUUIEs FALSE } Mar 4 01:32:00.236: RAS OUTGOING ENCODE BUFFER::= 27 88001D00 F0003800 31004600 35004500 32003400 38003000 30003000 30003000 30003000 31010180 69860201 80866940 02006F00 67007740 05000005 40B50000 12138000 0008A001 810B1249 53444E2D 564F4943 45E1575D A6175611 CC8014A6 05156164 9A056120 01801100 E1575DA6 175611CC 8015A605 1561649A 2A010402 006F0067 0077C02B 955C0F08 2A864886 F70D0205 00808010 5475A4C0 A833E7DE 8E370AD3 A8CDFF01 00 Mar 4 01:32:00.240: h323chan_dgram_send:Sent UDP msg. Bytes sent: 170 to 172.16.13.35:1719 Mar 4 01:32:00.240: RASLib::GW_RASSendARQ: ARQ (seq# 30) sent to 172.16.13.35 Mar 4 01:32:00.312: h323chan_chn_process_read_socket Mar 4 01:32:00.312: h323chan_chn_process_read_socket: fd (2) of type CONNECTED has data Mar 4 01:32:00.312: h323chan_chn_process_read_socket: fd (2) of type CONNECTED has data Mar 4 3640-1#01:32:00.312: h323chan_chn_process_read_socket: h323chan accepted/connected Mar 4 01:32:00.312: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on so ck[2] Mar 4 01:32:00.312: RAS INCOMING ENCODE BUFFER::= 2C 001D8001 00 Mar 4 01:32:00.312: Mar 4 01:32:00.312: RAS INCOMING PDU ::= value RasMessage ::= admissionReject : !--- ARQ is rejected with a security denial reason. { requestSeqNum 30 rejectReason securityDenial : NULL } Mar 4 01:32:00.312: ARJ (seq# 30) rcvd
Zu den wichtigsten Themen, mit denen Sie sich befassen müssen, gehören:
Konfiguration Gateway und Gatekeeper
RADIUS-Konfiguration auf dem Gatekeeper und dem RADIUS-Server
Network Time Protocol (NTP) - Sie müssen auf allen Gateways und Gatekeepern dieselbe Zeit haben. Da die Authentifizierungsinformationen einen Zeitstempel enthalten, ist es wichtig, dass alle Cisco H.323-Gateways und die Gatekeepers (oder andere Einheiten, die die Authentifizierung durchführen) synchronisiert werden. Die Cisco H.323-Gateways müssen mit NTP synchronisiert werden.
Softwarefehler aufgrund eines Fehlers
Da die Sicherheitsstufe "Alle" sowohl die Registrierung als auch die Anfragen pro Anruf abdeckt, ist die Sicherheitsstufe für diese Übung in der Übung festgelegt. Die Anrufflüsse für den Registrierungsteil und ein normaler VoIP-Anruf werden in der Konfiguration hier erläutert.
Hinweis: Die Konfiguration hier ist nicht vollständig. Zwischen den Debug-Ausgaben folgen weitere Befehle. Es wurde entwickelt, um zu zeigen, welches Problem auftreten kann, wenn Sie nicht alle Komponenten wie Konfiguration, NTP und RADIUS überprüfen. Darüber hinaus wird das Gateway lokal auf dem Gatekeeper authentifiziert, sodass Sie sehen können, welche Werte für die Gateway-ID und das Passwort festgelegt sind. Diese Konfiguration wird ausgeschnitten, sodass nur die zugehörige Konfiguration angezeigt wird.
! interface Ethernet0/0 ip address 172.16.13.15 255.255.255.224 half-duplex h323-gateway voip interface h323-gateway voip id gka-1 ipaddr 172.16.13.35 1718 !--- The gatekeeper name is gka-1. h323-gateway voip h323-id gwa-1@cisco.com !--- The gateway H323-ID is gwa-1@cisco.com. h323-gateway voip tech-prefix 1# ! ! gateway ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 password ww logging synchronous end !--- No NTP is configured. !--- The snipped gatekeeper configuration is like this: ! aaa new-model aaa authentication login default local aaa authentication login h323 local aaa authorization exec default local aaa authorization exec h323 local aaa accounting connection h323 start-stop group radius ! username gwa-1 password 0 2222 username gwa-2 password 0 2222 ! gatekeeper zone local gka-1 cisco.com 172.16.13.35 security token required-for all !--- The gatekeeper is configured for the "All level security". no shutdown ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 password ww line vty 5 15 ! no scheduler max-task-time no scheduler allocate ntp master !--- This gatekeeper is set as an NTP master. ! end
Diese Debugging-Funktionen sind in diesem Beispiel aktiviert:
Zunächst sendet das Gateway eine GRQ an den Gatekeeper, und der Gatekeeper sendet eine GCF an das Gateway. Das Gateway sendet dann eine RRQ und wartet auf eine RCF oder einen RJ.
In der vorherigen Konfiguration wurde für das Gateway keine Sicherheitsstufe festgelegt, sodass seine GRQ keine Authentifizierungsfunktionen enthält, die für die Token erforderlich sind. Der Gatekeeper sendet jedoch weiterhin eine GCF zurück, wie diese Ausgabe zeigt:
*Mar 2 13:32:45.413: RAS INCOMING ENCODE BUFFER::= 00 A0000006 0008914A 000200AC 100D0FD2 C6088001 3C050401 00204002 00006700 6B006100 2D003102 400E0067 00770061 002D0031 00400063 00690073 0063006F 002E0063 006F006D 0080CC *Mar 2 13:32:45.421: *Mar 2 13:32:45.425: RAS INCOMING PDU ::= value RasMessage ::= gatekeeperRequest : { requestSeqNum 1 protocolIdentifier { 0 0 8 2250 0 2 } rasAddress ipAddress : { ip 'AC100D0F'H port 53958 } endpointType { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } gatekeeperIdentifier {"gka-1"} endpointAlias { h323-ID : {"gwa-1@cisco.com"}, !--- The H.323-ID of the gateway is gwa-1@cisco.com. e164 : "99" } } *Mar 2 13:32:45.445: RAS OUTGOING PDU ::= value RasMessage ::= gatekeeperConfirm : { requestSeqNum 1 protocolIdentifier { 0 0 8 2250 0 3 } gatekeeperIdentifier {"gka-1"} rasAddress ipAddress : { ip 'AC100D23'H port 1719 } } !--- The gateway sends an RRQ message to the gatekeeper with the !--- IP address sent in the GCF. This RRQ does not carry any Token information !--- because security is not configured on the gateway. *Mar 2 13:32:45.477: RAS INCOMING ENCODE BUFFER::= 0E C0000106 0008914A 00028001 00AC100D 0F06B801 00AC100D 0FD2C608 80013C05 04010020 40000240 0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006D00 80CC0800 67006B00 61002D00 3100B500 00120E8A 02003B01 000100 *Mar 2 13:32:45.489: *Mar 2 13:32:45.493: RAS INCOMING PDU ::= value RasMessage ::= registrationRequest : { requestSeqNum 2 protocolIdentifier { 0 0 8 2250 0 2 } discoveryComplete TRUE callSignalAddress { ipAddress : { ip 'AC100D0F'H port 1720 } } rasAddress { ipAddress : { ip 'AC100D0F'H port 53958 } } terminalType { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } terminalAlias { h323-ID : {"gwa-1@cisco.com"}, e164 : "99" } gatekeeperIdentifier {"gka-1"} endpointVendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } } timeToLive 60 keepAlive FALSE willSupplyUUIEs FALSE } !--- Since the gateway does not include !--- any tokens and the gatekeeper is set to authenticate !--- all endpoints and calls, the gatekeeper rejects the gateway request. !--- It sends an RRJ with the securityDenial reason. *Mar 2 13:32:45.525: RAS OUTGOING PDU ::= value RasMessage ::= registrationReject : { requestSeqNum 2 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason securityDenial : NULL !--- Gatekeeper rejects the RRQ with security denial reason. gatekeeperIdentifier {"gka-1"} } *Mar 2 13:32:45.529: RAS OUTGOING ENCODE BUFFER::= 14 80000106 0008914A 00038301 00080067 006B0061 002D0031 *Mar 2 13:32:45.533: !--- Configure the security password 2222 level all command on the gateway. !--- The configuration of the gateway appears like this: ! gateway security password 0356095954 level all !--- The password is hashed. ! !--- As soon as you make this change the gateway !--- sends a new GRQ to the gatekeeper. !--- You see the authenticationCapability and algorithmOIDs. *Mar 2 13:33:15.551: RAS INCOMING ENCODE BUFFER::= 02 A0000206 0008914A 000200AC 100D0FD2 C6088001 3C050401 00204002 00006700 6B006100 2D003102 400E0067 00770061 002D0031 00400063 00690073 0063006F 002E0063 006F006D 0080CC0C 30020120 0A01082A 864886F7 0D0205 *Mar 2 13:33:15.563: *Mar 2 13:33:15.567: RAS INCOMING PDU ::= value RasMessage ::= gatekeeperRequest : { requestSeqNum 3 protocolIdentifier { 0 0 8 2250 0 2 } rasAddress ipAddress : { ip 'AC100D0F'H port 53958 } endpointType { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } gatekeeperIdentifier {"gka-1"} endpointAlias { h323-ID : {"gwa-1@cisco.com"}, e164 : "99" } authenticationCapability { pwdHash : NULL } algorithmOIDs { { 1 2 840 113549 2 5 } } }
Dies erklärt einige der Meldungen in der GRQ:
authenticationCapability: Dieses Feld hat nur den Wert pwdHash. Sie gibt an, dass das MD5-Hashing der Authentifizierungsmechanismus ist.
algorithmusOIDs: Die Algorithmus-Objekt-ID. In diesem Fall enthält er den Wert (1 2 840 113549 2 5), der die Objekt-ID für das Hashing von Message Digest 5 darstellt.
(1 2 840 113549 2 5) wird übersetzt in iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) md5(5). Daher führt Cisco MD5-Passwort-Hashing durch.
Rsadsi steht für RSA Data Security Inc. Die Objektkennung von RSA Data Security, Inc. für Open Systems Interconnection (OSI) lautet 1.2.840.113549 (0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d in hex), wie vom American National Standards Institute (ANSI) registriert.
Der Gatekeeper sendet erneut eine GCF als vorherige Nachricht. Das Gateway sendet dann eine RRQ mit bestimmten Feldern, um die Token zu beschreiben, die für die Authentifizierung verwendet werden. Die gesendete asn1 RRQ-Nachricht wird in diesem Beispiel angezeigt.
*Mar 2 13:33:15.635: RAS INCOMING ENCODE BUFFER::= 0E C0000306 0008914A 00028001 00AC100D 0F06B801 00AC100D 0FD2C608 80013C05 04010020 40000240 0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006D00 80CC0800 67006B00 61002D00 3100B500 00120EEA 02003B47 014D000A 2A864886 F70C0A01 0201C02B 92A53610 B9D84DAE 58F6CB4B 5EE5DFB6 B92DD281 01011E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00 6D000042 01040E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00 6DC02B92 A536082A 864886F7 0D020500 80802B21 B94F3980 ED12116C 56B79F4B 4CDB0100 0100 *Mar 2 13:33:15.667: *Mar 2 13:33:15.671: RAS INCOMING PDU ::= value RasMessage ::= registrationRequest : { requestSeqNum 4 protocolIdentifier { 0 0 8 2250 0 2 } discoveryComplete TRUE callSignalAddress { ipAddress : { ip 'AC100D0F'H port 1720 } } rasAddress { ipAddress : { ip 'AC100D0F'H port 53958 } } terminalType { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } terminalAlias { h323-ID : {"gwa-1@cisco.com"}, e164 : "99" } gatekeeperIdentifier {"gka-1"} endpointVendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } } timeToLive 60 tokens !--- Clear Token, or what is called CAT. { { tokenOID { 1 2 840 113548 10 1 2 1 } timeStamp 731030839 challenge 'B9D84DAE58F6CB4B5EE5DFB6B92DD281'H random 1 generalID {"gwa-1@cisco.com"} } } cryptoTokens !--- CryptoToken field. { cryptoEPPwdHash : { alias h323-ID : {"gwa-1@cisco.com"} timeStamp 731030839 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "2B21B94F3980ED12116C56B79F4B4CDB" } } } keepAlive FALSE willSupplyUUIEs FALSE }
Bevor die Antwort besprochen wird, werden einige verwandte Felder in der obigen RRQ-Nachricht hier erläutert. Es gibt zwei Arten von Token: einen Clear Token (CAT) und einen Crypto Token.
Wie bereits erwähnt, ignorieren die Gatekeeper von Cisco die Krypto-Token. Das Gateway sendet jedoch weiterhin beide Pakete, da es nicht weiß, mit welchem Gatekeeper es kommuniziert. Da andere Anbieter möglicherweise Krypto-Token verwenden, sendet das Gateway beide.
Dies erklärt die ClearToken-Syntax.
tokenOID: Die Objekt-ID zum Identifizieren des Tokens.
timeStamp: Die aktuelle UTC-Zeit (Coordinated Universal Time) des Gateways. Sekunden seit 00:00 1.1.1970 UTC.
Es wird als implizite CHAP-Challenge verwendet, als ob es ursprünglich vom Torwächter gekommen wäre.
Challenge - Ein vom Gateway generierter 16-Byte-MD5-Message-Digest, der folgende Felder verwendet:
challenge = [ zufällig + GW/Benutzerkennwort + Zeitstempel ] MD5 Hash
RADIUS führt diese Berechnung durch (da er die Zufallszahl, das Gateway-Passwort und die CHAP-Abfrage kennt), um zu bestimmen, wie die Abfrage aussehen soll: CHAP-Antwort = [ CHAP-ID + Benutzerkennwort + CHAP-Herausforderung ] MD5-Hash
random - Ein Byte-Wert, der von RADIUS zum Identifizieren dieser bestimmten Anforderung verwendet wird.
Das Gateway erhöht das variable Modul um 256 für jede Authentifizierungsanforderung, um diese RADIUS-Anforderung zu erfüllen.
generalID: Die Gateway-H323-ID oder die Benutzerkontonummer, je nach Sicherheitsstufe und Typ der RAS-Nachricht.
Hinweis: Alle diese Felder sind wichtig. Allerdings wird mehr Aufmerksamkeit sowohl auf den Zeitstempel und die allgemeine ID gegeben. In diesem Fall ist der Zeitstempel 731030839 und die allgemeine ID ist gwa-1@cisco.com.
Das cryptoToken in der RRQ enthält Informationen über das Gateway, das das Token generiert. Dazu gehören die Gateway-ID (d. h. die auf dem Gateway konfigurierte H.323-ID) und das Gateway-Kennwort.
Dieses Feld enthält einen der cryptoToken-Typen, die für das in H.225 angegebene CryptoH323Token-Feld definiert sind. Derzeit wird der einzige Typ von cryptoToken unterstützt, nämlich cryptoEPPwdHash.
Diese Felder sind im cryptoEPPwdHash-Feld enthalten:
alias: Der Gateway-Alias, d. h. die H.323-ID des Gateways.
timestamp (Zeitstempel): Der aktuelle Zeitstempel.
token: Das MD5-codierte PwdCertToken. Dieses Feld enthält folgende Elemente:
timestamp (Zeitstempel): Entspricht dem Zeitstempel des cryptoEPPwdHash.
password: Das Kennwort des Kabelmodems.
generalID: Derselbe Gateway-Alias, der im cryptoEPPwdHash enthalten ist.
tokenID: Die Objekt-ID.
Zeigen Sie in diesem Beispiel die Antwort des Gatekeepers an.
*Mar 2 13:33:15.723: RAS OUTGOING PDU ::= value RasMessage ::= registrationReject : { requestSeqNum 4 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason securityDenial : NULL !--- The gatekeeper rejects the RRQ with securityDenial reason. gatekeeperIdentifier {"gka-1"} } *Mar 2 13:33:15.727: RAS OUTGOING ENCODE BUFFER::= 14 80000306 0008914A 00038301 00080067 006B0061 002D0031 *Mar 2 13:33:15.731:
Der RRQ wird vom Gatekeeper abgelehnt. Der Grund hierfür ist, dass in der Konfiguration des Gateways kein NTP festgelegt war. Der Gatekeeper überprüft den Zeitstempel des Tokens, um festzustellen, ob er sich in einem akzeptablen Fenster im Verhältnis zu seiner eigenen Zeit befindet. Derzeit beträgt dieses Fenster +/- 30 Sekunden um die UTC-Zeit des Gatekeeper.
Ein Token außerhalb dieses Fensters veranlasst den Gatekeeper, diese Nachricht zu verwerfen. Dadurch werden Wiederholungsangriffe von Personen verhindert, die versuchen, einen ausspionierten Token wiederzuverwenden. In der Praxis müssen alle Gateways und Gatekeeper NTP verwenden, um dieses Zeitverzerrungsproblem zu vermeiden. Der Gatekeeper stellt fest, dass sich der Zeitstempel im Token innerhalb des akzeptablen Zeitfensters seiner Zeit befindet. Daher wird bei RADIUS keine Authentifizierung des Gateways durchgeführt.
Das Gateway wird dann für NTP konfiguriert, das auf den Gatekeeper als NTP-Master verweist, sodass sowohl das Gateway als auch der Gatekeeper die gleiche Zeit haben. In diesem Fall sendet das Gateway eine neue RRQ, und diesmal antwortet der Gatekeeper mit einem RJ auf die neue RRQ.
Diese Debugs stammen vom Gatekeeper. Es wird geprüft, ob der Gatekeeper zur Authentifizierungsphase übergeht.
Mar 2 13:57:41.313: RAS INCOMING ENCODE BUFFER::= 0E C0005906 0008914A 00028001 00AC100D 0F06B801 00AC100D 0FD2C608 80013C05 04010020 40000240 0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006D00 80CC0800 67006B00 61002D00 3100B500 00120EEA 02003B47 014D000A 2A864886 F70C0A01 0201C02B 9367D410 7DD4C637 B6DD4E34 0883A7E5 E12A2B78 012C1E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00 6D000042 01040E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00 6DC02B93 67D4082A 864886F7 0D020500 8080ED73 946B13E9 EAED6F4D FED13478 A6270100 0100 Mar 2 13:57:41.345: Mar 2 13:57:41.349: RAS INCOMING PDU ::= value RasMessage ::= registrationRequest : { requestSeqNum 90 protocolIdentifier { 0 0 8 2250 0 2 } discoveryComplete TRUE callSignalAddress { ipAddress : { ip 'AC100D0F'H port 1720 } } rasAddress { ipAddress : { ip 'AC100D0F'H port 53958 } } terminalType { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } terminalAlias { h323-ID : {"gwa-1@cisco.com"}, e164 : "99" } gatekeeperIdentifier {"gka-1"} endpointVendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } } timeToLive 60 tokens { { tokenOID { 1 2 840 113548 10 1 2 1 } timeStamp 731080661 challenge '7DD4C637B6DD4E340883A7E5E12A2B78'H random 44 generalID {"gwa-1@cisco.com"} } } cryptoTokens { cryptoEPPwdHash : { alias h323-ID : {"gwa-1@cisco.com"} timeStamp 731080661 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "ED73946B13E9EAED6F4DFED13478A627" } } } keepAlive FALSE willSupplyUUIEs FALSE } Mar 2 13:57:41.401: AAA: parse name=<no string> idb type=-1 tty=-1 Mar 2 13:57:41.405: AAA/MEMORY: create_user (0x81416060) user='gwa-1@cisco.com' ruser='NULL' ds0=0port='NULL' rem_addr='NULL' authen_type=CHAP service=LOGIN priv=0 initial_task_id='0' Mar 2 13:57:41.405: AAA/AUTHEN/START (2845574558): port='' list='h323' action=LOGIN service=LOGIN Mar 2 13:57:41.405: AAA/AUTHEN/START (2845574558): found list h323 Mar 2 13:57:41.405: AAA/AUTHEN/START (2845574558): Method=LOCAL Mar 2 13:57:41.405: AAA/AUTHEN (2845574558): User not found, end of method list Mar 2 13:57:41.405: AAA/AUTHEN (2845574558): status = FAIL !--- Authentication fails. The user is not found on the list. Mar 2 13:57:41.405: voip_chapstyle_auth: astruct.status = 2 Mar 2 13:57:41.405: AAA/MEMORY: free_user (0x81416060) user='gwa-1@cisco.com' ruser='NULL' port='NULL' rem_addr='NULL' authen_type=CHAP service=LOGIN priv=0 Mar 2 13:57:41.409: RAS OUTGOING PDU ::= value RasMessage ::= registrationReject : { requestSeqNum 90 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason securityDenial : NULL gatekeeperIdentifier {"gka-1"} }
Nach der Konfiguration des NTP lehnt der Gatekeeper die RRQ weiterhin ab. Dieses Mal jedoch wird der Authentifizierungsprozess für dieses Gateway durchlaufen. Der Gatekeeper lehnt die RRQ ab, weil der Benutzer (hier die Gateway-ID) nicht in der Liste der gültigen Benutzer auf dem RADIUS gefunden wurde. Das Gateway wird in der Konfiguration des Gatekeepers lokal authentifiziert. Auf der Benutzerliste wird gwa-1 angezeigt. Dies ist jedoch nicht der richtige Benutzer, da der Benutzer in der Angebotsanfrage gwa-1@cisco.com ist.
Sobald der Befehl username gwa-1@cisco.com password 0 2222 auf dem Gatekeeper konfiguriert ist, bestätigt der Gatekeeper die RRQ und das Gateway ist registriert.
Bei dieser Übung wird ein weiteres Gateway (gwa-2) bei demselben Gatekeeper (gka-1) registriert. Rufen Sie von gwa-1@cisco.com aus gwa-2 an, um zu sehen, wie die ARQ-, ACF- und Setup-Meldungen aussehen.
Diese gesammelten Debugs stammen vom Quell- und Terminierungs-Gateway (gwa-2).
Eine Erläuterung einiger Debug-Meldungen ist enthalten.
Bevor Sie die Debug-Meldungen vom Ursprungs-/Terminierungs-Gateway ausdrucken, wird in diesem Text der Anruffluss erklärt:
Wenn eine SETUP-Nachricht vom PSTN empfangen wird, sendet das Gateway eine ARQ an den PSTN und empfängt eine ACF vom Gatekeeper.
Wenn das Gateway die ACF empfängt, generiert es eine CAT unter Verwendung des Gateway-Kennworts, des H323-ID-Alias und der aktuellen Uhrzeit. Das Token wird im Anrufsteuerungsblock (Call Control Block, CCB) platziert.
Wenn das Gateway die SETUP-Nachricht an das terminierende Gateway sendet, ruft es das Zugriffstoken aus dem CCB ab und platziert es im nonStandardParameter-Feld eines ClearToken in der SETUP-Nachricht.
Das terminierende Gateway entfernt das Token aus der SETUP-Nachricht, wandelt es aus einem nicht standardmäßigen Parameter in eine CAT um und platziert es im ARQ.
Der Gatekeeper überprüft den Zeitstempel des Tokens, um festzustellen, ob er sich in einem akzeptablen Fenster im Verhältnis zu seiner eigenen Zeit befindet. Derzeit beträgt dieses Fenster +/- 30 Sekunden um die UTC-Zeit des Gatekeeper. Ein Token außerhalb dieses Fensters veranlasst den Gatekeeper, diese Nachricht zu verwerfen. Dadurch wird der Anruf abgelehnt.
Wenn das Token zulässig ist, formatiert der Gatekeeper ein RADIUS-Zugriffsanforderungspaket, gibt die entsprechenden Attribute zum Überprüfen einer CHAP-Abfrage aus und sendet dieses an einen RADIUS-Server.
Basierend auf der Annahme, dass der Alias des Kabelmodems auf dem Server bekannt ist, sucht der Server das mit diesem Alias verknüpfte Kennwort und generiert eine eigene CHAP-Antwort unter Verwendung des Alias, des Kennworts und der CHAP-Abfrage vom Gatekeeper. Wenn seine CHAP-Antwort mit der vom Gatekeeper empfangenen übereinstimmt, sendet der Server ein Access Accept-Paket an den Gatekeeper. Wenn sie nicht übereinstimmen oder der Alias des Kabelmodems sich nicht in der Datenbank des Servers befindet, sendet der Server ein Access Reject-Paket zurück an den Gatekeeper.
Der Gatekeeper antwortet dem Gateway mit einer ACF, wenn es eine Access Accept erhält, oder einem ARJ mit Ursachencode securityDenial, wenn es eine Access Reject erhält. Wenn das Kabelmodem eine ACF empfängt, wird der Anruf verbunden.
In diesem Beispiel wird das Debuggen vom ursprünglichen Gateway veranschaulicht.
Hinweis: Das h225 asn1-Debugging für die Konfiguration wird in diesem Beispiel nicht gezeigt, da es dem Beispiel des abschließenden Gateways entspricht, das auf das Beispiel des ursprünglichen Gateways folgt.
Mar 2 19:39:07.376: cc_api_call_setup_ind (vdbPtr=0x6264AB2C, callInfo={called=3653,called_oct3=0x81,calling=,calling_oct3=0x81,calling_oct3a=0x0, calling_xlated=false,subscriber_type_str=RegularLine,fdest=1,peer_tag=5336, prog_ind=3},callID=0x61DDC2A8) Mar 2 19:39:07.376: cc_api_call_setup_ind type 13 , prot 0 Mar 2 19:39:07.376: cc_process_call_setup_ind (event=0x6231F0C4) Mar 2 19:39:07.380: >>>>CCAPI handed cid 30 with tag 5336 to app "DEFAULT" Mar 2 19:39:07.380: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(30), disp(0) Mar 2 19:39:07.380: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(30), disp(0) Mar 2 19:39:07.380: ssaCallSetupInd Mar 2 19:39:07.380: ccCallSetContext (callID=0x1E, context=0x6215B5A0) Mar 2 19:39:07.380: ssaCallSetupInd cid(30), st(SSA_CS_MAPPING),oldst(0), ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1 Mar 2 19:39:07.380: ssaCallSetupInd finalDest cllng(1#5336), clled(3653) Mar 2 19:39:07.380: ssaCallSetupInd cid(30), st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0 Mar 2 19:39:07.380: ssaSetupPeer cid(30) peer list: tag(3653) called number (3653) Mar 2 19:39:07.380: ssaSetupPeer cid(30), destPat(3653), matched(4), prefix(), peer(62664554), peer->encapType (2) Mar 2 19:39:07.380: ccCallProceeding (callID=0x1E, prog_ind=0x0) Mar 2 19:39:07.380: ccCallSetupRequest (Inbound call = 0x1E, outbound peer =3653, dest=, params=0x62327730 mode=0, *callID=0x62327A98, prog_ind = 3) Mar 2 19:39:07.380: ccCallSetupRequest numbering_type 0x81 Mar 2 19:39:07.380: ccCallSetupRequest encapType 2 clid_restrict_disable 1 null_orig_clg 1 clid_transparent 0 callingNumber 1#5336 Mar 2 19:39:07.380: dest pattern 3653, called 3653, digit_strip 0 Mar 2 19:39:07.380: callingNumber=1#5336, calledNumber=3653, redirectNumber= display_info= calling_oct3a=0 Mar 2 19:39:07.384: accountNumber=, finalDestFlag=1, guid=6aef.3a87.165c.11cc.8040.d661.b74f.9390 Mar 2 19:39:07.384: peer_tag=3653 Mar 2 19:39:07.384: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=, callParams={called=3653,called_oct3=0x81, calling=1#5336,calling_oct3=0x81, calling_xlated=false, subscriber_type_str=RegularLine, fdest=1, voice_peer_tag=3653},mode=0x0) vdbPtr type = 1 Mar 2 19:39:07.384: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=, callParams={called=3653, called_oct3 0x81, calling=1#5336,calling_oct3 0x81, calling_xlated=false, fdest=1, voice_peer_tag=3653}, mode=0x0, xltrc=-5) Mar 2 19:39:07.384: ccSaveDialpeerTag (callID=0x1E, dialpeer_tag=0xE45) Mar 2 19:39:07.384: ccCallSetContext (callID=0x1F, context=0x621545DC) Mar 2 19:39:07.384: ccCallReportDigits (callID=0x1E, enable=0x0) Mar 2 19:39:07.384: cc_api_call_report_digits_done (vdbPtr=0x6264AB2C, callID=0x1E, disp=0) Mar 2 19:39:07.384: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE), cid(30),disp(0) Mar 2 19:39:07.384: cid(30)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE) oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1) Mar 2 19:39:07.384: -cid2(31)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING) Mar 2 19:39:07.384: ssaReportDigitsDone cid(30) peer list: (empty) Mar 2 19:39:07.384: ssaReportDigitsDone callid=30 Reporting disabled. Mar 2 19:39:07.388: H225 NONSTD OUTGOING PDU ::= value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } interfaceSpecificBillingId "ISDN-VOICE" } Mar 2 19:39:07.388: H225 NONSTD OUTGOING ENCODE BUFFER::= 80 00000820 0B124953 444E2D56 4F494345 Mar 2 19:39:07.388: Mar 2 19:39:07.388: H235 OUTGOING ENCODE BUFFER::= 61 000100C0 2B93B7DA 08003200 32003200 3200001E 00670077 0061002D 00310040 00630069 00730063 006F002E 0063006F 006D0000 Mar 2 19:39:07.392: Mar 2 19:39:07.392: RAS OUTGOING PDU ::= value RasMessage ::= admissionRequest : !--- The ARQ is sent to the gatekeeper. { requestSeqNum 549 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"8155346000000001"} destinationInfo { e164 : "2#3653" } srcInfo { e164 : "1#5336", h323-ID : {"gwa-1@cisco.com"} } bandWidth 640 callReferenceValue 15 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008200B124953444E2D564F494345'H } conferenceID '6AEF3A87165C11CC8040D661B74F9390'H activeMC FALSE answerCall FALSE canMapAlias TRUE callIdentifier { guid '6AEF3A87165C11CC8041D661B74F9390'H } tokens !--- Token is included since there is an all level of security. { { tokenOID { 1 2 840 113548 10 1 2 1 } timeStamp 731101147 challenge '1CADDBA948A8291C1F134035C9613E3E'H random 246 generalID {"gwa-1@cisco.com"} } } cryptoTokens { cryptoEPPwdHash : { alias h323-ID : {"gwa-1@cisco.com"} timeStamp 731101147 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "5760B7B4877335B7CD24BD24E4A2AA89" } } } willSupplyUUIEs FALSE } Mar 2 19:39:07.408: RAS OUTGOING ENCODE BUFFER::= 27 88022400 F0003800 31003500 35003300 34003600 30003000 30003000 30003000 30003000 31010280 50698602 02804086 69400E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00 6D400280 000F40B5 00001211 80000008 200B1249 53444E2D 564F4943 456AEF3A 87165C11 CC8040D6 61B74F93 9004E320 01801100 6AEF3A87 165C11CC 8041D661 B74F9390 48014D00 0A2A8648 86F70C0A 010201C0 2B93B7DA 101CADDB A948A829 1C1F1340 35C9613E 3E0200F6 1E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006D00 00420104 0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006DC0 2B93B7DA 082A8648 86F70D02 05008080 5760B7B4 877335B7 CD24BD24 E4A2AA89 0100 Mar 2 19:39:07.412: h323chan_dgram_send:Sent UDP msg. Bytes sent: 291 to 172.16.13.35:1719 Mar 2 19:39:07.416: RASLib::GW_RASSendARQ: ARQ (seq# 549) sent to 172.16.13.35 Mar 2 19:39:07.432: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on sock[1] Mar 2 19:39:07.432: RAS INCOMING ENCODE BUFFER::= 2B 00022440 028000AC 100D1706 B800EF1A 00C00100 020000 Mar 2 19:39:07.432: Mar 2 19:39:07.432: RAS INCOMING PDU ::= value RasMessage ::= admissionConfirm : !--- Received from the gatekeeper with no tokens. { requestSeqNum 549 bandWidth 640 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } irrFrequency 240 willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } } Mar 2 19:39:07.436: ACF (seq# 549) rcvd
In diesem Beispiel werden die Fehlerbehebungen vom Terminierungs-Gateway (TGW) veranschaulicht. Beachten Sie, dass der TGW die zweite Etappe eingerichtet hat, seit er die ACF erhalten hat, und dass der Anruf verbunden ist.
Mar 2 19:39:07.493: PDU DATA = 6147C2BC value H323_UserInformation ::= { h323-uu-pdu { h323-message-body setup : { protocolIdentifier { 0 0 8 2250 0 2 } sourceAddress { h323-ID : {"gwa-1@cisco.com"} !--- Setup is sent from gwa-1@cisco.com gateway. } sourceInfo { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } activeMC FALSE conferenceID '6AEF3A87165C11CC8040D661B74F9390'H conferenceGoal create : NULL callType pointToPoint : NULL sourceCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11032 } callIdentifier { guid '6AEF3A87165C11CC8041D661B74F9390'H } tokens !--- Setup includes the Clear Token (CAT). { { tokenOID { 1 2 840 113548 10 1 2 1 } timeStamp 731101147 challenge 'AFBAAFDF79446B9D8CE164DB8C111A87'H random 247 generalID {"gwa-1@cisco.com"} nonStandard { nonStandardIdentifier { 0 1 2 4 } data '2B93B7DBAFBAAFDF79446B9D8CE164DB8C111A87...'H } } } fastStart { '0000000C6013800A04000100AC100D0F4673'H, '400000060401004C6013801114000100AC100D0F...'H } mediaWaitForConnect FALSE canOverlapSend FALSE } h245Tunneling TRUE nonStandardControl { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data 'E001020001041504039090A31803A983811E0285...'H } } } } RAW_BUFFER::= E0 01020001 04150403 9090A318 03A98381 1E028583 70058133 36353302 80060004 00000003 Mar 2 19:39:07.509: PDU DATA = 6147F378 value H323_UU_NonStdInfo ::= { version 2 protoParam qsigNonStdInfo : { iei 4 rawMesg '04039090A31803A983811E028583700581333635...'H } progIndParam progIndIEinfo : { progIndIE '00000003'H } } PDU DATA = 6147F378 value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } } RAW_BUFFER::= 00 0000 Mar 2 19:39:07.517: RAW_BUFFER::= 61 000100C0 2B93B7DA 08003200 32003200 3200000A 00670077 0061002D 00320000 Mar 2 19:39:07.517: PDU DATA = 6147C2BC value RasMessage ::= admissionRequest : !--- An answer ARQ is sent to the gatekeeper to authenticate the caller. { requestSeqNum 22 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"81F5989C00000002"} destinationInfo { e164 : "2#3653" } srcInfo { e164 : "1#5336" } srcCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11032 } bandWidth 640 callReferenceValue 2 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '000000'H } conferenceID '6AEF3A87165C11CC8040D661B74F9390'H activeMC FALSE answerCall TRUE canMapAlias FALSE callIdentifier { guid '6AEF3A87165C11CC8041D661B74F9390'H } tokens !--- CAT is included. { { tokenOID { 0 4 0 1321 1 2 } timeStamp 731101147 challenge 'AFBAAFDF79446B9D8CE164DB8C111A87'H random 247 generalID {"gwa-1@cisco.com"} } } cryptoTokens { cryptoEPPwdHash : { alias h323-ID : {"gwa-2"} timeStamp 731101147 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "8479E7DE63AC17C6A46E9E19659568" } } } willSupplyUUIEs FALSE } RAW_BUFFER::= 27 98001500 F0003800 31004600 35003900 38003900 43003000 30003000 30003000 30003000 32010280 50698601 02804086 6900AC10 0D0F2B18 40028000 0240B500 00120300 00006AEF 3A87165C 11CC8040 D661B74F 939044E3 20010011 006AEF3A 87165C11 CC8041D6 61B74F93 9044014D 00060400 8A290102 C02B93B7 DA10AFBA AFDF7944 6B9D8CE1 64DB8C11 1A870200 F71E0067 00770061 002D0031 00400063 00690073 0063006F 002E0063 006F006D 00002E01 04040067 00770061 002D0032 C02B93B7 DA082A86 4886F70D 02050080 808479E7 0DE63AC1 7C6A46E9 E1965905 680100 Mar 2 19:39:07.533: h323chan_dgram_send:Sent UDP msg. Bytes sent: 228 to 172.16.13.35:1719 Mar 2 19:39:07.533: RASLib::GW_RASSendARQ: ARQ (seq# 22) sent to 172.16.13.35 Mar 2 19:39:07.549: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on sock[1] RAW_BUFFER::= 2B 00001540 028000AC 100D1706 B800EF1A 00C00100 020000 Mar 2 19:39:07.549: PDU DATA = 6147C2BC value RasMessage ::= admissionConfirm : !--- ACF is received from the gatekeeper. { requestSeqNum 22 bandWidth 640 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } irrFrequency 240 willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } } Mar 2 19:39:07.553: ACF (seq# 22) rcvd Mar 2 19:39:07.553: cc_api_call_setup_ind (vdbPtr=0x61BC92EC, callInfo={called=2#3653,called_oct3=0x81,calling=1#5336,calling_oct3=0x81, calling_oct3a=0x0,subscriber_type_str=Unknown, fdest=1 peer_tag=5336, prog_ind=3},callID=0x6217CC64) Mar 2 19:39:07.553: cc_api_call_setup_ind type 0 , prot 1 Mar 2 19:39:07.553: cc_api_call_setup_ind (vdbPtr=0x61BC92EC, callInfo={called=2#3653, calling=1#5336, fdest=1 peer_tag=5336}, callID=0x6217CC64) Mar 2 19:39:07.553: cc_process_call_setup_ind (event=0x61E1EAFC) Mar 2 19:39:07.553: >>>>CCAPI handed cid 9 with tag 5336 to app "DEFAULT" Mar 2 19:39:07.553: sess_appl: ev(25=CC_EV_CALL_SETUP_IND), cid(9), disp(0) Mar 2 19:39:07.553: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(9), disp(0) Mar 2 19:39:07.553: ssaCallSetupInd Mar 2 19:39:07.553: ccCallSetContext (callID=0x9, context=0x62447A28) Mar 2 19:39:07.553: ssaCallSetupInd cid(9), st(SSA_CS_MAPPING),oldst(0), ev(25)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1 Mar 2 19:39:07.553: ssaCallSetupInd finalDest cllng(1#5336), clled(2#3653) Mar 2 19:39:07.553: ssaCallSetupInd cid(9), st(SSA_CS_CALL_SETTING),oldst(0), ev(25)dpMatchPeersMoreArg result= 0 Mar 2 19:39:07.557: ssaSetupPeer cid(9) peer list: tag(3653) called number (2#3653) Mar 2 19:39:07.557: ssaSetupPeer cid(9), destPat(2#3653), matched(5), prefix(21), peer(620F1EF0), peer->encapType (1) Mar 2 19:39:07.557: ccCallProceeding (callID=0x9, prog_ind=0x0) Mar 2 19:39:07.557: ccCallSetupRequest (Inbound call = 0x9, outbound peer =3653, dest=, params=0x61E296C0 mode=0, *callID=0x61E299D0, prog_ind = 3) Mar 2 19:39:07.557: ccCallSetupRequest numbering_type 0x81 Mar 2 19:39:07.557: dest pattern 2#3653, called 2#3653, digit_strip 1 Mar 2 19:39:07.557: callingNumber=1#5336, calledNumber=2#3653, redirectNumber=display_info= calling_oct3a=0 Mar 2 19:39:07.557: accountNumber=, finalDestFlag=1, guid=6aef.3a87.165c.11cc.8040.d661.b74f.9390 Mar 2 19:39:07.557: peer_tag=3653 Mar 2 19:39:07.557: ccIFCallSetupRequestPrivate: (vdbPtr=0x61E4473C, dest=, callParams={called=2#3653,called_oct3=0x81, calling=1#5336,calling_oct3=0x81, subscriber_type_str=Unknown, fdest=1, voice_peer_tag=3653},mode=0x0) vdbPtr type = 6 Mar 2 19:39:07.557: ccIFCallSetupRequestPrivate: (vdbPtr=0x61E4473C, dest=, callParams={called=2#3653, called_oct3 0x81, calling=1#5336,calling_oct3 0x81, fdest=1, voice_peer_tag=3653}, mode=0x0, xltrc=-4) Mar 2 19:39:07.557: ccSaveDialpeerTag (callID=0x9, dialpeer_tag= Mar 2 19:39:07.557: ccCallSetContext (callID=0xA, context=0x6244D9EC) Mar 2 19:39:07.557: ccCallReportDigits (callID=0x9, enable=0x0)
In derselben Übung wird IOS-Image 12.2(6a) in das OGW geladen. Wenn ein Anruf getätigt wird, stellt sich heraus, dass das OGW weiterhin ein Clear Token basierend auf seinem Kennwort sendet, obwohl das Gateway nicht für IVR konfiguriert ist, um das Konto/die PIN zu erfassen. Darüber hinaus akzeptiert der für alle Ebenen konfigurierte Gatekeeper diesen Anruf. Dies wird unter der Cisco Bug-ID CSCdw4324 dokumentiert (nur für registrierte Kunden).
Wie bereits in diesem Dokument erwähnt, wird die End-to-End-Anrufsicherheit durch die Verwendung von Zugriffstoken gewährleistet, die in den RAS/H.225-Nachrichten im clearTokens-Feld gesendet werden. Wenn diese Sicherheitsfunktion aktiviert ist, leitet das Quell-Gateway das vom Gatekeeper in einer ACF empfangene Zugriffstoken an den H.323-Zielendpunkt in der H.225 SETUP-Nachricht weiter. Dieser H.323-Zielendpunkt leitet dann das in der SETUP-Nachricht empfangene Zugriffstoken in seiner Zulassungsanforderung an den Gatekeeper weiter. Auf diese Weise erhält der entfernte Gatekeeper die Möglichkeit, Anrufe basierend auf der Gültigkeit des Zugriffstokens zuzulassen. Der Inhalt des Zugriffstokens hängt von der Entität ab, die ihn generiert. Um Sicherheitslücken zu minimieren und sich vor Man-in-the-Middle-Angriffen zu schützen, können Gatekeeper zielspezifische Informationen im Zugriffstoken codieren. Wenn alternative Endpunkte in einer ACF bereitgestellt werden, kann der Gatekeeper ein separates Zugriffstoken für jeden angegebenen alternativen Endpunkt bereitstellen.
Beim ersten Verbindungsversuch sendet das Cisco Gateway das empfangene Zugriffstoken im clearToken-Feld der ACF mit der Adresse im destCallSignalAddress-Feld. Wenn dieser Versuch fehlgeschlagen ist und das Cisco Gateway den Verbindungsversuch mit einem alternativen Endpunkt fortsetzt, verwendet es das zugeordnete Zugriffstoken (sofern verfügbar) aus der Liste der alternativen Endpunkte. Wenn die in der ACF empfangene Liste alternativer Endpunkte keine Zugriffstoken enthält, die ACF jedoch ein Zugriffstoken enthält, enthält das Cisco Gateway dieses Zugriffstoken bei allen Verbindungsversuchen mit einem alternativen Endpunkt.
Derzeit werden das Open Settlement Protocol (OSP) und seine Token nur auf Cisco Gateways unterstützt. Es gibt keine Unterstützung für den Gatekeeper. Das Gateway erkennt von einem Abrechnungsserver empfangene OSP-Token und fügt sie in die Q.931-Einrichtungsnachricht an ein terminierendes Gateway ein.
Derzeit können keine unterschiedlichen Sicherheitsebenen für die einzelnen Endpunkte oder Zonen konfiguriert werden. Die Sicherheitsstufe gilt für alle von diesem Gatekeeper verwalteten Zonen. Bei einem solchen Problem kann eine Featureanforderung geöffnet werden.
Sicherheit zwischen Domänenübergreifenden Gatekeeper ermöglicht die Validierung von domäneninternen und domänenübergreifenden Gatekeeper-to-Gatekeeper-Anforderungen auf Basis einzelner Hops. Das bedeutet, dass der Ziel-Gatekeeper den CAT beendet und einen neuen generiert, wenn der Gatekeeper beschließt, die LRQ weiterzuleiten. Wenn der Gatekeeper eine ungültige LRQ-Signatur erkennt, antwortet er, indem er eine Location Reject (LRJ) sendet.
Der ursprüngliche Gatekeeper generiert eine IZCT, wenn bei einem zoneninternen Anruf eine LRQ initiiert wird oder eine ACF gesendet werden soll. Dieses Token wird über seinen Routing-Pfad durchlaufen. Entlang des Pfads aktualisiert jeder Gatekeeper die Ziel-Gatekeeper-ID und/oder die Quell-Gatekeeper-ID, falls erforderlich, um die Zoneninformationen wiederzugeben. Der abschließende Gatekeeper generiert ein Token mit seinem Passwort. Dieses Token wird in den Standortbestätigungsnachrichten (LCF) zurückgeführt und an den OGW übergeben. Das OGW enthält dieses Token in der H.225 SETUP-Nachricht. Wenn der TGW das Token empfängt, wird es im ARQ-AnswerCall weitergeleitet und vom Terminating Gate Eeper (TGK) validiert, ohne dass ein RADIUS-Server erforderlich ist.
Der Authentifizierungstyp basiert auf einem Kennwort mit Hashing, wie in ITU H.235 beschrieben. Die Verschlüsselungsmethode ist MD5 mit Kennwort-Hashing.
Der Zweck des IZCT ist es zu wissen, ob die LRQ aus einer fremden Domain, aus welcher Zone, und von welchem Träger angekommen ist. Er wird auch verwendet, um ein Token vom TGK an das OGW im LCF zu übergeben. Innerhalb des IZCT-Formats sind diese Informationen erforderlich:
srcCarrierID - Quell-Carrier-ID
dstCarrierID - Ziel-Carrier-ID
intCarrierID - Carrier-Kennung (Intermediate)
srcZone - Quellzone
dstZone - Zielzone
Interzonentyp
INTRA_DOMÄNE_CISCO
INTERDOMÄNE_CISCO
INTRA_DOMAIN_TERM_NOT_CISCO
INTERDOMAIN_ORIG_NOT_CISCO
Diese Funktion funktioniert einwandfrei, ohne dass eine Carrier-ID vom Gateway oder einem CSR-Server (Carrier Sensitive Routing) benötigt wird. In diesem Fall sind die Felder um die Carrier-ID leer. Die Beispiele hier enthalten keine Carrier-ID. Detaillierte Informationen zu Anruffluss, Release- und Plattform-Unterstützung sowie Konfigurationen finden Sie unter Inter-Domain Gatekeeper Security Enhancement (Erweiterte Sicherheit bei domänenübergreifendem Gatekeeper).
Für die IZCT-Funktion ist diese Konfiguration auf dem Gatekeeper erforderlich.
Router(gk-config)# [no] security izct password
Das Kennwort muss sechs bis acht Zeichen lang sein. Ermitteln Sie, welche Zone sich in einer Fremddomäne wie dieser befindet:
Router(config-gk)# zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address [port-number] [cost cost-value [priority priority-value]] [foreign-domain]
Dieses Diagramm zeigt den IZCT-Fluss.
Bei dieser Konfiguration sind die Namen der Gateways und Gatekeeper mit denen identisch, die im IZCT-Anrufflussdiagramm verwendet werden, jedoch in Kleinbuchstaben. Der Anruffluss wird im Anschluss an die Konfiguration erläutert, und es werden Erläuterungen zum Debuggen gegeben.
Um die IZCT-Funktion und den Anruffluss zu erläutern, fehlt im ersten Beispiel das Intra-Domain-Gateway zur Gatekeeper-Sicherheit. Danach gibt es Beispiele, in denen der TGW nicht in der Lage ist, den IZCT zu generieren, sodass der TGK1 den Anruf ablehnt. Damit soll gezeigt werden, dass die Funktion wie vorgesehen funktioniert. Alle diese Einrichtungen basieren auf der Topologie im IZCT-Anrufflussdiagramm.
Beispiel 1: Anruffluss nur für die Sicherheit von Gatekeeper zu Gatekeeper
Dieses Beispiel zeigt die zugehörigen Konfigurationen aller Gateways und Gatekeeper.
OGW-Konfiguration | TGW-Konfiguration |
---|---|
! hostname ogw !controller E1 3/0 pri-group timeslots 1-2,16 ! interface Ethernet0/0 ip address 172.16.13.15 255.255.255.224 half-duplex h323-gateway voip interface h323-gateway voip id ogk1 ipaddr 172.16.13.35 1718 h323-gateway voip h323-id ogw h323-gateway voip tech-prefix 1# ! voice-port 3/0:15 ! dial-peer voice 5336 pots incoming called-number . destination-pattern 5336 direct-inward-dial port 3/0:15 prefix 21 ! dial-peer voice 3653 voip incoming called-number . destination-pattern 3653 session target ras dtmf-relay h245-alphanumeric codec g711ulaw ! gateway ! ntp clock-period 17178791 ntp server 172.16.13.35 end |
hostname tgw ! controller E1 0 clock source line primary ds0-group 0 timeslots 1-2 type r2-digital r2-compelled ! interface Ethernet0 ip address 172.16.13.23 255.255.255.224 h323-gateway voip interface h323-gateway voip id tgk1 ipaddr 172.16.13.41 1718 h323-gateway voip h323-id tgw h323-gateway voip tech-prefix 2# ! voice-port 0:0 compand-type a-law ! dial-peer voice 3653 pots application test1 incoming called-number . destination-pattern 3653 port 0:0 prefix 21 ! dial-peer voice 5336 voip incoming called-number . destination-pattern 5336 session target ras dtmf-relay h245-alphanumeric codec g711ulaw ! gateway ! ntp clock-period 17179814 ntp server 172.16.13.35 end |
OGK1-Konfiguration | TGK1-Konfiguration |
---|---|
! hostname ogk1 ! interface Ethernet0/0 ip address 172.16.13.35 255.255.255.224 half-duplex ! gatekeeper zone local ogk1 domainA.com 172.16.13.35 zone remote ogk2 domainA.com 172.16.13.14 1719 zone prefix ogk2 36* zone prefix ogk1 53* security izct password 111222 gw-type-prefix 1#* default- technology no shutdown ! ! no scheduler max-task-time no scheduler allocate ntp master ! end |
! hostname tgk1 ! interface Ethernet0/0 ip address 172.16.13.41 255.255.255.224 ip directed-broadcast half-duplex ! gatekeeper zone local tgk1 domainB.com 172.16.13.41 zone remote tgk2 domainB.com 172.16.13.16 1719 zone prefix tgk1 36* zone prefix tgk2 53* security izct password 111222 gw-type-prefix 2#* default- technology no shutdown ! ntp clock-period 17179797 ntp server 172.16.13.35 ! end |
OGK2-Konfiguration | TGK2-Konfiguration |
---|---|
! hostname ogk2 ! interface Ethernet0/0 ip address 172.16.13.14 255.255.255.224 full-duplex ! gatekeeper zone local ogk2 domainA.com zone remote ogk1 domainA.com 172.16.13.35 1719 zone remote tgk2 domainB.com 172.16.13.16 1719 foreign-domain zone prefix tgk2 36* zone prefix ogk1 53* security izct password 111222 lrq forward-queries no shutdown ! ntp clock-period 17208242 ntp server 172.16.13.35 ! end |
! hostname tgk2 ! interface Ethernet0/0 ip address 172.16.13.16 255.255.255.224 half-duplex ! gatekeeper zone local tgk2 domainB.com zone remote tgk1 domainB.com 172.16.13.41 1719 zone remote ogk2 domainA.com 172.16.13.14 1719 foreign-domain zone prefix tgk1 36* zone prefix ogk2 53* security izct password 111222 lrq forward-queries no shutdown ! ntp clock-period 17179209 ntp server 172.16.13.35 ! end |
In diesen Beispielen wird der Anruffluss anhand der Debugging-Anweisungen erklärt.
Ein Benutzer auf Träger E ruft einen Benutzer auf Träger D an.
Mar 4 15:31:19.989: cc_api_call_setup_ind (vdbPtr=0x6264ADF0, callInfo={called=3653, called_oct3=0x80,calling=4085272923,calling_oct3=0x21,calling_oct3a=0x80 calling_xlated=false,subscriber_type_str=RegularLine,fdest=1,peer_tag=5336, prog_ind=0},callID=0x6219F9F0) Mar 4 15:31:19.993: cc_api_call_setup_ind type 13 , prot 0 Mar 4 15:31:19.993: cc_process_call_setup_ind (event=0x6231A6B4) Mar 4 15:31:19.993: >>>>CCAPI handed cid 7 with tag 5336 to app "DEFAULT" Mar 4 15:31:19.993: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(7), disp(0) Mar 4 15:31:19.993: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(7), disp(0) Mar 4 15:31:19.993: ssaCallSetupInd Mar 4 15:31:19.993: ccCallSetContext (callID=0x7, context=0x621533F0) Mar 4 15:31:19.997: ssaCallSetupInd cid(7), st(SSA_CS_MAPPING),oldst(0), ev(24) ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1 Mar 4 15:31:19.997: ssaCallSetupInd finalDest cllng(4085272923), clled(3653) Mar 4 15:31:19.997: ssaCallSetupInd cid(7), st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0 Mar 4 15:31:19.997: ssaSetupPeer cid(7) peer list: tag(3653) called number (3653) Mar 4 15:31:19.997: ssaSetupPeer cid(7), destPat(3653), matched(4), prefix(), peer(626640B0), peer->encapType (2) Mar 4 15:31:19.997: ccCallProceeding (callID=0x7, prog_ind=0x0) Mar 4 15:31:19.997: ccCallSetupRequest (Inbound call = 0x7, outbound peer=3653, dest=, params=0x62327730 mode=0, *callID=0x62327A98, prog_ind = 0) Mar 4 15:31:19.997: ccCallSetupRequest numbering_type 0x80 Mar 4 15:31:19.997: ccCallSetupRequest encapType 2 clid_restrict_disable 1 null _orig_clg 0 clid_transparent 0 callingNumber 4085272923 Mar 4 15:31:19.997: dest pattern 3653, called 3653, digit_strip 0 Mar 4 15:31:19.997: callingNumber=4085272923, calledNumber=3653, redirectNumber = display_info= calling_oct3a=80 Mar 4 15:31:19.997: accountNumber=, finalDestFlag=1, guid=221b.686c.17cc.11cc.8010.a049.e052.4766 Mar 4 15:31:19.997: peer_tag=3653 Mar 4 15:31:19.997: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=, callParams={called=3653,called_oct3=0x80, calling=4085272923,calling_oct3=0x21, calling_xlated=false, subscriber_type_str=RegularLine, fdest=1, voice_peer_tag=365 3},mode=0x0) vdbPtr type = 1 Mar 4 15:31:19.997: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=, callParams={called=3653, called_oct3 0x80, calling=4085272923,calling_oct3 0x21, calling_xlated=false, fdest=1, voice_peer_tag=3653}, mode=0x0, xltrc=-5) Mar 4 15:31:20.001: ccSaveDialpeerTag (callID=0x7, dialpeer_tag=0xE45) Mar 4 15:31:20.001: ccCallSetContext (callID=0x8, context=0x6215388C) Mar 4 15:31:20.001: ccCallReportDigits (callID=0x7, enable=0x0)
Da der Dial Peer (Tag=3653) des ursprünglichen Gateways für RAS konfiguriert ist, sendet es einen ARQ an OGK1.
Mar 4 15:31:20.001: H225 NONSTD OUTGOING PDU ::= value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } callingOctet3a 128 interfaceSpecificBillingId "ISDN-VOICE" } Mar 4 15:31:20.005: H225 NONSTD OUTGOING ENCODE BUFFER::= 80 000008A0 01800B12 4953444E 2D564F49 4345 Mar 4 15:31:20.005: Mar 4 15:31:20.005: RAS OUTGOING PDU ::= value RasMessage ::= admissionRequest : !--- ARQ is sent out to ogk1. { requestSeqNum 1109 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"81567A4000000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "4085272923", h323-ID : {"ogw"} } bandWidth 640 callReferenceValue 4 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008A001800B124953444E2D564F494345'H } conferenceID '221B686C17CC11CC8010A049E0524766'H activeMC FALSE answerCall FALSE canMapAlias TRUE callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } willSupplyUUIEs FALSE } Mar 4 15:31:20.013: RAS OUTGOING ENCODE BUFFER::= 27 88045400 F0003800 31003500 36003700 41003400 30003000 30003000 30003000 30003000 31010180 69860204 8073B85A 5C564002 006F0067 00774002 80000440 B5000012 13800000 08A00180 0B124953 444E2D56 4F494345 221B686C 17CC11CC 8010A049 E0524766 04E02001 80110022 1B686C17 CC11CC80 11A049E0 52476601 00 Mar 4 15:31:20.017: h323chan_dgram_send:Sent UDP msg. Bytes sent: 130 to 172.16.13.35:1719 Mar 4 15:31:20.017: RASLib::GW_RASSendARQ: ARQ (seq# 1109) sent to 172.16.13.35
Wenn OGK1 den ARQ empfängt, bestimmt es, dass das Ziel von der entfernten Zone OGK2 bedient wird. Anschließend wird festgestellt, dass ein IZCT erforderlich ist (über CLI: security izct password <pwd>). OGK1 fährt mit der Erstellung des IZCT fort, bevor die LRQ gesendet wird. Anschließend werden IZCT und LRQ an OGK2 gesendet und eine RIP-Nachricht an OGW zurückgesendet.
Mar 4 15:31:19.927: H225 NONSTD OUTGOING PDU ::= value LRQnonStandardInfo ::= { ttl 6 nonstd-callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } callingOctet3a 128 gatewaySrcInfo { e164 : "4085272923", h323-ID : {"ogw"} } } Mar 4 15:31:19.935: H225 NONSTD OUTGOING ENCODE BUFFER::= 82 86B01100 221B686C 17CC11CC 8011A049 E0524766 01801002 048073B8 5A5C5640 02006F00 670077 Mar 4 15:31:19.939: Mar 4 15:31:19.939: PDU ::= value IZCToken ::= !--- The gatekeeper creates and sends out the IZCT. { izctInterZoneType intraDomainCisco : NULL !--- The destination is in the same domain, it is intraDomainCisco type. izctSrcZone "ogk1" !--- The source zone is ogk1. ) Mar 4 15:31:19.943: ENCODE BUFFER::= 07 00C06F67 6B310473 72630464 73740469 6E74 Mar 4 15:31:19.947: Mar 4 15:31:19.947: RAS OUTGOING PDU ::= value RasMessage ::= locationRequest : !--- LRQ is sent out to ogk2. { requestSeqNum 2048 destinationInfo { e164 : "3653" } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '8286B01100221B686C17CC11CC8011A049E05247...'H } replyAddress ipAddress : { ip 'AC100D23'H port 1719 } sourceInfo { h323-ID : {"ogk1"} } canMapAlias TRUE tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '0700C06F676B31047372630464737404696E74'H } } } } Mar 4 15:31:19.967: RAS OUTGOING ENCODE BUFFER::= 4A 8007FF01 01806986 40B50000 12288286 B0110022 1B686C17 CC11CC80 11A049E0 52476601 80100204 8073B85A 5C56400 2 006F0067 007700AC 100D2306 B70BA00B 01400300 6F006700 6B003101 802B0100 80092A 86 4886F70C 0A010009 2A864886 F70C0A01 00130700 C06F676B 31047372 63046473 74046 96E 74 Mar 4 15:31:19.983: Mar 4 15:31:19.987: IPSOCK_RAS_sendto: msg length 122 from 172.16.13.35:1719 to 172.16.13.14: 1719 Mar 4 15:31:19.987: RASLib::RASSendLRQ: LRQ (seq# 2048) sent to 172.16.13.14 Mar 4 15:31:19.987: RAS OUTGOING PDU ::= value RasMessage ::= requestInProgress : !--- RIP message is sent back to OGW. { requestSeqNum 1109 delay 9000 } Mar 4 15:31:19.991: RAS OUTGOING ENCODE BUFFER::= 80 05000454 2327 Mar 4 15:31:19.991: Mar 4 15:31:19.991: IPSOCK_RAS_sendto: msg length 7 from 172.16.13.35:1719 to 172.16.13.15: 57076 Mar 4 15:31:19.991: RASLib::RASSendRIP: RIP (seq# 1109) sent to 172.16.13.15
Wenn OGK2 die LRQ empfängt, überprüft es die IZCT. Aus der Konfiguration geht hervor, dass die LRQ ebenfalls eine IZCT enthalten muss. OGK2 erstellt dann einen neuen IZCT, indem die izctSrcZone und die izctDstZone in ogk2 geändert werden und leitet den LRQ an TGK2 weiter. Nachdem der LRQ an TGK2 gesendet wurde, sendet er eine RIP-Nachricht an OGK1 zurück.
Wenn die Gatekeeper Teil eines Clusters sind, wird der Clustername für die SrcZone oder DstZone verwendet.
Mar 4 15:31:20.051: RAS OUTGOING PDU ::= value RasMessage ::= requestInProgress : !--- RIP message is sent back to OGK1. { requestSeqNum 2048 delay 6000 } Mar 4 15:31:20.055: RAS OUTGOING ENCODE BUFFER::= 80 050007FF 176F Mar 4 15:31:20.055: Mar 4 15:31:20.055: IPSOCK_RAS_sendto: msg length 7 from 172.16.13.14:1719 to 172.16.13.35: 1719 Mar 4 15:31:20.059: RASLib::RASSendRIP: RIP (seq# 2048) sent to 172.16.13.35 Mar 4 15:31:20.059: H225 NONSTD OUTGOING PDU ::= value LRQnonStandardInfo ::= { ttl 5 nonstd-callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } callingOctet3a 128 gatewaySrcInfo { e164 : "4085272923", h323-ID : {"ogw"} } } Mar 4 15:31:20.063: H225 NONSTD OUTGOING ENCODE BUFFER::= 82 06B01100 221B686C 17CC11CC 8011A049 E0524766 01801002 048073B8 5A5C5640 02006F00 670077 Mar 4 15:31:20.072: Mar 4 15:31:20.072: PDU ::= value IZCToken ::= { izctInterZoneType intraDomainCisco : NULL !--- This is still intraDomain since message OGK1 is !--- not a foreign domain. izctSrcZone "ogk2" !--- ScrZone and DstZone become ogk2. izctDstZone "ogk2" } Mar 4 15:31:20.076: ENCODE BUFFER::= 47 00C06F67 6B32066F 676B3204 73726304 64737404 696E74 Mar 4 15:31:20.080: Mar 4 15:31:20.080: RAS OUTGOING PDU ::= value RasMessage ::= locationRequest : !--- The LRQ is forwarded to TGK2. { requestSeqNum 2048 destinationInfo { e164 : "3653" } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '8206B01100221B686C17CC11CC8011A049E05247...'H } replyAddress ipAddress : { ip 'AC100D23'H port 1719 } sourceInfo { h323-ID : {"ogk1"} } canMapAlias TRUE tokens !--- IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '4700C06F676B32066F676B320473726304647374...'H } } } } Mar 4 15:31:20.104: RAS OUTGOING ENCODE BUFFER::= 4A 8007FF01 01806986 40B50000 12288206 B0110022 1B686C17 CC11CC80 11A049E0 52476601 80100204 8073B85A 5C564002 006F0067 007700AC 100D2306 B70BA00B 01400300 6F006700 6B003101 80300100 80092A86 4886F70C 0A010009 2A864886 F70C0A01 00184700 C06F676B 32066F67 6B320473 72630464 73740469 6E74 Mar 4 15:31:20.120: Mar 4 15:31:20.120: IPSOCK_RAS_sendto: msg length 127 from 172.16.13.14:1719 to 172.16.13.16: 1719 Mar 4 15:31:20.124: RASLib::RASSendLRQ: LRQ (seq# 2048) sent to 172.16.13.16
TGK2 bestimmt, dass die LRQ aus einer Fremddomäne stammt. Es aktualisiert die dstZone der IZCT mit einer eigenen ID und interZoneType als INTER_DOMAIN_CISCO. Anschließend wird eine neue CAT erstellt und die aktualisierte IZCT und die LRQ an TGK1 übergeben.
TGK2 behandelt die Zone, von der ein LRQ empfangen wird, in einem der beiden folgenden Szenarien als Zone einer Fremddomäne:
Die Remote-Zonenliste des TGK2 enthält nicht die Zone, von der ein LRQ empfangen wird.
Die Remote-Zonenliste des TGK2 enthält die Zone, von der ein LRQ empfangen wird. Die Zone wird mit einer Fremddomänenmarkierung markiert.
Anschließend wird eine Nachricht mit einer laufenden Anfrage an OGK1 gesendet.
Mar 4 15:31:20.286: RAS OUTGOING PDU ::= value RasMessage ::= requestInProgress : !--- The RIP message is sent back to !--- OGK1 since lrq-forward queries are configured on OGK2 and TGK2. { requestSeqNum 2048 delay 6000 } Mar 4 15:31:20.286: RAS OUTGOING ENCODE BUFFER::= 80 050007FF 176F Mar 4 15:31:20.286: Mar 4 15:31:20.286: IPSOCK_RAS_sendto: msg length 7 from 172.16.13.16:1719 to 172.16.13.35: 1719 Mar 4 15:31:20.286: RASLib::RASSendRIP: RIP (seq# 2048) sent to 172.16.13.35 Mar 4 15:31:20.286: H225 NONSTD OUTGOING PDU ::= value LRQnonStandardInfo ::= { ttl 4 nonstd-callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } callingOctet3a 128 gatewaySrcInfo { e164 : "4085272923", h323-ID : {"ogw"} } } Mar 4 15:31:20.290: H225 NONSTD OUTGOING ENCODE BUFFER::= 81 86B01100 221B686C 17CC11CC 8011A049 E0524766 01801002 048073B8 5A5C5640 02006F00 670077 Mar 4 15:31:20.290: Mar 4 15:31:20.290: PDU ::= value IZCToken ::= !--- The IZCT information. { izctInterZoneType interDomainCisco : NULL !--- The zone type is interDomain since the OGK2 !--- in a foreign domain is configured in TGK2. izctSrcZone "ogk2" !--- SrcZone is still ogk2. izctDstZone "tgk2" !--- DstZone changed to tgk2. } Mar 4 15:31:20.294: ENCODE BUFFER::= 47 20C06F67 6B320674 676B3204 73726304 64737404 696E74 Mar 4 15:31:20.294: Mar 4 15:31:20.294: RAS OUTGOING PDU ::= value RasMessage ::= locationRequest : !--- LRQ is sent to TGK1. { requestSeqNum 2048 destinationInfo { e164 : "3653" } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '8186B01100221B686C17CC11CC8011A049E05247...'H } replyAddress ipAddress : { ip 'AC100D23'H port 1719 } sourceInfo { h323-ID : {"ogk1"} } canMapAlias TRUE tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '4720C06F676B320674676B320473726304647374...'H } } } } Mar 4 15:31:20.302: RAS OUTGOING ENCODE BUFFER::= 4A 8007FF01 01806986 40B50000 12288186 B0110022 1B686C17 CC11CC80 11A049E0 52476601 80100204 8073B85A 5C564002 006F0067 007700AC 100D2306 B70BA00B 01400300 6F006700 6B003101 80300100 80092A86 4886F70C 0A010009 2A864886 F70C0A01 00184720 C06F676B 32067467 6B320473 72630464 73740469 6E74 Mar 4 15:31:20.306: Mar 4 15:31:20.306: IPSOCK_RAS_sendto: msg length 127 from 172.16.13.16:1719 to 172.16.13.41: 1719 Mar 4 15:31:20.306: RASLib::RASSendLRQ: LRQ (seq# 2048) sent to 172.16.13.41
Normalerweise aktualisiert TGK1 die dstCarrierID der IZCT auf Carrier E, die durch den Routing-Prozess bestimmt wird. Da jedoch keine Träger verwendet werden, sehen Sie das nicht. TGK1 generiert ein Hash-Token mit dem Kennwort der IZCT. Es sendet eine LCF mit dem aktualisierten IZCT an OGK1. Dieser izctHash wird verwendet, um die Ansageruf-ARQ zu authentifizieren, die TGK1 vom TGW empfängt, wenn der letztere die VoIP-Einrichtungsnachricht vom OGW empfängt.
Mar 4 15:31:20.351: PDU ::= value IZCToken ::= !--- IZCT with a hash is generated to be sent back to TGK2. { izctInterZoneType interDomainCisco : NULL izctSrcZone "ogk2" izctDstZone "tgk2" izctTimestamp 731259080 izctRandom 3 izctHash '5A7D5E18AA658A6A4B4709BA5ABEF2B9'H } Mar 4 15:31:20.355: ENCODE BUFFER::= 7F 20C06F67 6B320674 676B32C0 2B9620C7 0103105A 7D5E18AA 658A6A4B 4709BA5A BEF2B904 73726304 64737404 696E74 Mar 4 15:31:20.355: Mar 4 15:31:20.355: RAS OUTGOING PDU ::= value RasMessage ::= locationConfirm : !--- LCF is sent back to OGK1 since lrq-forward queries !--- are configured on OGK2 and TGK2. { requestSeqNum 2048 callSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } rasAddress ipAddress : { ip 'AC100D17'H port 55762 } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '000140020074006700770600740067006B003101...'H } destinationType { gateway { protocol { voice : { supportedPrefixes { } } } } mc FALSE undefinedNode FALSE } tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } } Mar 4 15:31:20.367: RAS OUTGOING ENCODE BUFFER::= 4F 07FF00AC 100D1706 B800AC10 0D17D9D2 40B50000 122F0001 40020074 00670077 06007400 67006B00 31011001 40020074 00670077 00AC100D 1706B800 00000000 00000000 00104808 0880013C 05010000 48010080 092A8648 86F70C0A 0100092A 864886F7 0C0A0100 307F20C0 6F676B32 0674676B 32C02B96 20C70103 105A7D5E 18AA658A 6A4B4709 BA5ABEF2 B9047372 63046473 7404696E 74 Mar 4 15:31:20.371: Mar 4 15:31:20.371: IPSOCK_RAS_sendto: msg length 154 from 172.16.13.41:1719 to 172.16.13.35: 1719 Mar 4 15:31:20.371: RASLib::RASSendLCF: LCF (seq# 2048) sent to 172.16.13.35
OGK1 extrahiert die IZCT aus der LCF und sendet sie in einer ACF an das OGW.
Mar 4 15:31:20.316: PDU ::= value IZCToken ::= !--- The extracted IZCT. { izctInterZoneType interDomainCisco : NULL izctSrcZone "ogk2" izctDstZone "tgk2" izctTimestamp 731259080 izctRandom 3 izctHash '5A7D5E18AA658A6A4B4709BA5ABEF2B9'H } Mar 4 15:31:20.324: ENCODE BUFFER::= 7F 20C06F67 6B320674 676B32C0 2B9620C7 0103105A 7D5E18AA 658A6A4B 4709BA5A BEF2B904 73726304 64737404 696E74 Mar 4 15:31:20.328: Mar 4 15:31:20.332: RAS OUTGOING PDU ::= value RasMessage ::= admissionConfirm : !--- ACF is sent back to OGW with the hashed IZCToken. { requestSeqNum 1109 bandWidth 640 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } irrFrequency 240 tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } } Mar 4 15:31:20.352: RAS OUTGOING ENCODE BUFFER::= 2B 00045440 028000AC 100D1706 B800EF1A 08C04801 0080092A 864886F7 0C0A0100 092A8648 86F70C0A 0100307F 20C06F67 6B320674 676B32C0 2B9620C7 0103105A 7D5E18AA 658A6A4B 4709BA5A BEF2B904 73726304 64737404 696E7401 00020000 Mar 4 15:31:20.364: Mar 4 15:31:20.364: IPSOCK_RAS_sendto: msg length 97 from 172.16.13.35:1719 to 172.16.13.15: 57076 Mar 4 15:31:20.368: RASLib::RASSendACF: ACF (seq# 1109) sent to 172.16.13.15
Das OGW sendet die IZCT in der H.225 SETUP-Nachricht an den TGW.
Mar 4 15:31:20.529: H225.0 OUTGOING PDU ::= value H323_UserInformation ::= { h323-uu-pdu { h323-message-body setup : !--- H.225 SETUP message is sent to TGW. { protocolIdentifier { 0 0 8 2250 0 2 } sourceAddress { h323-ID : {"ogw"} } sourceInfo { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } activeMC FALSE conferenceID '221B686C17CC11CC8010A049E0524766'H conferenceGoal create : NULL callType pointToPoint : NULL sourceCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11003 } callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } tokens !--- The hashed IZCT information is included in the setup message. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } fastStart { '0000000C6013800A04000100AC100D0F4125'H, '400000060401004C6013801114000100AC100D0F...'H } mediaWaitForConnect FALSE canOverlapSend FALSE } h245Tunneling TRUE nonStandardControl { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '6001020001041F04038090A31803A983816C0C21...'H } } } }
Der TGW leitet den IZCT in einem ARQ-AnswerCall an den TGK1 weiter.
Mar 4 15:31:20.613: Mar 4 15:31:20.613: RAS OUTGOING PDU ::= value RasMessage ::= admissionRequest : !--- ARQ answerCall type is sent to TGK1. { requestSeqNum 78 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"617D829000000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "4085272923", h323-ID : {"ogw"} } srcCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11003 } bandWidth 1280 callReferenceValue 3 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008800180'H } conferenceID '221B686C17CC11CC8010A049E0524766'H activeMC FALSE answerCall TRUE canMapAlias TRUE callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } tokens !--- The hashed IZCToken information is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } willSupplyUUIEs FALSE }
TGK1 authentifiziert die Ziel-IZCT erfolgreich. Dies liegt daran, dass TGK1 den Hash im IZCT generiert und eine ACF an den TGW zurücksendet.
Mar 4 15:31:20.635: Mar 4 15:31:20.635: PDU ::= value IZCToken ::= !--- The extracted IZCT from the ARQ to be validated. { izctInterZoneType interDomainCisco : NULL izctSrcZone "ogk2" izctDstZone "tgk2" izctTimestamp 731259080 izctRandom 3 izctHash '5A7D5E18AA658A6A4B4709BA5ABEF2B9'H } Mar 4 15:31:20.639: RAS OUTGOING PDU ::= value RasMessage ::= admissionConfirm : !--- After the IZCT is validated, ACF is sent back to TGW. { requestSeqNum 78 bandWidth 1280 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } irrFrequency 240 willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } }
Der TGW richtet den Anruf in Richtung Carrier D ein, nachdem er die ACF erhalten hat.
Beispiel 2: Anruf fehlgeschlagen, weil TGW die IZCT nicht aus der empfangenen Einrichtungsnachricht extrahieren kann.
Dieses Beispiel basiert auf derselben Topologie und Konfiguration wie in Beispiel 1. In diesem Beispiel wird die Software des TGW in eine Version geändert, in der IZCT nicht unterstützt wird. In diesem Fall kann der TGW die IZCT nicht aus der Setup-Meldung extrahieren. Dies veranlasst den TGK1, den Anruf mit einem Grund für die Verbindungstrennung bei der Sicherheitsverweigerung abzulehnen.
In diesem Beispiel werden nur die Einrichtungsmeldung ARQ und der ARJ auf dem TGW angezeigt, da der Anruffluss mit Beispiel 1 identisch ist.
Mar 4 19:50:32.346: PDU DATA = 6147C2BC value H323_UserInformation ::= { h323-uu-pdu { h323-message-body setup : !--- H.225 SETUP message is received with a token included. { protocolIdentifier { 0 0 8 2250 0 2 } sourceAddress { h323-ID : {"ogw"} } sourceInfo { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } activeMC FALSE conferenceID '56CA67C817F011CC8014A049E0524766'H conferenceGoal create : NULL callType pointToPoint : NULL sourceCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11004 } callIdentifier { guid '56CA67C817F011CC8015A049E0524766'H } tokens !--- Hashed IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B965D85010410...'H } } } fastStart { '0000000C6013800A04000100AC100D0F45D9'H, '400000060401004C6013801114000100AC100D0F...'H } mediaWaitForConnect FALSE canOverlapSend FALSE } h245Tunneling TRUE nonStandardControl { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '6001020001041F04038090A31803A983816C0C21...'H } } } } RAW_BUFFER::= 60 01020001 041F0403 8090A318 03A98381 6C0C2180 34303835 32373239 32337005 80333635 33 Mar 4 19:50:32.362: PDU DATA = 6147F378 value H323_UU_NonStdInfo ::= { version 2 protoParam qsigNonStdInfo : { iei 4 rawMesg '04038090A31803A983816C0C2180343038353237...'H } } PDU DATA = 6147F378 value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } callingOctet3a 128 } RAW_BUFFER::= 80 00000880 0180 Mar 4 19:50:32.366: PDU DATA = 6147C2BC value RasMessage ::= admissionRequest : !--- ARQ is sent out. There is no token in it. { requestSeqNum 23 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"617D829000000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "4085272923" } srcCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11004 } bandWidth 640 callReferenceValue 1 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008800180'H } conferenceID '56CA67C817F011CC8014A049E0524766'H activeMC FALSE answerCall TRUE canMapAlias FALSE callIdentifier { guid '56CA67C817F011CC8015A049E0524766'H } willSupplyUUIEs FALSE } RAW_BUFFER::= 27 98001600 F0003600 31003700 44003800 32003900 30003000 30003000 30003000 30003000 31010180 69860104 8073B85A 5C5600AC 100D0F2A FC400280 000140B5 00001207 80000008 80018056 CA67C817 F011CC80 14A049E0 52476644 E0200100 110056CA 67C817F0 11CC8015 A049E052 47660100 Mar 4 19:50:32.374: h323chan_dgram_send:Sent UDP msg. Bytes sent: 117 to 172.16.13.41:1719 Mar 4 19:50:32.374: RASLib::GW_RASSendARQ: ARQ (seq# 23) sent to 172.16.13.41 Mar 4 19:50:32.378: h323chan_dgram_recvdata:rcvd from [172.16.13.41:1719] on sock[1] RAW_BUFFER::= 2C 00168001 00 Mar 4 19:50:32.378: PDU DATA = 6147C2BC value RasMessage ::= admissionReject : !--- ARJ is received with a reason of security denial. { requestSeqNum 23 rejectReason securityDenial : NULL } Mar 4 19:50:32.378: ARJ (seq# 23) rcvd
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
22-Jan-2002 |
Erstveröffentlichung |