Gateway to Gatekeeper (H.235) and Gatekeeper to Gatekeeper (IZCT) Security Troubleshooting Guide

업데이트:2019년 2월 20일
문서 ID:18729

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

H.323 네트워크에는 서로 다른 종류의 컨피그레이션 및 통화 흐름이 있습니다. 이 문서에서는 게이트키퍼와 관련된 H.323 네트워크에 대한 대부분의 보안 문제에 대해 설명합니다. 이 문서에서는 대부분의 디버그에 대한 설명과 함께 각 기능의 작동 방식 및 문제 해결 방법을 요약합니다. 이 문서에서는 VoIP의 전반적인 보안을 다루지 않습니다.

이 문서에서는 다음 기능에 대해 설명합니다.

  • 게이트키퍼 보안에 대한 Intradomain Gateway - 이 보안은 H.235를 기반으로 하며, 여기서 H.323 통화는 게이트키퍼가 인증, 권한 부여 및 라우팅합니다. 게이트웨이가 등록을 시도할 때 게이트웨이가 인증하지 않는다는 의미에서 게이트키퍼는 알려진 신뢰할 수 있는 엔티티로 간주됩니다.

  • InterDomain Gatekeeper to Gatekeeper Security(게이트키퍼 보안에 대한 도메인 간 게이트키퍼) - 이 보안에서는 IZCT(InterZone Clear Token)를 사용하여 ITSP(Internet Telephone Service Providers)의 관리 도메인 간 H.323 통화 인증 및 권한 부여를 다룹니다. 이 문서에서는 종료 게이트키퍼가 ARQ(AnswerCall Admission Request)를 인증하도록 LCF(Location Confirmation) 메시지에서 토큰을 전송하는 부분만 다룹니다. LRQ(위치 요청) 검증은 이 기능에 포함되지 않습니다. LRQ 검증은 향후 Cisco IOS® 소프트웨어 릴리스에 예약된 기능입니다.

정의

약어 정의
ARQ Admission Request(승인 요청) - H.323 엔드포인트에서 통화를 설정하기 위한 승인을 요청하는 게이트키퍼로 전송되는 RAS(Registration, Admission, and Status Protocol) 메시지입니다.
ACF Admission Confirm(승인 확인) - 통화 수락을 확인하는 RAS 메시지를 게이트키퍼에서 엔드포인트로 보냅니다.
아르즈 Admission Rejection(승인 거부) - 승인 요청을 거부하는 게이트키퍼에서 엔드포인트로의 RAS 메시지입니다.
고양이 Cisco Access Token - H.235 Clear Token입니다.
CHAP Challenge Handshake Authentication Protocol(챌린지 핸드셰이크 인증 프로토콜) - 챌린지가 사용되는 인증 프로토콜입니다.
GCF Gatekeeper Confirm(게이트키퍼 확인) - 게이트키퍼의 검색을 확인하는 RAS 메시지를 게이트키퍼에서 H.323 엔드포인트로 보냅니다.
GRQ 게이트키퍼 요청 - 게이트키퍼를 검색하기 위해 H.323 엔드포인트에서 전송된 RAS 메시지입니다.
H.235 H-Series(H.323 및 기타 H.245 기반) 멀티미디어 터미널의 보안 및 암호화를 위한 ITU 권장 사항.
아이작 InterZone Clear Token(영역 간 지우기 토큰) - ITSP 관리 도메인 내의 영역 내 통화에 대해 LRQ가 시작되거나 ACF가 전송되려고 할 때 원래 게이트키퍼에서 IZCT가 생성됩니다.
LRQ Location Request(위치 요청) - 통화를 추적하고 라우팅하기 위해 게이트키퍼에서 다음 홉 게이트키퍼 또는 통화 레그로 전송되는 RAS 메시지입니다.
RAS Registration, Admission 및 Status(등록, 입장 및 상태) - 게이트키퍼가 엔드포인트의 등록, 입장 및 상태 확인을 수행할 수 있는 프로토콜입니다.
RCF Registration Confirm(등록 확인) - 등록을 확인하는 게이트키퍼에서 엔드포인트로 전송되는 RAS 메시지입니다.
RRJ Registration Reject(등록 거부) - 등록 요청을 거부하는 게이트키퍼에서 보낸 RAS 메시지입니다.
RRQ Registration Request(등록 요청) - 엔드포인트에서 게이트키퍼로 전송된 RAS 메시지이며, 이 메시지는 엔드포인트에서 등록을 요청합니다.
RIP Request In Progress(요청 진행 중) - 통화가 진행 중임을 알리는 게이트키퍼에서 발신자에게 전송되는 RAS 메시지입니다.

게이트키퍼 보안에 대한 도메인내 게이트웨이

