令和６年春　午後Ⅰ　問１

問題の解説

問1　コンテンツ配信ネットワークに関する次の記述を読んで、設問に答えよ。

　D社は、ゲームソフトウェア開発会社で三つのゲーム(ゲームα、ゲームβ、ゲームγ)をダウンロード販売している。D社のゲームはいずれも利用者の操作するゲーム端末上で動作し、ゲームの進捗データやスコアはゲーム端末内に暗号化して保存される。D社のゲームは世界中に利用者がおり、ゲーム本体及びゲームのシナリオデータ(以下、両方をゲームファイルという)はインターネット経由で配信されている。

この設問の場合は、Nintendo Switchが身近な例として考えられます。パソコンのゲームではなく、「ゲーム端末」を使うと書かれているからです。

しかし、パソコンでデータをダウンロードする場合と同様に考えることが可能ですので、「ゲーム端末だから特殊」と身構える必要はありません。

[現状の配信方式]
　D社は、ゲームファイルの配信のためのデータセンターを所有している。D社データセンターの構成を図1に示す。

ロードバランサーについてはこの記事で学習をしました。わからない方はこちらも参考にしてみてください。

ロードバランサーのある構成の場合、パケットが下記のように割り振られると勘違いをしがちです。

しかし実際は、インターネットからパケットが流れてきた際、割り振られるのは各レイヤー2スイッチの更に向こう側です。

たとえば「ドンキーコング」がβ配信サーバにある場合、レイヤー2スイッチの更に奥にある複数のサーバの中からβ配信サーバを探してパケットを流します。

ロードバランサーは、複数ある配信サーバの中から一つにパケットを振り分けるのです。

ゲーム端末は、インターネット経由でゲームごとにそれぞれ異なるURLにHTTPSでアクセスする。LBは、プライベートIPアドレスが設定されたHTTPの配信サーバにアクセスを振り分ける。

後述する表1にURLの記載がありますが、ゲームαであれば「https://alpha.example/net/」、ゲームβであれば「https://beta.example.net/」、ゲームγであれば「https://gammma.example.net/」というように、それぞれURLが異なります。

LBは、プライベートIPアドレスが設定されたHTTPの配信サーバにアクセスを振り分ける。また、①LBは配信サーバにHTTPアクセスによって死活確認を行い、動作が停止している配信サーバに対してはゲーム端末からのアクセスを振り分けない。

ロードバランサーまではパケットはHTTPS通信で流れてきますが、ロードバランサー以降はD社データセンター内のサーバのため、HTTPSではなくHTTPで通信が行われているようです。

「HTTPアクセスによって死活確認を行う」というのは、ロードバランサーが対象のサーバに対してHTTPリクエストを送信し、そのレスポンスによってサーバが正常に稼働しているかを確認することを意味します。

※「死活確認とは」……死活確認（ヘルスチェック）とは、対象のサーバやサービスが「生きている（＝正常に応答する）」かどうかを定期的に調べる仕組みのことです。

種類	チェック方法	検出できる故障のレベル
TCP	ポートに接続できるかどうか	OSレベルの故障、サーバダウン
HTTP	実際にアプリにアクセスし、レスポンスを確認	Webサーバやアプリの不具合

• 単なるTCP接続の成功だけでは分からない「アプリケーションレベルの障害」検知できる。
• Webアプリが落ちていたら、それをスルーせずに検知して対象から外せる。

　ゲームファイルの配信に利用するIPアドレスとポート番号を、表1に示す。

• URLはゲームごとに異なっている。
• ロードバランサーのIPアドレスは共通なため、ロードバランサーはHTTPヘッダー（Hostヘッダー）のURL（FQDN）を見て振り分け先を判断している。
• 配信サーバは「所属セグメント」と表記されているため、配信サーバは複数ある。
• ロードバランサーのポート番号は443のため、HTTPS通信が行われている。
• 配信サーバのポート番号は80のため、HTTP通信が行われている。

D社が導入しているLBのサーバ振分けアルゴリズムには、ラウンドロビン方式及び最少接続数方式がある。ラウンドロビン方式は、ゲーム端末からの接続を接続ごとに配信サーバに順次振り分ける方式である。最少接続数方式は、ゲーム端末からの接続をその時点での接続数が最も少ない配信サーバに振り分ける方式である。
D社のゲームファイル配信では、振り分ける先の配信サーバの性能は同じだが、接続ごとに配信するゲームファイルのサイズに大きなばらつきがあり、配信に掛かる時間が変動する。各配信サーバへの同時接続数をなるべく均等にするために、LBの振分けアルゴリズムとして（　　ア　　）方式を採用している。
ゲームβの配信性能向上が必要になる場合には、表１中の所属セグメント（　　イ　　）にサーバを増設する。

• サーバA → サーバB → サーバC → サーバA → …というように、順番に回して割り振る。
• 各サーバの負荷や接続数は考慮しない。
• 実装が簡単。
• サーバ性能がほぼ同じなら、バランスよく分散できる。
• 各サーバの負荷状態を考慮しないため、不公平になることがある（たとえば、サーバAは軽い処理、サーバBは重い処理中でも、同じように割り振られてしまう）。

• 各サーバの接続数を常に監視。
• リクエストが来たら、最も接続数が少ないサーバを選ぶ。
• リアルタイムの負荷に応じて分散されるため、より公平。
• セッション時間にばらつきがあるアプリに強い（長くつながるユーザーがいても安心）。
• 各サーバの接続数を常時監視するため、仕組みがやや複雑。
• 短時間に大量リクエストが来ると、一時的に判断が追いつかないことも。

項目	ラウンドロビン方式	最少接続数方式
割り振り方法	順番に均等に	接続数が少ないサーバへ
サーバ負荷の考慮	しない	する
適したケース	短時間処理、同等性能のサーバ群	長時間接続が多い、負荷が不均一な場合
実装の複雑さ	シンプル	やや複雑

[配信方式の見直し]
D社は、ゲームファイルの大容量化と利用者のグローバル化に伴い、ゲームファイルの配信をコンテンツ配信ネットワーク(以下、CDNという)事業者のE社のサービスで行うことにした。E社CDNは、多数のキャッシュサーバを設置する配信拠点(以下、POPという)を複数もち、その中から、ゲーム端末のインターネット上の所在地に対して最適なPOPを配信元としてコンテンツを配信する。

CDN（Content Delivery Network）は、Webコンテンツをユーザに近い場所（エッジサーバ）から高速・安定的に配信する仕組みです。

たとえば、東京のユーザーがアメリカのサーバにある動画を見ようとすると、遅延や通信の不安定さが起こる可能性があります。

CDNは、世界中に設置されたキャッシュサーバ（エッジノード）にあらかじめそのコンテンツを配置しておき、ユーザーが最も近いサーバからデータを受け取れるようにすることで、高速化・負荷分散・可用性向上を実現します。

1. ユーザーがWebサイトにアクセス
2. DNSがCDNのエッジサーバへ誘導（例：Akamai、Cloudflareなど）
3. エッジサーバにキャッシュがあれば、それをそのまま返す
4. キャッシュがなければ、オリジンサーバ（元のWebサーバ）から取得してキャッシュしてから返す

