にたまご。

よく寝てよく食べる

IETF101の注目WG/BoFはデータセンター、セキュリティ、5G関連？

IETF

3/17-3/23にかけてIETF101会合がロンドンで開催されます。その中でもできたばかり or 今回始めてミーティングを開催する注目のトピックが以下になります。

IETF101のみどころ

DC関連
今回はデータセンター(以下DC), ルーティング周りがアツいようです。昨今のDCは、単一のネットワークに対して数万以上のエンドポイントを持つほどに成長し、トポロジーやトラフィックパターン、迅速な復旧の必要性等の特徴故、DCネットワークには独自の要件がある場合が多いです。上記のような大規模データセンターでのトポロジー、トラフィックパターン、管理性のニーズに対応するプロトコルの策定が新たにIETFの仲間入りをします。

  • ILA(Locator Addressing) BoF: 数十億のノードにまで成長したDCネットワークでは、既存のインフラと相互運用可能なデータセンター、仮想化、モビリティのシナリオにおける、ネットワークオーバーレイの必要性が求められている背景がああります。ILAはカプセル化せずに透過的なオーバーレイネットワークを実現するためのプロトコルを策定します。
  • RIFT( Rounting In Fat Trees) BoF: 上記のようなDCネットワークの集中化に伴い、ディスタンスベクター型とリンクステート型の2種類のダイナミックルーティングプロトコルを用いて、Clos and Fat-Treeネットワークトポロジーにおけるルーティング要求に対処します。Juniper, Comcastが提案中。
  • LSVR(Link State Vector Routing) BoF: リンクステート型とパスベクター型の2つのルーティングメカニズムを用いたハイブリッドルーティングプロトコルを開発し、文書化します。Arrcus, Linkedin, Cisco, Nokia等複数企業が提案中。

RIFTやLSVRについては詳しくは、IETF100報告会で発表者の方のスライドをぜひ！

セキュリティ関連

  • MLS(Messaging Layer Security) BoF: グループメッセージアプリケーション(MessengerとかWhatsAppとか？)における暗号鍵確立のためのセキュリティプロトコルを標準化します。
  • SUIT(Software Update for Internet of Things) WG: IoTデバイスの安全な定期的なファームウェアのアップデートに焦点当てます。SUITに関しても、IETF100報告会で発表者の方のこの資料がわかりやすい！
  • TEEP(Trusted Execution Environment Provisioning) BoF: 同じくIoTのソフトウェアアップデートをシナリオとするTEEPでは、初回のインストール(boot後のアプリ)に焦点当てます。TEEPは毎回BoFやっててなかなかWGにならない印象。。。

5G関連

  • COMS(Common Operations and Management on Network Slices) BoF: 5Gでは、低遅延・強いセキュリティ等、異なる要件に対して、ネットワークを仮想的に分けることで、顧客が提供するサービスの要件に合ったネットワーク環境を提供することができる、ネットワークスライシングという技術があります。COMSでは、このネットワークスライスを配送するアーキテクチャや情報モデルの検討を行います。
  • EMU(EAP Method Update) WG: Wi-Fiの802.1xを用いたアクセスコントロールに広く使われているのがEAPプロトコル(Extensible Authentication Protocol)です。EMU WGは、TLS1.3と5G環境へのデプロイを背景に、必要なEAPの拡張を策定していく予定です。また、このWGの特徴の1つとして、TLS WGや3GPP、EAPの開発コミュニティ等、外部組織や他WGと積極的に連携しながら標準化を進めていくことが挙げられます。

リモートで参加したい

IETFは普段はメーリングリスト(+ WGによってはGithub)ベースで議論が行われ、年3回のオンサイトミーティングがありますが、リモート参加に対するサポートも手厚いです。

「歩くI-Dアナウンス」こと@flano_yukiさんによる、IETFリモート参加のTipsが公開されているので参考に！
qiita.com

おまけ: 今までの議論を追いたい人