H.323은 안전하지 않은 네트워크를 통한 실시간 통신 보안을 다루는 ITU 권장 사항입니다. 여기에는 다음과 같은 두 가지 주요 문제가 포함됩니다. 인증 및 개인 정보 보호. H.235에 따르면 인증에는 두 가지 유형이 있습니다.

  • 통신 엔티티 간에 사전 접촉이 필요하지 않은 대칭 암호화 기반 인증

  • 일부 이전 공유 비밀(구독 기반이라고도 함)을 가질 수 있는 기능에 따라 두 가지 형식의 구독 기반 인증이 제공됩니다.

    • 암호

    • 인증서

토큰에 전달된 타임스탬프

타임스탬프는 재생 공격을 방지하는 데 사용됩니다. 따라서 (타임 스탬프를 파생시키는) 시간에 대한 상호 허용 가능한 참조가 필요합니다. 허용 가능한 시간 왜곡의 양은 로컬 구현의 문제입니다.

Cisco에서 H.235 권장 사항을 구현하는 방법

Cisco는 게이트키퍼 H.235 구현에 대한 게이트웨이의 기반으로 CHAP(Challenge Handshake Authentication Protocol) 유사 인증 체계를 사용합니다. 이렇게 하면 기존 기능을 사용하여 실제 인증을 수행하는 AAA(Authentication, Authorization, and Accounting)를 활용할 수 있습니다. 또한 게이트키퍼가 게이트웨이 ID, 사용자 계정 번호, 비밀번호 및 PIN의 데이터베이스에 액세스할 필요가 없습니다. 체계는 H.235, 섹션 10.3.3을 기반으로 합니다. 해싱을 사용하는 서브스크립션 기반 비밀번호로 설명됩니다.

그러나 이 방법에서는 H.225 cryptoTokens를 사용하는 대신 RADIUS에 사용할 수 있도록 적절히 채워진 필드가 있는 H.235 clearTokens를 사용합니다. 이 토큰을 Cisco Access Token(CAT)이라고 합니다. RADIUS 서버를 사용하는 대신 항상 게이트키퍼에서 로컬로 인증을 수행할 수 있습니다.

cryptoTokens를 사용하려면 게이트키퍼가 모든 사용자 및 게이트웨이의 비밀번호를 유지하거나 확보할 수 있는 몇 가지 방법을 가지고 있어야 합니다. 이는 인증 엔터티가 수신된 토큰을 비교할 자체 토큰을 생성하기 위해 비밀번호가 필요하도록 cryptoToken의 token 필드가 지정되었기 때문입니다.

Cisco 게이트키퍼는 cryptoTokens를 완전히 무시합니다. 그러나 H.235 섹션 10.3.3을 지원하는 vocalTek 게이트키퍼 및 기타 사용자는 cryptoTokens를 사용하여 게이트웨이를 인증합니다. Cisco 게이트키퍼는 CAT를 사용하여 게이트웨이를 인증합니다. 게이트웨이는 자신이 어떤 유형의 게이트키퍼로 이야기하는지 모르기 때문에 RRQ에 두 게이트키퍼를 모두 전송합니다. GRQ의 authenticationCapability는 cryptoToken에 대한 것이며 MD5 해싱이 인증 메커니즘임을 나타냅니다(CAT도 MD5를 사용하지만).

자세한 내용은 Cisco H.323 Gateway Security and Accounting Enhancements를 참조하십시오.