機能	内容
高速化	地理的に近いサーバから配信するため、遅延が小さくなる
負荷分散	オリジンサーバにアクセスが集中するのを防ぐ
高可用性	一部のサーバがダウンしても、他のCDNノードが対応
DDoS対策	CDNがトラフィックを吸収するバッファになる
SSL処理のオフロード	TLS終端処理をCDNが肩代わりすることでオリジンサーバの負荷軽減

POP（Point of Presence）とは、CDNやISP（インターネットサービスプロバイダ）、大規模なクラウドサービスなどが設置する、ユーザーに近い場所にあるネットワーク接続・配信拠点のことです。

言い換えれば、「サービスを届けるための中継・配信基地」であり、ここからユーザーへコンテンツを効率的に届けます。

機能	内容
キャッシュ配信	静的コンテンツ（画像、動画、CSSなど）をキャッシュして、近い拠点から高速配信
リクエストのルーティング	DNSやAnycastによって、最も近くて混雑の少ないPOPに誘導
トラフィックの終端処理	TLSの終端やHTTPリクエストの受付、必要に応じてオリジンへの転送
負荷分散・冗長化	地理的に複数配置されたPOP間でトラフィックを分散。障害時は他POPに迂回可能
DDoS緩和	攻撃トラフィックをPOPで吸収し、オリジンサーバを防御する機能を持つ場合もある

CDNサービス（例：Akamai、Cloudflare、Amazon CloudFrontなど）は世界中に多数のPOPを持っています。

ユーザーがCDN経由でWebサイトにアクセスすると、DNSが最適なPOPのIPアドレスを返すことで、地理的に最も近い・空いているPOPに接続されます。

これは、AnycastやGSLB（グローバルサーバロードバランシング）などの仕組みと組み合わさって、より効率的に動作します。

• POP＝CDNの「現地拠点」。コンテンツ配信の遅延やトラフィック集中を防ぐ。
• DNSやAnycastと連携して最適なPOPへ誘導する構成が多い（名前解決が鍵）。
• 障害対策としても重要。あるPOPがダウンしても、他のPOPにフェイルオーバー可能。
• Edge Server（エッジサーバ）とほぼ同義で使われることもあるが、POPはよりネットワーク全体の構成単位。

つまりPOP（Point of Presence）とは、ユーザーにコンテンツを高速・安定して届けるために設置された、CDNやISPの配信拠点です。

キャッシュ配信・負荷分散・セキュリティ処理などを担当し、DNSやAnycastと連携して最適な拠点から配信するのが特徴です。

あるPOPが端末からアクセスを受けると、POP内でLBがキャッシュサーバにアクセスを振り分ける。E社CDNのキャッシュサーバにコンテンツが存在しない場合は、D社データセンターの配信サーバからE社CDNのキャッシュサーバにコンテンツが同期される。

この文章は、CDNのキャッシュ配信フローを具体的に記述したものです。

ユーザーからPOPへのリクエスト → POP内のLBによる振り分け → キャッシュミス時のオリジンサーバからの取得 → キャッシュ保存という一連の流れを理解することが重要です。

• POP（Point of Presence）は、CDN業者（この文ではE社）が世界中に設置した配信拠点のこと。
• ユーザー（端末）がWebページにアクセスすると、DNSやAnycastによって最寄りのPOPに誘導される。
• 「アクセスを受ける」とは、HTTPリクエスト（例：画像や動画の取得要求など）を受信することを意味する。

• POPの中には複数台のキャッシュサーバ（Edge Server）があることが多く、負荷分散装置（LB：ロードバランサ）が搭載されている。
• このLBは、受け取ったリクエストを最も空いているキャッシュサーバに振り分ける。
• 振り分けアルゴリズムとしては、「ラウンドロビン」「最少接続数方式」などが利用される。

• キャッシュサーバには、過去にアクセスされたコンテンツがあらかじめ保存（キャッシュ）されている。
• ユーザーが要求したファイル（例：/image/banner.jpg）がキャッシュにヒット（存在）しなければ、「キャッシュミス」となり、オリジンから取得する必要がある。

• D社はWebコンテンツの提供元（オリジンサーバ）であり、E社はそれを配信代行するCDNベンダ。
• キャッシュミスが起きたとき、E社のCDNサーバはD社の配信サーバ（オリジン）に問い合わせて、必要なコンテンツを取得する。
• この「同期」とは、オリジンから取得したコンテンツをCDNキャッシュサーバに保存（キャッシュ）することを意味する。
• 次回からはそのキャッシュが使われるため、レスポンスが高速化され、D社のサーバ負荷も下がる。

配信方式の見直しプロジェクトはXさんが担当することになった。Xさんは、E社が提供しているBGP anycast方式のPOP選択方法を調査した。XさんがE社からヒアリングした内容は次のとおりである。

この文は、BGP AnycastによるPOP選択の仕組みを理解しているかどうかを問う設問の導入部です。

BGP Anycastでは、ユーザーの場所やISPによってネットワーク経路が異なるため、常に最も“ネットワーク的に近い”POPへ誘導されるのが特徴です。

エニーキャストは、1対1のように見えて、複数の受信者の中から“最も近い”1台が応答する通信方式です。

• 同じIPアドレスを、複数のサーバ（POP）に割り当てる。
• 送信元（クライアント）から見て、ネットワーク的に最も近い（ルーティングが最短な）ノードに接続される。
• DNSのルートサーバや、CDN（Cloudflare、Akamaiなど）で広く使われている。
• BGPによる経路制御によって、Anycastルーティングが実現される。

ユニキャストは、1対1の通信方式です。送信者が、宛先のIPアドレスを持つ特定の1台の機器（サーバ、PCなど）にデータを送る形式です。

• インターネット上の通常の通信（Webアクセス、メール送信、SSH接続など）はほとんどがユニキャスト。
• IPアドレスは、通信相手（1つのホスト）に固有に割り当てられており、ルーティングもその特定ホストへ向けて行われる。
• 同じIPアドレスは原則として世界中に1つだけ。

項目	ユニキャスト（Unicast）	エニーキャスト（Anycast）
通信形式	1対1	1対最も近い1（≒1対1）
IPアドレスの割り当て	世界で唯一のホストに割り当て	複数のホストに同一のIPアドレスを割り当て
通信相手の選択	固定のホスト（あらかじめ決められている）	BGPにより「ネットワーク的に近い」ホストが自動で選ばれる
主な用途	Webアクセス、メール送信、SSH接続など	DNS（ルートサーバ）、CDN、DDoS緩和など
可用性・冗長性	通信先が1台に依存（障害時は通信不可）	複数の受信先があるため、1台が落ちても他にルーティング可能
利点	シンプルで安定	高速化、冗長化、負荷分散が可能
実装の難易度	比較的簡単	BGPの設定が必要で高度

• エニーキャストは「地理的に近いのではなく、ネットワーク的に近いノード」にルーティングされる。
• 複数のPOPで同じIPを持つ→ルーティングによって最適なPOPが選ばれる。
• DNSやCDNにおける負荷分散・高速化・耐障害性の向上のために用いられている。
• 対比として、マルチキャスト（1対多）やブロードキャスト（1対全）も押さえておくと理解が深まる。

