Gateway to Gatekeeper (H.235) en Gatekeeper to Gatekeeper (IZCT) Handleiding voor het oplossen van beveiligingsproblemen

Inleiding

H.323-netwerken hebben verschillende soorten configuraties en oproepstromen. Dit document bespreekt de meeste beveiligingsproblemen met H.323-netwerken waarbij poortwachters betrokken zijn. Dit document vat de manier samen waarop elke functie werkt en hoe u problemen kunt oplossen met een uitleg over de meeste debugs. Dit document heeft geen betrekking op de algemene beveiliging van VoIP.

In dit document worden deze kenmerken behandeld:

• Intradomain Gateway to Gatekeeper Security—Deze beveiliging is gebaseerd op H.235, waarin H.323-oproepen worden geverifieerd, geautoriseerd en gerouteerd door een gatekeeper. De gatekeeper wordt beschouwd als een bekende en vertrouwde entiteit in die zin dat de gateway deze niet verifieert wanneer de gateway probeert zich bij hem te registreren.

• Interdomain Gatekeeper to Gatekeeper Security—Deze beveiliging omvat het authenticeren en autoriseren van H.323-oproepen tussen de administratieve domeinen van Internet Telephone Service Providers (ITSP's) met behulp van InterZone Clear Token (IZCT). Dit document heeft alleen betrekking op het gedeelte waar de afsluitende poortwachter een token verzendt in het locatiebevestigingsbericht (LCF), zodat het het antwoordoproep-toegangsverzoek (ARQ) verifieert. Validering van locatieaanvraag (LRQ) is niet inbegrepen in deze functie. LRQ-validatie is een functie die is gepland voor een toekomstige Cisco IOS®-softwarerelease.

Definities

Intradomain Gateway to Gatekeeper Security

H.323 is een ITU-aanbeveling die zich richt op het beveiligen van real-time communicatie over onveilige netwerken. Het gaat om twee belangrijke aandachtsgebieden: authenticatie en privacy. Er zijn twee soorten authenticatie, volgens H.235:

• Symmetrische op encryptie gebaseerde authenticatie die geen voorafgaand contact tussen de communicerende entiteiten vereist.

• Op basis van de mogelijkheid om vooraf een gedeeld geheim te hebben (verder aangeduid als abonnementsgebaseerd), worden twee vormen van op abonnementen gebaseerde authenticatie aangeboden:

  • wachtwoord

  • getuigschrift

Tijdstempel verstreken in de tokens

Een tijdstempel wordt gebruikt om replay-aanvallen te voorkomen. Daarom is het nodig voor een wederzijds aanvaardbare verwijzing naar tijd (waaruit tijdstempels kunnen worden afgeleid). De hoeveelheid aanvaardbare tijdsvervorming is een kwestie van lokale implementatie.

Hoe Cisco de H.235-aanbeveling implementeert

Cisco gebruikt een Challenge Handshake Authentication Protocol (CHAP)-achtig authenticatieschema als basis voor zijn gateway naar de implementatie van gatekeeper H.235. Hiermee kunt u gebruikmaken van verificatie, autorisatie en boekhouding (AAA), met behulp van bestaande functionaliteit om de daadwerkelijke verificatie uit te voeren. Het betekent ook dat de poortwachter geen toegang hoeft te hebben tot een database met gateway-ID's, gebruikersaccountnummers, wachtwoorden en pincodes. De regeling is gebaseerd op H.235, paragraaf 10.3.3. Het wordt beschreven als een wachtwoord op basis van een abonnement met hashing.

In plaats van H.225 cryptoTokens te gebruiken, gebruikt deze methode echter H.235 clearTokens met velden die op de juiste manier zijn ingevuld voor gebruik met RADIUS. Dit token wordt het Cisco Access Token (CAT) genoemd. U kunt de verificatie altijd lokaal uitvoeren op de poortwachter in plaats van een RADIUS-server te gebruiken.

Het gebruik van cryptoTokens vereist dat de poortwachter wachtwoorden voor alle gebruikers en gateways onderhoudt of heeft. Dit komt omdat het tokenveld van de cryptoToken zodanig is gespecificeerd dat de authenticerende entiteit het wachtwoord nodig heeft om zijn eigen token te genereren waarmee de ontvangen token kan worden vergeleken.

Cisco-poortwachters negeren cryptoTokens volledig. Echter, vocalTek gatekeepers en anderen die H.235 sectie 10.3.3 ondersteunen, gebruiken de cryptoTokens om de gateway te authenticeren. Cisco-poortwachters gebruiken de CAT om de gateway te verifiëren. Omdat de gateway niet weet met welk type poortwachter hij praat, stuurt hij beide in de RRQ. De authenticationCapability in de GRQ zijn voor de cryptoToken en geven aan dat de MD5 hashing het authenticatiemechanisme is (hoewel de CAT ook MD5 gebruikt).

Raadpleeg Cisco H.323 Gateway Security and Accounting Enhancements voor meer informatie.

De beveiligingsniveaus configureren

• Beveiliging op eindpunt- of registratieniveau

  Als Registratiebeveiliging is ingeschakeld op de poortwachter, moet de gateway een CAT opnemen in alle RRQ-berichten met zwaar gewicht. De CAT bevat in dit geval informatie die de toegangspoort zelf verifieert aan de poortwachter. De poortwachter formatteert een bericht naar een RADIUS-server die de informatie in de token verifieert. Het reageert terug naar de poortwachter met een Access-Accept of Access-Reject. Dit, op zijn beurt, reageert op de gateway met ofwel een RCF of een RRJ.

  Als een oproep vervolgens wordt geplaatst vanuit een met succes geverifieerde gateway, genereert die gateway een nieuwe CAT na ontvangst van een ACF van de gatekeeper met behulp van het gateway-wachtwoord. Deze CAT is identiek aan de CAT die tijdens de registratie is gegenereerd, met uitzondering van de tijdstempel. Deze wordt in het uitgaande SETUP-bericht geplaatst. De bestemmingsgateway extraheert het token uit het SETUP-bericht en plaatst het in de bestemmingszijde ARQ. De poortwachter gebruikt RADIUS om de oorspronkelijke gateway te verifiëren voordat deze de ACF aan de bestemmingszijde verzendt. Dit voorkomt dat een niet-geverifieerd eindpunt dat het adres van een gateway kent, het gebruikt om het beveiligingsschema te omzeilen en toegang te krijgen tot het openbare geschakelde telefoonnetwerk (PSTN).

  Daarom is het in dit niveau niet nodig tokens op te nemen in de oorspronkelijke ARQ's.

  Typ [geen] beveiligingstoken dat vereist is voor registratie vanuit de opdrachtregelinterface (CLI) van de gatekeeper om de gatekeeper te configureren. De geen optie van de opdracht zorgt ervoor dat de poortwachter niet langer controleert op tokens in RAS-berichten.

  Typ [geen] beveiligingswachtwoord <PASSWORD>-eindpuntniveau vanuit de CLI van de gateway om de gateway te configureren. De geen optie van de opdracht zorgt ervoor dat de gateway geen tokens meer genereert voor RAS-berichten.

• Beveiligingsniveau per oproep

  De beveiliging per oproep is gebaseerd op de beveiliging op registratieniveau. Naast het voldoen aan de vereisten voor registratiebeveiliging, is een gateway ook verplicht om Access Tokens op te nemen in alle uitgaande ARQ-berichten aan de zijkant wanneer Per-call beveiliging is ingeschakeld op de gatekeeper. Het token bevat in dit geval informatie die de gebruiker van de gateway naar de poortwachter identificeert. Deze informatie wordt verkregen met behulp van een Interactive Voice Response (IVR) -script op de gateway. Dit vraagt gebruikers om hun gebruikersnaam en pincode in te voeren vanaf het toetsenbord voordat ze een oproep plaatsen.

  De CAT in de oorspronkelijke ARQ wordt op dezelfde manier door RADIUS geverifieerd als eerder beschreven in Eindpunt- of Registratieniveau Beveiliging. Nadat het de ACF heeft ontvangen, genereert de gateway een nieuwe CAT met behulp van zijn wachtwoord en verzendt deze binnen het H.225 SETUP-bericht naar de afsluitende gateway.

  Typ [geen] beveiligingstoken vereist voor iedereen van de gatekeeper CLI om de gatekeeper te configureren. De geen optie van de opdracht zorgt ervoor dat de poortwachter niet langer controleert op tokens in RAS-berichten.

  Typ [geen] beveiligingswachtwoord <WACHTWOORD> niveau per oproep van de gateway-CLI om de gateway te configureren. De geen optie van de opdracht zorgt ervoor dat de gateway geen tokens meer genereert voor RAS-berichten.

• Beveiliging op alle niveaus

  Hierdoor kan de gateway een CAT opnemen in alle RAS-berichten die nodig zijn voor registratie en voor oproepen. Het is een combinatie van de twee bovenstaande niveaus. Met deze optie wordt de validatie van CAT in ARQ-berichten gebaseerd op het accountnummer en de PIN van de gebruiker die belt. De validatie van de CAT die in alle andere RAS-berichten wordt verzonden, is gebaseerd op het wachtwoord dat voor de gateway is geconfigureerd. Dit is vergelijkbaar met het niveau per oproep.

  Typ [geen] beveiligingstoken vereist voor iedereen van de gatekeeper CLI om de gatekeeper te configureren. De geen optie van de opdracht zorgt ervoor dat de poortwachter niet langer controleert op tokens in RAS-berichten.

  Typ [no] beveiligingswachtwoord <PASSWORD>-niveau vanuit de CLI van de gateway om de gateway te configureren. De geen optie van de opdracht zorgt ervoor dat de gateway geen tokens meer genereert voor RAS-berichten.

H.235 Gebruik op een niveau per oproep zonder IVR

H.235 kan niet worden gebruikt op een per-call niveau zonder IVR. Als er geen IVR is om een account en pincode te verzamelen, moet de gateway de ARQ verzenden zonder een Clear Token (maar met een crypto-token). Omdat de Cisco-poortwachter alleen Clear Tokens accepteert, wordt de oproep afgewezen door de poortwachter met een reden van beveiligingsontkenning.

Dit voorbeeld toont de h225 asn1-debugs verzameld van een gateway (OGW) die niet is geconfigureerd voor een IVR om het account en de pincode te verzamelen. Het RRQ-bericht heeft een Clear Token, maar de ARQ niet. Een ARJ-bericht wordt teruggestuurd naar de gateway.

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

Belangrijkste kwesties

De belangrijkste zaken waar u zich zorgen over moet maken, zijn:

• Configuratie van de gateway en poortwachter

• RADIUS-configuratie op de poortwachter en de RADIUS-server

• Network Time Protocol (NTP)—U moet dezelfde tijd hebben op alle gateways en poortwachters. Omdat de verificatiegegevens een tijdstempel bevatten, is het belangrijk dat alle Cisco H.323-gateways en de gatekeepers (of andere entiteit die de verificatie uitvoert) worden gesynchroniseerd. De Cisco H.323-gateways moeten worden gesynchroniseerd met behulp van NTP.

• Softwarestoring door een bug

Debugs en Call Flow voor de verschillende niveaus

Omdat alle beveiligingsniveaus zowel registratie- als oproepgevallen omvatten, is het lab opgezet met dat beveiligingsniveau voor deze oefening. De oproepstromen voor het registratiegedeelte en een normale VoIP-oproep worden hier uitgelegd in de configuratie.

Opmerking: de configuratie is hier niet voltooid. Er volgen meer opdrachten tussen de debug-uitgangen. Het is ontworpen om te laten zien welk probleem kan gebeuren als u niet alle dingen controleert, zoals configuratie, NTP en RADIUS. Bovendien wordt de gateway lokaal geverifieerd op de gatekeeper, zodat u kunt zien welke waarden zijn ingesteld voor de gateway-ID en het wachtwoord. Deze configuratie wordt afgekapt zodat alleen de bijbehorende configuratie wordt weergegeven.

!
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

Deze debugs zijn ingeschakeld in dit voorbeeld:

• debug ras

• Foutopsporing H225 ASN1

• debug radius

• debug aaa authentication

• Debug AAA-autorisatie

Het eerste dat zich voordoet is dat de gateway een GRQ naar de poortwachter stuurt en de poortwachter een GCF naar de gateway. De gateway verzendt vervolgens een RRQ en wacht op een RCF of RRJ.

In de vorige configuratie is de gateway niet ingesteld voor een bepaald beveiligingsniveau, zodat de GRQ geen verificatiecapaciteit heeft die nodig is voor de tokens. De poortwachter stuurt echter nog steeds een GCF terug, zoals deze uitvoer laat zien:

*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 }
   }
  }