보안 수준 구성 방법

  • 엔드포인트 또는 등록 레벨 보안

    게이트키퍼에서 등록 보안이 활성화된 경우 게이트웨이는 모든 heavyweight RRQ 메시지에 CAT를 포함해야 합니다. 이 경우 CAT에는 게이트키퍼에 대한 게이트웨이 자체를 인증하는 정보가 포함되어 있습니다. 게이트키퍼는 토큰에 포함된 정보를 인증하는 RADIUS 서버에 메시지를 포맷합니다. Access-Accept 또는 Access-Reject 중 하나로 게이트키퍼에 응답합니다. 그러면 RCF 또는 RRJ로 게이트웨이에 응답합니다.

    성공적으로 인증된 게이트웨이에서 통화가 발신된 경우, 해당 게이트웨이는 게이트웨이 비밀번호를 사용하여 게이트키퍼로부터 ACF를 수신하는 즉시 새 CAT를 생성합니다. 이 CAT는 타임스탬프를 제외하고 등록 중에 생성된 CAT와 동일합니다. 발신 SETUP 메시지에 배치됩니다. 목적지 게이트웨이는 SETUP 메시지로부터 토큰을 추출하여 목적지 측 ARQ에 배치한다. 게이트키퍼는 RADIUS를 사용하여 목적지 측 ACF를 전송하기 전에 원래 게이트웨이를 인증합니다. 이렇게 하면 게이트웨이의 주소를 알고 있는 인증되지 않은 엔드포인트가 보안 체계를 우회하고 PSTN(Public Switched Telephone Network)에 액세스하는 데 이 엔드포인트를 사용할 수 없게 됩니다.

    따라서, 이 레벨에서, 발신 ARQ들에 어떤 토큰들도 포함할 필요가 없다.

    게이트키퍼를 구성하기 위해 게이트키퍼 CLI(Command Line Interface)에서 등록하는 데 필요한 보안 토큰을 [no] 입력합니다. 이 명령의 no 옵션을 사용하면 게이트키퍼가 더 이상 RAS 메시지에서 토큰을 확인하지 않습니다.

    게이트웨이 CLI에서 [no] 보안 비밀번호 <PASSWORD> 레벨 엔드포인트를 입력하여 게이트웨이를 구성합니다. 이 명령의 no 옵션을 사용하면 게이트웨이가 더 이상 RAS 메시지에 대한 토큰을 생성하지 않습니다.

  • 통화별 보안

    통화별 보안은 등록 레벨 보안을 기반으로 구축됩니다. 등록 보안 요구 사항을 충족하는 것 외에도 게이트웨이는 게이트키퍼에서 통화별 보안이 활성화된 경우 모든 발신 측 ARQ 메시지에 액세스 토큰을 포함해야 합니다. 이 경우 토큰에는 게이트키퍼에 대한 게이트웨이의 사용자를 식별하는 정보가 포함됩니다. 이 정보는 게이트웨이의 IVR(Interactive Voice Response) 스크립트를 사용하여 얻습니다. 그러면 사용자가 전화를 걸기 전에 키패드에서 사용자 ID와 PIN을 입력하라는 프롬프트가 표시됩니다.

    발신 ARQ에 포함된 CAT는 엔드포인트 또는 등록 레벨 보안에서 앞서 설명한 것과 동일한 방식으로 RADIUS에 의해 인증됩니다. ACF를 수신한 게이트웨이는 비밀번호를 사용하여 새 CAT을 생성하고 H.225 SETUP 메시지 내에 이를 종료 게이트웨이로 보냅니다.

    게이트키퍼 CLI에서 모두 게이트키퍼를 구성하려면 [no] security token required를 입력합니다. 이 명령의 no 옵션을 사용하면 게이트키퍼가 더 이상 RAS 메시지에서 토큰을 확인하지 않습니다.

    게이트웨이 CLI에서 [no] security password <PASSWORD> level per-call을 입력하여 게이트웨이를 구성합니다. 이 명령의 no 옵션을 사용하면 게이트웨이가 더 이상 RAS 메시지에 대한 토큰을 생성하지 않습니다.

  • 모든 수준의 보안

    그러면 게이트웨이가 등록 및 통화에 필요한 모든 RAS 메시지에 CAT를 포함할 수 있습니다. 따라서 위의 두 가지 수준이 결합된 것이다. 이 옵션을 사용하면 ARQ 메시지에서 CAT의 검증은 전화를 건 사용자의 계정 번호와 PIN을 기준으로 합니다. 다른 모든 RAS 메시지에서 전송된 CAT의 검증은 게이트웨이에 대해 구성된 비밀번호를 기반으로 합니다. 따라서 통화당 수준과 비슷합니다.

    게이트키퍼 CLI에서 모두 게이트키퍼를 구성하려면 [no] security token required를 입력합니다. 이 명령의 no 옵션을 사용하면 게이트키퍼가 더 이상 RAS 메시지에서 토큰을 확인하지 않습니다.

    게이트웨이 CLI에서 [no] security password <PASSWORD> level all을 입력하여 게이트웨이를 구성합니다. 이 명령의 no 옵션을 사용하면 게이트웨이가 더 이상 RAS 메시지에 대한 토큰을 생성하지 않습니다.

IVR이 없는 통화당 레벨에서 H.235 사용

H.235는 IVR이 없는 통화당 수준에서 사용할 수 없습니다. 계정과 PIN을 수집할 IVR이 없는 경우 게이트웨이가 Clear Token 없이 ARQ를 전송해야 합니다(단, 암호화 토큰은 있음). Cisco 게이트키퍼는 Clear Token만 수락하므로 보안 거부 사유와 함께 게이트키퍼가 통화를 거부합니다.

이 예에서는 계정 및 PIN을 수집하도록 IVR에 대해 구성되지 않은 원래 게이트웨이(OGW)에서 수집된 h225 asn1 디버그를 보여 줍니다. RRQ 메시지는 Clear Token을 갖지만 ARQ는 그렇지 않습니다. ARJ 메시지가 게이트웨이로 다시 전송됩니다. 

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

주요 문제

다음과 같은 주요 문제를 고려해야 합니다.

  • 게이트웨이 및 게이트키퍼 컨피그레이션

  • 게이트키퍼 및 RADIUS 서버의 RADIUS 컨피그레이션

  • NTP(Network Time Protocol) - 모든 게이트웨이 및 게이트키퍼에서 동일한 시간을 가져야 합니다. 인증 정보에는 타임스탬프가 포함되므로 모든 Cisco H.323 게이트웨이와 게이트키퍼(또는 인증을 수행하는 다른 엔티티)가 동기화되어야 합니다. Cisco H.323 게이트웨이는 NTP를 사용하여 동기화해야 합니다.

  • 버그로 인한 소프트웨어 오류