E社BGP anycast方式では、同じアドレスブロックを同じAS番号を用いてシンガポールPOP及び東京POPの両方からBGPで経路広告する。シンガポールPOPと東京POPの間は直接接続されていない。ゲーム端末が接続するISPでは、E社ASの経路情報を複数の隣接したASから受信する。どの経路情報を採用するかはBGPの経路選択アルゴリズムで決定される。ゲーム端末からのHTTPSリクエストのパケットは、決定された経路で隣接のASに転送される。BGP anycast方式によるE社の経路広告イメージを図2に示す。

この問題文は、CDNにおけるBGP Anycast方式による経路選択とその実際の動作を理解しているかどうかを問う設問の前提部分です。

ネットワークスペシャリスト試験では、AS（Autonomous System）やBGPの経路選択アルゴリズム、Anycastの性質について深く理解していることが求められます。

• E社はCDNベンダーであり、複数のPOP（配信拠点）を持っている。
• Anycast方式の特徴として、同じIPアドレス（またはアドレスブロック）を複数のPOPで共有し、BGPを使ってそれぞれの拠点から経路広告する。
• 「同じAS番号を用いて」という点がポイントで、これにより「どのPOPも同じE社ASから来ているように見える」状態をつくる。
• AS番号を統一することにより、Anycast的に動作する（複数POPにある同じIPに対して、BGPが最短経路を選ぶ）。

• POP間は直接的な物理接続やプライベートバックボーンがないという意味。
• よって、片方のPOPがダウンしても、BGPルーティングによって自動的に他方にトラフィックを切り替える。
• 冗長構成ではなく、BGPに依存した疎結合な分散型設計であることが示唆されている。

• ゲーム端末が所属するISP（インターネットプロバイダ）は、複数のAS（トランジットプロバイダなど）からE社ASへの経路情報を受け取っている。
• これは、BGPで一般的に見られる「複数の経路候補の中から最適経路を選ぶ」状態。
• E社ASがAnycastでシンガポールPOPと東京POPから広告しているため、それぞれの経路がISPに伝わってきている。

• BGPには経路選択ルール（プレフィクス長、メトリック、AS-PATH長、オリジンタイプ、MED、次ホップ、ローカルプリファレンスなど）があり、それに従って最も「よい」と判断された経路が選ばれる。
• 結果として、ISPがどのPOPを選ぶかはE社ではなく、ISPのBGP経路選択ポリシーに依存する。

• ゲーム端末から送られるHTTPS通信は、ISPがBGPで選んだ最も短い（良好な）経路に従って、近いPOP（東京POPまたはシンガポールPOP）に送信される。
• これにより、Anycastによる“最も近いPOPへ導く”という特徴が実現されている。
• 経路はAS境界（インターネット）をまたぐため、完全に自動化されたルーティングに依存している。

観点	解説
Anycastの本質	同一IPアドレスを複数拠点で使い、BGP経路によって“最も近い”POPに自動接続させる
ASとBGP	経路広告はAS単位で行われる。どのAS経路を選ぶかは中継AS（ISP側）の選択に委ねられる
経路選択アルゴリズム	AS-PATH長、Local Pref、MEDなどをBGPが総合的に評価して決定する
冗長性	片方のPOPが使えなくなっても、BGPが自動で別のPOPを選ぶため高可用性が保たれる

この問題文は、BGP Anycastにおける経路広告とPOP選択の仕組みを理解しているかどうかを問う背景情報です。重要な点は以下の通り。

• E社のCDNは、東京POP・シンガポールPOP両方から同じAS番号・IPアドレスを使って広告している。
• ゲーム端末が接続するISPが、BGP経路選択アルゴリズムによりどのPOPに接続するかを決定。
• BGP Anycastは、地理的距離ではなくネットワーク的距離（経路）によって最適なPOPに誘導される。

図2でIXは、レイヤー2ネットワーク相互接続点であり、接続された隣接のAS同士がBGPで直接接続することができる。

この文章の中の「IX」や「レイヤー2ネットワーク相互接続点」「隣接AS同士がBGPで直接接続」といった専門用語には、ネットワークインフラとBGPの構造を理解するうえで重要な要素が詰まっています。

ネットワークスペシャリスト試験では、IX（インターネットエクスチェンジ）の仕組みや役割、AS（自律システム）間の接続方法について問われることがあり、この一文はそうした理解を前提とした問題文の一部です。

• IX（Internet Exchange／インターネットエクスチェンジ）は、複数のAS（ISPや事業者のネットワーク）が相互にトラフィックを交換するための中立的な接続拠点。
• レイヤ2（L2）ネットワーク、つまりイーサネットスイッチを使った共有ネットワークで構成されている。
• それぞれのASはIXにルータを設置し、IXのスイッチに物理的に接続することで、他のASと直接BGPピアを張ることができる。

• IXはL2なので、各ASのルータは同一のセグメント（ブロードキャストドメイン）上にある。
• これにより、物理的な接続数を抑えながら、多対多のBGP接続が可能になる。

• BGP（Border Gateway Protocol）は、AS間で経路情報を交換するためのプロトコル。
• 通常、AS間でBGPを使うには、相手ASのルータとTCP接続（BGPセッション）を張る必要がある。
• IXを経由すれば、多数のASが物理的に1箇所で集まり、L2ネットワーク上でBGPセッションを張れるようになる。

観点	解説
経路制御	各ASが、他のASとの経路を個別に管理できる（柔軟）
コスト効率	すべてのASと専用線を張らずに、多対多の接続が実現できる
帯域効率	近隣トラフィックをIX内で完結でき、トランジット回線の節約に
遅延低減	地理的・ネットワーク的に近いAS同士で直接通信できる

BGPでの経路選択では、LP(LOCAL_PREF)属性については値が（　　ウ　　）経路を優先し、MED(MULTI_EXIT_DISC)属性については値が（　　エ　　）経路を優先する。E社では、LP属性とMED属性が経路選択に影響を及ぼさないように設定している。これによって②E社のあるPOPからゲーム端末へのトラフィックの経路は、そのPOPのBGPルータが受け取るAS Path長によって選択される。

この文章は BGPの経路選択アルゴリズム に関する知識を前提に、「どのような設定を行うと AS Path 長によって経路が選ばれるか？」を理解しているかを問う内容です。

LOCAL_PREF（ローカルプリファレンス）とは

• LOCAL_PREF（ローカルプリファレンス） は、AS内部（iBGP）の経路選択時に使用される属性です。
• 値が 大きいほうが優先されます。
• 主に、出口（どのトランジット回線を使うか）をコントロールするために使用されます。

よって、（　ウ　）には 「大きい」 が入ります。

MED（Multi Exit Discriminator）とは

• MED（マルチエグジットディスクリミネータ） は、異なるAS同士の間で、相手ASに「どの入り口から入ってきてほしいか」を伝えるためのヒントです。
• 値が 小さい方が優先 されます。
• ただし、同じASから来た複数経路の比較にのみ有効で、ASが異なる経路同士では使われないケースもあります。

よって、（　エ　）には 「小さい」 が入ります。

• E社では、LOCAL_PREFやMEDを使って強制的に経路を操作せず、BGPのデフォルトに近い状態で経路選択をさせている。
• このような設定により、経路選択が中立かつ自動的になり、たとえばAnycast構成で最も自然なルート（AS Pathが短い）を選びやすくなる。