Dit verklaart enkele van de berichten in de GRQ:

• authenticationCapability—Dit veld heeft alleen de waarde pwdHash. Het geeft aan dat de MD5 hashing het authenticatiemechanisme is.

• algoritmeOIDs: het algoritme Object ID. In dit geval draagt het de waarde (1 2 840 113549 2 5) die het object ID is voor Message Digest 5 hashing.

  (1 2 840 113549 2 5) vertaalt naar iso(1) ledenlichaam(2) US(840) rsadsi(113549) digestAlgoritme(2) md5(5). Daarom doet Cisco MD5-wachtwoordhashing.

  Rsadsi staat voor RSA Data Security Inc. RSA Data Security, Inc.'s Open Systems Interconnection (OSI) object identifier is 1.2.840.113549 (0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d in hex), zoals geregistreerd door het American National Standards Institute (ANSI).

De poortwachter stuurt opnieuw een GCF als het vorige bericht. De gateway verzendt vervolgens een RRQ met bepaalde velden om de tokens te beschrijven die het gebruikt om te worden geverifieerd. Het asn1 RRQ-bericht dat wordt verzonden, wordt in dit voorbeeld weergegeven.

*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
   }

Voordat de reactie wordt besproken, worden enkele van de gerelateerde velden in het bovenstaande RRQ-bericht hier uitgelegd. Er zijn twee soorten tokens: een duidelijke token (of CAT) en een crypto-token.