다양한 레벨에 대한 디버깅 및 통화 흐름

모든 레벨의 보안은 등록 및 통화별 사례를 모두 포함하므로 이 실습에서는 이 실습의 보안 수준을 설정합니다. 등록 부분 및 일반 VoIP 통화에 대한 통화 흐름은 여기 구성에서 설명합니다.

참고: 여기서 컨피그레이션이 완료되지 않았습니다. 디버그 출력 사이에 추가 명령이 있습니다. 컨피그레이션, NTP, RADIUS 등 모든 것을 확인하지 않을 경우 어떤 문제가 발생할 수 있는지 보여주기 위해 고안되었습니다. 또한 게이트웨이는 로컬로 게이트키퍼에서 인증되므로 게이트웨이 ID 및 비밀번호에 대해 설정된 값을 확인할 수 있습니다. 이 컨피그레이션은 관련 컨피그레이션만 표시되도록 스니핑됩니다.

!
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

다음 예에서는 이러한 디버그가 활성화됩니다.

가장 먼저 발생하는 것은 게이트웨이가 게이트키퍼에게 GRQ를 전송하고 게이트키퍼가 게이트웨이에 GCF를 전송하는 것입니다. 그러면 게이트웨이가 RRQ를 전송하고 RCF 또는 RRJ를 기다립니다.

이전 컨피그레이션에서는 게이트웨이가 어떤 보안 레벨에도 설정되지 않으므로 해당 GRQ는 토큰에 필요한 authenticationCapability를 전달하지 않습니다. 그러나 이 출력에 표시된 대로 게이트키퍼는 여전히 GCF를 다시 전송합니다. 

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

다음은 GRQ의 몇 가지 메시지에 대한 설명입니다.

  • authenticationCapability - 이 필드에는 pwdHash 값만 있습니다. MD5 해싱이 인증 메커니즘임을 나타냅니다.

  • algorithmOIDs - 알고리즘 개체 ID입니다. 이 경우 메시지 다이제스트 5 해싱의 개체 ID인 값(1 2 840 113549 2 5)을 전달합니다.

    (1 2 840 113549 2 5)는 iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) md5(5)로 변환됩니다. 따라서 Cisco는 MD5 비밀번호 해싱을 수행합니다.

    Rsadsi는 RSA Data Security Inc.의 약어입니다. RSA Data Security, Inc.의 OSI(Open Systems Interconnection) 개체 식별자는 ANSI(American National Standards Institute)에 등록된 1.2.840.113549(0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d in hex)입니다.

게이트키퍼는 다시 이전 메시지로 GCF를 전송합니다. 그런 다음 게이트웨이는 특정 필드가 포함된 RRQ를 전송하여 인증할 때 사용하는 토큰을 설명합니다. 전송된 asn1 RRQ 메시지가 이 예에 나와 있습니다. 

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

응답에 대해 논의하기 전에 위 RRQ 메시지의 관련 필드 중 일부에 대해 여기서 설명합니다. 토큰에는 두 가지 유형이 있습니다. CAT(Clear Token) 및 암호화 토큰입니다.

앞에서 설명한 것처럼 Cisco 게이트키퍼는 암호화 토큰을 무시합니다. 그러나 게이트웨이는 자신이 어떤 유형의 게이트키퍼로 이야기하는지 모르기 때문에 여전히 두 가지를 모두 전송합니다. 다른 벤더에서 암호화 토큰을 사용할 수 있으므로 게이트웨이에서 두 토큰을 모두 전송합니다.

다음은 ClearToken 구문에 대해 설명합니다.

  • tokenOID - 토큰을 식별하는 개체 ID입니다.

  • timeStamp—게이트웨이의 현재 UTC(Coordinated Universal Time) 시간입니다. 00:00 1/1/1970 UTC 이후 초

    이는 마치 처음 게이트키퍼에서 온 것처럼 암시된 CHAP-Challenge로 사용됩니다.

  • challenge(챌린지) - 게이트웨이에서 다음 필드를 사용하여 생성한 16바이트 MD5 메시지 다이제스트입니다.

    challenge = [ 임의 + GW/사용자 암호 + 타임스탬프 ] MD5 해시

    RADIUS는 이 계산을 수행하여(난수, 게이트웨이 비밀번호, CHAP 챌린지를 알기 때문에) 챌린지가 무엇인지 결정합니다. CHAP 응답 = [ CHAP ID + 사용자 암호 + CHAP 챌린지 ] MD5 해시

  • random(임의) - RADIUS에서 이 특정 요청을 식별하는 데 사용하는 1바이트 값입니다.

    게이트웨이는 이 RADIUS 요구 사항을 충족하기 위해 각 인증 요청에 대해 변수 모듈 256을 증분합니다.

  • generalID—게이트웨이 H323-ID 또는 보안 수준 및 RAS 메시지 유형에 따른 사용자 계정 번호입니다.