◯◯の部分を好きなWGの略語(e.g. quic, capport, httpbis)を入れてください

  1. 気になるWGを決める。=>WGページヘGO: https://datatracker.ietf.org/wg/◯◯/about/
  2. その中でも気になるトピックの関連ドキュメント(Internet Draft)を見つけて斜め読み。
  • 最新の会合の議論を見る。
  1. 会合の様子はYouTubeで見れます。「IETF100 ◯◯WG」とか検索すると出てくるかと思います。(動画の字幕をONにすると純ジャパにも嬉しい。)
  2. 手元にはMinitesを置くとわかりやすいかも？「https://datatracker.ietf.org/meeting/100/session/◯◯」のページにMinites(議事録)があります。

302リダイレクトを使わずにCaptive Portalの認証ページへユーザーを誘導できる？RFC7710

capport IETF

CAPPORT WGでは現在RFC7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs)の改変が行われそうな雰囲気なので、RFC7710について一旦このへんでまとめておく。

背景

現在のCaptive Portalはユーザーのセッションを横取りし、302リダイレクトを用いて強制的にユーザーを認証/同意ページに誘導する、いわば中間者攻撃のような挙動をとるものがほとんどです。この挙動がCaptive PortalにおいてUXを損なっているという背景から、認証/同意ポータルページへ誘導する別の手段が必要とされています。

The Captive-Portal Option

ユーザーのデバイスに「Captive Portalの存在」と「ポータルにコンタクトをとる方法」を知らせるために、DHCPオプションやRAの拡張を用いて、Captive PortalのURIをユーザーのデバイスに広告する方法が挙げられています。いずれも基本的にはCode, Length, URIを含む構成となります。(今のところ、URIは実際にユーザーがアクセスすることとなるポータルのURI、またはCAPPORT APIのURIということになっています。)

f:id:ao0780:20180303163613p:plain

f:id:ao0780:20180303163605p:plain

  • IPv6 RA option: Type 37。このType code37は、RFC7710のためにIANAがアサインしてくれたものです。

f:id:ao0780:20180303163609p:plain

まとめ:

RFC7710は、DHCP/RAのオプションを用いて、デバイスにIPアドレスを割り振る際に、同時にCaptive PortalのURIも配ってしまおうというものです。それにより、以下を実現できます。

  • ユーザーとCaptive Portal間の手続きの簡素化
  • ハイジャックに代わる、よりクリーンな方法の提供(=セキュリティ向上にもなる?)

関連の最新の議論:

  • CAPPORT WGでは他にも、ユーザーとCaptive Portal間の認証情報の手続きを自動化する、CAPPORT APIが策定されており、RFC7710で配るURIはそもそもAPIサーバーのURIなのか、またはポータルページのURIと定義すべきか？
  • “there’s no captive portal to talk to”というシグナルを送る機構が必要

等複数議題が上がっており、本RFCのアップデートも含め、IETF101では議論されそうです。

DNS Queries over HTTPSとネット中立性

IETF インターネットガバナンス

インターネットの標準化を推進する任意団体IETF(Internet Engineering Task Force)では、昨年11月のIETF100にてDOH(DNS over HTTPS) WGの初回ミーティングが開催されました。来たるIETF101@ロンドンでは、２回目となるミーティングが開催予定です。WGで現在議論されているのがdraft-ietf-doh-dns-over-https-03 - DNS Queries over HTTPSDNS Queries over HTTPSです。

DNS Queries over HTTPSの技術面での記事やプレスはたくさんあるのですが、ちょっと違う視点から書いてる海外のおもしろい記事があったので、ネット中立性視点から日本語で補足&まとめてみます。

元記事はこちら：IETF protects privacy and helps net neutrality with DNS over HTTPS • The Register

ネット中立性ってなに

主にアメリカで話題になっている問題ですが、簡単に説明すると「インターネット上のコンテンツやアプリケーション、Webサービス、トラフィック等を、ISP(インターネットサービスプロバイダ)が公正に扱う」ことです。ネット中立性の原理に反する例としては、通信事業者やISPが、特定のコンテンツを優先して配信したり、料金や通信速度で優遇するケースです。身近な例だと、LINEモバイルのコミュニケーションフリープラン(特定のSNSが使い放題。データ通信の上限に含まれない)がこれに当たるかもしれません。アメリカでは、オバマ大統領時代にネット中立性に関する規制が設けられましたが、その後大統領・FCCチェアが変わり、昨年の2017年12月に規制が撤廃され、大きな話題になりました。