Zoals eerder vermeld, negeren Cisco-poortwachters de crypto-tokens. De gateway stuurt echter nog steeds beide omdat hij niet weet naar welk type poortwachter hij praat. Omdat andere leveranciers cryptotokens kunnen gebruiken, verzendt de gateway beide.

Dit verklaart de ClearToken-syntaxis.

• tokenOID—De Object ID om de token te identificeren.

• timeStamp—De huidige Gecoördineerde Universele Tijd (UTC) tijd van de gateway. Seconden sinds 00:00 1/1/1970 UTC.

  Het wordt gebruikt als een geïmpliceerde CHAP-Challenge alsof het in eerste instantie afkomstig was van de poortwachter.

• uitdaging—Een 16-byte MD5-berichtdiagram dat door de gateway wordt gegenereerd met behulp van deze velden:

  challenge = [ random + GW/User Password + timeStamp ] MD5 Hash

  RADIUS voert deze berekening uit (omdat het het willekeurige nummer, het gateway-wachtwoord en de CHAP-uitdaging kent) om te bepalen wat de uitdaging moet zijn: CHAP Response = [ CHAP ID + UserPassword + CHAP Challenge ] MD5 Hash

• willekeurig: een waarde van één byte die door RADIUS wordt gebruikt om dit specifieke verzoek te identificeren.

  De gateway verhoogt een variabele module van 256 voor elk verificatieverzoek om aan deze RADIUS-vereiste te voldoen.