참고: 이 모든 필드가 중요합니다. 다만 타임스탬프와 일반ID에 모두 더 많은 관심이 쏠린다. 이 경우 타임스탬프는 731030839이고 generalID는 gwa-1@cisco.com입니다.

RRQ의 cryptoToken에는 토큰을 생성하는 게이트웨이에 대한 정보가 포함되어 있습니다. 여기에는 게이트웨이 ID(게이트웨이에 구성된 H.323 ID)와 게이트웨이 비밀번호가 포함됩니다.

이 필드에는 H.225에 지정된 CryptoH323Token 필드에 대해 정의된 cryptoToken 유형 중 하나가 포함되어 있습니다. 현재 지원되는 cryptoToken 유형은 cryptoEPPwdHash뿐입니다.

다음 필드는 cryptoEPPwdHash 필드에 포함됩니다.

  • alias - 게이트웨이의 H.323 ID인 게이트웨이 별칭입니다.

  • timestamp - 현재 타임스탬프입니다.

  • token - MD5(Message Digest 5) 인코딩 PwdCertToken입니다. 이 필드에는 다음 항목이 포함됩니다.

    • timestamp — cryptoEPPwdHash의 타임스탬프와 동일합니다.

    • password — 게이트웨이의 비밀번호입니다.

    • generalID - cryptoEPPwdHash에 포함된 것과 동일한 게이트웨이 별칭입니다.

    • tokenID—개체 ID

이 예에서는 게이트키퍼의 응답을 확인합니다.

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

게이트키퍼가 RRQ를 거부합니다. 그 이유는 게이트웨이 컨피그레이션에 NTP 설정이 없었기 때문입니다. 게이트키퍼는 토큰의 타임스탬프를 확인하여 토큰이 해당 시간과 관련된 허용 가능한 윈도우 내에 있는지 확인합니다. 현재 이 창은 게이트키퍼의 UTC 시간을 기준으로 +/- 30초입니다.

이 창 외부에 있는 토큰으로 인해 게이트키퍼가 이 메시지를 삭제합니다. 이렇게 하면 스누핑된 토큰을 재사용하려고 시도하는 사용자로부터의 재생 공격을 방지할 수 있습니다. 실제로 모든 게이트웨이와 게이트키퍼는 이러한 시간 왜곡 문제를 방지하기 위해 NTP를 사용해야 합니다. 게이트키퍼는 토큰의 타임스탬프가 허용되는 시간 범위 내에 있음을 확인합니다. 따라서 게이트웨이를 인증하기 위해 RADIUS로 확인하지 않습니다.

그러면 게이트웨이가 NTP 마스터로 게이트키퍼를 가리키는 NTP에 대해 구성되므로, 게이트웨이와 게이트키퍼 모두 동일한 시간을 갖게 됩니다. 이 경우 게이트웨이는 새 RRQ를 전송하고, 이번에는 게이트키퍼가 RRJ를 사용하여 새 RRQ에 다시 응답합니다.

이 디버그는 게이트키퍼에서 가져온 것입니다. 디버그는 게이트키퍼가 인증 단계로 이동하는지 확인하기 위해 실행됩니다. 

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

NTP를 구성한 후에도 게이트키퍼는 여전히 RRQ를 거부합니다. 그러나 이번에는 해당 게이트웨이에 대한 인증 프로세스를 거칩니다. 사용자(여기서 게이트웨이 ID)가 RADIUS의 유효한 사용자 목록에 없으므로 게이트키퍼가 RRQ를 거부합니다. 게이트웨이는 게이트키퍼의 컨피그레이션에서 로컬로 인증됩니다. 사용자 목록에 gwa-1이 표시되지만 RRQ의 사용자가 gwa-1@cisco.com이므로 올바른 사용자가 아닙니다.

또한 게이트키퍼에서 username gwa-1@cisco.com password 0 2222 명령이 구성되면 게이트키퍼는 RRQ 및 게이트웨이가 등록되었음을 확인합니다.

이 Lab에서는 다른 게이트웨이(gwa-2)가 동일한 게이트키퍼(gka-1)에 등록됩니다. ARQ, ACF 및 설정 메시지의 모양을 확인하기 위해 gwa-1@cisco.com에서 gwa-2로 전화를 겁니다.

수집된 이러한 디버깅은 시작 및 종료 게이트웨이(gwa-2)에서 가져옵니다.

일부 디버그 메시지에 대한 설명이 포함되어 있습니다.

