進化するインターネット技術/IETFトピックス2016-17

最終回

IoTのさらなる実現に向けたプロトコル/セキュリティ

インターネット技術の普及に向け、IPv6、DNS、HTTPなど基本となるプロトコルを定めてきたIETF(The Internet Engineering Task Force)。今年11月には、100回目の会合(IETF 100)がシンガポールにて開催される予定である。IETFがこれまで手がけてきたインターネット技術も、技術の進歩と普及により、現在も多くの分野において議論が継続され、まだまだ目が離せない状況が続いている。本連載では、インターネットの普及と発展を目的に日ごろIETFを中心に活動を行っているISOC-JP(Internet Society Japan chapter)メンバー有志が、ここ最近のIETFでの活動状況について紹介していく。

 本連載「進化するインターネット技術/IETFトピックス2016-17」の最終回は、IETFにおけるIoTに関するトピックを紹介する。

 近年のインターネットの世界ではIoTが大きく着目されることはいうまでもないが、一方で、IoT機器をボット化して大規模なDDoS攻撃が実施されるなど衝撃的な出来事も続いている。これはIoT機器に関するセキュリティの向上が求められていることを意味し、IoTが安心かつ安定して浸透するには技術的課題が残されていると言えるだろう。

 そのためIETFにおいてもIoTに関する技術検討は活発に行われ、IAB workshopでもテーマとして頻繁に取り上げられている(本連載初回『「IETF」30周年、IoT分野で新WG、トランスポートレイヤーで大きな動きも』参照)。また、IoTに関する技術をレビューするチームとして、IoT directorateを組織し、IoT技術の検討を進めている。

 IoTの議論において明確化しなければならないのが、想定するIoT機器のスペックである。IoTの定義が広いため、統一はできていないものの、IETFでは、組み込みLinuxを走らせるシステムオンチップ機器や、さらに制約の厳しい、数年間のバッテリー駆動が求められるような極小型の機器などが想定されている。

 このような背景の中でIETFにおける最新動向を、以下、2つの側面で紹介する。

  • IoTにおけるプロトコル動向
  • IoTにおけるセキィリティ動向

IoTにおけるプロトコル動向

 IETFではIoTに向け、もちろんIPv6を前提に議論が進められている。上記の通り、IoTにおいては、制約の厳しい条件での実現が求められ、特に低消費電力かつ処理負荷の軽いプロトコルが要求される。さらにインフラとしては無線系を想定し、Routing Area(RTG)並びにInternet Area(INT)にて以下のWGが関与している。

IoTに関するIPプロトコルを扱う主なWG
WG名主な活動内容
ROLL(Routing over Low power and Lossy Network)ワイヤレスなど制約されたパワーやリソースで構成されるネットワークにおけるルーティング手法を検討。RPL(RFC 6550)はこのWGから誕生
6lo(IPv6 over Networks of Resource-constrained Nodes)リソースに制約あるノードで構成のネットワークおけるIPv6使用に向けた技術定義。IPv6ヘッダー圧縮(RFC 6282)などを策定した6Lowpan WGの後継
6TiSCH(IPv6 over the TSCH mode of IEEE 802.15.4e)IEEE 802.15.4eのTSCHモード(時間同期チャンネルホッピング)を用いたIPv6ネットワーク構築方法などを議論
LWIG(Light-Weight Implementation Guidance)IoT装置のように制約ある装置に対してのプロトコル実装に関するガイダンスを議論
LPWAN(Low Power Wide Area Network)広域かつ低消費電力のネットワーク実現に向けたIPv6向けプロトコル規定を定義
IPWAVE(IP Wireless Access in Vehicular Environments)IETF 97以降活動を開始。自動車~インターネット間(v2i)、自動車間(v2v)のIPv6向けプロトコル規定(IPv6 over IEEE 802.11-OCB)を定義

 この中から本稿では、IETF 96以降活動を開始し、多くの中間会合も開催されているLPWAN WGについて紹介する。

 LPWANは、その名の通り、広域かつ低消費電力のネットワーク実現に向けたIPv6向けプロトコル規定を定めるものであり、現在、3つのWG I-Dが存在する。