• generalID—De gateway H323-ID of het gebruikersaccountnummer op basis van het beveiligingsniveau en het type RAS-bericht.

Opmerking: al deze velden zijn belangrijk. Er wordt echter meer aandacht besteed aan zowel de tijdstempel als de algemene ID. In dit geval is de tijdstempel 731030839 en de algemene ID is gwa-1@cisco.com.

De cryptoToken in de RRQ bevat informatie over de gateway die het token genereert. Dit omvat de gateway-ID (de H.323-ID die op de gateway is geconfigureerd) en het gateway-wachtwoord.

Dit veld bevat een van de typen cryptoToken die zijn gedefinieerd voor het veld CryptoH323Token dat is gespecificeerd in H.225. Momenteel is het enige type cryptoToken dat wordt ondersteund de cryptoEPPwdHash.

Deze velden bevinden zich in het veld cryptoEPPwdHash:

• alias—De gateway alias, die de H.323 ID van de gateway is.

• timestamp—De huidige tijdstempel.

• Token—Het Message Digest 5 (MD5)-gecodeerde PwdCertToken. Dit veld bevat de volgende items:

  • timestamp—Hetzelfde als de timestamp van de cryptoEPPwdHash.

  • wachtwoord: het wachtwoord van de gateway.

  • generalID—Dezelfde gateway-alias als die welke is opgenomen in de cryptoEPPwdHash.

  • tokenID: de object-ID.

Bekijk het antwoord van de poortwachter in dit voorbeeld.

*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:

De RRQ wordt afgewezen door de poortwachter. De reden hiervoor is dat er geen NTP is ingesteld in de configuratie van de gateway. De poortwachter controleert de tijdstempel van het token om te zien of het zich binnen een aanvaardbaar venster bevindt ten opzichte van zijn eigen tijd. Momenteel is dit venster +/- 30 seconden rond de UTC-tijd van de poortwachter.

Een token buiten dit venster zorgt ervoor dat de poortwachter dit bericht weggooit. Dit voorkomt replay-aanvallen van iemand die een gesnuffeld token probeert te hergebruiken. In de praktijk moeten alle gateways en poortwachters NTP gebruiken om dit tijdsprobleem te voorkomen. De poortwachter vindt dat de tijdstempel in het token binnen het acceptabele venster van zijn tijd ligt. Daarom controleert het niet bij RADIUS om de gateway te verifiëren.

De gateway wordt vervolgens geconfigureerd voor NTP die naar de gatekeeper verwijst als de NTP-master, zodat zowel de gateway als de gatekeeper dezelfde tijd hebben. Wanneer dit gebeurt, verzendt de gateway een nieuwe RRQ en deze keer antwoordt de gatekeeper terug naar de nieuwe RRQ met een RRJ.

Deze debugs zijn van de poortwachter. Debugs worden uitgevoerd om te zien of de poortwachter naar de authenticatiefase gaat.

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"}
  }

Na het configureren van NTP wijst de poortwachter nog steeds de RRQ af. Deze keer gaat het echter door het authenticatieproces voor die gateway. De poortwachter wijst de RRQ af omdat de gebruiker (hier de gateway-ID) niet wordt gevonden in de lijst met geldige gebruikers op de RADIUS. De gateway wordt lokaal geverifieerd in de configuratie van de gatekeeper. Op de gebruikerslijst zie je gwa-1. Dat is echter niet de juiste gebruiker, aangezien de gebruiker in de RRQ gwa-1@cisco.com is.

Ook, zodra de gebruikersnaam gwa-1@cisco.com wachtwoord 0 2222 commando is geconfigureerd op de gatekeeper, de gatekeeper bevestigt de RRQ en de gateway is geregistreerd.

In dit lab wordt een andere gateway (gwa-2) geregistreerd bij dezelfde gatekeeper (gka-1). Er wordt een oproep gedaan van gwa-1@cisco.com naar gwa-2 om te zien hoe de ARQ-, ACF- en setup-berichten eruit zien.

Deze debugs zijn verzameld van de oorsprong en het beëindigen van gateway (gwa-2).

• Foutopsporing H225 ASN1

• debug ras

• VoIP-capi-ingang voor foutopsporing

Een uitleg van een aantal van de debug berichten is opgenomen.

Voordat u de debugs afdrukt vanaf de gateway die wordt gestart/beëindigd, wordt in deze tekst de aanroepstroom uitgelegd:

1. Wanneer een SETUP-bericht wordt ontvangen van de PSTN, verzendt de gateway een ARQ naar en ontvangt een ACF van de poortwachter.

2. Wanneer de gateway de ACF ontvangt, genereert de gateway een CAT met behulp van het gateway-wachtwoord, H323-ID-alias en de huidige tijd. De token wordt in het Call Control Block (CCB) geplaatst.

3. Wanneer de gateway het SETUP-bericht naar de afsluitende gateway verzendt, haalt deze het toegangstoken op van de CCB en plaatst deze in het veld nonStandardParameter van een clearToken in het SETUP-bericht.

4. De afsluitende gateway verwijdert het token uit het SETUP-bericht, converteert het van een niet-StandardParameter naar een CAT en plaatst het in de ARQ.

5. De poortwachter controleert de tijdstempel van het token om te zien of het zich binnen een aanvaardbaar venster bevindt ten opzichte van zijn eigen tijd. Momenteel is dit venster +/- 30 seconden rond de UTC-tijd van de poortwachter. Een token buiten dit venster zorgt ervoor dat de poortwachter dit bericht weggooit. Dit zorgt ervoor dat de oproep wordt afgewezen.

6. Als het token acceptabel is, formatteert de poortwachter een RADIUS-toegangspakket, vult de juiste attributen in om een CHAP-uitdaging te verifiëren en verzendt deze naar een RADIUS-server.