AS_PATH 長とは？

• AS_PATH（ASパス） は、その経路が通ってきたASのリスト。
• AS_PATHの長さが短いほど、経路が優先されます。
• BGPの経路選択における基本的な指標の1つで、LPやMEDよりも下位の優先順位ではありますが、他の属性が同じであればこのAS_PATHの短さが決定打になります。

BGP経路選択の順序（代表的なもの）

1. Highest LOCAL_PREF（大きい方）
2. Shortest AS_PATH（短い方）
3. Lowest ORIGIN type
4. Lowest MED（小さい方）
5. その他（IGP cost、Router IDなど）

※ MED は AS_PATH より下位に扱われることもありますが、基本的な順序は環境設定によって異なるため試験では明記されます。

属性	優先される値	備考
LOCAL_PREF	大きい	AS内部で出口制御に使う
AS_PATH	短い	経路が少ないほど優先
MED	小さい	相手ASに対して「こっちから入ってきて」の提案

このような経路選択のアルゴリズムは、Anycast構成、マルチホーム構成、トラフィックエンジニアリングなどにおいて重要な役割を果たします。

Xさんは、BGPのセキュリティ対策として何を行っているか、E社の担当者に確認した。E社BGPルータは、③隣接ASのBGPルータとMD5認証のための共通のパスワードを設定していると説明を受けた。また、④アドレスブロックやAS番号を偽った不正な経路情報を受け取らないための経路フィルタリングを行っていると説明があった。

この文章は、BGP（Border Gateway Protocol）における代表的なセキュリティ対策について理解しているかを確認するための前提文です。

ネットワークスペシャリスト試験でも頻出の内容で、BGPの脆弱性と、それに対する現実的な対策がどれだけ理解されているかを問う設問に続くことが想定されます。

BGPでは、TCPセッションを確立したうえで経路情報を交換しますが、このセッションが第三者に乗っ取られるリスクがあります。

それを防ぐのが「BGPセッションの認証」です。

BGPピア（隣接ASルータ同士）で、あらかじめ共通のパスワード（シークレット）を設定し、そのパスワードを元にTCPセグメントごとにMD5ハッシュ値を付けてやりとりします。

相手のTCPセグメントに含まれるMD5が一致しない場合、接続は拒否されます。

• なりすまし防止：第三者が不正にBGPセッションを張るのを防止。
• 経路ハイジャックやDoSの予防：偽の経路を注入されたり、セッションを強制切断されたりするリスクが低減。

BGPの脆弱性の一つに、不正な経路情報を受け入れてしまうという問題があります。

• アドレスプレフィクスを偽る：自分のものではないIPアドレスブロックを広告する（プレフィクスハイジャック）。
• AS番号を偽る：AS_PATHを書き換えて経路選択を操作する（経路偽装）。

経路フィルタリングの仕組みとしては、BGPルータに対し、「受け取るべきIPアドレスブロック（プレフィクス）やAS番号のリスト」を設定し、それ以外の経路情報は拒否します。

セキュリティ対策	内容	目的
MD5認証	BGPピア間でTCPセッションごとにハッシュ値を確認	ピアのなりすまし防止
経路フィルタリング	信頼できるプレフィクスやAS番号のみを受け入れる	経路偽装・ハイジャック防止

この文章が示すBGPのセキュリティ対策は、次の2点です。

• MD5認証でBGPセッションの正当性を確保し、不正接続やセッション乗っ取りを防ぐ。
• 経路フィルタリングによって不正なIPブロックやAS番号を拒否し、経路ハイジャックや誤配信を防ぐ。

これらはいずれも、インターネットのルーティングの安全性を保つための現実的かつ基本的な防御手段であり、試験では「どの脅威に対して有効か」「なぜ必要か」を理解しているかが問われます。

[配信拠点の保護]
D社ではDDoS攻撃を受けることが何度かあった。そこでXさんは、コンテンツ配信サーバへのDDoS攻撃対策について、どのような対策を行っているかE社の担当者に確認したところ、E社ではRFC 5635の中で定義されたDestination Address RTBH(Remote Triggered Black Hole) Filtering(以下、RTBH方式という)のDDoS遮断システムを導入しているとの回答があった。

この問題文は、DDoS攻撃に対するネットワーク層での防御手法の一つ「RTBH方式」について問うための前提文です。

ネットワークスペシャリスト試験でも、RFCベースの防御手法や経路制御によるセキュリティ対策は頻出テーマであり、ここでは RFC 5635 に基づく Destination Address RTBH Filtering というやや専門的な技術が扱われています。

DDoS（分散型サービス拒否）攻撃は、複数のマシンを使って標的サーバに大量のトラフィックを送ることで、サービスを停止させる攻撃です。

特にWebサービスやゲーム配信など外部に公開しているサーバが標的になりやすいため、D社もその標的になっていたと考えられます。

RTBH（Remote Triggered Black Hole）は、特定のトラフィックを意図的に「ブラックホール」に落とす（廃棄する）ことで、攻撃を回避する方法です。

RFC5635に定義されており、インターネットのAS間でも使える実用的なBGPベースのDDoS対策手法です。

Destination Address RTBHは、攻撃対象（＝宛先IPアドレス）そのものをブラックホール化する方法です。

1. 攻撃が検出される（DDoSの兆候あり）。
2. 管理者または自動システムが「この宛先IPアドレス（例：203.0.113.10）を捨ててほしい」というブラックホール情報を、BGP経由でトリガールータに通知。
3. トリガールータがその情報をBGPで周囲に広告。
4. 経路上のルータがこの情報を受け取り、その宛先へのパケットを Null0（ブラックホール） に転送＝破棄。

• 宛先ごとトラフィックごと破棄するため、正規の通信も遮断される（犠牲的防御）。
• ただし攻撃トラフィックが回線を埋め尽くすような場合には、ネットワークそのものを守るために有効。

方式	対象	特徴
Destination RTBH	宛先IPアドレスを破棄対象とする	DDoS対策に有効、だが正規アクセスも遮断される
Source RTBH	攻撃元IPアドレスを破棄対象とする	ピンポイント対応可能だが、攻撃元特定が難しいことも

項目	内容
RFC 5635	RTBH Filtering の基本的な仕組みを標準化
RTBH方式	BGPを使って動的に特定のトラフィックをブラックホールに誘導する仕組み
トリガールータ	特定の条件が満たされたとき、BGP経由でブラックホール経路を広告する
ブラックホール（Null0）	パケットを廃棄する仮想インタフェース
使いどころ	帯域を埋め尽くすようなDDoS攻撃時に、被害を局所化／拡大防止するために有効

• Destination Address RTBH：攻撃対象のIPアドレスをブラックホールに送ることで遮断。
• BGPを使って柔軟に、迅速に制御できる。
• 正規通信も止めてしまう犠牲的対策であることに注意。

E社POPの概要を図3に示す。
E社のDDoS遮断システムは、RFC 3954で定義されるNetFlowで得た情報を基にDDoS攻撃の宛先IPアドレスを割り出し、該当IPアドレスへの攻撃パケットを廃棄することで、ほかのIPアドレスへの通信に影響を与えないようにする。DDoS検知サーバは、E社POP内の各BGPルータとiBGPピアリングを行っている。

