WAN暗号化もシンプルに！ MACsecの提供価値

ビジネス推進本部 応用技術部
コアネットワークチーム
平河内 竜樹

スイッチ製品で商用実装が先行していたMACsecは、追ってルータ製品でも対応が開始され、拠点間接続の暗号化を実現する選択肢としても挙げられる様になってきました。本コラムでは広域ネットワークに適用したケースを想定し、MACsec活用の可能性について検証データを交えて紹介します。

MACsecの位置付け

今回取り上げるMACsecとはその名が示す通りイーサネットレイヤの通信保護機構です。相手認証と鍵合意は802.1Xの枠組みの中で行われ、MACsecが実装された製品は、イーサネットフレームに対して暗号化・メッセージ認証・シーケンスチェックの機能を提供することが可能になります。またIEEE 802.1AEとして既に標準化が完了しており、実装としても多様な選択肢が期待できるプロトコルとなっています（□ □）。

MACsecを早期に実装した製品としてはCatalyst 3750-X/3560-XシリーズやNexus 7000シリーズといったCisco Systems社のスイッチ製品が有名で、これらの機器間でMACsecが適用される際には802.1AEで規定されているヘッダ（SecTAG）の他にアクセス制御に活用できるユーザ識別用のタグも利用されています（□）。こういった経緯などから、MACsecに関しては、純粋なレイヤ2のデータ保護機構というよりは構内のセキュリティソリューションを構成する一要素という印象をお持ちの方もいるかもしれません。

一方で、数年前から商用のルータ製品でもMACsecの対応が開始される様になりました。実装としてもユーザ認証と独立しており、ルータの主な適用場面に応じる形でWANの暗号化を実現する選択肢として利用されることが想定されます。

拠点間接続におけるデータ保護と言えばIPsecがスタンダードな技術として幅広く利用されています。IPsecを伴うデータ転送は負荷の高い処理ですが、製品の進化に伴って処理性能は着実に向上しており、適切な製品選択を行えば多くのケースで必要なスループットは十分に確保できます。またIPでトンネリングされるため様々なWANに適用でき、NAT / Firewallを経由する構成にも十分な実績があります。ユーザ拠点とフロントシステムとの間を暗号化付きのVPNで接続する際には、第一に採用されるプロトコルと言えます。

対してMACsecは利用に際してイーサネットの接続性が前提となるため、WAN暗号化の手段として見た場合、WANに対する要求がまずハードルになることは想像に難くありません。そういった中でMACsecがどのような場面に適用できる技術か、検証を通じて探っていきたいと思います。

性能面の利点

ルータ製品のMACsec機能に関するドキュメントでは「高速」「ラインレート」といった文言があり、特徴的な転送性能を有することが窺えます。本項では、2ポートの10GE環境に対するスループット測定の試験結果を紹介します。こちらは2015年の頭に測定を行った際のデータですが、MACsecの特徴が現れた結果となっています。

試験対象機器としてCisco Systems社のASR1000 シリーズを2台用意し、その間でMACsecを有効にした状態で、テスターのテストアプリケーションを利用してノンドロップレートの測定を行いました。同製品ではIPsecもサポートされており、トポロジ・アドレッシング・ルーティングおよび暗号アルゴリズムが共通となる環境で、そちらのデータ採取も行いました。以下に示す図1は双方の値をまとめたものとなります。IPsecでは最大でおよそ4Gbps双方向の値であったことに対し、MACsecでは2ポートの10GE環境に対してフレーム長を問わずにラインレートの転送が可能となりました。

なおロングフレームにおけるIPsecのスループットに着目すると、転送処理装置、および図1には含まれていませんがIPsec暗号化処理装置の利用率においても余力がある状態にも関わらず4Gbps双方向の値に留まっていました。このため同製品のIPsecスループットは、リンク速度より低い値の上限が総帯域として存在しており、処理性能とは別にその点がボトルネックとなっている可能性があります。しかしながら、転送処理装置の負荷が高騰する短いフレーム長で比較すると確保できるスループットの差は歴然としており、IPsecとMACsecでは転送処理装置へ及ぼす影響に大きな違いがあることが窺えます。

次に示すデータは、上記と合わせて実施した、転送処理装置における負荷の増分に着目した試験結果です。図2はMACsecスループットの測定で得られたPPSを印加レートとし、MACsec処理を外した際の転送負荷を測定した結果です。また図3は、PPSをある一定の値に固定した状態で、併用するサービス処理が異なる複数のパターンで転送負荷を採取した結果となります。

図2の結果を見ると、MACsecを無効にして通常の転送とした場合も、転送負荷はほとんど下がっていないことが解ります。逆に言えば、MACsecによる転送負荷の増分は無視できる範囲であると言って差し支えありません。