(ネット中立性に関しては、バーガーキングのこの動画がわかりやすい↓)
gigazine.net

ISPによるDNS操作が一般化しつつある？

IETF99では、RIPE Atlasを用いたDNSハイジャックの検知に関する発表がありました。例えば、Google DNSのハイジャックの割合を調べると、中国やロシア、その他発展途上国にハイジャックの傾向が目立ちます。これは必ずしも政府による検閲や、ISPによるネット中立性侵害が目的とは限らず、各ISPが独自のポリシーを定めている可能性もあります。しかし、ISPによるDNSの操作が一般化しつつあり、プライバシー面での対策が求められていることは間違いありません。

また、過去には、米VerizonがDNS lookupを失敗した顧客を自社の検索サイトに誘導した上で、顧客が検索失敗した単語に紐づいた広告を出していたため、当時のVerizonのDNSポリシーがネット中立性違反なのではないか、と物議を醸しました(*1, *2参考)。

DNS Queries over HTTPSとは

DNSクエリの通信は暗号化されていないため、なりすましや盗聴等セキュリティ・プライバシーの面で課題があります。例えば、公衆無線LAN環境のようなオープンなネットワークにて、DNSの通信が偽装され、想定外のDNSサーバーへ誘導される場合や、経路の途中で機器によりDNSメッセージの書き換えが起こる場合があります。

そこで、HTTPSをDNSクエリの通信に用いることで、DNSクライアント間の完全性と機密性を提供するメカニズムを開発し、安全な通信を確立しようというのがDNS Queries over HTTPSモチベーションです。

例えば、ユーザーのデバイスがGoogleのPublic DNSである8.8.8.8をDNSリゾルバとして使用する際、そのデバイスはDNSクエリをHTTPSを介して投げることができ、これがend-to-endの暗号化に繋がります。

https://i2.wp.com/respectfulinsolence.com/wp-content/uploads/2016/12/homer-computer-doh.jpg?ssl=1

DOHとネット中立性の関連性は？

このDNS Queries over HTTPSを使えば、インターネットのトラフィックに対して、DNSを用いて何らかのポリシーを課すようなネットワーク(または上記を強いるような政府、ISP)を撃退することの助けになるそうです。

単純にDNSの応答の正当性を担保するのであれば、DNSSECがありますが、DNSSEC自体はISP側でダウングレードすることができてしまいます。そこで用いるのが、ISPの操作の影響を受ける心配がないHTTPSによるend-to-endの暗号化です(=DNS Queries over HTTPS)。

まだ仕様は確定していませんが、DOHクライアントは、ユーザーが検索に失敗した原因を知らせるエラーメッセージを表示したり、クライアントが「通常の」リゾルバにフォールバックすると、何が起こったのかエラーメッセージを表示する等、ユーザーに通知する機能を持つそうです。よって、プロバイダ側からDNSの通信に何らかの操作が行われた際、ユーザーはそれを知ることができます。また、ISPがDNSを用いて差別したいソースを識別している場合、この識別行為は暗号化によりできなくなります。(*実際はDNS lookupがユーザーの識別に不正に使われるのを防いでくれる)

まとめ

DNS Queries over HTTPSは、DNSを用いてネットワークに何らかのポリシー操作を行うような行為を防ぐという意味で、ネット中立性を担保するための技術としても期待されているみたいです。

補足:

Coova Chilli 1.4のインストール方法

capport

Coova Chilli公式のインストール手順を書き残しておく。

Coova Chilliって何

IETFのcapport WGやhackathonでアクティブにrunning codeしている、GoogleのDavid Birdを中心として開発されているOSSのCaptive Portal(Wi-Fiのアクセスコントロール)ソフトウェア。capport WGにおけるInteroperabilityテストもこのOSSベースで試されることが多いです。
 
とはいえ、これだけではCaptive Portalシステムは構築できません。isc-dhcp-serverやRadius、haserl等と組み合わせるとLinux上で構築できます。そのあたりは下記の方々がわかりやすく書いてくださっていると思うので参考にしてください。自分の記事はCoova Chilliのインストール部分のみ触れます。

 

Coova Chilli 1.4(最新版)インストール手順

実行環境:

Raspbian Stretch Lite 4.9 on Raspberry Pi3 

手順:

coova-chilli-1.4をwgetで持ってきて解凍。

$ cd /home/pi
$ sudo wget https://github.com/coova/coova-chilli/archive/1.4.tar.gz
$ tar zxfzf coova-chilli-1.4.tar.gz

buildする

$ cd coova-chilli-1.4
$ ./bootstrap #bootstrap scriptを走らせる 
$ ./configure --help #コマンドにつけるオプションが見れます。加えたい項目があれば、./configure以降に加えてコマンドとして実行。
$ ./configure --enable--miniportal --prefix=/tmp/foo #--prefix=/X/Xでcoova-chilliをインストールする場所を指定できます。--prefix=/tmp/fooにするとrebootすると消えてしまうので、私は何も指定せずに./configure --enable-miniportalだけで実行しました。その場合/usr/local/etc以下にchilliができます。
$ make #buildする
$ make install
$ cd www #終わったらwwwディレクトリも
$ make install

参考:

公式のインストールガイド

このあたりとかが動画つきでわかりやすいと思います。


(俺の考えたさいきょうのCaptive Portal構築の一連のログを残したい気持ちはあるのですが、それは大学が春休みになって余裕ができたら書きたいと思います...)

DHCP option43を使ってAPをWLCにJoinさせる

Wi-Fi NWオペレーション

本記事は下記のアドカレ記事として執筆しています。

SFC-RG Advent Calendar 2017 - Qiita

経験上、本話題は英語での記事はヒットするものも、実際に動いた実績のある設定例が、公式以外で日本語で公開されているケースをあまり見ないなーと思ったので書き残しておきます。

----------------------------------

 　たくさんのアクセスポイント(AP)を集中管理できるのがワイヤレスコントローラー(WLC)ですが、初期状態ではAPは自分たちがどのWLCへ帰属(Join)して良いのかわかりません。そこで、まずAPがWLCを検出できるようにしてあげる必要があります。

　Cisco WLCでは、APをWLCにJoinさせるための設定方法がいくつかありますが、そのうち個人的に最も理解がしやすい/手間がかからないと思われるLinux DHCPサーバーにoption43の設定を書く方法を紹介したいと思います。(他にもスイッチでのoption43設定、Cisco ISC DHCPサーバーでの設定等があります)

DHCP option43とは

　DHCP option43はベンター固有オプションです。これを利用することで、APにWLCの管理インターフェースのIPアドレスを教えることができます。この設定はスイッチに入れることもできますが、今回はLinuxのDHCPサーバーで行う場合の設定方法を紹介します。 

前提

  • DHCPサーバの構築が完了している
  • WLCの初期設定、Interfaceの追加、WLANの追加設定が完了している

実際の設定例

　DHPCサーバー内の/etc/dhcpd.confの該当カラム(自分の環境ではAP-WLC間のマネジメントセグメントであるwireless-mgmtのVLAN)のカラム内に書きます。

*ただし１つのDHCP poolを１種類のAPにだけ割り当てることが可能なため、APの種類が増えた際は、異なるDHCP poolを設定する必要がある。

 

#wireless-mamt
#vlan XXXX
option space Cisco_LWAPP_AP;
option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
subnet X.X.X.X netmask X.X.X.X {  #wireless manegement内のWLCのアドレスとネットマスク
   pool { 
         
         省略
         
         vendor-option-space Cisco_LWAPP_AP;
         option Cisco_LWAPP_AP.server-address X.X.X.X; #managementネットワーク内のwlcのアドレス＝ポータルでアクセスするときのアドレスです
  }
}

 

　これで終わりです。WLC側でこのDHCPサーバーのアドレスを明示的に指定しておけば、APをPoEスイッチに接続すると、DHCP経由でAPにWLCのアドレスがアドバタイズされ、APがWLCを検出できるようになります。

 

＊注意点としては、DHCPサーバーがあらかじめ構築されていないと本設定は動かないため、あらかじめサーバーを構築しておきましょう！

 

 

 

 

cisco WLCでのLaunch failure時のRecovery方法

Wi-Fi NWオペレーション

WLC初期セットアップ時にLaunch failureした時の対応

事象