E社のBGPルータは、インターネット側インタフェースから流入するパケットの送信元と宛先のIPアドレス、ポート番号などを含むNetFlowパケットを生成する。生成されたNetFlowパケットはDDoS検知サーバに送信される。DDoS検知サーバは、送られてきたNetFlowパケットを基に独自アルゴリズムでDDoS攻撃の有無を判断し、攻撃を検知した場合はDDoS攻撃の宛先IPアドレスを取得する。

この問題文では、NetFlowを用いたDDoS検知とRTBH（Remote Triggered Black Hole）方式による対処の仕組みが、E社のCDNインフラ内でどのように連携して機能しているかを説明しています。

ネットワークスペシャリスト試験でも、NetFlowによるトラフィック分析やiBGPによる制御ルータとの連携は、DDoS対策の理解において非常に重要なトピックです。

NetFlow は、Ciscoが開発し、RFC 3954 によって標準化されたフローベースのトラフィック収集技術です。

通信の単位（フロー）ごとに、以下のような情報を記録します。

• 送信元IPアドレス
• 宛先IPアドレス
• プロトコル（TCP/UDP）
• ポート番号（src/dst）
• バイト数、パケット数
• 通信時間 など

ネットワーク上で発生しているトラフィックの傾向や異常を可視化することや、特定の宛先IPアドレスに急激に通信量が集中している＝DDoS攻撃の兆候を検知することが可能です。

対策手段として、RTBH + NetFlow連携が行われます。

NetFlowにより、「不自然に大量のパケットが向かっている宛先IPアドレス（例：203.0.113.10）」を特定します。

それを「ブラックホール対象IP（RTBH宛先）」とみなし、そのIPへの経路をNull0（破棄）に向けるようにBGPで指示します。

これにより、他のIPアドレスへの通信には影響を与えず、攻撃対象のみを遮断することが可能になります。

この文では、Destination Address RTBHの効果が限定的であること（ピンポイント遮断）を強調しています。

攻撃対象のIPだけを落とすため、CDNが持つ他のコンテンツや利用者に対する影響を最小限にできるのです。

DDoS検知サーバは、攻撃対象IPを発見したら、その情報をルータに通知する必要があります。

その際、E社のPOP内にある複数のBGPルータに対して、経路制御情報（ブラックホール経路）を配布します。

これを行うために、iBGP（内部BGP）セッションを張っている→ iBGPを使えば、AS内部の全ルータに対して一貫した経路制御が可能ということです。

キーワード	解説
NetFlow	フローデータ（通信単位）を収集・可視化するための技術。異常トラフィックの検知に有効。
RFC 3954	NetFlow Version 9 の仕様を定義した標準文書
RTBH	BGPで「このIP宛てのトラフィックは破棄せよ」と指示するDDoS防御手法。
Destination Address RTBH	宛先IP単位で通信をブラックホールに送る方式。正規通信も止まるため、緊急時用。
iBGPピアリング	同一AS内で経路情報を広報するための手法。制御用サーバから複数ルータへ経路を伝播可能。

まとめると、この文章は、E社のDDoS対策が「NetFlowによるトラフィック分析」＋「RTBH方式によるピンポイント遮断」で構成されていることを示しています。

ポイントとしては……。

• NetFlowで攻撃の宛先IPを自動検知。
• そのIPに対する経路をBGPでブラックホールに流す。
• iBGPを通じて、E社の複数ルータで一貫して遮断処理を実施。
• 他の正常な通信には影響を与えず、サービス全体の可用性を保つ。

DDoS検知サーバは、検知したDDoS攻撃の宛先IPアドレスへのホスト経路を生成しRTBH方式の対象であることを示すBGPコミュニティ属性を付与して各BGPルータに経路広告する。

この一文は、RTBH（Remote Triggered Black Hole）方式における「DDoS検知サーバ」からのBGP制御の仕組みを説明しています。

特にここでは、ホスト経路の生成とBGPコミュニティ属性によるブラックホール指示という2つの重要な技術要素が含まれています。

ネットワークスペシャリスト試験では、BGPの経路制御技術（とくにコミュニティ属性）や動的なDDoS遮断の仕組みを理解しているかが問われるため、以下に要素ごとに分解して丁寧に解説します。

ホスト経路（host route）とは、宛先IPアドレスに対してプレフィクス長が /32（IPv4）である非常に限定的な経路のことです。

例：203.0.113.10/32 のように、1つのIPアドレスのみに適用される経路。

これは、攻撃対象の1台のホストだけをブラックホール化するために必要です。

DDoS攻撃の影響を最小限に抑えるために、攻撃を受けている宛先IPアドレス“だけ”に影響する経路を作成し、他の通信を巻き込まないようにするためです。

BGPコミュニティ属性とは、BGPコミュニティ（Community）属性は、経路に任意の意味付けを加えるための拡張属性です。

フォーマット例：65000:666 のように、数字の組み合わせで構成されます。

この属性を利用することで、ルータ側が「特定の属性が付いた経路に対して特別な処理（例：Null0にルーティング）」を実行できます。

1. DDoS検知サーバは、iBGPセッションを通じて、AS内部にある各BGPルータに対してホスト経路を配布する。
2. 各ルータは、広告された経路にRTBH用のコミュニティ属性がついていることを検知し、Null0へのルーティング処理を適用する。
3. これにより、DDoSトラフィックはE社のネットワーク内部に到達する前に破棄される。

技術要素	解説
ホスト経路	/32（IPv4）のように、1台のホスト宛に限定した経路。ピンポイントでの対処が可能。
BGPコミュニティ属性	経路に意味を付加するためのタグのようなもの。ルータ側で事前に処理方針を定義しておく。
RTBH制御の仕組み	DDoS検知 → ホスト経路生成＋コミュニティ付加 → BGP広告 → Null0転送により破棄。
iBGP活用	AS内部にいる複数のルータへ、一貫した経路制御情報を配信するために使用。

まとめると、この一文は、DDoS攻撃対象のIPアドレスに対し、BGPとコミュニティ属性を活用してピンポイント遮断（RTBH）を実施する仕組みを説明しています。ポイントは……。

• 検知サーバが /32 のホスト経路を生成することで、影響範囲を限定。
• コミュニティ属性でブラックホール対象であることを明示。
• iBGPを通じて複数ルータに指示を一括伝播し、効率的かつ統一的に遮断処理が可能。

RTBH方式の対象であることを示すBGPコミュニティ属性が付いたホスト経路を受け取った各BGPルータは、そのホスト経路のネクストホップを廃棄用インタフェース宛てに設定することで、DDoS攻撃の宛先IPアドレス宛ての通信を廃棄する。

この一文は、RTBH（Remote Triggered Black Hole）方式における最終的な遮断動作――つまり、BGPルータが「攻撃対象IPアドレス宛ての通信をいかにして廃棄するか」という仕組みを説明しています。

• DDoS検知サーバが生成したホスト経路（例：203.0.113.10/32）が、BGPルータに広告される。
• 経路には、あらかじめ「この経路はブラックホールに落とすべき」という意味のBGPコミュニティ属性（例：65000:666）が付与されている。
• 各BGPルータは、このコミュニティ属性を見て「このIP宛ての通信は廃棄すべきだ」と判断する。