図3は同機器でサポートされているOTV (Overlay Transport Virtualization) の機能を利用してレイヤ2 VPNを構築し、その通信をIPsec・MACsecそれぞれで保護した際の結果です。OTVを用いる場合、機能単体を有効にする際も転送負荷は引き上げられ、IPsecと組み合わせればその負荷は上乗せされる結果となりました。対してMACsecと組み合わせたケースでは、負荷増分はOTVのみを有効にした際と同等であり、MACsecの適用による負荷の増加は見受けられませんでした。

ルータ製品の一般的な振る舞いとしてサービス処理を有効にするごとに転送負荷は上積みされる中、MACsecを利用することで高負荷なデータ保護の処理を全面的に切り出すことが可能となり、またその猶予を他のサービス処理に充てることができます。

同製品の情報が掲載されたドキュメントにはMACsecはPHYチップに実装されており、これの利用による性能影響は無い旨が記載されています。前述の試験はMACsecに関係する処理はほぼ全て転送処理装置からオフロードできていることを裏付ける結果になったと言えます。とりわけ有効化に伴う転送処理装置の負荷上昇が見られない点はIPsecでは見られない特徴であり、例えば暗号化を利用した際にも上限帯域を保証する必要があるケース・暗号化以外に負荷の高いサービス処理を併用するケースにおいて活用が見込めます。

なおMACsecの処理を行うチップが実際にどの程度の暗号化処理性能を有するかの数字情報は表へ出ていない様に思えますが、ラインレートの到達が保証されている結果を鑑みると、担当するポートで交換され得るデータに対しては漏れなく処理可能な様に設計されていることが窺えます。IPsecのアクセラレータが搭載される製品では、暗号化処理部は通信が交換されるインタフェース間で共用可能な様に配置されることが一般的です。MACsecは、要素技術こそ他のセキュリティプロトコルと多くを共有しているものの、対応するコンポーネントが複数の半導体メーカーからPHYチップとしてリリースされる様になったという側面では特徴的な仕様と言えます。

これまでVPNなどにおいて暗号化機能を付与する際には、暗号化処理部の性能を意識することがあり常であり、またそれが製品の差別化要素にもなっていました。データの暗号化があたかもシリアライゼーションの様にリンク速度一杯まで自然と提供される様になることは、ネットワークを設計・構築する立場から見ると、大きな転換と言えるのではないでしょうか。

イーサネットの特性

MACsecはイーサネットレイヤで機能するため、上位層に対して透過的に適用することが可能です。例えばARPやIPv4・IPv6に加えてIP MulticastやMPLSなど、イーサネットの上で行われる通信であれば単一の仕組みで全て保護することが可能です。これらの転送ロジックからMACsecが意識されることはありません。

図4・図5は前項の試験環境を流用してMPLSおよびIP Multicastの疎通性を確認した際の結果であり、どちらも平常時と全く同じ方法で利用することができました。

またMACsecは、伝送路となるイーサネットの中継機器全てが処理に対応するホップバイホップ（シングルホップ）構成の他に、非対応の機器が介在するマルチホップ構成を取ることができます。このため、広域イーサネットサービスを介してMACsecを適用すれば、マルチポイント型のWAN接続を透過的に保護することが可能となります。

IPsecでGSA (Group Security Association) を扱う場合、例えばGDOI (Group Domain of Interpretation) といった、相応に複雑な鍵管理プロトコルが別途必要となります（□）。これは、対応製品が限られるだけでなく、導入や運用の難易度へ跳ね返ることにもなります。筆者も多数の拠点間接続において増大するIPsecSA数の集約を期待してGSAの検証を行った経験があり、その際は追加ナレッジの習得やトラブルシューティングの実施まで鑑みると、必須でない環境にも積極的に使っていける技術...とは言い難い印象を受けました。

MACsecもマルチホップ構成になれば製品によって対応可否は分かれます。ただ、コントロールプレーンとして802.1X-2010という統一された標準があること、折衝はリンクローカルなマルチキャストを通じて行われることなどが特徴として挙げられ、動作の理解や設定を行う上でシンプルさが期待できます。

なおMACsecでは、デフォルトの暗号スイートに鍵長128ビットの認証付き暗号となるGCM-AES-128が定められています。その後に鍵長が256ビットのGCM-AES-256（□）と、シーケンス番号の拡張に対応するためのGCM-AES-XPN-128およびGCM-AES-XPN-256（□）が追加されています。将来にわたっての暗号強度や転送容量の拡張を踏まえればGCM-AES-XPN-256の採用が理想的であり、これを利用するに際は対応の設定が必要になるかもしれません。他方、保護処理の要素は一つのパラメータで表現され、IPsecと比較すれば設定に纏わる複雑さは軽減される側面もあります。

