packetcable 音声設定 - cisco...chapter 5-1 cisco broadband access center for cable...

C H A P T E R

5-1Cisco Broadband Access Center for Cable アドミニストレータガイド

OL-4409-01-J

5

PacketCable 音声設定

この章では、PacketCable 音声を配備してサービスを提供するために必要となる、すべての作業につ

いて説明します。この章は、PacketCable の次の使用形態に関する情報を含んでいます。

• PacketCable EMTA のセキュアプロビジョニング（P.5-2）

• PacketCable EMTA の BASIC プロビジョニング（P.5-5）

• Euro-PacketCable（P.5-6）

また、PacketCable 音声技術の配備を妨げるおそれのある問題を解決するための情報も示します。

• eMTA プロビジョニングのトラブルシューティング（P.5-8）

• トラブルシューティングのツール（P.5-12）

• トラブルシューティングのシナリオ（P.5-13）

• 証明書信頼階層（P.5-17）

この章は、PacketCable MTA Device Provisioning Specification（PKT-SPPROV1.5-I01-050128）の内容

を熟知している読者を対象としています。詳細については、www.packetcable.com を参照してくださ

い。

第 5 章 PacketCable 音声設定

PacketCable EMTA のセキュアプロビジョニング


OL-4409-01-J

PacketCable EMTA のセキュアプロビジョニングこの項では、主にセキュアな PacketCable 音声プロビジョニングについて取り上げます。PacketCable

Secure は、テレフォニーサービスの盗用や、悪意のあるサービス中断などが発生する可能性を小

限に抑えるように設計されています。PacketCable Secure では、Kerberos インフラストラクチャを利

用して、MTA とプロビジョニングシステムを相互に認証します。MTA とプロビジョニングシス

テム間の対話をセキュリティで保護するために、SNMPv3 も使用されます。

BACC PacketCable のセキュアなプロビジョニングのフロー

PacketCable のプロビジョニングのすべてのフローは、一連のステップとして定義されます。EMTA

プロビジョニングの問題点を診断するときは、ここで示すフロー説明を参考にすると、PacketCable

プロビジョニングフローのどのステップが失敗しているかを特定できます。図 5-1 に、PacketCable

組み込み型 MTA のセキュアなプロビジョニングのフローを示します。

図 5-1 組み込み型 MTA のセキュアなプロビジョニングのフロー

CM/MTAFlow CMTS SYSLOGDOCSISDHCP

DOCSISTFTP

DOCSISToD

ProvServer

PKTDHCP

PKTDNS

PKTTFTP

MSOKDC

MTA-1

CM-1

CM-2

CM-3

CM-4

CM-5

CM-6

CM-7

CM-8

CM-9

CM-10

MTA-25

MTA-2

MTA-3

MTA-4

MTA-5

MTA-6

MTA-7

MTA-8

MTA-9

MTA-10

MTA-11

MTA-12

MTA-13

MTA-14

MTA-15

MTA-16

MTA-17

MTA-18

MTA-19

MTA-20

MTA-21

MTA-22

MTA-23

MTA-24

1294

91

Start with DOCSIS 1.1 Initialization/Registration

Complete DOCSIS 1.1 Initialization/Registration

MTA config file

DHCP Broadcast Discover (includes Option code 60 w/MTA device identifier, option code 43 & requests Option 122 )

SNMP Notify completion of telephony provisioning (MTA MAC address, ESN, pass/fail)

DHCP Offer (option code 122 w/name of provisioning realm)

DHCP Request

DHCP Ack

DHCP Request

DNS Srv (KDC host name associated with the provisioning REALM)

DNS Request

DNS Response (KDC IP Address)

AS Request

AS Reply

TGS Request

TGS Reply

AP Request (KeyMgmt Prot Vers., Protocol ID, KRB_AP_REQ,, Ciphersuites, SHA-1 HMAC)

AP Reply (KeyMgmtProtVers, Protocol ID, KRB_AP_REQ,, ciphersuite selected, key lifetime, Ack req HMAC),

SNMP Inform (see table for data list)

SNMP Get Request(s) for MTA device capabilities (optional/iterative)

SNMP Get Response(s) containing MTA device capabilities (optional/iterative)

SNMP Set with URL encoded file download access method (TFTP or HTTP), filename, hash, and encryption key (if required)

Resolve TFTP server FQDN

TFTP server IP Address

Telephony config file request

Telephony config file

MTA send telephony service provider SYSLOG a notification of provisioning completed (Optional)

DHCP Broadcast Discover (Requests Option Code 122 )