LPWAN Overview(draft-ietf-lpwan-overview):
この文書ではLPWAN技術に関わる標準化団体での規格を検討し、IETFでの関連WGとのギャップ分析を行うものである。取り上げている規格にはLoRaWAN(LoRa Alliance)、NB-IoT(Narrowband IoT)(3GPP)、SIGFOX(ETSI)、Wi-SUN Alliance FAN(Field Area Network)があり、上記団体でと互換性を考慮しつつLPWANアーキテクチャを定義している。なお、LPWANという名目でターゲットスペックを明記している資料などが存在するが、LPWAN WG並びにこの文書では明確な規定は行っていない。

LPWANアーキテクチャ(draft-ietf-lpwan-overviewのFigure 1をベースに作成)

Static Context Header Compression(SCHC)(draft-ietf-lpwan-ipv6-static-context-hc、draft-ietf-lpwan-coap-static-context-hc):
LPWAN向けヘッダー圧縮機であり、低帯域での通信を考慮し、IPv6/UDPヘッダー並びにCoAPヘッダーに適用するためのドラフト作成が進められている。

 プロトコル動向の最後は、COR(Constrained RESTful Environments)WGを紹介する。CORE WGでは、制限された環境でのRESTfulアクセスを提供するもので、RFC 7252として発行されたCoAP(Constrained Application Protocol)を始め、HTTPとの相互接続、エンドポイント・リソースの発見、センサーなどのデバイスと定義するメディアタイプ規定、Pub-Sub対応などの拡張を策定している。

 また、CoAPは、プロトコル軽量化のためUDP/DTLSベースで設計されてきたが、TLSに対応するべくTCPへの拡張も議論されている。

 なお、参考までにIoT向けプロトコル比較として、XMPP(Extensible Messaging and Presence Protocol)、MQTT(Message Queue Telemetry Transport)がよく取り上げられるが、XMPPは、2015年にWG活動を終息したXMPP WGにてRFC 6120等で定義されたプロトコルであり、MQTTはOASISと呼ばれる別団体で規定されたプロトコルになる。

 以上、プロトコルに関わる動向を広く浅く紹介したが、注目するべきは、他団体の動向を加味しつつ、IETFで培ったものをいかに最大限に利用するか、という議論が進められているのではないかと考える。

IoTおけるセキィリティ動向

 IETFではIoTのセキュリティ面でも各種の検討がなされている。ACEやCORE、COSE、DICEをはじめ、IETFにおいてIoTのセキィリティ面を検討しているWGは多数存在しているが、その中でもACE(Authentication and Authorization for Constrained Environments)WGはIoTセキュリティに特化しており、具体的には制約を伴う環境での認証・認可に関して議論を進めている。また、IRTFにおいては、T2TRGにおいて、セキュリティに関しての考察文書をRG I-Dとして検討している。同文書ではIoTに対してのライフサイクルを定義し、セキュリティ考察に対する出発点としている。

draft-irtf-t2trg-iot-secconsのFigure 1から。IoTにおけるライフサイクルを定義する

 このライフサイクルにも登場するが、冒頭に紹介したIAB主催のIoT向けワークショップ(2016年6月開催)では、ソフトウェアアップデート(またはファームウェアアップデート)にフォーカスして開催された。そこで本稿では、ソフトウェアアップデートに着目したセキュリティ動向を紹介する。

 IoT向けソフトウェアであっても、通常のソフトウェア同様のアップデートを実施するメカニズムが必要不可欠であるという認識は、皆が共有するものである。では、課題をもう一段掘り下げ、セキュリティアップデートを実施していく際には、何が課題なのだろうか。さまざまな議論がなされた結果、以下のような点が課題・考慮点として提起された。

  1. 長期間の動作
  2. トラフィックの増加
  3. IoT機器本来の業務の阻害
  4. ファームウェア自体の知的所有権保護
  5. IoTデバイス内のコンポーネント別アップデート
  6. アップデート適用の選択

 上述の要求条件の議論を通し、いくつかのソリューション技術の議論がなされた。そのいくつかを紹介すると、まず登場するのが暗号技術の活用についてである。ソフトウェア自体に含まれる知的財産権を保護し、また、正しい送信者から正しい受信者にデータを送るためにデジタル署名をすることが必要との議論がなされている。そのために、共通のFirmware package formatがあるとよいのではないかとの議論もあり、RFC 4108(Using Cryptographic Message Syntax(CMS)to Protect Firmware Packages)をベースに検討するのが良いとの提案があった。