시작/종료 게이트웨이에서 디버그를 인쇄하기 전에 이 텍스트는 통화 흐름에 대해 설명합니다.

  1. PSTN으로부터 설정 메시지가 수신될 때, 게이트웨이는 ARQ를 전송하고 게이트키퍼로부터 ACF를 수신한다.

  2. 게이트웨이가 ACF를 수신하면 게이트웨이 암호, H323-ID 별칭 및 현재 시간을 사용하여 CAT를 생성합니다. 토큰은 CCB(Call Control Block)에 배치됩니다.

  3. 게이트웨이가 종료 게이트웨이로 SETUP 메시지를 전송하면 CCB에서 액세스 토큰을 검색하여 SETUP 메시지 내의 clearToken의 nonStandardParameter 필드에 배치합니다.

  4. 종단 게이트웨이는 SETUP 메시지에서 토큰을 제거하고, 이를 nonStandardParameter에서 CAT로 변환하고, ARQ에 배치합니다.

  5. 게이트키퍼는 토큰의 타임스탬프를 확인하여 토큰이 해당 시간과 관련된 허용 가능한 윈도우 내에 있는지 확인합니다. 현재 이 창은 게이트키퍼의 UTC 시간을 기준으로 +/- 30초입니다. 이 창 외부에 있는 토큰으로 인해 게이트키퍼가 이 메시지를 삭제합니다. 그러면 통화가 거부됩니다.

  6. 토큰이 허용되는 경우 게이트키퍼는 RADIUS 액세스 요청 패킷을 포맷하고 CHAP 챌린지를 확인하기 위해 적절한 특성을 입력한 다음 RADIUS 서버로 전송합니다.

  7. 게이트웨이의 별칭이 서버에 있다는 가정 하에 서버는 이 별칭과 연결된 비밀번호를 찾고 게이트웨이 키퍼의 별칭, 비밀번호 및 CHAP 챌린지를 사용하여 고유한 CHAP 응답을 생성합니다. CHAP 응답이 게이트키퍼에서 수신한 응답과 일치하면 서버는 액세스 수락 패킷을 게이트키퍼에 보냅니다. 일치하지 않거나 게이트웨이의 별칭이 서버의 데이터베이스에 없으면 서버는 액세스 거부 패킷을 다시 게이트키퍼로 보냅니다.

  8. 게이트키퍼는 게이트웨이가 Access Accept(액세스 수락)를 수신하는 경우 ACF로 응답하고, Access Reject(액세스 거부)를 수신하는 경우 원인 코드 securityDenial(보안 거부)을 사용하여 ARJ로 응답합니다. 게이트웨이가 ACF를 받으면 통화가 연결됩니다.

이 예에서는 시작 게이트웨이의 디버그를 보여줍니다.

참고: 설정에 대한 h225 asn1 디버깅은 시작 게이트웨이 예 다음에 나오는 종료 게이트웨이 예에 표시된 것과 동일하므로 이 예에서는 이 예가 아닙니다.

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

다음 예에서는 종료 게이트웨이(TGW)에서 디버그를 보여줍니다. TGW가 ACF를 받은 이후 두 번째 레그를 설정했고 통화가 연결되었음을 확인합니다.

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)

게이트웨이 IOS 문제

같은 실습에서는 OGW에 IOS 이미지 12.2(6a)가 로드됩니다. 통화가 이루어지면 게이트웨이가 계정/PIN을 수집하도록 IVR에 구성되지 않았음에도 불구하고 OGW는 여전히 비밀번호를 기반으로 Clear Token을 전송합니다. 또한 모든 레벨에 대해 구성된 게이트키퍼가 해당 통화를 수락합니다. 이는 Cisco 버그 ID CSCdw43224(등록된 고객만 해당)에 문서화되어 있습니다.

대체 엔드포인트를 사용한 보안

이 문서의 앞부분에서 설명한 것처럼 엔드 투 엔드 통화 보안에는 RAS/H.225 메시지의 clearTokens 필드에서 전송되는 액세스 토큰을 사용하는 기능이 제공됩니다. 이러한 보안을 활성화하면 소스 게이트웨이는 ACF의 게이트키퍼에서 수신한 액세스 토큰을 H.225 SETUP 메시지의 목적지 H.323 엔드포인트로 전달합니다. 그러면 이 대상 H.323 엔드포인트는 SETUP 메시지에서 받은 액세스 토큰을 승인 요청의 게이트키퍼로 전달합니다. 이렇게 하면 원격 게이트키퍼에게 액세스 토큰의 유효성을 기준으로 통화를 허용할 수 있는 기능이 제공됩니다. 액세스 토큰의 내용은 이를 생성하는 엔터티에 따라 달라집니다. 보안 허점을 최소화하고 중간자(man-in-the-middle) 공격을 방지하기 위해 게이트키퍼는 액세스 토큰에서 목적지 특정 정보를 인코딩할 수 있습니다. 이는 alternateEndpoints가 ACF에 제공되는 경우 게이트키퍼가 지정된 각 alternateEndpoint에 대해 별도의 액세스 토큰을 제공할 수 있음을 의미합니다.

처음 연결을 설정하려고 시도하면 Cisco 게이트웨이는 ACF의 clearToken 필드에서 수신한 액세스 토큰을 destCallSignalAddress 필드의 주소와 함께 전송합니다. 이 시도가 실패하고 Cisco 게이트웨이가 대체 엔드포인트와의 연결을 시도하려고 진행할 경우, 대체 엔드포인트 목록에서 연결된 액세스 토큰(사용 가능한 경우)을 사용합니다. ACF에 수신된 대체 엔드포인트 목록에 액세스 토큰이 포함되어 있지 않지만 ACF에 액세스 토큰이 포함되어 있는 경우, Cisco 게이트웨이는 대체 엔드포인트와 연결하려는 모든 시도에 이 액세스 토큰을 포함합니다.