ネクストホップ（Next Hop）は、「このIPアドレス宛てのパケットを、どのインタフェース・どのルータへ送るか？」を指すBGPの基本情報です。

こでは通常、Nullインタフェース（Null0）が使われます。

Null0 は「届いたパケットを即座に破棄する仮想的なインタフェース」です。いわば「シュレッダー」と考えると良いでしょう。

パケットがその宛先に向かう過程でこのインタフェースにルーティングされると、実際の転送はされずに破棄されます（≒ドロップ）。

この結果、攻撃対象IP宛てに向かう大量のDDoSパケットは、すべてBGPルータによって破棄されます。

これにより、下流（CDNの配信サーバなど）にはパケットが届かず、サーバや回線が守られるのです。

項目	解説
ホスト経路	/32 のプレフィクス長で、特定のIPアドレス宛てだけを対象にする
BGPコミュニティ属性	「この経路はブラックホール対象」という意味付けをBGPで伝達
ネクストホップ＝Null0	BGPルータがそのIP宛てのパケットをシュレッダー（Nullインタフェース）に送る設定
結果としての効果	攻撃対象だけを選んで遮断。他の通信や利用者には影響しない精密防御が可能

まとめると、この一文は、DDoS検知サーバから広告された「ブラックホール用経路」を、BGPルータがどのように処理してパケットを廃棄するかを示しています。ポイントは……。

• ホスト経路＋BGPコミュニティ属性により「このIPは破棄せよ」という指示を伝える。
• 各BGPルータは、そのIPへのネクストホップをNull0（破棄）に設定。
• 結果的に、DDoSトラフィックはネットワーク内部に届く前に排除される。

DDoS遮断システムの今後の開発予定をE社技術担当者に確認したところ、RFC 8955で定義されるBGP Flowspecを用いる対策(以下、BGP Flowspec方式)をE社が提供する予定であることが分かった。
BGP Flowspec方式では、DDoS検知サーバからのiBGPピアリングで、DDoS攻撃の宛先IPアドレスだけではなく、DDoS攻撃の送信元IPアドレス、宛先ポート番号などを組み合わせてBGPルータに広告して該当の通信をフィルタリングすることができる。

この文章は、従来のRTBH（Remote Triggered Black Hole）方式よりもさらに細かく柔軟にDDoS攻撃を遮断できる「BGP Flowspec」という新しい仕組みについて解説する前提文です。

ネットワークスペシャリスト試験でも、RFCベースの最新の経路制御技術やセキュリティ対策が問われることがあるため、ここではRFC 8955で定義されるBGP Flowspec方式の仕組みと利点について、段階的に解説します。

BGP Flowspec（Flow Specification）は、RFC 8955で定義された、BGPを使って「トラフィックフィルタリングの条件」をネットワーク中のルータに配布する仕組みです。

通常のBGPは「どの宛先IPにどうルーティングするか」という経路情報を扱いますが、Flowspecではどのような条件のパケットを破棄・制限すべきかをBGPで伝達するという拡張です。

これは、特定の攻撃トラフィックだけをフィルタリングしたいときに非常に有効です。

• Flowspecルールは、「送信元IP」「宛先IP」「プロトコル番号」「ポート番号」などの条件を組み合わせて指定可能。
• iBGPセッションを通じてAS内の全ルータに一斉配布できる（拡張NLRIを使用）。

検知サーバからAS内のすべてのBGPルータに一貫した制御ルールを配信するためということと、iBGPを使えば、管理ドメイン内で効率的にFlowspecルールを展開できるということが理由として挙げられます。

項目	RTBH方式	BGP Flowspec方式
対象	宛先IPアドレスのみ	宛先IP、送信元IP、ポート番号、プロトコルなど
制御内容	パケットの破棄（Null0）	フィルタリング、帯域制限（rate-limit）、ミラーリングなど
粒度	荒い（1IPごとに遮断）	細かい（特定の条件のみ遮断可能）
RFC	RFC 5635	RFC 8955

つまり、Flowspecでは、「送信元が特定のIP、ポート番号がUDP 123（NTPリフレクション）」のように、攻撃に該当する条件だけを絞って遮断できます。

正常なユーザの通信は残しつつ、攻撃トラフィックのみを排除できる点で非常に優秀です。

1. DDoS検知サーバが「この条件のトラフィックは遮断すべき」と判断。
2. BGP FlowspecのNLRI（Network Layer Reachability Information）を使って、ルールをiBGPで広告。
3. 各ルータがそのルールを受信し、ACLやルーティングポリシーに自動的に反映。
4. 攻撃トラフィックが通過しようとすると、ルータが即座にフィルタリング（破棄・制限）。

観点	解説
Flowspecの主目的	DDoSトラフィックなどの細粒度な遮断制御をBGPで行う
技術的特徴	NLRIで定義されたトラフィックマッチ条件をルールとして広告
iBGPの役割	AS内全体へ一括展開するためのピアリング手段
RTBHとの違い	Flowspecは選択的・動的・精密な対策が可能
RFC番号	RFC 8955（Flowspec）、RFC 5575bis（最新版ではFlowspec v2）

まとめると、この問題文はE社が従来のRTBH方式に加えて、より高度なBGP Flowspec方式を導入しようとしていることを説明しています。

Flowspecの導入により、下記の3点が可能になります。

• 攻撃対象だけでなく、攻撃元やプロトコル・ポートといった条件で柔軟に遮断が可能に。
• 正常な通信を維持しつつ、攻撃のみを排除する精密防御が実現。
• BGPとiBGPの技術を拡張的に活用し、ルータ全体で自動かつ一貫した対処が可能。

Xさんは、⑤BGP Flowspec方式の方が有用であると考え、E社技術担当者に早期提供をするよう依頼した。Xさんは、E社CDNとDDoS遮断システムを導入する計画を立て、計画はD社内で承認された。

この一文は、技術的な背景をもとにした意思決定の流れと、BGP Flowspec方式が持つ実用上の優位性を前提にした導入計画の進展を描いています。

XさんがRTBHよりBGP Flowspecの方が「有用」と判断したのは、おそらく以下の理由からです。

比較観点	RTBH方式	BGP Flowspec方式
遮断の粒度	宛先IP単位（/32）でのみ	送信元IP、宛先IP、ポート番号、プロトコルなどの条件を柔軟に組み合わせ可能
対象	攻撃を受けているIP全体（正規通信含む）	攻撃通信のみを精密に選んでフィルタ可能
動作	経路制御によるNull0ルーティング	ACL相当の動的ポリシーとして実行される
影響範囲	正規ユーザにも影響しやすい	影響を最小限に抑えられる（サービス継続性）

このように、BGP Flowspecは「遮断の精度」と「業務影響の最小化」の両立が可能な高度なDDoS対策として有用と判断された、という前提が読み取れます。

観点	解説
技術選定理由の妥当性	Flowspecの粒度の細かさ・柔軟性から「有用」と判断
DDoS対策の進化	RTBH（粗い）→ Flowspec（精密）への移行は技術的にも実用的にも自然な流れ
業務への影響を抑える工夫	Flowspecでは正規通信を極力遮断せず、サービス継続性を保てる
社内調整と承認プロセス	技術判断だけでなく、企業内での導入意思決定も問われることがある