7. Op basis van de veronderstelling dat de alias van de gateway bekend is op de server, zoekt de server het wachtwoord dat aan deze alias is gekoppeld en genereert hij zijn eigen CHAP-reactie met behulp van het alias, wachtwoord en de CHAP-uitdaging van de gatekeeper. Als de CHAP-respons overeenkomt met de respons die is ontvangen van de poortwachter, verzendt de server een Access Accept-pakket naar de poortwachter. Als ze niet overeenkomen of als het alias van de gateway niet in de database van de server staat, stuurt de server een Access Reject-pakket terug naar de gatekeeper.

8. De poortwachter reageert op de gateway met een ACF als deze een Access Accept ontvangt, of een ARJ met beveiligingscodeDenial als deze een Access Reject ontvangt. Als de gateway een ACF ontvangt, is de oproep verbonden.

Dit voorbeeld toont het debug van de oorspronkelijke gateway.

Opmerking: De h225 asn1-debugs voor de installatie bevinden zich niet in dit voorbeeld, omdat dit hetzelfde is als in het voorbeeld van de terminerende gateway dat het voorbeeld van de oorspronkelijke gateway volgt.

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

Dit voorbeeld toont de debugs van de terminating gateway (TGW). Merk op dat de TGW het tweede been heeft ingesteld sinds hij ACF heeft en dat het gesprek is aangesloten.

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)

Probleem met gateway-IOS

In hetzelfde lab wordt IOS-afbeelding 12.2 (6a) op de OGW geladen. Wanneer een oproep wordt gedaan, wordt opgemerkt dat de OGW nog steeds een Clear Token stuurt op basis van het wachtwoord, hoewel de gateway niet is geconfigureerd voor IVR om de Account / PIN te verzamelen. Bovendien accepteert de poortwachter die is geconfigureerd voor alle niveaus die oproep. Dit is gedocumenteerd in Cisco bug ID CSCdw43224 (alleen geregistreerde klanten).

Beveiliging met alternatieve eindpunten

Zoals eerder vermeld in dit document, is end-to-end gespreksbeveiliging voorzien van het gebruik van toegangstokens die worden verzonden in het clearTokens-veld in de RAS / H.225-berichten. Bij het inschakelen van een dergelijke beveiliging stuurt de brongateway het toegangstoken dat is ontvangen van de poortwachter in een ACF door naar het eindpunt van bestemming H.323 in het H.225 SETUP-bericht. Dit eindpunt van bestemming H.323 stuurt vervolgens het toegangstoken dat is ontvangen in het SETUP-bericht door naar de poortwachter in zijn toelatingsverzoek. Door dit te doen, geeft het de externe poortwachter de mogelijkheid om oproepen toe te laten op basis van de geldigheid van het toegangstoken. De inhoud van het toegangstoken is afhankelijk van de entiteit die het genereert. Om gaten in de beveiliging te minimaliseren en te beschermen tegen man-in-the-middle-aanvallen, kunnen poortwachters bestemmingsspecifieke informatie in het toegangstoken coderen. Dit betekent dat wanneer alternatieve Eindpunten worden verstrekt in een ACF, de poortwachter een afzonderlijke toegangstoken kan bieden voor elk opgegeven alternatieve Eindpunt.

Wanneer de Cisco-gateway voor het eerst probeert een verbinding tot stand te brengen, verzendt deze het toegangstoken dat hij heeft ontvangen in het clearToken-veld van de ACF met het adres in het destCallSignalAddress-veld. Als deze poging mislukt en de Cisco-gateway vervolgens probeert verbindingen met een alternatief eindpunt te maken, wordt het gekoppelde toegangstoken gebruikt (indien beschikbaar) uit de lijst met alternatieve eindpunten. Als de lijst met alternatieve eindpunten die in de ACF is ontvangen geen toegangstokens bevat, maar de ACF wel een toegangstoken bevat, neemt de Cisco-gateway dit toegangstoken op in alle pogingen om verbinding te maken met een alternatief eindpunt.

OSP-tokenondersteuning

Momenteel worden het Open Settlement Protocol (OSP) en de tokens alleen ondersteund op Cisco-gateways. Er is geen ondersteuning op de poortwachter. De gateway herkent OSP-tokens die zijn ontvangen van een settlementserver en voegt deze in het installatiebericht Q.931 in een afsluitende gateway in.

Verschillende beveiligingsniveaus voor elk eindpunt of elke zone