OSP 토큰 지원

현재 OSP(Open Settlement Protocol) 및 해당 토큰은 Cisco 게이트웨이에서만 지원됩니다. 문지기에 대한 지원이 없습니다. 게이트웨이는 결제 서버로부터 수신된 OSP 토큰을 인식하여 종료 게이트웨이에 대한 Q.931 설정 메시지에 삽입합니다.

각 엔드포인트 또는 영역에 대해 서로 다른 보안 수준

현재 각 엔드포인트 또는 영역에 대해 서로 다른 보안 수준을 구성할 수 없습니다. 보안 레벨은 해당 게이트키퍼가 관리하는 모든 영역에 대한 것입니다. 이러한 문제에 대한 기능 요청을 열 수 있습니다.

도메인 간 게이트키퍼에서 게이트키퍼 보안

도메인 간 게이트키퍼-게이트키퍼 보안은 홉별로 도메인 간 및 도메인 간 게이트키퍼-게이트키퍼 요청을 검증하는 기능을 제공합니다. 즉, 게이트키퍼가 LRQ를 앞으로 전달하기로 결정하면 대상 게이트키퍼가 CAT를 종료하고 새 CAT를 생성합니다. 게이트키퍼가 유효하지 않은 LRQ 시그니처를 탐지하면 LRJ(Location Reject)를 보내 응답합니다.

게이트키퍼-게이트키퍼 보안 구현

영역 내 통화 시 LRQ가 시작되거나 ACF가 전송되려고 할 때 원래 게이트키퍼가 IZCT를 생성합니다. 이 토큰은 라우팅 경로를 통해 통과됩니다. 경로에 따라 각 게이트키퍼는 영역 정보를 반영하기 위해 필요한 경우 대상 게이트키퍼 ID 및/또는 소스 게이트키퍼 ID를 업데이트합니다. 종료 게이트키퍼는 비밀번호와 함께 토큰을 생성합니다. 이 토큰은 LCF(Location Confirmation) 메시지에서 다시 전달되고 OGW로 전달됩니다. OGW는 H.225 SETUP 메시지에 이 토큰을 포함합니다. TGW가 토큰을 수신하면 ARQ answerCall에서 전달되고 종료 게이트키퍼(TGK)에 의해 RADIUS 서버가 필요 없이 검증됩니다.

인증 유형은 ITU H.235에 설명된 대로 해싱을 사용하는 비밀번호를 기반으로 합니다. 특히 암호화 방법은 비밀번호 해싱을 사용하는 MD5입니다.

IZCT의 목적은 LRQ가 외부 도메인에서 도착했는지, 어떤 영역에서 왔는지, 어떤 캐리어에서 도착했는지를 파악하는 것입니다. TGK에서 LCF의 OGW로 토큰을 전달하는 데에도 사용됩니다. IZCT 형식 내에서 다음 정보가 필요합니다.

  • srcCarrierID - 소스 캐리어 ID

  • dstCarrierID - 대상 캐리어 ID

  • intCarrierID - 중간 캐리어 ID

  • srcZone—소스 영역

  • dstZone - 대상 영역

  • 영역 간 유형

    • 도메인 내부 CISCO

    • 도메인 간_시스코

    • INTRA_DOMAIN_TERM_NOT_CISCO

    • INTER_DOMAIN_ORIG_NOT_CISCO

이 기능은 게이트웨이 또는 CSR(Carrier Sensitive Routing) 서버의 캐리어 ID를 필요로 하지 않고 원활하게 작동합니다. 이 경우 캐리어 ID에 대한 필드는 비어 있습니다. 여기의 예에는 캐리어 ID가 포함되어 있지 않습니다. 자세한 통화 흐름, 릴리스 및 플랫폼 지원 및 컨피그레이션은 도메인 간 게이트키퍼 보안 강화를 참조하십시오.

게이트키퍼 컨피그레이션

IZCT 기능을 사용하려면 게이트키퍼에서 이 컨피그레이션을 수행해야 합니다. 

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

비밀번호는 6-8자여야 합니다. 다음과 같이 외부 도메인에 있는 영역을 식별합니다.

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 통화 흐름

이 다이어그램은 IZCT 흐름을 보여줍니다.

gw_security.gif

이 컨피그레이션에서는 게이트웨이 및 게이트키퍼의 이름이 IZCT 통화 흐름 다이어그램에서 사용된 이름과 동일하지만 소문자가 사용됩니다. 컨피그레이션 후 통화 흐름에 대한 설명이 디버그 설명과 함께 제공됩니다.