通常WLCは、電源を入れコンソールケーブルを接続するとCLIで対話型の初期セットアッププロセスが開始する。しかし、WLCのプライマリ・セカンダリパーティションに有効なイメージがない場合、またはRTOSが壊れている場合、下記のような「boot loader menuメニュー」が出てきて、1-4番を選択してもその命令が実行されず、永遠にboot loader menuが繰り返し出てきてしまう。結果、いつまでたっても初期設定の対話画面にたどり着けない。

 

上記の状態になってしまうと、boot loader menuの6番を選ぶ以外手段がない。ということで6番を選択した際のプロセスを紹介する。

 

実際のlaunch failure時の画面 

---------------------------------------------------

Verifying boot loader integrity... OK.

[ ... ]

Press ESC now to access the Boot Menu...

 

Hit the Escape key now

 

============================================================
 Boot Loader Menu
============================================================
 1. Run primary image (Image not found) - Active
 2. Run backup image (Image not found)

  1. Change active boot image
     4. Clear configuration
     5. Format FLASH Drive
     6. Manually update images
    ------------------------------------------------------------
    Enter selection: 4       
    Launching...

  Unable to read "linux.pri.img" from ide 0:2

  Launch Failure

  Loading backup image(Image not found)

  Unable to read "linux.pri.img" from ide 0:2

  Launch Failure

Verifying boot loader integrity... OK.

[ ... ]

Press ESC now to access the Boot Menu...

 

Hit the Escape key now

 

============================================================
 Boot Loader Menu
============================================================
 1. Run primary image (Image not found) - Active
 2. Run backup image (Image not found)

  1. Change active boot image
     4. Clear configuration
     5. Format FLASH Drive
     6. Manually update images
    ------------------------------------------------------------
    Enter selection: 

 

(以下上記プロセスがループ)
  

上記のような事象にあった場合は、

  • ciscoサポートに問い合わせRTOS(+上げたいバージョンのファームウェア)をいただく
  • boot loader menuで6番を選び、手順に従いTFTP経由でWLCにRTOSを転送する

 の2つの手順が必要である。

 

事前準備

  • ciscoサポートに問い合わせRTOS(+上げたいバージョンのファームウェア)をダウンロードする。
  • 今回はMacをTFTPサーバーとし、tftp用ディレクトリにRTOSのイメージファイルを設置。Mac bookとWLCをUTPケーブル1本で繋げる。

 

tftpサーバーの起動

sudo launchtl load -w /System/Library/LaunchDaemons/thtp.plist

以下のように/private/tftpboot/以下にRTOSのイメージ(AS~~がRTOSイメージ名)を置く。 

/private/tftpboot/AS_5500_RTOS-7.0.250.0

 

WLCでのコンソール(CLI)操作

今回自分が組んだ構成。

f:id:ao0780:20171105021148p:plain

 

WLCにコンソールで接続する。以下が入力例。(太字部分)

 

Verifying boot loader integrity... OK.

[ ... ]

Press ESC now to access the Boot Menu...

Hit the Escape key now

============================================================
 Boot Loader Menu
============================================================
 1. Run primary image (Image not found) - Active
 2. Run backup image (Image not found)

  1. Change active boot image
     4. Clear configuration
     5. Format FLASH Drive
     6. Manually update images
    ------------------------------------------------------------
    Enter selection: 6       
    Launching...
    Launching images...
    init started: BusyBox v1.6.0 (2009-02-03 04:56:32 EST) multi-call binary
    Mount failed for selinuxfs on /selinux:  No such file or directory
    starting pid 655, tty '': '/etc/init.d/rcS'
    Use DHCP for ip configuration (Y/n)? n
    Enter switch IP address: 192.168.1.100

  By "switch", the boot loader means WLC
Enter switch netmask: 255.255.255.0
Enter switch gateway: 192.168.1.1
Enter TFTP server IP address: 192.168.1.157
You have entered:
     IP Address     : 192.168.1.100  #WLCのアドレスを設定。なんでもいい。
     Netmask        : 255.255.255.0  #↑のサブネットマスク
     Gateway        : 192.168.1.1      #↑のデフォルトゲートウェイ
     Server Ip Addr : 192.168.1.157  #TFTPサーバー(Mac)のアドレス(WLCのアドレスと同じセグメントであるべき)