RFC 4108記載のHardware Module構成図。後述のSUITでは、このアーキテクチャをベースに検討する

 また、暗号技術はソフトウェアアップデートの悪用対策という観点でも重要である。ソフトウェアアップデートが悪性コードに置き換えられるリスクがあるため、暗号技術を利用することによりこれを防ぐ必要があるというものだ。アップデート発行者の認証と、通信の暗号化が必要であり、既存の各種暗号方式の長所・短所についても議論が展開されている。

 また、満たすべきセキュリティ/対応できるセキュリティは、それぞれのIoT機器や状況により異なるとの認識に立った議論もなされている。1つの提案として、満たすべきセキュリティのレベルをprofileというかたちで分けて定義することが提案された。また、Bootstrap roaderが、ソフトウエア(ファームウェアを含む)のサイズとメモリサイズを計算し、それに従い4種類のパッケージから1つを選択し、アップデートを実施するなどというアイデアも提案されている。

 ソフトウェアモジュールのライフタイムという視点に立った提案もなされている。その1つが、ソフトウェアコンポーネントが従うべきポリシーの提案だ。本ポリシーを開発の初期の段階で設定し、そのコンポーネントのライフタイム全体にわたり、ポリシーに従っていることをチェックできるフレームワークが示された。

 これらの議論でIoT機器のソフトウェアアップデートが、さまざまな視点にて本課題に対する対応策が検討されている現状が見て取れるかと思う。実際に、IETF 100では、より議論を加速するべく、新たにSUIT(Software Updates for Internet of Things)というBoFを開催する予定である。正式にWGとなるかどうかはIETF 100での結果次第であるが、ここでの議論が将来の礎になることは間違いないだろう。

 以上、IoTに関わる動向を広く浅く紹介したが、注目するべきは、プロトコルにせよセキュリティにせよ他団体の動向を考慮しつつ、すなわち広く柔軟な視点で、IETFで培ったものをいかに最大限に利用するか、という方向で議論が進められているのではないかと考える。

最後に

 ここまで本連載「進化するインターネット技術/IETFトピックス2016-17」では、11月11日~17日に開催のIETF 100(シンガポール)に向け、近年のIETFでの活動状況について、日ごろIETFを中心に活動を行っているISOC-JP(Internet Society Japan chapter)メンバー有志による紹介を行ってきた。

 本連載を続けている間にも、新たな提案や活発な議論が続いているのであるが、一方で日本からの参加・貢献を見ていると、以下のグラフの通り、日本からの参加人数が減少傾向にあるのが現状である。昨今の状況では、会合に参加するには諸事情で容易ではなく、特に新規参加者にとってはハードルは高いと考えられがちではあるが、ISOC-JPにおいては、あらゆる角度でこのハードルを下げ、関心を高める活動を微力ながら続けている。

 本連載並びにISOC-JP主催のイベントなどを通して、将来のインターネット技術そしてIETFへの関心を深めていただければ幸いである。

9月1日に開催された「IETF報告会(99thプラハ)」での米谷嘉朗氏の発表資料より

「IETF報告会(100thシンガポール)」12月15日に開催

ISOC-JPでは、IETF 100の参加者による報告会を12月15日(金)14時30分より、エッサム神田ホール(東京都千代田区)で開催予定です。参加登録および詳細については、下記ページをご参照ください。