Op dit moment kunt u geen verschillende beveiligingsniveaus configureren voor elk eindpunt of elke zone. Het beveiligingsniveau is voor alle zones die door die poortwachter worden beheerd. Voor een dergelijk probleem kan een aanvraag voor een functie worden geopend.

Interdomein Gatekeeper naar Gatekeeper Security

Interdomain gatekeeper-to-gatekeeper-beveiliging biedt de mogelijkheid om verzoeken voor intradomein- en interdomeingatekeeper-to-gatekeeper per hop te valideren. Dit betekent dat de bestemmingspoortwachter de CAT beëindigt en een nieuwe genereert als de poortwachter besluit de LRQ verder door te sturen. Als de poortwachter een ongeldige LRQ-handtekening detecteert, reageert deze door een locatieverwerping (LRJ) te verzenden.

Implementeren van Gatekeeper naar Gatekeeper Security

De oorspronkelijke poortwachter genereert een IZCT wanneer een LRQ wordt geïnitieerd of een ACF op het punt staat te worden verzonden in het geval van een oproep binnen de zone. Deze token wordt doorkruist door zijn routeringspad. Langs het pad werkt elke poortwachter de doelpoortwachter-ID en/of de bronpoortwachter-ID bij, indien nodig, om de zone-informatie weer te geven. De afsluitende poortwachter genereert een token met zijn wachtwoord. Dit token wordt teruggevoerd in de locatiebevestigingsberichten (LCF) en doorgegeven aan OGW. De OGW neemt dit token op in het H.225 SETUP-bericht. Wanneer de TGW het token ontvangt, wordt het doorgestuurd in de ARQ-antwoordoproep en gevalideerd door de terminerende poortwachter (TGK) zonder dat er een RADIUS-server nodig is.

Het verificatietype is gebaseerd op wachtwoord met hashing zoals beschreven in ITU H.235. De encryptiemethode is MD5 met wachtwoordhashing.

Het doel van de IZCT is om te weten of de LRQ afkomstig is uit een buitenlands domein, uit welke zone en van welke vervoerder. Het wordt ook gebruikt om een token door te geven aan de OGW in de LCF van de TGK. Binnen het IZCT-formaat is deze informatie vereist:

• srcCarrierID—Identificatie van brondrager

• dstCarrierID—Identificatie van bestemmingsvervoerder

• intCarrierID—identificatie van tussenliggende draaggolf

• srcZone—Bronzone

• dstZone—Bestemmingszone

• interzonetype

  • INTRA_DOMAIN_CISCO

  • INTER_DOMAIN_CISCO

  • INTRA_DOMAIN_TERM_NOT_CISCO

  • INTER_DOMAIN_ORIG_NOT_CISCO

Deze functie werkt prima zonder dat er een carrier-ID van de gateway of een Carrier Sensitive Routing (CSR)-server nodig is. In dat geval zijn de velden over de ID van de expediteur leeg. De voorbeelden hier bevatten geen vervoerder-ID. Voor een gedetailleerde gespreksstroom, release- en platformondersteuning en configuraties, raadpleegt u Interdomain Gatekeeper Security Enhancement.

Gatekeeper-configuratie

De IZCT-functie vereist deze configuratie op de poortwachter.

Router(gk-config)#
[no] security izct password 

Het wachtwoord moet uit zes tot acht tekens bestaan. Bepaal welke zone zich in een buitenlands domein bevindt zoals dit:

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]

IZCT-oproepstroom

Dit diagram toont de IZCT-stroom.

In deze configuratie zijn de namen van de gateways en poortwachters dezelfde als die in het IZCT-oproepstroomdiagram, maar met kleine letters. De oproepstroom wordt uitgelegd na de configuratie, met uitleg over foutopsporing.

Om de IZCT-functie en de oproepstroom uit te leggen, heeft het eerste voorbeeld niet de intradomein-gateway naar gatekeeper-beveiliging. Daarna zijn er voorbeelden waarbij de TGW niet in staat is om de IZCT te genereren, zodat de TGK1 de oproep afwijst. Dit is om aan te tonen dat de functie werkt zoals ontworpen. Al deze opstellingen zijn gebaseerd op de topologie in het IZCT-oproepstroomdiagram.

Voorbeeld 1: oproepstroom voor alleen poortwachter naar alleen poortwachter-beveiliging

Dit voorbeeld toont de gerelateerde configuraties van alle gateways en poortwachters.

!
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

!
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