次いで紹介するデータは、前項の試験で利用した2台のMACsec機器に3台目のMACsec機器とそれらを接続するレイヤ2スイッチを追加し、マルチポイント接続を確認した際のものとなります。図6は試験の構成図、表1はその際に各機器へ投入した設定となります。設定後、各機器間でMACsecによって保護された通信が可能な状態となりました。

表1：設定の抜粋

　key chain KEY-CHAIN macsec
     key 01
       key-string 12345678901234567890123456789012
    interface GigabitEthernet0/1/0
     mtu 9216
     ip address 172.16.1.10 255.255.255.0
     eapol destination-address broadcast-address
     mka pre-shared-key key-chain KEY-CHAIN
     macsec

　key chain KEY-CHAIN macsec
     key 01
       key-string 12345678901234567890123456789012
    interface GigabitEthernet0/0/0
     mtu 9216
     ip address 172.16.1.20 255.255.255.0
     eapol destination-address broadcast-address
     mka pre-shared-key key-chain KEY-CHAIN
     macsec

　key chain KEY-CHAIN macsec
     key 01
       key-string 12345678901234567890123456789012
    interface GigabitEthernet0/0/0
     mtu 9216
     ip address 172.16.1.30 255.255.255.0
     eapol destination-address broadcast-address
     mka pre-shared-key key-chain KEY-CHAIN
     macsec

今回の環境において必要となった設定は、事前共有鍵の定義とインタフェースでの有効化くらいです。この環境ではGCM-AES-128を利用したため、利用するアルゴリズム等のパラメータ指定も不要でした。またピアに依存した設定項目は無く、投入されているMACsec関連のコマンドは各機器間で同一のものとなっています。環境構築の過程で2台の機器間で疎通が可能となった後に3台目を追加する際にも、既存の2台に対する設定の更新作業は発生しませんでした。今回の試験では、MACsecで必要となる設定は簡素であり、またマルチポイント接続への対応も容易であることが窺える結果となりました。

なお試験の過程で、中継に配置する機器によって、MKA (MACsec Key Agreement) セッションが未確立となる現象が確認されました。この状態では対向まで対象の通信が届いておらず、転送されるべき802.1Xの通信が中継機器上で終端されてしまったことが原因であると推察されます。

中継機器を介してMACsecを利用する場合、802.1Xで使用されるMulticastアドレスとEtherType、および802.1AEに対応するEtherTypeのフレームを正しく転送できることが要求されます。WAN経由で利用する際には、ヘッダ追加に伴うMTUの対応に加え、上記の通信を転送データとして交換する仕様であるかの確認が利用するサービスに対して必要となります。もしくはMACsecの機能として宛先アドレスやEtherTypeの変更がサポートされていれば、機器側の対応でカバーすることも可能となります。

トンネリングプロトコルとの連携

これまでに挙げられた通り、MACsecはイーサネットレイヤの保護機構であり、利用にあたってはイーサネットの接続性が必要となります。そこから連想される発展的な使い方として、トンネリングプロトコルを併用しMACsecで保護されたフレームをレイヤ2のVPNで伝送するという形態が挙げられます。

IP以外の通信を対象とするためGREやL2TPなどを適用した後のIPパケットにIPsecを適用する方法は VPNの構築でよく用いられるテクニックです。今回はMACsecによって暗号化されたイーサネットフレームをIPネットワーク上で運ぶことが目的となるため、方式は例えばMACsec over VXLANといった形になります。

なおLinux 環境ではこの機能の組み合わせを既にサポートしています。本項で紹介するデータは、機能対応済みのKernel 4.10が採用されているUbuntu17.04を用い、MACsec通信をIP上にオーバーレイする構成を試した時の結果です。トポロジは図7の様に構成し、併用するトンネリングプロトコルはVXLANとGeneveの2パターンで行いました。なお今回利用した機能の有効化は初期状態でセットアップ済みのiproute2で提供されているipコマンドで完結しました。表2はGeneveと組み合わせる際に投入したコマンドです。

表2：投入コマンドの抜粋

　sudo ip link add geneve0 type geneve id 5000 remote 172.16.20.20
    sudo ip address add 10.120.0.10/24 dev geneve0
    sudo ip link set geneve0 up
    sudo ip link add link geneve0 macsec0 type macsec
    sudo ip macsec add macsec0 tx sa 0 on pn 100 key 00 81818181818181818181818181818181
    sudo ip macsec add macsec0 rx address 7a:98:2b:24:36:3e port 1
    sudo ip macsec add macsec0 rx address 7a:98:2b:24:36:3e port 1 sa 0 pn 100 on key 01 82828282828282828282828282828282
    sudo ip address add 10.255.0.10/24 dev macsec0
    sudo ip link set macsec0 up
    sudo ip link set macsec0 type macsec encrypt on