まとめると、この問題文は次のような流れを意味しています。

1. Xさんは、RTBHよりBGP Flowspecの方が柔軟で実用的と判断。
2. 将来導入予定の機能であっても、早期提供を技術部門に依頼。
3. CDN＋DDoS遮断という包括的な導入計画を立案。
4. D社内でもその技術的・運用的な妥当性が評価され、計画が承認された。

設問1

[現状の配信方式]について答えよ。

(1)　本文中の下線①について、HTTPではなくICMP Echoで死活確認を行った場合どのような問題があるか。50字以内で答えよ。

【問題の意図】

• なぜHTTPで死活確認しているのか？
• ICMP Echoにした場合、どんな問題があるのか？

要素	解説
ICMP Echo	いわゆる「ping」。OSレベルで「生きているか？」の確認はできる
応答するが…	OSやネットワークインターフェースは生きている可能性がある
HTTPサーバのプロセスが停止している	Webアプリケーション（Apacheやnginxなど）がダウンしている可能性がある
検知できない	ICMPはアプリケーション層の動作までは見られないため、HTTPでの死活確認でないと気づけない

項目	HTTPによる死活確認	ICMP Echoによる死活確認
層	アプリケーション層（L7）	ネットワーク層（L3）
チェック内容	Webサーバが正しく動作しているか	OSが動いていて応答可能か
検出できる故障	アプリのバグ、HTTPエラー、503など	ネットワーク断、マシン停止など
検出できない故障	–	HTTPプロセスだけが死んでいる場合 など

そのため、ロードバランサが実際にサービスを提供できているか（＝HTTP応答が返るか）をチェックするには、HTTP死活確認が必要というのが本質です。

まとめると、この問題は、死活確認の精度・信頼性を問う基本的かつ重要なテーマです。

• ICMPはOSの稼働確認には有効だが、アプリケーションの異常は検出できない
• HTTPアクセスを使えば、Webサーバのプロセス停止やアプリ層の異常も検出可能
• よって、ロードバランサがHTTPで死活確認を行うのは妥当

(2)　本文中の（　　ア　　）に入れる適切な字句を、本文中から選んで答えよ。また、本文中の（　　イ　　）に入れる適切なセグメントを、表1中から選んで答えよ。

（ア）この問題は、ロードバランサ（LB）の振り分けアルゴリズムの選択理由を理解しているかどうかを問う設問です。

振り分ける先の配信サーバの性能は同じ
→ サーバごとの処理能力に差はない

接続ごとにゲームファイルのサイズに大きなばらつきがあり
→ 軽い接続もあれば、重い接続（大容量DLなど）もある

配信に掛かる時間が変動する
→ 処理時間が一定でないため、単純な順番割り振りでは不公平が起きる

同時接続数をなるべく均等にしたい
→ アクセス数の多いサーバを避けて、空いているサーバに振り分けたい

アルゴリズム名	特徴	このケースに適しているか
ラウンドロビン	順番にサーバへ振り分ける（単純）	❌ 一時的な接続数の偏りが発生する可能性あり
最小接続数（Least Connections）	現在の接続数が少ないサーバに割り振る	✅ 各サーバの接続数を均等に保ちやすい
IPハッシュ	IPアドレスなどで固定的に振り分ける	❌ ユーザーに偏りが生じる場合がある

したがって、このケースで最も適しているのは 最小接続数方式です。

（イ）この設問は、表1に記載されたセグメント情報とゲーム配信の関係性を把握し、ゲームβに対応するサーバセグメント（ネットワーク）を特定する問題です。

この問題を解くために必要なポイントは以下の通りです。

ゲームβに関連する配信トラフィックが増える → 対応するサーバセグメントの台数を増やして負荷分散したい。

よって、ゲームβの配信に使用しているサーバが所属するセグメントを特定する必要があります。

　ゲームファイルの配信に利用するIPアドレスとポート番号を、表1に示す。

このように、ゲームβ配信用のサーバが属しているのが「172.22.1.0/24」セグメントであると明記されているため、サーバを増設する先もこのセグメントになります。

• サーバを増設する際は、同一用途・同一セグメントに配置することで負荷分散やスケーラビリティが確保できる。
• セグメントは通常、用途別・トラフィック特性別に分けられており、ルータやファイアウォールで適切な制御が行えるように設計されている。

(3)　HTTPSに必要なサーバ証明書はどの装置にインストールされているか。必ず入っていなければならない装置を一つだけ選び、図1中の字句で答えよ。

この問題は、HTTPS通信を実現するために必要な「サーバ証明書」が、システム構成の中のどの装置にインストールされている必要があるかを問う設問です。

HTTPSは、TLS（SSL）で暗号化されたHTTP通信です。

クライアントがサーバと安全に通信するために、サーバ側はデジタル証明書（サーバ証明書）を提示して「自分が正当なサーバである」ことを証明します。

この証明書は、HTTPS通信を受け付ける最初の装置にインストールされている必要があります。

TLS終端のパターンによって異なるものの、多くのCDNや負荷分散構成では、TLS終端（暗号復号の処理）をLBで行います。

つまり、クライアントはLBとHTTPS通信を行うため、LBにサーバ証明書をインストールする必要があるのです。

• 配信サーバは、LBから内部的にHTTPで接続されるだけであり、証明書は不要（TLS終端しない）。
• クライアントに対して証明を行うのはLBなので、HTTPS通信を正しく行うためには、LBがサーバ証明書を必ず持っている必要がある。

• HTTPS通信に必要なサーバ証明書は、クライアントとのTLS通信の終端装置にインストールされる。
• 今回の構成では、TLS終端はLBで行われている。
• よって、証明書が必ず必要な装置は「LB」。

設問2　

[配信方式の見直し]について答えよ。

(1)　本文中の（　　ウ　　）、（　　エ　　）に入れる適切な字句を、“大きい”、“小さい”のいずれかから選んで答えよ。

この問題は、BGP（Border Gateway Protocol）の経路選択における属性値の優先順位について理解しているかを問う、典型的な設問です。

ネットワークスペシャリスト試験では、BGPの経路制御属性の意味と評価順序を問う問題がよく出題されます。

• AS内部（iBGP間）で使用する経路選択用の属性。
• 値が 大きいほど優先される。
• 経路選択の最も優先度が高い属性のひとつ。
• 主に、「どの出口（トランジット）を使うか」を自AS内で調整するために使われる。

つまり（　ウ　）には「大きい」。

• 他のASに対して「うちのASに入るならこのルートを使ってほしい」というヒントを伝える属性。
• 値が 小さいほど優先される。
• ただし、同一AS内の経路比較でのみ有効（異なるAS同士の比較には基本的に使われない）。

つまり（　エ　）には「小さい」。

BGPの経路選択は、次のような属性の優先順位で評価されます。

• Highest LOCAL_PREF（大きい値が優先）
• Shortest AS_PATH
• Lowest ORIGIN type
• Lowest MED（小さい値が優先）
• eBGP over iBGP
• IGPメトリックが小さいネクストホップ