Is this correct(y/N)? y
!!! WARNING updating using .aes or unapproved files will disable this unit !!!
Do you want to update RTOS (y/N)? y
Do you want to update Primary Or Secondary Image (P/s)? P
Enter filename for RTOS update: AS_5500_RTOS-7.0.250.0
RTOS update Done ←これが出れば成功。失敗するとCould not Transferingみたいなエラーが出てLaunchできない。
Enter filename for FP update: AS_5500_cavium_main-7.0.250.0

  Depending on your WLC model / boot loader version, you may not be prompted for FP update
FP update Done
Do you want to update an AP image (y/N)? N
AP Images Not Updated
Done.  Restarting...
Restarting system.

 

ここまでくると、あとは再起動しプロセスが終わり次第、コンソールから初期設定ができるようになる。

 

後処理

tftpサーバーは使い終わったらkillする。設置した当該ファイルも削除する。

sudo lsof -i:69
rm /private/tftpboot/AS_5500_RTOS-7.0.250.0 

 

参考: 

- Cisco WLC 2504 fails to boot - Cisco Support Community

- mac osx には tftp サーバーが内蔵されてるので起動してみた - それマグで！

 

インターネットシャットダウン/中国インターネット安全法

インターネットガバナンス

インターネットシャットダウンとは

- (政治的な背景から)意図的に通信の中断が行われ、情報が遮断されることです。政権に対する世論操作・選挙の際のイメージ操作などのためにソーシャルメディアのサイト、モバイルアプリケーションの通信が制御・遮断されることがあるのです。中国のネット検閲などがわかりやすい例かと思いますが、 (中国の検閲とインターネットシャットダウンはちょっと別枠の議論のようです。)

このインターネットシャットダウンが近年増加しており、2016年の国連人権理事会でもその人権侵害が強く非難されました。通信や特定のアプリケーションの利用に遮断・制限があった場合、具体的には下記のような影響があります。

  • インターネットを利用するビジネス対する阻害
  • 離れた家族・友人と連絡がとれなくなる
  • インターネット上ので金銭取引に対する阻害

ISOC(Internet Society)からも声明が出ており、最近注目されているトピックとして考えていいと思います。

Let's Keep The Internet On For Everyone | Internet Society

 

アフリカ地域で増加するインターネットシャットダウン

2016年に観測されたインターネットシャットダウンの数は56だったそうですが、そのうちの大部分はアフリカ地域が占めていたと言われており、AFRINIC(アフリカ地域を管轄する地域インターネットレジストリ (RIR))が6/2に声明を出しています。

AFRINICはこの声明が根本的な解決になるとは思っておらず、場合によってはこの声明による状況の悪化も危ぶまれるとしていますが、政策手段としての「インターネットシャットダウン」を放棄するよう呼びかけ、政府に対しステークホルダーとの対話を求めています。


(おまけ)中国のインターネット安全法

6/1に中国政府が出したインターネット上での言論の統制を強化する「インターネット安全法(サイバーセキュリティ法)」があります。もともと中国でFacebookをはじめとする各種SNSの利用が制限されているのは有名は話ですが、これに対し中国人は有料のVPNサービスを利用することで検閲から逃れ、Facebookなどを利用していることが多いです。しかし、このVPNの利用規制が今年の1月に発表され、引き続き6/1にインターネット安全法が施行されました。この場合の「安全」はあくまで中国政府にとっての安全でしかないのですが、この法律により、インターネットのオペレーターは政府からの要請があれば技術的な協力やインターネットの利用者に関する個人の情報を提供する必要があります。

 

このブログ投稿当時はインターネットシャットダウンと中国のネット検閲問題を同枠で説明してしまいましたが、

  • インターネットシャットダウン - 人権的な問題として注目
    (アフリカ・インドあたりで議論されることが多い気がします)
  • 中国のインターネット安全法・検閲 - 経済的な注目を浴びている
    (先進国視点から、中国市場への参入・事業展開を阻む観点から)

といった別の文脈で議論されることが多いそうでした。

 

参考: 

中国が主張する「サイバー主権」って？ 言論統制強化へ「セキュリティー法」施行（1/2ページ） - 産経ニュース

中国、ビッグデータ統制 持ち出し規制の新法施行 ：日本経済新聞