　sudo ip link add geneve0 type geneve id 5000 remote 172.16.10.10
    sudo ip address add 10.120.0.20/24 dev geneve0
    sudo ip link set geneve0 up
    sudo ip link add link geneve0 macsec0 type macsec
    sudo ip macsec add macsec0 tx sa 0 on pn 100 key 01 82828282828282828282828282828282
    sudo ip macsec add macsec0 rx address c2:42:62:e1:44:09 port 1
    sudo ip macsec add macsec0 rx address c2:42:62:e1:44:09 port 1 sa 0 pn 100 on key 00 81818181818181818181818181818181
    sudo ip address add 10.255.0.20/24 dev macsec0
    sudo ip link set macsec0 up
    sudo ip link set macsec0 type macsec encrypt on

この状態で左方のNVEからpingを実行したところ、通信が疎通することを確認できました。この時、中継のL3ノードおよび対向のNVEでパケットをキャプチャした結果は以下の通りです。

図8・図9を見るとMACsecで保護されたサブネット内通信がBroadcastであるARPも含めてIP Unicastで転送されている様子が窺えます。

なおVXLANの様に上位層を示すFieldを持たないプロトコルであっても、転送機器が管理するMACアドレスを利用することによって、レイヤ3のVPNに適用することが可能となります（□）。今回の環境においてもMACsecはNVEが生成したMACフレームに対して処理を行っており、この形態を転送機器上に適用すればMACsecによるレイヤ3VPNの保護も実現することができます。

また図8・図9のフレーム構造を見返すと、どちらにおいてもNVO tunnelのヘッダだけでなく、オリジナルフレームのヘッダにあるMACアドレスなども平文で伝送されていることが解ります。MACsecの暗号化機能はイーサネットのペイロードが対象となり、トンネリングによって元のヘッダが伝送路上で参照されない情報になった際も、ヘッダは暗号化対象に含まれない状態が維持されます。ブリッジした通信を盗聴された場合、通信の中身が見えるわけではないものの、例えばトラフィックのフローに関する情報が得られることも事実です。もしこの部分を隠蔽する要求があれば、MACsecの適用は前段でのトンネリング利用を前提とするか、もしくはトンネリングとの連携が意識された新たな方式が必要となります。

他の留意点としては、ハードウェアの対応面が挙げられます。MACsecの処理系がプロセッサやASICなどの転送処理装置と離れた位置に存在する場合、そこにトンネリングレイヤの処理もオフロードされていなければMACsecの後（受信時はMACsecの前）にその処理を加えることはできません。このため同一の機器上でMACsec通信をIP上にオーバーレイする場合、MACsecの処理系を転送処理装置に近づけるか、もしくはトンネリングの処理もMACsecと合わせてオフロード可能なチップを新たに用意する必要があります。どちらにせよMACsec処理を経由してラインレートを維持できる様にチップを配置することになれば、消費電力やスペースの面でリソースを消費する・製造コストが製品価格に大きく転嫁される・限られたポートにだけ採用されるといった形で影響を及ぼす可能性があります。

VXLANやMACsecは半導体メーカーの供給するスイッチチップ・PHYチップで広く対応が進んでいますが、その組み合わせが効率良く実現可能なハードウェアはまだ登場していない様に見受けられます。このため性能面の特徴を維持した製品が早期に実現される場合、当初は独自の開発を伴って登場することが予想されます。併せて半導体メーカーのチップで実現可能になれば、MACsecをIP上にオーバーレイする機能も、VXLAN製品の様な対応状況の広がりを期待することができます。

今回のまとめ

WAN暗号化の手段としてMACsecを見た場合、適用のハードルは存在する一方で、データの保護処理を転送処理装置から全面的にオフロードできることが特徴として挙げられます。結果、従来ではボトルネックとなりやすい暗号化等の保護処理が広帯域の転送で発生するケースにおいても、ラインレートを保証することが可能となります。

MACsecは処理がイーサネットレイヤで行われるため、上位層に対して透過的に適用可能であり、またマルチポイント接続がシンプルに実現されます。これは、特にMPLSやマルチキャストなどの要求がある際に利点となります。

MACsecは、半導体メーカーが供給するPHYチップで実装が進んでおり、ネットワーク製品の対応状況が急速に整備されています。加えて、別途ハードウェアの要求を伴うものの、VXLANなどのトンネリングプロトコルと連携することによって適用領域をさらに広げることが可能となります。

執筆者プロフィール

平河内 竜樹
ネットワンシステムズ株式会社 ビジネス推進本部
応用技術部 コアネットワークチーム
所属

ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事

• CCIE RS
• CCIE SP

ナレッジセンターを検索する