(2)　本文中の下線②について、図2でAS-E東京POPにAS-GからのHTTPSリクエストのパケットが届く場合、E社トラフィックはどちらの経路から配信されるか。途中通過する場所を、図2中の字句で答えよ。ここで、AS Path長以外は経路選択に影響せず、途中に無効な経路や経路フィルタリングはないものとする。

この問題は、BGP（Border Gateway Protocol）における経路選択の基準、特に AS Path長の比較に着目して、どの経路が選ばれるかを図2の構成から読み取る問題です。

「AS-GからE社東京POPにHTTPSリクエストが届く」＝入口方向（ingress）
→ このパケットに対し、E社東京POPからの戻りトラフィック（egress）がどの経路を通るか？
→ 経路選択基準は AS Path長のみ。

• BGPでは、AS Pathが短い経路（通過するASの数が少ない経路）を優先。
• それ以外の属性（LOCAL_PREFやMEDなど）は「影響しない」と明記されている。
• 経路はすべて有効（フィルタやエラーはない）。

問題文中の「下線②」の意味は、東京POPのBGPルータが、「AS-Gに返すパケットの経路として、最もAS Pathが短い経路」を選ぶという前提です。

まとめると

• BGPでAS Path長のみが考慮される条件。
• AS-Gへの最短のAS Pathを持つ経路が「IX経由」である。
• よって、E社の東京POPからのトラフィックはIX経由で配信される。

よって、正解は：IXとなります。

(3)　本文中の下線③の設定をすることで何を防いでいるか。“BGP”という字句を用いて10字以内で答えよ。

この問題は、BGPセッションに対してMD5認証を設定することの目的（セキュリティ効果）を、簡潔に答えさせるものです。

BGPは、TCP（通常ポート179）上でセッションを確立し、ルータ間で経路情報を交換します。

しかし、TCPには本来認証機能がないため、第三者がなりすましてBGPセッションを張るリスクがあります。

これを防ぐために、BGPセッションにMD5ベースの共通鍵認証（TCP MD5オプション）を設定することで、正当な相手としかセッションを張れないようにするのが本設定の目的です。

MD5認証で防げる脅威は

• 不正なBGP接続
  • 攻撃者が偽ルータとしてBGPセッションを張るのを防止。
• 経路情報の改ざんや誤注入
  • なりすましたBGPピアからの偽の経路情報注入をブロック。

まとめると、MD5認証設定の目的はBGPピア間の接続を正当なものに限定することです。

これによって防げるものは不正なBGP接続となります。

よって、答えは：不正なBGP接続です。

(4)　本文中の下線④について、フィルタリングせずに不正な経路を受け取った場合に、コンテンツ配信に与える悪影響を“不正な経路”という字句を用いて40字以内で答えよ。

この問題は、BGP経路フィルタリングを行わずに「不正な経路情報」を受け入れてしまった場合に、どのような実害があるかを理解しているかを問う設問です。

「アドレスブロックやAS番号を偽った不正な経路情報を受け取らないための経路フィルタリング」→これは、経路ハイジャック（BGPハイジャック）や誤った経路情報の伝播によって、正常な通信ができなくなることを防ぐための対策です。

1. BGPルータが信じてはいけない経路を選択してしまう。
   → 実際には存在しない経路や、攻撃者が広告した経路にトラフィックを流してしまう。
2. 不正な経路に誘導された通信は届かない or 攻撃者に盗聴される。
   → 配信サーバからコンテンツを送り出しても、ユーザーに届かない。

1. 攻撃者が「203.0.113.0/24」を自分のASから広告する。
2. 本来の正規ASよりもAS Pathが短ければ、多くのルータがその偽経路を選択してしまう。
3. 結果、E社CDNがそのブロック宛に配信しようとしても、トラフィックが偽ASに向かい、ユーザーに届かないということになる。

まとめると……。

• 経路フィルタを行わないと、不正な経路情報に基づくルーティングが行われる。
• その結果、本来届くはずのユーザーにコンテンツが届かなくなる。

したがって、解答は「不正な経路に含まれるアドレスブロックへのコンテンツ配信ができなくなる。」となります。

設問3

[配信拠点の保護]について答えよ。

(1)　図3において、インターネットからBGPルータ1を経由してLB11にHTTPS Flood攻撃があったとき、FW1でフィルタリングする方式と比較したRTBH方式の長所は何か。30字以内で答えよ。

この問題は、RTBH（Remote Triggered Black Hole）方式の特徴と、従来のファイアウォールによるフィルタリングとの違いを理解しているかを問うものです。

• BGPルータ1経由でLB11にHTTPS Flood攻撃が発生。
• FW1（ファイアウォール1）でフィルタリングする方式 → 通常のネットワーク境界での遮断。
• 比較対象はRTBH方式。

• BGPで「この宛先（攻撃対象IP）宛ての通信は破棄せよ」という情報をネットワーク内に広告する。
• これにより、経路上にある複数のBGPルータが該当パケットをNull0（ブラックホール）へ転送する。
• 目的は、できるだけ上流（攻撃元に近い場所）で遮断することである。

比較項目	FW方式	RTBH方式
遮断位置	ネットワーク境界（例：FW1）	上流のBGPルータ（可能ならISPレベル）
効果範囲	社内への進入を止めるのみ	回線帯域やLBなど社内リソースへの負荷も防げる
レスポンス速度	検知から手動対応のことも	BGPで広範囲に即時に伝播可能

まとめると、

• RTBH方式は、「社内に届く前に」上流のネットワーク（BGP経由）でトラフィックを破棄できる。
• これにより、社内回線や装置の負荷増大を未然に防げる。

したがって答えは「攻撃パケットを攻撃元に近いところで遮断できる。」となります。

(2)　本文中の下線⑤について、RTBH方式と比較したBGP Flowspec方式の長所は何か。30字以内で答えよ。

この問題は、RTBH方式とBGP Flowspec方式の違い・進化点を正しく理解しているかを問う設問です。

• 宛先IPアドレス単位でブラックホール化。
  • 例：203.0.113.10/32 を丸ごと破棄。
• メリット：シンプルでBGPだけで実現可能。
• デメリット：対象IPアドレスの正規通信もまとめて遮断されてしまう（犠牲的）。

• 送信元IP・宛先IP・ポート番号・プロトコルなどの条件を組み合わせてマッチング。
  • 例：送信元IPがX、宛先がY、TCP 443番のパケットだけ破棄。
• BGP経由で、これらの「トラフィックフィルタ条件」をルータに配布。
  → 不正なトラフィックだけをピンポイントで遮断できる。

RTBHとの比較はこのようになります。

項目	RTBH方式	BGP Flowspec方式
制御単位	宛先IP単位（/32など）	IP、ポート、プロトコルなど複数条件
精度	粗い（すべて破棄）	細かい条件で選別可能 ✅
正規通信への影響	高い	低い ✅
柔軟性	低い	高い ✅

まとめると、BGP Flowspec方式は、トラフィックの内容（送信元・宛先・ポートなど）を細かく指定して遮断できるのが最大の強みであり、RTBHより柔軟かつ正確に攻撃をブロックできます。

したがって答えは「より細かい条件で選別して破棄することができる。」となります。