!
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

Oproepstroom met debugs

Deze voorbeelden gebruiken de debugs om de oproepstroom uit te leggen.

1. Een gebruiker op carrier E belt een gebruiker op carrier D.

   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)

2. Aangezien de kiezer van de oorspronkelijke gateway (tag=3653) is geconfigureerd voor RAS, verzendt deze een ARQ naar 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
   

3. Wanneer OGK1 de ARQ ontvangt, bepaalt het dat de bestemming wordt onderhouden door de externe zone OGK2. Vervolgens wordt vastgesteld dat een IZCT nodig is ( via CLI: security izct password <pwd>). OGK1 gaat verder met het maken van de IZCT voordat de LRQ wordt verzonden. Vervolgens stuurt het de IZCT en de LRQ naar OGK2 en stuurt het een RIP-bericht terug naar OGW.

   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

4. Wanneer OGK2 de LRQ ontvangt, controleert het de IZCT. Uit de configuratie blijkt dat de LRQ ook een IZCT moet bevatten. OGK2 maakt vervolgens een nieuwe IZCT door de izctSrcZone en izctDstZone te wijzigen in ogk2 en de LRQ door te sturen naar TGK2. Nadat het de LRQ naar TGK2 heeft verzonden, stuurt het een RIP-bericht terug naar OGK1.

   Als de poortwachters deel uitmaken van een cluster, wordt de clusternaam gebruikt voor de SrcZone of DstZone.

   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
   

5. TGK2 bepaalt dat de LRQ afkomstig is van een buitenlands domein. Het werkt de DstZone van de IZCT bij met zijn eigen ID en interZoneType als INTER_DOMAIN_CISCO. Vervolgens wordt een nieuwe CAT gemaakt en worden de bijgewerkte IZCT en de LRQ doorgegeven aan TGK1.

   TGK2 behandelt de zone van waaruit een LRQ wordt ontvangen als een foreign-domain zone in een van deze twee scenario's:

   • De lijst met afgelegen zones van de TGK2 bevat niet de zone waaruit een LRQ wordt ontvangen.

   • De lijst van de TGK2-zones bevat de zone waaruit een LRQ wordt ontvangen. De zone is gemarkeerd met een buitenlandse domeinvlag.

   Vervolgens stuurt het een Request In Progress-bericht terug naar OGK1.

   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

6. Normaal gesproken werkt TGK1 de DstCarrierID van de IZCT bij naar Carrier E, die wordt bepaald door het routeringsproces. Aangezien er geen vervoerders worden gebruikt, ziet u dat echter niet. TGK1 genereert een hash-token met het wachtwoord van de IZCT. Het stuurt een LCF met de bijgewerkte IZCT erin naar OGK1. Deze izctHash wordt gebruikt om de answerCall ARQ te verifiëren die TGK1 van de TGW ontvangt wanneer de laatste het VoIP-installatiebericht van OGW ontvangt.

   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
   

7. OGK1 haalt de IZCT uit de LCF en stuurt deze in een ACF naar de 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
   

8. De OGW stuurt de IZCT naar de TGW in het H.225 SETUP-bericht.

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

9. De TGW geeft de IZCT door aan de TGK1 in een ARQ-antwoordoproep.

   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
     }

10. TGK1 verifieert de bestemming IZCT met succes. Dit komt omdat TGK1 de hash in de IZCT genereert en een ACF terugstuurt naar de TGW.

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

11. De TGW stelt de oproep naar Carrier D vast nadat deze de ACF heeft ontvangen.

    Voorbeeld 2: Oproep mislukt omdat TGW de IZCT niet uit het ontvangen installatiebericht kan halen.

    Dit voorbeeld is gebaseerd op dezelfde topologie en configuratie als voorbeeld 1. In dit voorbeeld wordt de software van de TGW gewijzigd in een versie waarbij de IZCT niet wordt ondersteund. In een dergelijk geval kan de TGW de IZCT niet uit het installatiebericht halen. Dit zorgt ervoor dat de TGK1 het gesprek afwijst met een reden voor ontkenning van de beveiliging.

    In dit voorbeeld worden alleen het installatiebericht, ARQ en de ARJ op de TGW weergegeven, omdat de oproepstroom hetzelfde is als in voorbeeld 1.

    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
    

Gerelateerde informatie

• Beveiligingsverbetering voor interdomeinpoortwachters