IZCT 기능 및 통화 흐름을 설명하기 위해 첫 번째 예에는 게이트키퍼 보안에 대한 내부 게이트웨이가 없습니다. 그 후, TGW가 IZCT를 생성할 수 없어 TGK1이 호출을 거부하는 예들이 존재한다. 이는 기능이 설계대로 작동함을 보여주기 위한 것입니다. 이러한 설정은 모두 IZCT 통화 흐름 다이어그램의 토폴로지를 기반으로 합니다.

예 1: 게이트키퍼-게이트키퍼 보안 전용 통화 흐름

이 예에서는 모든 게이트웨이 및 게이트키퍼의 관련 컨피그레이션을 보여줍니다.

OGW 컨피그레이션 TGW 컨피그레이션 
!
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 컨피그레이션 TGK1 컨피그레이션 
!
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 컨피그레이션 TGK2 컨피그레이션 
!
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

디버그가 있는 통화 흐름

다음 예에서는 디버그를 사용하여 통화 흐름을 설명합니다.

  1. 캐리어 E의 사용자는 캐리어 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. 발신 게이트웨이의 다이얼피어(tag=3653)가 RAS에 대해 구성되어 있으므로 OGK1에 ARQ를 전송합니다.

    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. OGK1이 ARQ를 수신하면 원격 영역 OGK2에서 목적지를 서비스하고 있음을 확인합니다. 그런 다음 CLI를 통해 IZCT가 필요함을 확인합니다. 보안 izct 암호 <pwd>). OGK1은 LRQ가 전송되기 전에 IZCT를 생성합니다. 그런 다음 IGCT 및 LRQ를 OGK2로 전송하고 RIP 메시지를 다시 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. OGK2가 LRQ를 수신하면 IZCT를 확인합니다. 컨피그레이션에서 LRQ는 IZCT도 포함해야 합니다. 그런 다음 OGK2는 izctSrcZone 및 izctDstZone을 ogk2로 변경하여 새 IZCT를 생성하고 LRQ를 TGK2로 전달합니다. LRQ를 TGK2로 전송한 후 RIP 메시지를 OGK1로 다시 전송합니다.

    게이트키퍼가 클러스터의 일부인 경우 SrcZone 또는 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는 LRQ가 외부 도메인에서 가져온다는 것을 확인합니다. IZCT의 dstZone을 자체 ID와 interZoneType으로 INTER_DOMAIN_CISCO로 업데이트합니다. 그런 다음 새 CAT를 생성하고 업데이트된 IZCT 및 LRQ를 TGK1에 전달합니다.

    TGK2는 다음 두 시나리오 중 하나에서 LRQ가 수신된 영역을 외부 도메인 영역으로 취급합니다.

    • TGK2의 원격 영역 목록에는 LRQ가 수신된 영역이 포함되지 않습니다.

    • TGK2의 원격 영역 목록에는 LRQ가 수신된 영역이 포함됩니다. 영역은 외부 도메인 플래그로 표시됩니다.

    그런 다음 OGK1에 Request In Progress(진행 중인 요청) 메시지를 다시 보냅니다.

    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. 일반적으로 TGK1은 IZCT의 dstCarrierID를 라우팅 프로세스에 의해 결정되는 캐리어 E로 업데이트합니다. 그러나 운송업체가 사용되지 않기 때문에, 당신은 그것을 볼 수 없습니다. TGK1은 IZCT의 비밀번호로 해시 토큰을 생성합니다. LCF는 업데이트된 IZCT가 포함된 LCF를 OGK1로 전송합니다. 이 izctHash는 나중에 OGW로부터 VoIP 설정 메시지를 수신할 때 TGW로부터 TGK1이 수신하는 answerCall ARQ를 인증하는 데 사용됩니다. 

    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은 LCF에서 IZCT를 추출하여 ACF에서 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. OGW는 H.225 SETUP 메시지에서 IZCT를 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
    }
   }
  }
 }

  9. TGW는 ARQ answerCall에서 IZCT를 TGK1에 전달한다. 

    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이 대상 IZCT를 인증했습니다. 이는 TGK1이 IZCT에서 해시를 생성하고 ACF를 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. TGW는 ACF를 수신한 후 캐리어 D에 대한 호를 설정한다.

    예 2: TGW가 수신된 설정 메시지에서 IZCT를 추출할 수 없기 때문에 호출이 실패했습니다.

    이 예는 예 1과 동일한 토폴로지 및 구성을 기반으로 합니다. 이 예에서는 TGW의 소프트웨어가 IZCT가 지원되지 않는 버전으로 변경됩니다. 이러한 경우, TGW는 셋업 메시지로부터 IZCT를 추출할 수 없다. 이렇게 하면 TGK1이 보안 거부의 연결 끊기 이유로 통화를 거부합니다.

    이 예에서는 Example 1과 통화 흐름이 동일하므로 TGW의 설정 메시지, ARQ 및 ARJ만을 나타낸다. 

    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

관련 정보

개정 이력

개정 게시 날짜 의견
1.0
22-Jan-2002
최초 릴리스

기고자

  • 느다드
    삼류

이 문서가 도움이 되셨습니까?

Feedback피드백

지원 문의