DHCP Offer (option code 122 w/telephony service provider's DHCP server address)

DHCP Request

DHCP Ack

DOCSIS CM config file request

DOCSIS config file

ToD Request

ToD Response

CM registration with CMTS

CMTS Registration ACK

MTA config file

DHCP Broadcast Discover (includes Option code 60 w/MTA device identifier, option code 43 & requests Option 122 )

SNMP Notify completion of telephony provisioning (MTA MAC address, ESN, pass/fail)

DHCP Offer (option code 122 w/name of provisioning realm)

DHCP Request

DHCP Ack

DHCP Request

DNS Srv (KDC host name associated with the provisioning REALM)

DNS Request

DNS Response (KDC IP Address)

AS Request

AS Reply

TGS Request

TGS Reply

AP Request (KeyMgmt Prot Vers., Protocol ID, KRB_AP_REQ,, Ciphersuites, SHA-1 HMAC)

AP Reply (KeyMgmtProtVers, Protocol ID, KRB_AP_REQ,, ciphersuite selected, key lifetime, Ack req HMAC),

SNMP Inform (see table for data list)

SNMP Get Request(s) for MTA device capabilities (optional/iterative)

SNMP Get Response(s) containing MTA device capabilities (optional/iterative)

SNMP Set with URL encoded file download access method (TFTP or HTTP), filename, hash, and encryption key (if required)

Resolve TFTP server FQDN

TFTP server IP Address

Telephony config file request

Telephony config file

MTA send telephony service provider SYSLOG a notification of provisioning completed (Optional)

DHCP Broadcast Discover (Requests Option Code 122 )

DHCP Offer (option code 122 w/telephony service provider's DHCP server address)

DHCP Request

DHCP Ack

DOCSIS CM config file request

DOCSIS config file

ToD Request

ToD Response

CM registration with CMTS

CMTS Registration ACK




OL-4409-01-J

（注）データパケットをキャプチャできるプロトコルアナライザ（プロトコルスニッファ）を使用して、

どのステップが失敗しているかを正確に把握することを強くお勧めします。

また、KDC の障害の根本的な原因を把握するには、KDC ログファイルの内容が重要です。

1. CM-1 ～ 10：これは通常の DOCSIS CM ブートフローで、PacketCable DHCP サーバのリストを

MTA に提供するための DHCP オプション 122 が付加されます。MTA は、これらの DHCP サー

バから DHCP OFFER を受け付けられるようになります。

2. MTA-1 ～ 4：DHCP を使用して、MTA が自身を PacketCable MTA としてアナウンスし、どの機

能およびプロビジョニングフロー（SECURE、BASIC など）をサポートしているかについて情

報を提供します。MTA は、アドレス解決情報と DHCP オプション 122 も取得します。DHCP オプション 122 は、PacketCable ProvServ のアドレスとセキュリティ領域名を含んでいます。

この情報は、MTA が KDC および ProvServer にアクセス可能になるために必要なものです。基

本的なトラブルシューティングのヒントを次に示します。

－ CMTS 上で DHCP リレーエージェントが正しく設定されていることを確認する。CMTS が正しい DHCP サーバをポイントしていることを確認します。

－ MTA、CMTS、DHCP サーバ、DPE 間のルーティングが正しいことを確認する。

－セカンダリサブネットが CMTS 上で正しく設定されていることを確認する。

－ Network Registrar の DHCP 設定が正しいことを確認する。スコープが設定され、IP アドレ

スが利用可能であり、すべてのセカンダリサブネットが設定されていることを確認しま

す。

－ BACC の設定を確認する。cnr_ep.properties ファイルを確認して、必要な PacketCable CNR拡張のプロパティが設定されていることを確認します。この properties ファイルの詳細につ

いては、付録 B「PacketCable DHCP オプションと BACC プロパティのマッピング」を参照

してください。

MTA がフローステップの MTA-1 ～ 2 を循環していることをパケットトレースで発見した場合は、DHCP オプション 122（領域名またはプロビジョニングサーバ FQDN のサブオプション）、DHCP オプション 12（ホスト名）、または DHCP オプション 15（ドメイン名）の設定に問題がある可能性があります。これらのオプションは、すべて MTA にとって必須となる DHCP コンテンツです。

3. MTA-5 ～ 8：MTA が（DHCP オプション 122 で提供される）セキュリティ領域名を使用して、

KDC サービスに対して DNS SRV ルックアップを実行し、KDC の IP アドレスを解決します。

基本的なトラブルシューティングのヒントを次に示します。

－パケットスニッファを使用して、Network Registrar DNS に送信される、送信先や形式が不

正な DNS パケットを検出する。

－ Network Registrar DNS のログレベルをパケット詳細トレースに設定して、Network RegistrarDNS にどのようなパケットが到達するかを確認する。

－ DNS の設定を確認する。cnr_ep.properties に指定されている DNS サーバは、KDC の領域

ゾーン、SRV レコード、および DNS「A」レコードを保持している必要があります。

4. MTA-9：AS_REQ 要求メッセージが KDC によって使用され、MTA が認証されます。基本的な

トラブルシューティングのヒントを次に示します。

－ KDC のログファイルを確認して、AS_REQ が到達しているかどうかを特定し、エラーや

警告がないことを確認する。

－ KDC が、正しい MTA_Root 証明書を使用して設定されていることを確認する。MTA が AS_REQ メッセージに添付して送信する製造業者証明書およびデバイス証明書は、KDC にインストールされている MTA_Root 証明書とチェーンを構成する必要があります。




OL-4409-01-J

5. FQDN_REQ および FQDN_REP（フローには示していません）：KDC が MTA の MAC アドレス

を MTA 証明書から抽出して、検証のために ProvServ に送信します。ProvServ がこの MAC アドレスの FQDN を保持している場合は、FQDN が KDC に返されます。KDC は、MTA から受

信した FQDN を FQDN_REP 応答メッセージで受信した FQDN と比較します。

基本的なトラブルシューティングのヒントを次に示します。

－パケットスニッファを使用して、送信先や形式が不正な DNS パケットを検出する。MTAは、（MTA が DHCP オプション 122 で受信した）ProvServ の FQDN を AS_REP メッセージ

内で KDC に渡します。KDC は、この FQDN を使用して ProvServ の IP アドレスを解決し

ます。

－ KDC キーファイルのファイル名と内容を確認する。DPE 内の KDC サービスキーは、KDCにあるサービスキーと一致している必要があります。KDC にあるサービスキーファイル

の名前は、非常に重要です。

6. MTA-10（AS_REP）：KDC がプロビジョニングサービスチケットを MTA に付与し、サービス

プロバイダー証明書、ローカルシステムプロバイダー証明書（オプション）、および KDC 証明書を MTA に送信します。MTA は、KDC によって送信された証明書が、MTA に格納されて

いるサービスプロバイダールート証明書とチェーンを構成していることを確認します。これ

らの証明書がチェーンを構成していない場合、MTA はプロビジョニングフローのステップ

MTA-1 に処理を戻します。KDC.cer ファイルの詳細については、P.12-42 の「KDC 証明書を管

理するための PKCert.sh ツールの使用方法」を参照してください。基本的なトラブルシューティ

ングのヒントを次に示します。

－ KDC のログファイルを表示して、AS_REP メッセージがデバイスに送信されたことを確認

する。MTA がステップ MTA-1 ～ MTA-10 を循環していることをパケットトレースで発見

した場合は、サービスプロバイダー証明書チェーンに問題があります。

7. MTA-13（AP_REQ）：MTA が、（MTA-10 で受信した）チケットを DHCP オプション 122 で指

定されている ProvServ に提示します。

8. MTA-14（AP_REP）：ProvServ が KDC 共有秘密情報を使用して AP_REQ を復号化し、MTA の提示した ProvServ チケットを検証して、AP_REP を SNMPv3 キーを使用して送信します。以後

の SNMPv3 は認証済みになり、必要な場合は暗号化されます。

9. MTA-15（SnmpV3 Inform）：MTA が、プロビジョニング情報を受信可能なことを ProvServ に通

知します。

10. MTA-19（SNMPv3 SET）：ProvServ が、MTA 設定ファイルの URL、このファイルの暗号キー、

およびこのファイルのハッシュ値を含んだ SNMPv3 SET を MTA に対して実行します。

11. MTA-22 ～ 23：MTA が、指定された TFTP サーバから VoIP 設定ファイルをダウンロードする

処理を進めます。BACC によって、TFTP サーバが DPE コンポーネントに統合されていること

に注意してください。

12. MTA-25（SnmpV3 Inform）：MTA が、新しい設定を受け付け可能かどうかを ProvServ に通知し

ます。


PacketCable EMTA の BASIC プロビジョニング


OL-4409-01-J

PacketCable EMTA の BASIC プロビジョニングBACC では、PacketCable BASIC もサポートしています。BASIC は、簡潔で DOCSIS に似た、ノン

セキュアなプロビジョニングフローを提供します。

ここでは、BASIC.1 のフローについて説明します。

1. MTA-1：セキュアなフローと同様に実行されます。

2. MTA-2：プロビジョニングシステムが BASIC.1 モードで MTA をプロビジョニングするように

設定されている場合、プロビジョニングシステムは、オプション 122 のサブオプション 6 を含

んだ DHCP OFFER を返します。このサブオプションには、特殊な予約済み領域名「BASIC.1」が含まれています。この予約済み領域名は、MTA に対して BASIC.1 プロビジョニングフロー

を使用するように指示するものです。また、この OFFER はプロビジョニングシステムの IP アドレスをオプション 122.3 に保持しており、file フィールドと siaddr フィールドに MTA 設定

ファイルの位置が入力されています。

3. MTA-3、4：MTA DHCP 交換の残りの部分が実行されます（REQUEST および ACK が交換され

ます）。

4. MTA は、ステップ MTA-22 まで直接スキップします。file および siaddr の情報を使用して、MTAは設定ファイルをプロビジョニングシステムから TFTP で取得します。

（注） MTA および ProvServ の認証や、暗号化は一切発生しません。

BASIC.2 フローは BASIC.1 と同一ですが、次の点が異なります。

• MTA の DHCP オプション 122 のサブオプション 6 に、「BASIC.2」が入力される。

• フローの後となる MTA-25 で、MTA がプロビジョニングステータス SNMPv2c INFORM を発行する（INFORM ターゲットは、DHCP オプション 122 のサブオプション 3 で指定されたも

の）。

BASIC PacketCable フローは DOCSIS フローと似ていますが、次の点が異なります。

• MTA とプロビジョニングシステムの間で ToD 交換が発生しない。

• MTA 設定ファイルの中に、完全性ハッシュが含まれている必要がある。具体的には、設定ファ

イルの内容全体の SHA1 ハッシュが pktcMtadevConfigFileHash SNMP varbind に入力され、Endof File TLV の直前の TLV 11 内に配置されている必要があります。

• BASIC.2 フローは、MTA が設定ファイルを受信して処理した後に、プロビジョニングステー

タス SNMPv2c INFORM を発行する。この INFORM は、MTA のプロビジョニングが正常に完

了したかどうか、つまりプロビジョニングに問題がなかったかどうかを BACC に通知するもの

です。問題がある場合は、エラーが生成されて、イベントが DPE から RDU に送信され、次に

BACC クライアントに送信されることがあります。この INFORM は、設定ファイルの問題点を

デバッグする場合に特に役立ちます。

DOCSIS フローの詳細については、第 4 章「DOCSIS 設定」を参照してください。

（注） PacketCable BASIC プロビジョニングフローを使用する場合は、PacketCable BASIC 対応の eMTA を使用していることを事前に確認してください。eMTA は、BASIC に対応していることを DHCPDISCOVER のオプション 60、TLV 5.18（サポートされているフロー）で報告する必要があります。

第 5 章 PacketCable 音声設定Euro-PacketCable


OL-4409-01-J

PacketCable の TLV 38 と MIB のサポート

BACC は、一連の PacketCable 1.5 MIB を完全にサポートしています。

BACC は、PacketCable 設定テンプレートで TLV 38 をサポートしています。この TLV を使用して、

複数の SNMP 通知ターゲットを設定できます。この TLV を設定すると、すべての通知が TLV 38 で

設定したターゲットにも発行されます。

SNMP v2C 通知

BACC では、PacketCable MTA からの SNMP v2C TRAP 通知と SNMP v2C INFORM 通知の両方をサ

ポートしています。

Euro-PacketCableEuro-PacketCable サービスは、基本的には North American PacketCable サービスのヨーロッパ版にあ

たりますが、次の点が異なります。

• Euro-PacketCable では、使用する MIB が異なる。

• Euro-PacketCable では、使用するデバイス証明書（MTA_Root.cer）とサービスプロバイダー証

明書（サービスプロバイダールート）のセットが異なる。

Euro-PacketCable の証明書の場合は、kdc.ini に「euro-packetcable = true」プロパティが記述され

ている必要があります。詳細については、P.2-15 の「Euro-PacketCable のサポート」を参照して

ください。

Euro-PacketCable を使用する場合は、PacketCable のプロパティ /pktcbl/prov/locale の値を必ず

EURO に設定してください（デフォルトは NA（North America）です）。ロケールは、設定ファ

イルユーティリティで指定することができます。詳細については、P.12-25 の「設定ファイル

ユーティリティの使用方法」を参照してください。

Euro-PacketCable の MIB

Euro-PacketCable の MIB は、基本的にはドラフト IETF MIB のスナップショットです。MTA の設定

ファイルは、MIB を参照する SNMPVarBind が基本的な構成要素です。PacketCable の MIB と Euro

の MIB は大きく異なるため、PacketCable と Euro-PacketCable の設定ファイルには互換性がありま

せん。インストール時に、PacketCable のサンプルファイル（cw29_config.tmpl）と Euro-PacketCable

のサンプルファイル（ecw15_mta_config.tmpl）が <BACC_HOME>/rdu/samples ディレクトリにコ

ピーされます。

BACC には、次の Euro-PacketCable MIB が付属しています。

• DOCS-IETF-BPI2-MIB

• INTEGRATED-SERVICES-MIB

• DIFFSERV-DSCP-TC

• DIFFSERV-MIB

• TCOMLABS-MIB

• PKTC-TCOMLABS-MTA-MIB

• PKTC-TCOMLABS-SIG-MIB

第 5 章 PacketCable 音声設定Euro-PacketCable


OL-4409-01-J

Euro-PacketCable の MIB の設定

Euro-PacketCable の MIB を使用するように BACC を設定するには、ロードされる MIB を指定して

いる BACC RDU プロパティを変更する必要があります。デフォルトでは、このプロパティは

PacketCable の MIB を含んでいます。

この操作は、次のいずれかの方法で実行できます。

• rdu.properties を修正して、RDU を再起動する。

• 管理者のユーザインターフェイスを使用する。Configuration > Defaults > System Defaults に移動

して、MIB リストを下に示したリストに置き換えます。RDU を再起動する必要はありあません。

• Prov API の changeSystemDefaults() コールを使用する。RDU を再起動する必要はありあません。

プロパティの名前は、/snmp/mibs/mibList（properties ファイル）、または SNMPPropertyKeys.MIB_LIST

（Prov API の定数の名前）です。プロパティの値はカンマ区切り形式（CSV）で、下に示す必要な

MIB 名で構成されています。

/snmp/mibs/mibList=SNMPv2-SMI,SNMPv2-TC,INET-ADDRESS-MIB,CISCO-SMI,CISCO-TC,SNMPv2-MIB,RFC1213-MIB,IANAifType-MIB,IF-MIB,DOCS-IF-MIB,DOCS-IF-EXT-MIB,DOCS-BPI-MIB,CISCO-CABLE-SPECTRUM-MIB,CISCO-DOCS-EXT-MIB,SNMP-FRAMEWORK-MIB,DOCS-CABLE-DEVICE-MIB,DOCS-CABLE-DEVICE-MIB-OBSOLETE,DOCS-QOS-MIB,CISCO-CABLE-MODEM-MIB,DOCS-IETF-BPI2-MIB,INTEGRATED-SERVICES-MIB,DIFFSERV-DSCP-TC,DIFFSERV-MIB,TCOMLABS-MIB,PKTC-TCOMLABS-MTA-MIB,PKTC-TCOMLABS-SIG-MIB


eMTA プロビジョニングのトラブルシューティング


OL-4409-01-J

eMTA プロビジョニングのトラブルシューティングPacketCable 組み込み型メディアターミナルアダプタ（eMTA）のプロビジョニングは、比較的複

雑なプロセスです。ただし、適切なツールと方法を使用することで、ごく簡単に eMTA を運用可能

にすることができます。

この章では、Network Registrar と BACC の両方を使用していることを前提としています。ただし、

情報の多くはこれ以外の配備状態にも適用されます。また、Network Registrar の基礎知識（スコー

プ、ポリシー、基本的な DNS ゾーン設定、およびレコードエントリ）と BACC の基礎知識（サー

ビスクラス、DHCP 基準、外部ファイル、および BACC ディレクトリ構造）があることを前提と

しています。

PacketCable eMTA のプロビジョニングプロセスは、セキュアなフローの場合は 25 ステップで構成

されます。BASIC フローでは、ステップの数はかなり少なくなります。eMTA をトラブルシュー

ティングするには、PacketCable プロビジョニング仕様に基づいたこれらの 25 ステップに関する知

識が不可欠です。

この項では、次のトピックについて取り上げます。

• コンポーネント（P.5-8）

• 基本変数（P.5-10）

コンポーネント

eMTA をトラブルシューティングする前に、以降の項で説明する次のシステムコンポーネントにつ

いて理解する必要があります。

• 組み込み型メディアターミナルアダプタ

• DHCP サーバ

• DNS サーバ

• 鍵発行局

• PacketCable プロビジョニングサーバ

• Call Management Server

組み込み型メディアターミナルアダプタ

eMTA は、ケーブルモデム（CM）とメディアターミナルアダプタ（MTA）を、よく利用される

ソフトウェアイメージとともに 1 つのボックスに組み込んだものです。CM と MTA はいずれも固

有の MAC アドレスを持っており、それぞれが DHCP を実行して固有の IP アドレスを取得します。

eMTA は、少なくとも 3 つの証明書を保持しています。証明書の 1 つは、一意の MTA 証明書です。

2 番目の証明書は、MTA の製造業者を識別するものです。デバイス証明書と製造業者証明書は、デ

バイスや製造業者を認証するために、いずれも MTA によって鍵発行局（KDC）に送信されます。3

番目の証明書は、KDC から MTA に送信される証明書を検証するためのテレフォニールート証明書

です。KDC の証明書は、テレフォニールートを起点としてチェーンを構成するため、KDC 証明書

の信頼性を検証するには、テレフォニールートが MTA 上に存在している必要があります。MTA 部

分は、MTA を制御するコールエージェントを識別するための固有の設定ファイルを受信します。




OL-4409-01-J

DHCP サーバ

DOCSIS 仕様では、ケーブルモデムが自身の IP アドレスをダイナミックホストコンフィギュレー

ションプロトコル（DHCP）を使用してネゴシエートするように規定されています。MTA は、

DOCSIS ネットワーク上のほとんどの CPE と同様に、DHCP を使用して自身の IP アドレスおよび

その他の必須情報（DNS サーバ、Kerberos 領域名のための PacketCable オプション 122、プロビジョ

ニングサーバの FQDN）を取得する必要があります。

（注）ケーブルモデム部分は、通常の必須 DHCP オプションに加えて、オプション 122 のサブオプショ

ン 1 も要求して取得する必要があります。このサブオプションは、オファーの送信元となる適切な

DHCP サーバの IP アドレスとして、ケーブルモデム部分が MTA 部分に渡します。

PacketCable をサポートする BACC を使用すると、正しく設定した BACC は、オプション 122 フィー

ルドに加えて、ToD サーバ、DNS サーバ、TFTP サーバのフィールドにも自動的に値を入力します。

これらについて、Network Registrar ポリシーで明示的に設定する必要はありません。

DNS サーバ

ドメインネームシステム（DNS）サーバは、PacketCable のプロビジョニングに不可欠です。BACC

アーキテクチャにおけるデバイスプロビジョニングエンジン（DPE）である PacketCable プロビ

ジョニングサーバは、適切なゾーン内にアドレス（A）レコードを持っている必要があります。こ

れは、このサーバの完全修飾ドメイン名（FQDN）が DHCP サーバによって MTA にオプション 122

で提供されるためです。KDC 領域は、Kerberos サーバの FQDN を記述したサーバ（SRV）レコー

ドを含んでいる領域名と同じ名前でゾーンを持っている必要があります。

SRV レコードで指定される Kerberos サーバは、適切なゾーン内に自身の A レコードを持っている

必要があります。MTA 設定ファイルで指定される Call Management Server（CMS）も、適切なゾー

ン内に A レコードを持っている必要があります。後に、MTA 自体も適切なゾーン内に A レコー

ドを持っている必要があります。これは、CMS は MTA の FQDN を解決することによって MTA に

到達するためです。MTA の A レコードを作成する方法としては、ダイナミック DNS（DDNS）を

お勧めします。DDNS の設定およびトラブルシューティングについては、Cisco Network Registrar の

マニュアルを参照してください。

鍵発行局

KDC は、MTA の認証を担当します。このため、KDC は MTA の証明書を検証するとともに、MTA

が KDC を認証できるように KDC 自身の証明書を提供する必要があります。また、KDC は DPE（プ

ロビジョニングサーバ）と通信して、MTA がネットワーク上でプロビジョニングされていること

を検証します。

PacketCable プロビジョニングサーバ

PacketCable プロビジョニングサーバは、SNMP を使用して MTA 設定ファイルの位置を MTA に伝

達し、MTA のパラメータをプロビジョニングします。MTA とプロビジョニングサーバ間のすべて

の通信で、SNMPv3 が使用されます。SNMPv3 通信の開始に使用されるキーは、MTA によって、

KDC との認証フェーズ中に取得されます。プロビジョニングサーバの機能は、BACC アーキテク

チャにおける DPE によって提供されます。




OL-4409-01-J

Call Management Server

Call Management Server（CMS）は、基本的にはソフトスイッチ（コールエージェント）です。ケー

ブルネットワーク上の QoS を制御するための追加の PacketCable 機能を備えています。PacketCable

プロビジョニングが成功すると、MTA はネットワークコールシグナリング（NCS）の Restart in

Progress（RSIP）メッセージを CMS に送信します。

基本変数

この項では、eMTA の適切なプロビジョニングに必要となる基本変数について説明します。

• 証明書（P.5-10）

• スコープ選択タグ（P.5-11）

• MTA 設定ファイル（P.5-11）

証明書

MTA_Root.cer ファイルには、MTA ルート証明書（正式な PacketCable MTA ルートがルートになっ

ている証明書）が含まれています。MTA_Root.cer は、通常は重大な問題を引き起こすことはあり

ません。

プロビジョニングの対象となる MTA でどのテレフォニールート証明書が必要になるかについて、

あらかじめ把握しておく必要があります。実稼働ネットワークへの配備では、実在の PacketCable

ルートがルートになっているテレフォニー証明書を使用します。ルートには、ラボ環境およびテス

ト環境で使用される PacketCable テストルートもあります。KDC が自身を MTA に認証させるため

に使用する KDC 証明書は、MTA に格納されているものと同じテレフォニールート（PacketCable

の実在ルートまたはテストルート）がルートになっている必要があります。MTA 製造業者のほと

んどは、Telnet ログイン機能と HTTP ログイン機能の一方または両方を備えたテストイメージをサ

ポートしているため、どのテレフォニールートがイネーブルになっているかを特定して、使用され

るルートを変更することができます（ほとんどの場合、選択できるのは PacketCable 実在ルートと

テストルートのいずれかのみです）。

も一般的なシナリオでは、次の証明書を（$BACC_HOME/kdc/solaris/packetcable/certificates ディレ

クトリから）ロードした KDC を使用します。

• CableLabs_Service_Provider_Root.cer

• Service_Provider.cer

• Local_System.cer

• KDC.cer

• MTA_Root.cer

初の 4 つの証明書は、テレフォニー証明書チェーンを構成します。MTA_Root.cer ファイルは、

MTA の送信する証明書を検証するために KDC が使用する MTA ルートを保持しています。

（注） KDC 証明書のインストールおよび管理については、P.12-42 の「KDC 証明書を管理するための

PKCert.sh ツールの使用方法」を参照してください。

PacketCable テストルートを現在使用しているかどうかを特定するには、

CableLabs_Service_Provider_Root.cer ファイルを Windows で開いて、Subject OrgName エントリが O

= CableLabs であることを確認するか、サブジェクト代替名が CN=CABLELABS GENERATED TEST

ROOT FOR EQUIPMENT TEST PURPOSES ONLY と記述されていることを確認します。




OL-4409-01-J

KDC 証明書（KDC.cer）は、使用する領域名を保持しています。BACC（および対応する DNS ゾー

ン）で使用するように設定されている領域名は、この領域名と一致している必要があります。また、

MTA 設定ファイルの領域オリジナル名が、テレフォニールート内にある組織名と一致している必

要があります。

KDC 証明書は、対応する秘密鍵を持っています。この秘密鍵は、$BACC_HOME/kdc/solaris ディレ

クトリにインストールされている必要があります。秘密鍵の名前は、通常は KDC_private_key.pkcs8

または KDC_private_key_proprietary です。証明書を変更するときは、秘密鍵も変更する必要があり

ます。

スコープ選択タグ

ほとんどのシナリオでは、BACC は、BACC 管理ユーザインターフェイスの DHCP 基準ページで指

定されている選択基準に一致しているスコープ選択タグを使用して、スコープからのすべての

DHCP 要求の処理に関係します。クライアントクラスもスコープを BACC 処理に関連付けるため

に使用できます。この関連付けは、デバイスをプロビジョニングする前に実行する必要があります。

MTA 設定ファイル

MTA 設定ファイルは、CMS の位置を保持しています。また、領域名のエントリを保持している必

要があります。この値は、使用中の証明書チェーンの値と一致している必要があります。

MTA 設定ファイル内の特定のテーブルエントリは、MTA にオプション 122 で配送された領域名に

基づいてインデックス付けされます。MTA 設定ファイル内のこの領域名エントリは、オプション

122 で配送されたものと一致する必要があります。たとえば、オプション 122 で配送された領域名

が DEF.COM であった場合、MTA 設定ファイルの pktcMtaDevRealm テーブルのエントリは、この

領域名の ASCII 符号化文字値（Cisco Broadband Configurator を使用している場合はドット区切り 10

進形式）、68.69.70.46.67.79.77 で構成されるサフィックスを使用してインデックス付けされます。

Web には、この変換を容易にする無料の ASCII 変換ページが多数存在しています。


トラブルシューティングのツール


OL-4409-01-J

トラブルシューティングのツールPacketCable MTA Device Provisioning Specification に記述されている 25 の eMTA セキュアプロビ

ジョニングのステップについては、図 5-1 に示しています。

この項では、次のトピックについて取り上げます。

• ログ（P.5-12）

• Ethereal、SnifferPro、およびその他のパケットキャプチャツール（P.5-12）

ログ

次に示すログファイルを使用して、次の情報が管理されています。

• Network Registrar の 2 つのログ（name_dhcp_1_log と name_dns_1_log）。Network Registrar の直

近のいくつかのログエントリを保持しています。DHCP または DNS に関する問題については、

これらのファイルを調べてください。

• $BACC_HOME/kdc/logs/kdc.log ファイル。KDC と MTA とのインタラクション、および KDC とDPE とのインタラクションのすべてを記録しています。

• $BACC_DATA/dpe/logs/dpe.log ファイル。MTA との SNMPv3 インタラクションに関連する主な

ステップを記録しています。ハードウェア DPE に対して作業している場合は、show log CLI コマンドも使用できます。

（注）コマンドラインインターフェイスを使用して、SNMP、登録サーバ、および登録サーバの詳細メッ

セージのトレースを有効にしておくと、PacketCable に潜在的な問題があった場合のトラブルシュー

ティングに役立ちます。適切なトラブルシューティングコマンドについては、『Cisco BroadbandAccess Center for Cable Command Line Interface Reference』を参照してください。

Ethereal、SnifferPro、およびその他のパケットキャプチャツール

eMTA のトラブルシューティングには、パケットキャプチャツールが不可欠です。CableLabs が

パッケージ化している Ethereal バージョンには、PacketCable 固有の数多くのパケットデコーダが含

まれています。これらには、Kerberos の AS パケットおよび AP パケットが含まれます。

• 特定の障害が DHCP に関係していると考えられる場合は、CMTS ケーブルインターフェイスの

IP アドレスと DHCP サーバの IP アドレスを送信元または宛先とするパケットをフィルタリン

グしながら、パケットをキャプチャします。

• 特定の障害が、DHCP の後に発生する 25 ステップのいずれかに関係していると考えられる場合

は、eMTA の IP アドレスを送信元または宛先とするパケットをすべてフィルタリングします。

この方法では、図 5-1 に示したプロビジョニングステップ 5 ～ 25 を単純な手順で容易にトレー

スできます。


トラブルシューティングのシナリオ


OL-4409-01-J

トラブルシューティングのシナリオ組み込み型 MTA に関して発生するおそれのある障害のシナリオを、表 5-1 に示します。

表 5-1 トラブルシューティングのシナリオ

発生する問題考えられる原因対処の方法

KDC が起動しない。 KDC 証明書が秘密鍵と対応していません。互いに対応する証明書と秘密鍵があることを

確認します。

KDC ライセンスが有効期限切れであるか、見

つかりません。

KDC ライセンスを $BACC_HOME/kdc ディレ

クトリに復元します。

MTA デバイスが BACC の

Devices ページに表示され

ない。

不正なケーブルヘルパーアドレスが設定さ

れている可能性があります。

ヘルパーアドレスを修正します。

スコープ選択タグが、BACC ユーザインター

フェイスで選択されている DHCPCriteria と

一致しません。

MTA スコープ選択タグが、関係する MTA に

ついて BACC で作成した PacketCable DHCP

基準のスコープ選択タグと一致していること

を確認します。

Network Registrar 拡張ポイントが正しくイン

ストールされていません。

Network Registrar 拡張ポイントを再インス

トールします。正しい手順については、『CiscoBroadband Access Center for Cable Installation

Guide』を参照してください。

ケーブルモデム部分がオプション 122 を受

信しませんでした。

ケーブルモデム部分のスコープのタグが、

BACC に設定されている DOCSIS DHCP 基準

と一致していることを確認します。

MTA が DHCP オファーを

受け付けず、DHCP フロー

を循環し続ける。

無効な DHCP オプションが設定されていま

す。

スコープポリシーに DNS サーバオプション

が含まれていること、または cnr_ep.properties

ファイルにプライマリ DNS サーバとセカン

ダリ DNS サーバのエントリが含まれている

ことを確認します。

DHCP オファーが、ケーブルモデム部分のオ

プション 122 のサブオプション 1 で指定され

ているものとは別の DHCP サーバから送信

された可能性があります。

cnr_ep.properties ファイルを確認して、プライ

マリとセカンダリの DHCP サーバが正しく設

定されていることを確認します。

KDC.log ファイルと

ethereal トレースの両方

が、MTA が KDC にアクセ

スしないことを示してい

る。

cnr_ep.properties ファイルと MTA スコープ

ポリシーの一方または両方で、不正な DNS

サーバが指定されています。

cnr_ep.properties の DNS サーバを確認し、修

正します。

Kerberos 領域のゾーンが見つからないか、正

しく設定されていません。

領域と同じ名前のゾーンが作成されているこ

と、およびゾーンが「SRV」レコードを

「_kerberos._udp 0 0 88 <KDC FQDN>」形式で

保持していることを確認します。

KDC の「A」レコードエントリが見つから

ないか、正しくありません。

Kerberos ゾーンの「SRV」レコードに含まれ

ている FQDN について、「A」レコードが存在

していることを確認します。

DPE の FQDN を解決できません。 dpe.properties の provFQDNs エントリに、DPE

の正しい FQDN と IP が記述されていること

を確認します。




OL-4409-01-J

Kerberos の AS-Request 中

に、KDC が障害を報告す

る。

MTA 証明書が、KDC によって使用されてい

る MTA ルートと一致しません。

MTA_Root.cer を現用システムで使用されて

いるものと比較して、MTA_Root.cer が適切な

ことを確認します。

適切なものである場合は、MTA 自体で証明書

に関する問題が発生している可能性がありま

す。この状況は非常にまれであり、該当する

場合は MTA 製造業者に連絡してください。

プロビジョニングサーバに対する KDC から

の FQDN ルックアップが失敗しました。デバ

イスが、まだ BACC でプロビジョニングされ

ていない可能性があります。

デバイスが表示されることを確認します。

サービスクラスと DHCP 基準が与えられて

いる必要があります。

クロックスキューエラー。詳細については、

P.3-8 の「PacketCable チェックリスト」を参

照してください。

すべての BACC ネットワーク要素が NTP を

介してクロック同期していることを確認しま

す。詳細については、『Broadband Access Center

for Cable Command Line Interface Reference』を

参照してください。

KDC と DPE の間にミスマッチが存在してい

る可能性があります。

（注）他のデバイスが正しくプロビジョニングされている場合、これは問題の原因ではありません。

次の 3 つのエントリが、

$BACC_HOME/kdc/solaris/keys ディレクトリ

に存在していることを確認します。

• mtafqdnmap,[email protected]

• mtaprovsrvr,[email protected]

• krbtgt,[email protected]

システムに、この例と異なる DPE FQDN と領

域名が保持されています。これらのエントリ

の内容は、dpe.properties の「KDCServiceKey」

エントリ、または keygen ユーティリティを使

用して生成されるキーに含まれているエント

リと一致している必要があります。

KDC は AS-Request と

AS-Reply（図 5-1 のステッ

プ 9 とステップ 10）が成

功したことを報告するが、

MTA はステップ 9 より後

に進まず、このステップま

でを再プロビジョニング

し続ける。

MTA でロードされているかイネーブルに

なっているテレフォニールートと、KDC で

ロードされているテレフォニールートとの

間で、証明書のミスマッチが存在していま

す。

MTA と KDC の証明書を確認します。

非常にまれですが、テレフォニー証明書

チェーンが破損している可能性があります。

（注）他のデバイスが正しくプロビジョニングされている場合、これは問題の原因ではありません。

MTA で正しい証明書がロードされているか、

イネーブルになっていることを確認します。

正常にプロビジョニングできているデバイス

がまったくない場合は、KDC 上で別の証明書

を試してみます。

表 5-1 トラブルシューティングのシナリオ（続き）





OL-4409-01-J

AP Request と AP Reply（図

5-1 のステップ 14）が失敗

する。

クロックスキューエラー。詳細については、

P.3-8 の「PacketCable チェックリスト」を参

照してください。

すべての BACC ネットワーク要素が NTP を

介してクロック同期していることを確認しま

す。詳細については、『Broadband Access Center

for Cable Command Line Interface Reference』を

参照してください。

プロビジョニングサーバの FQDN を解決で

きません。

プロビジョニングサーバ（DPE）の DNS エン

トリが正しいことを確認します。

dpe.properties の provFQDNs エントリに、プロ

ビジョニングサーバ（DPE）の正しい FQDN

と IP が保持されていることを確認します。

MTA から DPE に到達するルートが存在して

いません。

ルーティングの問題を解決します。

MTA が設定ファイルの

TFTP 要求を発行しない。

DPE 上で実行されている TFTP サーバに到達

するためのルートが存在していません。

ルーティングの問題を解決します。

MTA が TFTP 設定ファイ

ルを受信しない。

設定ファイルが DPE でキャッシュされてい

ません。

次のプロビジョニング試行でファイルが

キャッシュされるまで、待機します。この方

法で失敗する場合には、MTA をリセットしま

す。

Network Registrar の MTA スコープポリシー

に、矛盾する TFTP サーバオプションが含ま

れています。

TFTP サーバの DPE アドレスは BACC が挿入

するため、このオプションはポリシーから削

除しても問題ありません。

MTA は設定ファイルを受

信するが、dpe.log ファイ

ルを参照すると、DPE が

SNMP Inform（図 5-1 のス

テップ 25）の受信に失敗

している。

次のいずれかが発生しています。

• 設定ファイル内部での矛盾

• テレフォニー証明書チェーンの領域オ

リジナル名との矛盾

• オプション 122 で提供されている領域名

との矛盾

MTA 設定ファイルに一貫性があることを確

認します。

RSIP が送信されていない

にもかかわらず、MTA が

成功を報告する（図 5-1 の

ステップ 25）。

MTA が、MTA 設定ファイルで指定されてい

る CMS FQDN の IP アドレスを解決できませ

ん。

CMS の DNS エントリが存在していることを

確認します。

MTA が CMS の IP アドレスに到達できませ

ん。これは、ルートが設定されていないこと

を示しています。

ルーティングの問題をすべて解決します。

CMS サービスのために

KDC に再度アクセスしよ

うとしているにもかかわ

らず、MTA が成功を報告

する（図 5-1 のステップ

25）。

MTA 設定ファイルが誤ったケーブルモデム

をポイントしています。

設定ファイルを修正するか、設定ファイルに

リストされている FQDN を使用するように

Cisco BTS 10200 を再設定します。

MTA 設定ファイルのpktcMtaDevCmsIPsecCtrl

値が見つからないか、1 に設定されています。

これは、MTA がセキュア NCS コールシグナ

リングを実行すること、または CMS FQDN

の ASCII サフィックスと一致しない ASCII

サフィックスを使用することを意味します。

設定ファイルを修正します。セキュアシグナ

リングを実行する場合は、必要な手順に従っ

て、セキュアシグナリングをサポートするよ

うに KDC と BTS を設定します。






OL-4409-01-J

MTA が成功を報告して

（図 5-1 のステップ 25）、

RSIP を送信するが、ソフ

トスイッチからの応答が

ないか、応答としてエラー

を受信する。

MTA が Cisco BTS 10200 上でプロビジョニン

グされていないか、不正にプロビジョニング

されています。

MTA を Cisco BTS 10200 上でプロビジョニン

グします。

eMTA の DNS エントリが存在していません。適切な DNS ゾーンに eMTA のエントリを配

置します。ダイナミック DNS を使用すること

をお勧めします。DDNS のイネーブル化につ

いては、Cisco Network Registrar のマニュアル

を参照してください。




証明書信頼階層


OL-4409-01-J

証明書信頼階層BACC PacketCable には、図 5-2 に示すように、MTA デバイス証明書階層と CableLabs サービスプ

ロバイダー証明書階層の 2 つの証明書階層があります。

図 5-2 PacketCable の証明書階層

BACC PacketCable の実装作業を行う前に、次の技術ドキュメントの内容を完全に理解しておく必要

があります。

• RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile

• DOCSIS Baseline Privacy Plus Interface Specification（SP-BPI+-I11-040407、2004 年 4 月 7 日）

（注） Euro-PacketCable は PacketCable のセキュリティ仕様（PKT-SP-SEC-I08-030415）を使用しています

が、Euro-PacketCable 環境で使用されるデジタル証明書に関しては、変更の必要な部分があります。

Euro-PacketCable と PacketCable を可能な限り類似したものにするため、Euro-PacketCable では、セ

キュリティ仕様の新しいリビジョン（PKTSP-SEC-I08-030415）を含めて、PacketCable のすべての

セキュリティ技術を使用しています。

Euro-PacketCable 証明書の要素で PacketCable 証明書と異なっているものについては、以降の表で示

します。

Euro-PacketCable では、Euro-PacketCable 証明書が有効となる唯一の証明書です。

PKT-SP-SEC-I08-030415 で述べられている、PacketCable 証明書について言及している PacketCable の

すべての要件は、対応する Euro-PacketCable 証明書の要件に変更されます。

Euro-PacketCable 対応の組み込み型 MTA では、DOCSIS CVC CA の公開鍵の代わりに、Euro-DOCSIS

ルート CVC CA の公開鍵が CM の不揮発性メモリに格納されている必要があります。

Euro-PacketCable 対応の独立型 MTA では、不揮発性メモリに tComLabs CVC ルート証明書と

tComLabs CVC CA 証明書が格納されている必要があります。製造業者の CVC は、証明書チェーン

を検証することで検証されます。

CableLabs

CableLabs

CA

CA

DFKDC12

9909

MTA

MTA

MTA

MTA




OL-4409-01-J

証明書の検証

PacketCable 証明書の検証では、通常は証明書のチェーン全体が検証されます。たとえば、プロビ

ジョニングサーバが MTA デバイス証明書を検証するときは、次の証明書チェーンが検証されます。

MTA ルート証明書 + MTA 製造業者証明書 + MTA デバイス証明書

MTA 製造業者証明書の署名は MTA ルート証明書を使用して検証され、MTA デバイス証明書の署

名は MTA 製造業者証明書を使用して検証されます。MTA ルート証明書は自己署名されていて、プ

ロビジョニングサーバにとって既知のものです。MTA ルート証明書に存在する公開鍵は、この証

明書自体の署名を検証するために使用されます。

チェーンの初の証明書は、ケーブル経由で送信される証明書チェーンに通常は明示的に含まれて

いません。初の証明書が明示的に含まれている場合、初の証明書は、検証する側にとって既知

のものである必要があり、変更が一切加えられていない必要があります。ただし例外として、証明

書シリアル番号、有効期間、署名の値は変更されてもかまいません。ケーブル経由で渡された

CableLabs サービスプロバイダールート証明書に、既知の CableLabs サービスプロバイダールート

証明書と比較してこれら以外の変更点が存在している場合、比較を実行するデバイスは証明書の検

証に失敗する必要があります。

証明書チェーンの検証のためのルール自体が、RFC 2459 に完全に準拠している必要があります。こ

の RFC では、証明書パスの検証として言及されています。通常、X.509 証明書では、証明書の発行

者名がもう一方の証明書のサブジェクト名と一致している場合、一連の緩やかな判定ルールがサ

ポートされます。ルールが緩やかであるため、2 つの名前フィールドのバイナリ比較が一致してい

ない場合でも、2 つの名前フィールドは一致していると宣言されることがあります。RFC 2459 で

は、実装が単純なバイナリ比較を使用して一致またはミスマッチを宣言できるように、認証局が名

前フィールドの符号化を制限することを勧めています。

PacketCable のセキュリティは、この推奨事項に従っています。したがって、PacketCable 証明書の

DER 符号化された tbsCertificate.issuer フィールドが、発行者の証明書の DER 符号化された

tbsCertificate.subject フィールドと完全に一致している必要があります。実装は、DER 符号化された

tbsCertificate.issuer フィールドと tbsCertificate.subject フィールドのバイナリ比較を実行することに

よって、発行者名をサブジェクト名と比較できます。

以降の項では、必要な証明書チェーンが指定されています。この証明書チェーンを使用して、図 5-2

に示している PacketCable 証明書信頼階層のリーフノード（下層）に該当する各証明書を検証す

る必要があります。

入れ子化されている有効期間は検証されず、強制されません。このため、証明書の有効期間は、そ

の証明書を発行した証明書の有効期間内に収まっている必要はありません。




OL-4409-01-J

MTA デバイス証明書階層

デバイス証明書階層は、DOCSIS1.1/BPI+ 階層のデバイス証明書階層をそのまま写したものです。一

連の製造業者証明書の発行元証明書として使用される、CableLabs 発行の PacketCable MTA ルート

証明書がルートになっています。製造業者証明書は、個々のデバイス証明書に署名するために使用

されます。

以降の表に含まれている情報は、RFC 2459 に従った必須フィールドで使用する PacketCable 固有の

値を示しています。これらの PacketCable 固有の値は、表 5-2 に従って指定する必要がありますが、

Validity Period は各表で示されているとおりにする必要があります。必須フィールドの PacketCable

での値が特に示されていない場合は、RFC 2459 のガイドラインに従う必要があります。

MTA ルート証明書

この証明書は、MTA ルート証明書、MTA 製造業者証明書、および MTA デバイス証明書で構成さ

れる証明書チェーンの一環として検証する必要があります。

表 5-2 MTA ルート証明書

MTA ルート証明書

Subject Name Form PacketCable

C=US

O=CableLabs

OU=PacketCable

CN=PacketCable Root Device Certificate Authority

Euro-PacketCable

C=BE

O=tComLabs

OU=Euro-PacketCable

CN=Euro-PacketCable Root Device Certificate

Authority

Intended Usage この証明書は、MTA 製造業者証明書に署名するために KDC によって使用されます。この証明書

は MTA によって使用されることがないため、MTA MIB には表示されません。

Signed By 自己署名

Validity Period 20 年以上。この証明書を再発行する必要のない、十分な長さの有効期間であると想定されます。

Modulus Length 2048

Extensions keyUsage[c,m](keyCertSign, cRLSign)

subjectKeyIdentifier[n,m]

basicConstraints[c,m](cA=true, pathLenConstraint=1)




OL-4409-01-J

MTA 製造業者証明書

この証明書は、MTA ルート証明書、MTA 製造業者証明書、および MTA デバイス証明書で構成され

る証明書チェーンの一環として検証する必要があります。state/province、city、および製造業者のファ

シリティは、オプションのアトリビュートです。製造業者は、製造業者証明書を複数保有している

ことがあり、証明書が製造業者ごとに 1 つまたはそれ以上存在することがあります。同じ製造業者

のすべての証明書が、製造時または現地でのアップデート中に各 MTA に提供される可能性があり

ます。MTA は、MTA デバイス証明書の発行者名を MTA 製造業者証明書のサブジェクト名と比較

して、使用する適切な証明書を選択する必要があります。デバイス証明書の authorityKeyIdentifier

は、存在する場合、RFC 2459 に記述されているとおり、製造業者証明書の subjectKeyIdentifier と一

致している必要があります。O と CN にある <CompanyName> フィールドは、2 つのインスタンス

間で異なる場合があります。

表 5-3 MTA 製造業者証明書

MTA 製造業者証明書


C=US

O=CableLabs

OU=PacketCable

CN=PacketCable Root Device Certificate Authority

Euro-PacketCable

C = <Country of Manufacturer>

O = <Company Name>

[stateOrProviceName = <state/province>]

[localityName = <City>]

OU = Euro-PacketCable

[organizationalUnitName = <Manufacturing

Location>]

CN = <Company Name> Euro-PacketCable CA

Intended Usage この証明書は各 MTA 製造業者に発行され、PacketCable Security Specification で規定されていると

おり、（製造時または現地でのアップデート中に）セキュアコードダウンロードの一環として各

MTA に提供されることがあります。この証明書は、読み取り専用パラメータとして MTA MIB に

表示されます。この証明書は、KDC による認証中に、MTA デバイスのアイデンティティ（MAC

アドレス）を認証するために MTA デバイス証明書とともに使用されます。

Signed By MTA ルート証明書の CA

Validity Period 20 年

Modulus Length 2048

Extensions keyUsage[c,m](keyCertSign, cRLSign)、subjectKeyIdentifier[n,m]、

authorityKeyIdentifier[n,m](keyIdentifier=<subjectKeyIdentifier value from CA certificate>)、basicConstraints[c,m](cA=true, pathLenConstraint=0)




OL-4409-01-J

MTA デバイス証明書

この証明書は、MTA ルート証明書、MTA 製造業者証明書、および MTA デバイス証明書で構成さ

れる証明書チェーンの一環として検証する必要があります。state/province、city、および製造業者の

ファシリティは、オプションのアトリビュートです。MAC アドレスは、6 組のコロン区切り 16 進

数（「00:60:21:A5:0A:23」など）で記述されている必要があります。16 進数のアルファベット文字

（A ～ F）は、大文字で記述されている必要があります。MTA デバイス証明書は、置換および更新

しないでください。

MTA 製造業者コード検証証明書

組み込み型 MTA のコード検証証明書（CVC）の仕様は、DOCSIS 仕様 SP-BPI+-I11-040407 で指定

されている DOCSIS 1.1 CVC と同一である必要があります。

表 5-4 MTA デバイス証明書

MTA デバイス証明書


C=<country>

O = <Company Name>

[ST=<state/province>]

[L=<city>], OU=PacketCable

[OU=<Product Name>]

[OU=<Manufacturer’s Facility>]

CN=<MAC Address>

Euro-PacketCable

C = <Country of Manufacturer>

O = <Company Name>


[L = <City>]


[OU=<Product Name>]

[OU = <Manufacturing Location>]

CN=<MAC Address>

Intended Usage この証明書は MTA 製造業者によって発行され、製造時にインストールされています。プロビジョ

ニングサーバはこの証明書をアップデートできません。この証明書は、読み取り専用パラメータ

として MTA MIB に表示されます。この証明書は、プロビジョニング中に MTA デバイスのアイデ

ンティティ（MAC アドレス）を認証するために使用されます。

Signed By MTA 製造業者証明書の CA

Validity Period 20 年以上

Modulus Length 1024、1536、または 2048

Extensions keyUsage[c,o](digitalSignature, keyEncipherment)

authorityKeyIdentifier[n,m](keyIdentifier=<subjectKeyIdentifier value from CA certificate>)




OL-4409-01-J

CableLabs サービスプロバイダー証明書階層

サービスプロバイダー証明書階層は、CableLabs 発行の CableLabs サービスプロバイダールート証

明書がルートになっています。この証明書は、一連のサービスプロバイダー証明書の発行元証明書

として使用されます。サービスプロバイダー証明書は、オプションのローカルシステム証明書に

署名するために使用されます。ローカルシステム証明書が存在する場合は、ローカルシステム証

明書を使用して補助装置証明書が署名されます。存在しない場合には、補助証明書はサービスプロ

バイダーの CA によって署名されます。

表 5-5 に含まれている情報は、RFC 2459 に従った必須フィールドで使用する固有の値を示していま

す。これらの固有値に従って指定する必要があります。必須フィールドの値が特に示されていない

場合は、RFC 2459 のガイドラインを遵守する必要があります。

CableLabs サービスプロバイダールート証明書

Kerberos キー管理を行うには、Kerberos プロトコルの PKINIT 拡張を使用して、事前に MTA と KDC

の相互認証を実行しておく必要があります。MTA は、KDC 証明書チェーンを含んだ PKINIT Reply

メッセージを受信した後に KDC を認証します。KDC の認証で、MTA は KDC 証明書チェーンを検

証します。このチェーンは、CableLabs サービスプロバイダールート CA が署名した KDC のサー

ビスプロバイダー証明書を含んでいます。

表 5-5 CableLabs サービスプロバイダールート証明書



C=US

O=CableLabs

CN=CableLabs Service Provider Root CA

Euro-PacketCable

C=BE

O=tComLabs

CN=tComLabs Service Provider Root CA

Intended Usage この証明書は、サービスプロバイダー CA 証明書に署名するために使用されます。この証明書は、

各 MTA に製造時にインストールされるか、または PacketCable Security Specification で規定されて

いるとおり、セキュアコードダウンロードでインストールされます。プロビジョニングサーバで

アップデートすることはできません。このルート証明書および対応する公開鍵は、MTA MIB に表

示されません。



Modulus Length 2048

Extensions keyUsage[c,m](keyCertSign, cRLSign)


basicConstraints[c,m](cA=true)




OL-4409-01-J

サービスプロバイダー CA 証明書

これはサービスプロバイダーが保有する証明書で、CableLabs サービスプロバイダールート CA に

よって署名されます。CableLabs サービスプロバイダールート証明書、テレフォニーサービスプ

ロバイダー証明書、オプションのローカルシステム証明書、およびエンドエンティティサーバ証

明書で構成される証明書チェーンの一環として検証されます。認証する側のエンティティは、通常

はすでに CableLabs サービスプロバイダールート証明書を所有しており、この証明書は、証明書

チェーンの残りの部分とともに転送されることはありません。

サービスプロバイダー CA 証明書が常に明示的に証明書チェーンに含まれているため、サービスプ

ロバイダーは、自身の証明書を柔軟に変更できます。変更時に、この証明書チェーンを検証する各

エンティティ（たとえば、MTA は PKINIT Reply を検証します）を再設定する必要はありません。

サービスプロバイダー CA 証明書を変更したら、そのたびに署名を CableLabs サービスプロバイ

ダールート証明書を使用して検証する必要があります。ただし、同じサービスプロバイダーの新

しい証明書では、SubjectName の OrganizationName アトリビュートが以前と同じ値に保たれている

必要があります。O と CN にある <Company> フィールドは、2 つのインスタンス間で異なる場合が

あります。

表 5-6 CableLabs サービスプロバイダー CA 証明書



C=<Country>

O=<Company>

CN=<Company> CableLabs Service Provider CA

Euro-PacketCable

C=<Country>

O=<Company>

CN=<Company> tComLabs Service Provider CA

Intended Usage この証明書は、サービスプロバイダー CA 証明書に署名するために使用されます。この証明書は、

各 MTA に製造時にインストールされるか、または PacketCable Security Specification で規定されて

いるとおり、セキュアコードダウンロードでインストールされます。プロビジョニングサーバで

アップデートすることはできません。このルート証明書および対応する公開鍵は、MTA MIB に表

示されません。



Modulus Length 2048

Extensions keyUsage[c,m](keyCertSign

cRLSign), subjectKeyIdentifier[n,m]





OL-4409-01-J

ローカルシステム CA 証明書

サービスプロバイダー CA は、ローカルシステム CA（対応するローカルシステム証明書を持つ）

と呼ばれる地域別の認証局に証明書の発行を委任することがあります。ネットワークサーバは、同

じサービスプロバイダーの地域別の認証局の間を自由に移動できます。したがって、MTA MIB に

は、ローカルシステム証明書に関する情報は含まれません（ローカルシステム証明書では、MTA

が特定地域内の KDC に制限される場合があるためです）。

表 5-7 ローカルシステム CA 証明書

ローカルシステム CA 証明書


C=<Country>

O=<Company>

OU=<Local System Name>

CN=<Company> CableLabs Local System CA

Euro-PacketCable

C=<Country>

O=<Company>

OU=<Local System Name>

CN = <Company> tComLabs Local System CA

Intended Usage サービスプロバイダー CA は、ローカルシステム CA（対応するローカルシステム証明書を持つ）

と呼ばれる地域別の認証局に証明書の発行を委任することがあります。ネットワークサーバは、同

じサービスプロバイダーの地域別の認証局の間を自由に移動できます。したがって、MTA MIB に

は、ローカルシステム証明書に関する情報は含まれません（ローカルシステム証明書では、MTA

が特定地域内の KDC に制限される場合があるためです）。

Signed By サービスプロバイダー CA 証明書


Modulus Length 1024, 1536, 2048

Extensions keyUsage[c,m](keyCertSign, cRLSign)、subjectKeyIdentifier[n,m]、

authorityKeyIdentifier[n,m](keyIdentifier=<subjectKeyIdentifier value from CA certificate>)、basicConstraints[c,m](cA=true, pathLenConstraint=0)




OL-4409-01-J

運用上の補助証明書

ここで説明する証明書は、すべてローカルシステム CA またはサービスプロバイダー CA のいずれ

かによって署名されます。他の補助証明書がこの標準に将来追加されることがあります。

鍵発行局証明書

この証明書は、CableLabs サービスプロバイダールート証明書、サービスプロバイダー CA 証明

書、および補助デバイス証明書で構成される証明書チェーンの一環として検証する必要がありま

す。PKINIT 仕様では、KDC 証明書に subjectAltName v.3 証明書拡張が含まれていることを要件と

しています。この拡張の値は、KDC の Kerberos プリンシパル名である必要があります。

配送機能（DF）

この証明書は、CableLabs サービスプロバイダールート証明書、サービスプロバイダー CA 証明

書、および補助デバイス証明書で構成される証明書チェーンの一環として検証する必要がありま

す。この証明書は、（電子サーベイランスで使用される）DF 間でのフェーズ 1 IKE ドメイン間交換

表 5-8 鍵発行局証明書

鍵発行局証明書


C=<Country>

O=<Company>,

[OU=<Local System Name>]

OU= CableLabs Key Distribution Center

CN=<DNS Name>

Euro-PacketCable

C=<Country>

O=<Company>

[OU = <Local System Name>]

OU = tComLabs Key Distribution Center

CN=<DNS Name>

Intended Usage KDC サーバのアイデンティティを PKINIT 交換中に MTA に対して認証すること。この証明書は

PKINIT 応答の中で MTA に渡されるため、MTA MIB には含まれておらず、プロビジョニングサー

バがアップデートおよびクエリーすることはできません。

Signed By サービスプロバイダー CA 証明書またはローカルシステム証明書


Modulus Length 1024、1536、または 2048

Extensions keyUsage[c,o](digitalSignature)authorityKeyIdentifier[n,m](keyIdentifier=<subjectKeyIdentifier value from

CA certificate>)subjectAltName[n,m]




OL-4409-01-J

に署名するために使用されます。Local System Name はオプションですが、ローカルシステム CA

がこの証明書に署名する場合は必須です。IP アドレスは、245.120.75.22 などの標準的なドット付き

4 数字列表記で指定する必要があります。

PacketCable サーバ証明書

これらの証明書は、CableLabs サービスプロバイダールート証明書、サービスプロバイダー証明

書、ローカルシステムオペレータ証明書（使用されている場合）、および補助デバイス証明書で構

成される証明書チェーンの一環として検証する必要があります。これらの証明書は、PacketCable シ

ステムの各種サーバを識別するために使用されます。たとえば、フェーズ 1 IKE 交換に署名するた

め、または PKINIT 交換を認証するために使用される場合があります。Local System Name はオプ

ションですが、ローカルシステム CA がこの証明書に署名する場合は必須です。IP アドレスの値

は、245.120.75.22 などの標準的なドット区切り 10 進表記で指定する必要があります。DNS Name の

値は、device.packetcable.com などの完全修飾ドメイン名（FQDN）で指定する必要があります。

表 5-9 DF 証明書

DF 証明書


C=<Country>

O=<Company>


OU=PacketCable Electronic Surveillance

CN=<IP address>

Euro-PacketCable

C=<Country>

O=<Company>


OU = Euro-PacketCable Electronic Surveillance

CNe = <IP address>

Intended Usage IKE キー管理を認証するために、1 組の DF 間で IPsec セキュリティアソシエーションを確立する

のに使用されます。これらのセキュリティアソシエーションは、合法的に傍聴されているサブジェ

クトが、新しい傍聴サーバ（DF）に転送される必要のあるコール情報を含んだコールメッセージ

とイベントメッセージを転送するときに使用されます。

Signed By サービスプロバイダー CA 証明書またはローカルシステム CA 証明書


Modulus Length 2048

Extensions keyUsage[c,o](digitalSignature)

authorityKeyIdentifier[n,m](keyIdentifier=<subjectKeyIdentifier value from CA certificate>)

subjectAltName[n,m] (dNSName=<DNSName>)




OL-4409-01-J

表 5-10 PacketCable サーバ証明書



C=<Country>

O=<Company>

OU=PacketCable

OU=[<Local System Name>]

OU=<Sub-System Name>

CN=<Server Identifier[:<Element ID>]>

<Server Identifier> の値は、サーバの FQDN または IP アド

レスにする必要があります。オプションで、値の後にコロ

ン（:）に続けて Element ID を記述できます（コロンの前

後は空白なし）。

<Element ID> は、課金イベントメッセージに表示される

ID です。イベントメッセージを生成できるすべてのサー

バの証明書に含まれている必要があります。このような

サーバとしては、CMS、CMTS、および MGC があります。

Element ID は 5 オクテットの右揃え ASCII 符号化数値文字

列として定義し、余白には空白文字を埋め込みます。

Element ID を証明書で使用するために変換するときは、空

白文字を ASCII の 0（0x48）に変換する必要があります。

たとえば、CMTS の Element ID が「311」で IP アドレスが

123.210.234.12 である場合、CMTS の通常名は

「123.210.234.12:00311」になります。

<Sub-System Name> の値は、次のいずれかにする必要があ

ります。

• ボーダープロキシの場合：bp

• ケーブルモデムターミネーションシステムの場合：cmts

• Call Management Server の場合：cms

• メディアゲートウェイの場合：mg

• メディアゲートウェイコントローラの場合：mgc

• メディアプレーヤーの場合：mp

• メディアプレーヤーコントローラの場合：mpc

• プロビジョニングサーバの場合：ps

• レコード記録サーバの場合：rks

• シグナリングゲートウェイの場合：sg

Euro-PacketCable

C=<Country>

O=<Company>



OU = <Sub-system Name>

CN=<Server Identifier[:<Element ID>]>

commonName の仕様の詳細について

は、PKT-SP-SEC-IO8-030415 を参照し

てください。

Intended Usage これらの証明書は、PacketCable システムの各種サーバを識別するために使用されます。たとえば、

フェーズ 1 IKE 交換に署名するため、または PKINIT 交換でデバイスを認証するために使用される

場合があります。

Signed By テレフォニーサービスプロバイダー証明書またはローカルシステム証明書

Validity Period MSO ポリシーにより設定




OL-4409-01-J

CMS 証明書の CN アトリビュート値は、Element ID にする必要があります。subjectAltName 拡張に

は、CMS の IP アドレスまたは FQDN のいずれかが含まれている必要があります。CMTS 証明書の

CN アトリビュート値は、Element ID にする必要があります。subjectAltName 拡張には、CMTS の IP

アドレスまたは FQDN のいずれかが含まれている必要があります。

MGC 証明書の CN アトリビュート値は、Element ID にする必要があります。subjectAltName 拡張に

は、MGC の IP アドレスまたは FQDN のいずれか含まれている必要があります。

証明書失効

現時点では、PacketCable の仕様範囲外です。

コード検証証明書階層

CableLabs コード検証証明書（CVC）PKI は汎用的な性質を持っており、CVC を必要とするすべて

の CableLabs プロジェクトに適用できます。つまり、基本インフラストラクチャをあらゆる

CableLabs プロジェクトで再利用することができます。必要となるエンドエンティティ証明書は、プ

ロジェクトごとに異なる場合がありますが、エンドエンティティ証明書が重複している場合は、1

つのエンドエンティティ証明書を使用してその重複に対応できる可能性があります。

CableLabs CVC 階層は、eMTA には適用されません。

CVC の全般的要件

すべてのコード検証証明書に対して、次の要件が適用されます。

• 証明書は、DER 符号化されている必要がある。

• 証明書は、バージョン 3 である必要がある。

• 証明書は、以降の各表で指定する拡張を含んでいる必要があり、その他の拡張を含んでいては

ならない。

• 公開指数は、F4（10 進数の 65537）にする必要がある。

Modulus Length 2048

Extensions keyUsage[c,o](digitalSignaturekeyEncipherment)

authorityKeyIdentifier[n,m](keyIdentifier=<subjectKeyIdentifier value from CA cert>)

subjectAltName[n,m](dNSName=<DNSName> | iPAddress=<IP AddressName>)

keyUsage タグはオプションです。使用する場合は、このタグをクリティカルとしてマークする必

要があります。以降で特に説明のない限り、subjectAltName 拡張には、対応する名前値が、サブ

ジェクトの CN フィールドで指定されているとおりに含まれている必要があります。

表 5-10 PacketCable サーバ証明書（続き）





OL-4409-01-J

CableLabs コード検証ルート CA 証明書

この証明書は、CableLabs コード検証ルート CA 証明書、CableLabs コード検証 CA 証明書、および

コード検証証明書で構成される証明書チェーンの一環として検証する必要があります。証明書の検

証方法の詳細については、P.5-18 の「証明書の検証」を参照してください。

CableLabs コード検証 CA 証明書

CableLabs コード検証 CA 証明書は、CableLabs コード検証ルート CA 証明書、CableLabs コード検証

CA 証明書、およびコード検証証明書で構成される証明書チェーンの一環として検証する必要があ

ります。証明書の検証方法の詳細については、P.5-18 の「証明書の検証」を参照してください。

CableLabs コード検証 CA は、複数存在する場合があります。S-MTA は、一度に 1 つずつ CableLabs

CVC CA をサポートする必要があります。

表 5-11 CableLabs コード検証ルート CA 証明書

CableLabs コード検証ルート CA 証明書


C=US

O=CableLabs

CN=CableLabs CVC Root CA

Euro-PacketCable

C = BE

O = tComLabs

CN = tComLabs CVC Root CA

Intended Usage この証明書は、コード検証 CA 証明書に署名するために使用されます。この証明書は、製造時に

S-MTA 不揮発性メモリに含める必要があります。


Validity Period 20 年以上

Modulus Length 2048

Extensions KeyUsage [c,m] (keyCertSign, cRL Sign)

subjectkeyidentifier [n,m]


表 5-12 CableLabs コード検証 CA 証明書

CableLabs コード検証 CA 証明書


C=US

O=CableLabs

CN=CableLabs CVC CA

Euro-PacketCable

C = BE

O = tComLabs

CN = tComLabs CVC CA

Intended Usage この証明書は、CableLabs コード検証ルート CA によって CableLabs に発行されます。この証明書

がコード検証証明書を発行します。この証明書は、製造時に S-MTA 不揮発性メモリに含める必要

があります。

Signed By CableLabs コード検証ルート CA

Validity Period CableLabs ポリシーにより設定

Modulus Length 2048

Extensions KeyUsage [c,m] (keyCertSign, cRL Sign)


authorityKeyIdentifier [n,m]

basicConstraints [c,m](cA=true, pathLenConstraint=0)




OL-4409-01-J

製造業者コード検証証明書

CableLabs コード検証 CA は、認可された各製造業者に対して、この証明書を発行します。この証

明書は、セキュアなソフトウェアダウンロードのために CATV 事業者により設定されたポリシー

で使用されます。

Organization の Company Name と Common Name の Company Name は、異なる場合があります。

表 5-13 製造業者コード検証証明書

製造業者コード検証証明書


C=<country>

O = <Company Name>


[L=<city>]

CN=<Company Name> Mfg CVC

Euro-PacketCable

C=<Country>

O = <Company Name>


[L = <City>]

CN=<Company Name> Mfg CVC

Intended Usage CableLabs コード検証 CA は、認可された各製造業者に対して、この証明書を発行します。この証

明書は、セキュアなソフトウェアダウンロードのために CATV 事業者により設定されたポリシー

で使用されます。

Signed By CableLabs コード検証 CA tComLabs コード検証 CA 証明書



Extensions extendedKeyUsage [c,m] (id-kp-codeSigning)





OL-4409-01-J

サービスプロバイダーコード検証証明書

サービスプロバイダーコード検証証明書は、CableLabs コード検証ルート CA 証明書、CableLabs

コード検証 CA 証明書、およびサービスプロバイダーコード検証証明書で構成される証明書チェー

ンの一環として検証する必要があります。証明書の検証方法の詳細については、P.5-18 の「証明書

の検証」を参照してください。

Organization の Company Name と Common Name の Company Name は、異なる場合があります。

CVC の証明書失効リスト

S-MTA は、CVC の証明書失効リスト（CRL）をサポートしている必要はありません。

表 5-14 サービスプロバイダーコード検証証明書

サービスプロバイダーコード検証証明書

Subject Name Form C=<country>

O = <Company Name>


[L=<city>]

CN=<Company Name> Service Provider CVC

C=<Country>

O = <Company Name>


[L = <City>]

CN=<Company Name> Service Provider CVC

Intended Usage CableLabs コード検証 CA は、認可された各サービスプロバイダーに対して、この証明書を発行し

ます。この証明書は、セキュアなソフトウェアダウンロードのために CATV 事業者により設定さ

れたポリシーで使用されます。

Signed By CableLabs コード検証 CA tComLabs コード検証 CA 証明書



Extensions extendedKeyUsage [c,m] (id-kp-codeSigning)





OL-4409-01-J

packetcable 音声設定 - cisco...chapter 5-1 cisco broadband access center for cable...

Documents