9/30/2014

auひかり、IPv6化完了

auひかりのマンションタイプもIPv6化完了したようだ。OS XやiOSだと、Privacy Extensionが有効になっているので、2つのIPv6アドレスが付いているのが分かる。OS Xで無効化する場合は下記のとおり。

sudo sysctl -w net.inet6.ip6.use_tempaddr=0
sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf'

その他のパラメータは、

パラメータ デフォルト 内容
net.inet6.ip6.temppltime 86400 一時アドレスの有効時間(1日)
net.inet6.ip6.tempvltime 604800 一時アドレスの最大有効時間(1週間)
net.inet6.prefer_tempaddr 1 一時アドレスを優先使用(1=yes)

9/28/2014

iOS 8のMACアドレスのランダム化機能

iOS 8ではプライバシー対策機能として、Wi-FiのMACアドレスのランダム化機能が取り入れられているとWWDC 2014で公表されていた。9to5Macが、AirTight Networksがその機能について検証し、レポートを上げている件を伝えている(1部2部)。

まず、MACアドレスのランダム化機能はベータ段階では実装されておらず、正式リリースで利用可能になった機能だとしている。調査にあたり、2.4GHz(Ch 11)と5GHz(Ch 116)へのプローブ要求をキャプチャして、動作を検証した結果次の事が分かったそうだ。

  • AppleはiOS 8が動作する全モデルで使えると謳っているが、検証した中ではiPhone 5やiPad miniは動作せず、iPhone 5sが動作した
  • MACのランダム化が起こるのは次の条件が必要になる
    • iPhoneがスリープモードに入る(ディスプレイがオフになるだけでは使われない)
    • Wi-Fiはオンでなければならない
    • 位置情報サービスはオフにしなければならない
  • 上記条件の下で、次の特徴を持つプローブ要求でランダム化MACを使用する
    • ランダムMACはローカルに管理されたMAC
    • iPhoneがスクリーンロックし、120〜150秒で最初のランダム化MACのプローブ要求が送出される
    • 同じランダム化MACが全チャンネル、2.4GHz/5GHzバンドで使われる
    • 次のプローブ要求の処理間隔は大きくなり、最大385秒になり、その次は再度最初のように120-150秒になる。トレースの継続時間は1時間。
    • これらのプローブ要求は全て同じランダム化MACアドレスが使われる
    • プローブ要求で使われるランダム化MACアドレスはスリープモードから動作モードに入る度に変わる
    • スリープモード中のプローブ要求はSSIDを付けて送らない(Nullプローブ)。
    • MACのランダム化はiPhoneが充電中かそうではないかは関係無く動く

検証の際には、SIMカードを挿入していなかったが、SIMカードを挿入すると、突然ランダムMACアドレスが生成されなくなったそうだ。そして、モバイルデータ通信をオフにすると(位置情報サービスもオフ)、ランダムMACアドレスが現れたという。

MACアドレスのランダム化機能は、位置情報サービスとモバイルデータ通信を切った状態でなければ機能しないので、ほとんどの人はこの機能が使われていないことになる。彼らはこれを「iOS 8 MACランダムゲート」と呼んでいる。シュナイアーは名案と書いていたのだが...

9/27/2014

ブラックホールは存在しない?

Slashdotによると、ノースカロライナ大学のローラ・メルシニ=ホートン教授が、ブラックホールが存在しなことを数学的に証明したと発表している。巨大な星が寿命を迎えて自重で崩壊し、ブラックホールが形成されるというのが一般的な説だが、彼女の主張は星が崩壊する際に起きると予想されているホーキング輻射が起こる際に、ブラックホールを形成するのに必要な密度にならないほど質量も放出してしまって、特異点や事象の地平線は決して形成されないとのことだ。まだ、査読を受けていないarXiv段階の論文で、Physics Letter Bに投稿中。

そういえば、彼女はあるサイエンス番組でWMAPのコールドスポットが平行宇宙の痕跡とする説を唱えていたような...。ユニークな仮説を唱える人なのかも。

iOS 8.0に登録されている認証局

Karl Kornel氏がiOS 8.0に登録されている認証局を分析している(Hacker News)。222の認証局が登録されており(HT5012)、署名アルゴリズムにMD2やMD5を使ったものがあるらしい。OS Xに入っているが、日本政府が運用しているGPKILGPKIの認証局も登録されている。iOSは、OS Xキーチェーンのように認証局を無効化できないので、Appleを信用するしかない、という点が気になる。

9/25/2014

Bashに深刻な脆弱性

Stephane Chazelas氏が、GNU Bashに環境変数の処理に問題があり、外部から任意のコードを実行させることができる深刻な脆弱性(CVE-2014-6271)を見付けたそうだ。CGI、SSH、Telnetなどを通じてシェルやスクリプトを実行させる環境を持っていれば、注意が必要である。脆弱性は1.14から4.3までのバージョンに存在し、既にパッチは公開されている。下記スクリプトで脆弱性の有無をチェックできる(脆弱性のあるbashは、"echo vulnerable" が実行されてしまう)。詳細は、Red Hatのレポートを参照。

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

更新(2014.09.26)

リリースされた修正は不完全で、Travis Ormandy氏によって別の攻撃法が見付かり(CVE-2014-7169)、今のところパッチは無い。取り敢えずの対処方法としては、

  • WAF/IDSがあれば、文字列"(){"の入ったリクエストを遮断する
  • デフォルトのシェルをshやkshなど脆弱性の無いものに置き換える(スクリプトが動くかチェック要)
  • 組み込み系ではbusyboxを利用

リンク

新しいCVEの番号体型

2014年から、CVEの番号体型を新しいものに変えていたそうだ(Mitre, JPCERT)。脆弱性が年に1万件を超える可能性ができてきたため、4桁を基本に必要な数だけ増やすことが可能というもの。CVE-YYYY-NNNNからCVE-YYYY-NNNN...Nとなる。

Cve ids

9/18/2014

iOS 8がリリース

iOS 8がリリースされた。国内だけでも、一千万台はあると思われるiOSデバイスが、1台あたり1〜2GBのファイルイメージをダウンロードするのだから、インターネット全体のトラフィック量を2割ほど押し上げるというのも分かる。Appleは、これまでAkamai、Level 3などのCDNを利用してきたが、Apple自身のCDNを準備したという噂があった。iOS 8の配信はどうだったかというと、Apple自身のCDNからも配信された模様だ。

PeeringDBでAppleの情報を見ると、日本国内の主要IX (JPNAP、JPIX、EQUINIX)に接続しており、東京のデータセンタ2カ所に拠点を設置していることが分かる。そして、swcdn.apple.comdigってみると、下記のように表示される(auひかり)。

;; ANSWER SECTION:
swcdn.apple.com.	20862	IN	CNAME	swcdn.apple.com.akadns.net.
swcdn.apple.com.akadns.net. 105	IN	CNAME	jptyo2.cdn-apple.com.akadns.net.
jptyo2.cdn-apple.com.akadns.net. 5 IN	CNAME	geo.buni.guat.aaplimg.com.
geo.buni.guat.aaplimg.com. 2	IN	A	17.253.64.225
geo.buni.guat.aaplimg.com. 2	IN	A	17.253.64.223

geo.buni.guat.aaplimg.comというのが、IPアドレスからしてApple自身のものだ。このアドレスにtracerouteをすると、国外 (香港?)に抜けて行く。AkamaiにCNAMEが向けられているのは、トラフィックの動向に応じて、Akamaiに切り替えられるようになっているのだろう。この国外にあるサーバからのダウンロードは非常に遅いので、これを捕まえてしまうと時間が掛かり、Akamai CDNが捕まえられれば速くダウンロードできるという事だろう(10分以内で終わる)。

更新 (2014.09.18 16:37)

今確認すると、swcdn.apple.comは全面的にアカマイに切り替わっている。トラフィックと合わせて類推すると、Apple CDNから配信されていたのは、02:00〜07:00のようだ。その後、アカマイに切り替わった。そもそも設定が間違っていたのか、Apple CDNの実力を確認したかったのかは分からない。Apple CDNは米のみで開始、他国はサードパーティCDNを使うという事なのだろう。

;; ANSWER SECTION:
swcdn.apple.com.	1923	IN	CNAME	swcdn.apple.com.akadns.net.
swcdn.apple.com.akadns.net. 20	IN	CNAME	jptyo2.cdn-apple.com.akadns.net.
jptyo2.cdn-apple.com.akadns.net. 27 IN	CNAME	geo.buni.guat.aaplimg.com.
geo.buni.guat.aaplimg.com. 28	IN	CNAME	ios8-apac-lb.apple.com.akadns.net.
ios8-apac-lb.apple.com.akadns.net. 265 IN CNAME	appldnld2.apple.com.edgesuite.net.
appldnld2.apple.com.edgesuite.net. 9298	IN CNAME appldnld2.apple.com.edgesuite.net.globalredir.akadns.net.
appldnld2.apple.com.edgesuite.net.globalredir.akadns.net. 265 IN CNAME a1271.gi3.akamai.net.
a1271.gi3.akamai.net.	14	IN	A	69.192.3.73
a1271.gi3.akamai.net.	14	IN	A	69.192.3.66
a1271.gi3.akamai.net.	14	IN	A	69.192.3.81
a1271.gi3.akamai.net.	14	IN	A	69.192.3.72
a1271.gi3.akamai.net.	14	IN	A	69.192.3.75
a1271.gi3.akamai.net.	14	IN	A	69.192.3.74
a1271.gi3.akamai.net.	14	IN	A	69.192.3.67
a1271.gi3.akamai.net.	14	IN	A	69.192.3.64
a1271.gi3.akamai.net.	14	IN	A	69.192.3.80

更新 (2014.09.19)

iOS 8のインストール数を予測しているサイトが軒並み、iOS 8の立ち上がりは遅いと指摘している。iOS 8のインストール条件が厳しい事(OTAの場合、ストレージに6〜7GBの空き容量が必要)が主な原因だが、Apple CDNの影響も少しはあるのではないかと思っている。

9/17/2014

スコットランドのccTLD

いよいよ明日(日本時間18日午後3時から午後10時まで)、スコットランドの独立の是非がを問う住民投票が実施される。NANOGのメーリングリストでは、スコットランドが独立した場合のccTLD (ISO国コード)は何になるのか、というのが話題になっていた。インターネットのccTLDは、ISO 3166-1 alpha-2をベースにしているが、ここにスコットランドは無い。「.sc」が一番良いのだろうが、セーシェル共和国(Seychelles)に割り当てられている。そして、「S」で始まる2文字はほとんどが埋まっていて、残りは「SP」,「SQ」,「SW」しか無い。古ラテン語でグレートブリテン島の北部を意味するカレドニアから「CE」という意見、スコットランド地方に住んでいた種族ピクトから「PC」あるいは「SP」という意見、gTLDにして「.scot」にするという意見も。

さて、スコットランドの住民は独立を選択するのだろうか?

9/15/2014

SELinux Coloring Book

私は、Red Hat/CentOSをインストールすると、面倒なのですぐにSELinuxを無効にしてしまう。SELinuxを無効せずに使えるようにしたいところだ。Red Hatが、SELinuxの概念を説明した「The SELinux Coloring Book」(PDF)という解説本を出していることを知ったので、まずはこころから始めよう。

Selinux comic book thumb

iPhone 6/6+の価格

3社からiPhone 6/6+の価格が出そろったので一括料金(分割総額)の一覧。キャリア販売のiPhone 6 Plusの64GBと128GBの価格差が小さい。

iPhone KDDI/au Softbank NTTドコモ Apple
iPhone 6 16GB 72,360 70,080 78,872 67,800
iPhone 6 64GB 85,320 83,280 86,832 79,800
iPhone 6 128GB 96,120 94,080 97,200 89,800
iPhone 6 Plus 16GB 85,320 83,280 86,832 79,800
iPhone 6 Plus 64GB 96,120 94,080 97,200 89,800
iPhone 6 Plus 128GB 99,360 99,360 99,792 99,800

9/11/2014

Apple Watchの時間? まさか!

今日の"Joy of Tech"は、Apple Watchが取り上げられている。「Time for Apple Watch? Never!」の超訳。

「ワオ! 見たかい? Appleの新しい...」
「聞くな!」
「腕時計は付けてないし、付けたいと思わない!」
「iWATCHとかその手の類いは全く興味ないんだ」
「そもそもダサイ、第一世代の、最悪のバッテリの過剰宣伝のテレビのリモコンみたいなものに大枚を使う必要があるなんてもっともやりたくないことだよ!」
「おまけに、まっとうに使えるようにするには新しいiPHONEを買わなきゃならない!」
「もういいよ。とんでもない! 絶対に買わない!」
それから4ヶ月後...
「ヤッホー、アハハハ」

Apple Special Eventのライブ中継の障害原因

iPhone 6とApple Watchの発表が行われた昨日のApple Special Eventは、インターネットを通じてライブ中継が行われたが、開始30分くらいは接続が途切れる(再接続がなかなかできない)、中国語などの同時通訳の音声が混入する不具合が起きていた。StreamingMediaBlogに障害の原因が掲載されている。

Appleがこのイベント用に作ったwebページ下部にツイートを表示させるために加えたJavaScriptコードの影響で、ページの更新が数ミリ秒ごとに行われるようになり、apple.comがAkamaiにキャッシュできなくなった。そのため、webページの更新やストリーミングのパフォーマンスの影響を与えることとなった。そして、Appleは直接webページにビデオを埋め込んだため、ライブ中継のビデオにも影響を与えた。リクエストはセンターに集中することとなり、接続障害となったというわけ。

他にもいくつか問題があったようだが、Appleが準備不足だったということになるのだろう。

9/10/2014

Named Data Networking (2)

続き。

データ中心のセキュリティ

NDNでは、どこで、あるいはどのように取り出されたかという働きよりも、セキュリティがデータ自身の中に組み込まれている。データの各要素はその名前と一緒に署名され、安全に結び付いている。データ署名は必須で、アプリケーションはセキュリティから手を引くことでできない。署名は、データプロデューサーの情報とデータの出所を明確にするもので、データへのコンシューマの信頼は、データをどのようにどこから取り出すかという事から切り離されている。コンテキスト中の詳細なデータ要素から、公開鍵の持ち主が条件にあったプロデューサーかどうかをコンシューマが判断できるきめ細かな信頼もサポートしている。

しかし、実際には、このきめ細かな、かつデータ中心のセキュリティアプローチは、技術革新を要求する。歴史的に、公開鍵暗号ベースのセキュリティは非効率的で、デプロイメントが難しく適さない。効率的なデジタル署名のみならず、NDNはユーザの信頼を管理するのにフレキシブルで便利なメカニズムが必要である。事前調査で、NDNがこれらのセキュリティ目標に到達するための有望な基盤を提供することを示している。重要な点はNDNデータとやり取りができて、鍵分散が単純でなけれならない。データ名の安全な結び付きは、信頼モデルの広い範囲への土台を提供する。例えば、もしデータ要素が公開鍵なら、結び付きは公開鍵証明が有効である。最後に、セキュリティに対するNDNのエンドツーエンドの取り組みは、プロデューサーとコンシューマ間の信頼を容易にすることである。これはプロデューサー、コンシューマ、そしてアプリケーションに信頼モデルを選択することとカスタマイズする多くの柔軟性を提供する。

NDNのデータ中心のセキュリティは、コンテンツアクセス制御やインフラのセキュリティを拡張する事ができる。アプリケーションは、暗号化されたNDNデータとして暗号化・分散化された鍵を使って、データへのアクセスを制御することができ、一つのアプリケーションのコンテキストへのデータセキュリティペリメータを制限する。ネットワークルーティングや制御メッセージ(その他のNDNデータ)の署名要求は、非常に求められるルーティングプロトコルの安全性を提供する。我々は効率的な署名、便利な信頼管理、ネットワークセキュリティ、コンテンツ保護やプライバシーを研究している。

ルーティングとフォワーディング

NDNは、名前でルーティングやパケットの転送を行い、IPアーキテクチャで困らせているアドレスに関する4つの問題(アドレス空間の枯渇、NAT通過問題、モビリティ、そしてアドレス管理) を取り除く。名前空間は無限なのでアドレス枯渇問題はない。ホストはコンテンツを提供するためのアドレスを見せる必要はないので、NATトラバーサル問題はない。IP環境ではアドレスが変わっていく事が要求されるモビリティは、データ名は変更しないので、通信が途切れることはない。最後に、アドレス割当や管理はローカルネットワークで要求されず、特に組み込みセンサーネットワークに向いている。

十分理解され、よくテストされたコアIPルーティングプロトコル、BGP、IS-ISやOSPFは、NDNネットワークでもルーティングプロトコルとしておおよそ現状のまま使う事ができる。IPプレフィックスを広報する代わりに、NDNルータはルータが担うデータを満たす名前プレフィックスを広報する。ルータは一連のオペーク(不透明)なコンポーネントとして単純に名前を処理し、FIBではなくパケットの中で成分ごとに名前のロンゲストプレフィックスマッチを実行する。しかし、無限の名前空間はルーティングテーブルサイズに対する制御維持の方法に疑問をもたらす。もう一つ重要な疑問は可変長で階層的な名前を検索することが、ライン速度で実行できるかどうかである。

NDNはルーティングセキュリティをとてもうまく改善できる。第一に、ルーティングメッセージを含む全てのデータが署名され、なりすましあるいは改ざんから防ぐことができる。第二に、ルータがプレフィックスハイジャックによって生じた異常を検知できるため、後で説明するインテリジェントなデータプレーンが持つマルチパスルーティングが、プレフィックスハイジャックを効率的に緩和でき、代替パスを通じてデータを取り戻すことができる。第三に、NDNメッセージがデータについてのみやり取りするという事実が、ホストへのアドレスではないので、特定の標的への不正パケットの送出を難しくする。NDNへの攻撃はサービス不能攻撃中心となり、それが我々が積極的に取り組むべき問題となる。

インテリジェント・データプレーン

NDNのデータプレーンでは、PITが全てのペンディング状態のインタレストと入力インタフェースを記録する。各PITエントリはデータパケットの期待値とパーミッションを示し、一致するデータを受信した、もしくはタイムアウトが起こったら削除される。このパケット毎の状態が、データプレーンがステートレスであるIPからの根本的な変更点である。この状態情報はNDNのデータプレーンがネットワーク障害を扱うのに適用でき、ネットワーク資源の活用に有効である。

第一に、PITと戻りデータ(あるいはタイムアウト)をベースに、NDNノードは異なるインタフェースのパケット配送性能や、もし何か起きた場合のパケットロスを監視できる。第二に、PITとインタレストパケットにある乱数ノンスをベースに、同じノードに戻るインタレストを簡単に識別して破棄できる。従って、インタレストパケットもデータパケットもループしない。データプレーンのフィードバックとループフリーダムがあるので、個々のNDNルータはサービス選択やロードバランスに適した複数インタフェースを介してインタレストを転送することをローカルに決定できる。そして、素早く問題を検知し、障害を迂回する代替パスを選択できる。我々は、どの特定のインタフェースか、インタレストを転送するのに使える通信可能なインタフェースがいくつあるか、許可すべき要求が満たされていないインタレストがいくつあるか、異なるインタレストの相対的優先順位などなど、インタレストを転送するための決定プロセス、フォワーディングストラテジーの研究開発を行っている。

個々のルータのPIT状態も他の重要な目的に役立つ。同じデータ名で到着したインタレストのインタフェースセットがあれば、マルチキャスト配送を自然にサポートする。各インタレストは一つのデータパケットを獲得するので、ルータはフローバランスを実施するのにペンディングしているインタレストの数を制御することでトラフィック負荷を制御できる。PIT状態もDDoS攻撃を効率的に緩和するのにも使う事ができる。PITエントリの数が、ルータ負荷を表すインジケータになるので、この数の上限はDDoS攻撃の影響を限度に設定する。PITエントリタイムアウトは比較的安直な攻撃検知を提供する(LADS参照)。そして、各PITエントリの到着インタフェース情報はプッシュバックスキームを実装する情報を与える。

キャッシング

ネットワーク内での自動キャッシングはネーミングデータによって可能となる。各NDNデータパケットが、どこから来て、どこに転送されるかとは分離しているので、ルータは今後の要求に応じるためコンテンツストアにキャッシュできる。新しいインタレストを受信すると、ルータはコンテンツストアを最初にチェックする。もし、インタレスト名に該当するデータがあれば、データが応答として送り返される。コンテンツストアの元となったものは、今日のルータのバッファメモリである。IPルータもNDNルータもデータパケットをバッファする。異なる点は、IPルータがデータを転送した後は再利用しないが、NDNルータはデータ名を確認してデータを再利用できる。静的ファイルなら、NDNは最適なデータ配送を行う。動的コンテンツでは、マルチキャスト(例えばテレビ会議)あるいはパケットロス後のパケット再送において、キャッシュによる恩恵を受けることができる。キャッシュの管理と置換は、ISPポリシーへのテーマであり、我々の研究項目の一つである。

ネームデータのキャッシュは、プライバシに対する懸念を提起する。今日のIPネットワークは能力が低いプライバシ保護を提供する。それは、送信先アドレスを検査することでデータを要求したのが誰で、ヘッダあるいはペイロードを検査することでIPパケットの中に何があるかを調査する。一方、NDNは明示的にデータを指定するので、要求されデータが何かを知るためのネットワーク監視を容易にする。キャッシュの中に何があるかを得るのに、巧妙で厳密なスキームを通じて要求されたデータを学習することもできる。しかしながら、NDNはデータを要求した人に関する情報を完全に削除する。ポイントツーポイントで要求したホストに直接接続していない限り、ルータは要求源を知らず、どのルータがデータを要求したかという事のみを理解する。従って、NDNアーキテクチャは必然的に現在のIPネットワークよりも全く異なるレベルでプライバシ保護を実現している。

トランスポート

NDNアーキテクチャは独立したトランスポート層を持っていない。今日のトランスポートプロトコルはアプリケーション、サポートするライブラリやフォワーディングプレーン内の戦略コンポーネントの中に機能を持っている。アプリケーションプロセスに含まれる多重化はデマルチプレクシングは、NDN層で直接名前を利用して実行する。そして、適切な信頼性検査、データ署名や信頼決定を担うアプリケーションプロセスによって、処理されるデータの完全性や信頼性が作られる。

NDNネットワークは、モバイルやユビキタスコンピュータの非常に動的な接続性など、信頼できないパケット配送サービスの上で動くよう設計されている。信頼できる配送を提供するには、要求が満たされないインタレストパケットが合理的な時間内に最後のコンシューマ (最初のインタレストの送出したアプリケーション)によって再転送されなければならない。そのような機能は多くのNDNアプリケーションには一般的で、NDNコモンライブラリによって提供される。

NDNルータは、ホップバイホップ原理でインタレストの転送割合を操作することでトラフィック負荷を管理する。そして、ルータは特定の隣接ルータからの流入トラフィックが過負荷になったら、その隣接ルータへのインタレストパケットの送出を停止あるいは単純にペースを落とす。これもNDNが輻輳制御を実行するエンドホストへの依存を取り除くことを意味する。輻輳が発生したら、データ再送はキャッシュに支援され、その後再送されたインタレストは元の送り主ではなく、パケットが失われたリンクのすぐ上流でデータに合うことになる。従って、NDNは、パケットがホップ終端で失われた場合やバンド幅が元の送信元ホストから再送を繰り返されるような場合でも、今日のインターネットで起こるような輻輳崩壊を回避できる。

従来のトランスポートサービスは、ポイントツーポイントのデータ配送と、ピアツーピアや中央型サーバを極端に頼るようなアプリケーションを含む今日の分散アプリケーションの大部分に対応する。堅牢で効率的な分散アプリケーションの開発を助けるため、分散システムに基礎的な新しい構成要素の追加を計画している。我々はそれを「Sync」と呼んでいる。

NDNの基本のインタレストデータ通信モデルの上で作られたSyncは、個々のグループが効率よく堅牢な方法で新しく欠落したデータを発見して取り戻せるよう、データダイジェストを交換する、そして、それらのデータセットを同期するために、複数グループで利用可能なネーミング規約を利用する。我々は、NDNアーキテクチャの中でSyncの役割がIPアーキテクチャのTCPと同じように進化することを願っている。

9/09/2014

Named Data Networking (1)

UCLA、ベリサイン、シスコ、パナソニックなどが、Named Data Networking (NDN) コンソーシアムを発足することを発表。NDNは、IPアドレスに基づく位置依存型のネットワークから、コンテンツ名に基づくネットワークに置き換えようという野心的なプロジェクトで、PARCのバン・ジェイコブソン(VJ)氏らが提唱している。

NDNの概要を示したページ(http://named-data.net/project/archoverview/)の部分超訳(1)。


アーキテクチャ上の原則

NDNアーキテクチャのデザインを案内するのに、次の6つの構造上の原則を用いる。始めの3つはインターネットの成功から導き出されたもので、残りの3つは長年にわたる研究から得たものである。

Hourglass

図1: インターネットとNDNアワーグラス・アーキテクチャ

アワーグラス(砂時計)・アーキテクチャは、オリジナルのインターネットの設計が洗練され、強力である要因を示している。グローバルな相互通信を行うための最小限の機能的な必須事項を実装する共通のネットワーク層(IP)を中心とする。いわゆる「シンウエスト(thin waist)」は、低・上位層に制約無しに新しい技術導入を可能にしており、インターネットの爆発的な成長の鍵となった。NDNは、図1のように同じアワーグラス・アーキテクチャを持っている。

エンドツーエンド原則は、ネットワーク障害に対して、堅牢なアプリケーションの開発を可能にする。NDNはこのデザイン原則を残し、更に拡張している。

ルーティングとフォワーディングプレーンの分離は、インターネットの発展でその必要性が証明されている。ルーティングシステムが長く進化し続けるよう、フォワーディングプレーンに機能を持たせている。NDNでは、平行して新しいルーティングシステムの研究を実行できるよう、最善のフォワーディング技術でNDNの展開を可能にするため、同じ原理を利用する。

セキュリティはアーキテクチャの中に組み込まれなければならない。現在のインターネット・アーキテクチャのセキュリティは後知恵で、今日の増大する厳しい環境の要件に合ったものではない。NDNは全名前データを署名することで、シンウエストで権利ブロックを作る基本的なセキュリティを提供する。ネットワーク・トラフィックは自動制御でなければならない。フローバランスのとれたデータ配送が安定的なネットワーク・オペレーションには不可欠なものである。IPはオープンループなデータ配送を実行するため、トランスポート・プロトコルはユニキャスト・トラフィック・バランスを提供するため修正されている。NDNはシンウエストでフローバランスを設計している。アーキテクチャはユーザ選択や可能であれば競争を促進すべきである。オリジナルのインターネットデザインの関連要因ではあるが、グローバルな展開が「アーキテクチャが公平ではない」ということを我々に教えている。NDNはエンドユーザに権限を持たせ、競争を可能にしようと意識的に努力している。

NDNのアーキテクチャ

今日のIPアーキテクチャと同じように、シンウエストはNDNアーキテクチャの最も重要なものである。しかし、NDNのシンウエストは、新しい最小限の機能性を提供するため、配送にはIPアドレスの代わりにデータ名を使用する。そして、この一見したところ外見的にはシンプルな変更がデータ配送のオペレーションでIPとNDNの重要な違いをもたらせている。この節では、第一にNDNデータ配送の基本コンセプトの概要を伝え、全体のアーキテクチャの中の各要素とその役割について説明する。

Ndn packet

図2: NDNパケット

Node

図3: NDNノード

NDNの通信はエンド、例えばコンシューマがデータを受信することで駆動する。データを受信するには、コンシューマは、要求データを識別するための名前を運ぶインタレストパケットを送出する(図2参照)。ルータは要求が入ってきたインタフェースを記憶し、名前ベースのルーティングプロトコルに追加されたファワーディング・インフォメーション・ベース (FIB)の中で名前を調べ、インタレストパケットを転送する。データ要求となるインタレストがノードに届くと、データパケットが戻り、名前とデータのコンテンツ両方が、製作者の鍵による署名を付けて運ばれる(図2)。このデータパケットは、コンシューマに戻るインタレストによって運ばれるパスとは逆方向に流れる。注意すべき点は、インタレストでもデータパケットでもないものはホストやインタフェースアドレス(例えばIPアドレスなど)である。そして、インタレストパケットは、インタレストパケットの中で運ばれる名前に基づくデータプロデューサーに向かって送られ、データパケットは、各ルータホップでインタレストによってセットされる状態情報に基づいて戻される(図3)。

ルータは、戻りのデータパケットを待っている全てのインタレストを「ペンディング・インタレスト・テーブル (PIT)」に保持する。同じデータ向けの複数のインタレストを下流から受信した場合、最初のインタレストのみがデータソースへの上流方向に送られる。各PITエントリはインタレストの名前と同じ名前のインタレストを受信したインタフェース組を含んでいる。データが届くと、ルータは一致するPITエントリを探し出し、PITエントリにリストされている全てのインタフェースにデータを転送し、コンテンツストアの中にデータをキャッシュする。NDNデータパケットはどこからどこに転送されたかという事から独立しているので、ルータは今後の要求に応じるためにキャッシュできる。一つのデータが各ホップで一つのインタレストに一致するので、NDNネットワークはホップバイホップのフローバランスを実現する。

名前

NDNの設計は階層構造の名前は、'/'が名前成分(名前の一部ではない)間の境界を示している。例えばPARCによって製作されたビデオは「name/parc/videos/WidgetA.mpg」となる。この階層構造はデータの要素間の関連を表すのにアプリケーションが役立つ。例えば、ビデオのバージョン1のセグメント3は、/parc/videos/WidgetA.mpg/1/3 という名前になる。階層も規模に応じてルーティングを可能にする。理論上フラットな名前をルーティングすることはできるが(ROFL参照)、今日のルーティングシステムがスケールするための最も重要な点は、集約を可能にするIPアドレスの階層構造にあった。NDN名で動作するプログラムで考慮に入れておく必要性がある一般的な構造は、データプロデューサーとコンシューマ間の同意を慣例によって得ることができる。例えば、バージョンとセグメントを示す命名規約がそれである。

名前規約はアプリケーション特有だが、ネットワークにはオペーク(opaque:不透明)である。例えば、ルータは名前の意味を知らない(名前成分間の境界は理解できるが)。これは各アプリケーションにその必要性に適するネーミングスキームを選択することや、ネットワークから独立して進化するネーミングスキームを可能にする。

動的に生成されたデータを取り込むには、コンシューマは名前あるいはデータを事前に知ること無しに求めるデータの要素の名前を明確に組み立てることができなければならない。(1) 双方あるいは個別に利用可能なデータベースから同じ名前にたどり着ける確定的なアルゴリズムをプロデューサーとコンシューマに許可する、(2) コンシューマは部分的な名前のデータベースを取り込むことができる、のどちらかである。例えば、コンシューマは /parc/videos/WidgetA.mpg を要求すると、/parc/videos/WidgetA.mpg/1/1 というデータパケットが戻る。コンシューマは後でセグメントを指定し、最初のデータパケットによって明らかな情報の組み合わせとコンシューマとプロデューサーのアプリケーションで合意された名前変換を使って要求できる。

全ての名前はグローバルに一意である必要はなく、グローバルな一意性が必要なデータを取り出すのに使われる名前のみが一意となる。ローカル通信を対象とする名前は、ローカルコンテキストをベースに依存しており、一致するデータを見付けるのに、ローカルなルーティング(あるいはローカルなブロードキャスト)のみが必要となる。事実、個々のデータ名は、「この部屋の中のスイッチ」から「世界の全ての国名」で、様々な特定のスコープやコンテキストの意味を持つ事ができる。対象とするスコープの中でデータを転送するための効率的な戦略を開発する方法が、新しい研究分野となる。

名前空間の管理は、IPアドレスを使ってパケットを配送するIPネットワークでのIPアドレス空間の管理がIPアーキテクチャの機能ではないのとと同様に、NDNアーキテクチャの機能ではない。しかし、データネーミングはNDNの設計の中でとても重要な要素である。名前データは、コンテンツ分散(多くのユーザが異なる時間に同じデータを要求する)、マルチキャスト(多くのユーザが同じ時間に同じデータを要求する)、移動性(ユーザが異なる場所からデータを要求する)や遅延耐性ネットワーク(ユーザが断続的に接続性が止まるネットワーク超しにデータを要求する)を含む様々な機能性を自動的にサポートすることを可能とする。同時に、我々はまだアプリケーションがアプリケーション開発やネットワーク配信両方を容易できる名前を選択すべき最適な方法に関する理解の初期段階にいる。我々は、豊富なパイロットアプリケーションの実験や開発を通じて理解を獲得している。そして、NDNネットワークのネーミングの基本的な原則やガイドラインを得ることができる。これらの原則とガイドラインを、将来のアプリケーション開発を単純化するために、一貫性のある再利用に向けてシステムライブラリに実装されるネーミング技法に具現化したいとを考えている。

幸いにも、全てのネーミングの疑問; ネットワークへの名前のオペーク - アプリケーションへの依存性 - NDNアーキテクチャのデザインや開発手段、そしてアプリケーション開発のコンテキストの中の名前構造、名前発見および名前空間ナビの研究を平行して進展させなければならない。

9/07/2014

パスワードマネージャのセキュリティ

ブルース・シュナイアーのブログ「Security of Password Managers」の超訳。



パスワードマネージャのセキュリティ

今年のUSENIXセキュリティで、パスワードマネージャのセキュリティを研究した2つの論文があった。

興味深い仕事で、とりわけ、セキュリティを改善する筈だったものが、セキュリティの問題であると見ているからだ。

私は昔から、簡単に思い出す事ができるパスワードは辞書攻撃に対する脆弱性を持つという深刻な問題を解決するため、パスワードマネージャを推薦してきた。今週始めハッカーがセレブのiCloudの写真を漏洩させた際、世界は心の底から注意を得た。攻撃はiCloudの欠陥を突いたものではなく、弱いパスワードを悪用したものだった。

セキュリティはしばしば便利さとトレードオフにあり、ほとんどのパスワードマネージャはブラウザのページで自動的にパスワードを入力してしまう。これは結局はセキュリティを保つ事を難しいものにしてしまい、パスワードマネージャに攻撃を広げてしまう。

私自身が使っているパスワードマネージャ「Password Safe」は、いずれの論文には言及されていなかった。私は明確に自動入力しない設計した。そして明確にスタンドアローンアプリケーションとして設計した。Password Safeからブラウザページへのパスワードの転送する手っ取り早い方法は、OS自体のカットアンドペーストコマンドを使う手法だ。

私は、長い強固なパスワードを選択できるようにするという理由だけで、まだパスワードマネージャを使う事を推奨する。そして、あなたが覚えるべきわずかなパスワードには、パスワードを生成する私のスキームがここにある。

9/06/2014

ビッグ・インターネット

Hacker Newsに出ていたニコラス・カーのブログ「ROUGH TYPE」の"Big Internet"の超訳


我々は大手石油会社、大手製薬会社、大手穀物会社について話題にする。そろそろ、ビッグ・インターネット(大手インターネット会社)を話題してもいい時期かも知れない。

最近とあるブログ記事を読んだ後、そんな考えがチラリとよぎった。一つは、ブログをすることの古びた活動の復興について書かれたスコット・ローゼンバーグ氏の1本で、私はブログが再び重要なものになると実感できなかったが、ローゼンバーグはその根拠を述べている。ジェイソン・コッケ氏も、ブログは時代精神を復活させたと語っている。世界よ、おかえり。

もう一つはアラン・ジェイコブズのツイッターへのお別れだ。ジェイコブズは、ユビキタスなマイクロブログ・プラットフォームへの幻滅と失望の高まりについて書いている:

私がツイッターにいるときから(2007年5月に開始した)、人々はツイッターについて不満を言っていた。しかし、最近になって何かが変わった。不満は頻度や激しさは増し、今ではしばしば特にプラットフォームの思慮深く前向きなユーザから聞こえてくる。これらの不満は、ほとんど明白なギブアップといった敗北感がある。ツイッターを利用する本当に賢明な人々の多くにとって、おしまいだ。彼らはツイッターを使うのを完全にやめてしまうという意味ではない。しかし、ツイッターで最高だったこと、第一に発見の体験、が今は過去のものになったことが非常に明白だ。

ジェイコブは語る「ビッグ・ツイッターは偉大だった ー 暫くの間」「しかし、今は終わり、先に進む時だ」。

これらのトレンドは、彼らが本当にトレンドなら、関連しているように見える。私がビッグ・インターネットと呼ぶものが持つ脱力感が二人の原因だと感じる。ビッグ・インターネットとは、グーグル、フェイスブック、ツイッター、アマゾンやアップルのような巨人を中心とするインターネットをベースとするプラットフォームやプランテーションと考える。これらの企業はひところ反乱者 (insurgents) だったかも知れないが、今では巨大で面白味に欠け、自分たちの帝国を拡張し、維持することで頭がいっぱいである。ウェブ世界のヘンリー8世となっている。そして、彼らの存在を少し気持ち悪く感じ始めている。

だから、そう、私はこの再流行の動きに賛成だ。個人ブログを復活させ、RSSを復活させ、楽しみを復活させたい。ビッグ・インターネットめ。

しかし、「ブロゴスフィア」という言葉は復活させないで下さい。

更新(2014.09.19)

yomoyomoさんのエッセイ「個人ブログ回帰と『大きなインターネット』への忌避感、もしくは、まだTwitterで消耗してるの?」。

9/05/2014

ChromeOSのマルチユーザログイン機能

先日リリースされた最新Stable版(バージョン37)には、マルチユーザログイン機能が追加されたので試してみた。まず所有者がログインし、そのあと右下のアイコンをクリック、一番上の自分のアカウントをクリックし、「別のアカウントにログイン...」を選択してログインすれば、ユーザを選択するだけで簡単に切り替えられるようになる。ただ、壁紙が変わってくれない...。

Chromeos mul

9/04/2014

疑似SNMPトラップを送る方法

SNMPマネージャーのテストのためだけに、機器をダウンさせるわけにはいかないので、疑似トラップを出したくなることがある。LinuxやMacのように、Net-SNMPが入っていれば、snmptrapコマンドで簡単に送出できる。SNMP v2cの場合、SNMP-Trap-PDUの形式の通りに送ればよい。SNMPv2-Tap-PDUは、sysUpTime.0snmpTrapOID.0の次に任意のトラップデータ(varbind)を足していくだけだ。varbindは「OID 型 値」のように記述する。コマンド形式は次のようになる。

snmptrap -v 2c -c コミュニティ名 ホスト名 タイムスタンプ トラップOID
varbind1
varbind2
:

例えば、bgpBackwardTransNotificationを送りたければ、次のように送ればよい。

snmptrap -v 2c -c public localhost '' .1.3.6.1.2.1.15.0.2 \
.1.3.6.1.2.1.15.3.1.7.10.1.1.1 a 10.1.1.1 \
.1.3.6.1.2.1.15.3.1.14.10.1.1.1 x 0000 \
.1.3.6.1.2.1.15.3.1.2.10.1.1.1 i 6

Juniperルータなら「request snmp spoof-trap」コマンドが用意されている。Junosが持つトラップ名を指定するだけでSNMPマネージャへ簡単に送出できる。variable-bindingsオプションで、任意のvarbindを付けて送ることもできる。例えば、bgpBackwardTransition1)なら、次のように送ればよい。

request snmp spoof-trap bgpBackwardTransition variable-bindings \
"bgpPeerLastError[10.1.1.1] = 04\ 00, bgpPeerState[10.1.1.1] = 1"
1) JunosはなぜかRFC 4273のBGP Trapをサポートしていない

アカマイ、IptabLes & IptabLexを警告

アカマイが、IptabLesとIptabLexに感染したLinuxシステムがボットネット化しており、非常に危険だと警告を出しているとのこと(Slashdot)。マルウェアは脆弱性のあるApache Struts、TomcatやElasticsearchを利用しているLinuxシステムに感染していると見られ、ボットネットのC&Cサーバは中国にあることが確認されているそうだ。

このマルウェアのメインファイルは/bootあるいは/usrの下に置かれ、起動スクリプトが作られるので(Malware Must Die!)、駆除はこれらの感染ファイルを消し、プロセスをkillあるいは再起動すればよい。findで全体スキャンも忘れずに。

/boot/.IptabLes
/boot/.IptabLex
/usr/.IptabLes
/usr/.IptabLex
/etc/rc.d/init.d/IptabLes
/etc/rc.d/IptabLes
/etc/rc.d/init.d/IptabLex
/etc/rc.d/IptabLex

9/02/2014

Apple製品周期

来週の日本時間9月10日2時からAppleのiPhoneとウェアラブルデバイスの発表がある。それを受けてか、今日の"Joy of Tech"は、Appleフリークが取り上げられている。「The Apple product cycle...」の超訳。

基調講演前
興奮状態の高まり、噂が飛び交い、あなたはもういくつ寝るとと数えるオタク(geek-giddy)と化している
(OMG: どうしよう! なんてこった! げっ、うっそー)
基調講演当日
ぶったまげた! あなたの人生はiThing無しでは、どのくらい空虚で虚しいかを実感する
基調講演後
複雑な気持ち... あなたはまだハイだが、イライラ、半信半疑、疑念が再発
(iTHINGはすごい! iTHINGが今欲しい! iTHINGはすごいのか? iTHINGをあきらめられない!)
購入前
あなたはどんなに人生がiThingで素晴らしいものになるかを想像する
手に入れた
契約、確定、そして配送! iThingは全てあなたのもの! あなたはテックゴッドだ!
(力を手に入れたぞ!)
購入後
iThingは素晴らしいが、ある側面があなたをいらつかせる。アーリーアダプタ鬱の危険性
(iTHINGがもう少し薄ければ、ほんのわずかでも速ければ!)
基調講演切望
あなたは次のアップル製品を待つ
(どうしてアップルは世界を変えるのにそんなに時間が掛かるんだ?!)

9/01/2014

iCloudから写真漏洩?、「iPhoneを探す」が原因か

iCloudから、ジェニファー・ローレンスなど有名ハリウッド女優のプライベート写真が漏洩した事件。「iPhoneを探す(Find My iPhone)」の脆弱性を突いて、パスワードが盗まれたのではないかとの事。「iPhoneを探す」サービスAPIに、ブルートフォース攻撃の防御機能が実装されていなかった事が原因らしく、PoC (iBrute)がGithubに公開されている。Appleは既にこの問題に対処した模様(twitter)。

更新(20140902)

Re/codeによれば、Appleの広報が「前向きに調査している」と発表していることから、まだ原因は特定されてはいないようだ。今すぐできる自分自身を守る方法としては、強固なパスワード(使い回しはしない)、2段階認証の有効化。心配な人はフォトストリームをオフにする。

更新(20140903)

Appleはこの事件の調査結果を公表。iCloud、「iPhoneを探す」を含むAppleのシステムを破られたわけではなく、標的型攻撃だったと結論付けた。結局、狙われたセレブのセキュリティが甘かったということだろう。落ち着くべきところに落ち着いた感じだ。AppleはGoogleと比較して、決してセキュリティ強化に熱心だとは思えない。少なくともユーザがアクティビティログを閲覧できるようにして欲しい。

更新(20140904)

2段階認証の適用範囲が限られているため、2段階認証無しで新しいデバイスでのiCloud復元が可能で、更にElcomsoftのようなフォレンジックソフトを用いれば、復元せずに様々なデータにアクセス可能と指摘されている。これは脆弱性というより、Appleの仕様だろう。復元時に確認コード(SMS)が必要になるとしたら、もう一台携帯電話を持つか、その度に復旧キーを使わなければならない。何か別の手段を考える必要があるだろう。

もし、プログラミング言語が武器だったら

Hacker Newsに出ていた「If programming languages were weapons*の超訳(よく分からない点もあるが)。

  • Cは、M1ガーランド標準装備銃、旧式だが信頼性がある
  • C++はぬんちゃく。パワフルで素晴らしいが、習得には長い苦労が伴い、たいていは他の武器を使いたいと望むだろう
  • Perlは火炎瓶、かつては便利だったが、今では利用者が少ない
  • Javaはベルト給弾式240G機関銃。ベルトは一発分の弾か、ベルトが無い場合もある。そして、NullPointerExceptionが発生すると、銃が暴発してあなたは死ぬ
  • Scalaは240G Javaの派生形、訓練マニュアル以外は不可解な方言で書かれており、怪しい点の多くはでたらめである
  • JavaScriptは柄の無い剣である
  • Goはカスタムメイド「if err != nil」スターターピストルで、発砲後、本当に発砲したかを確かめるために検査しなければならない
  • Rustは3Dプリンタで作られた拳銃。いつか動くかもしれない
  • Bashは呪われたハンマー。扱う全てものが釘のように見える、特にあなたの親指は
  • Pythonは「v2/v3」2連式ショットガン(散弾銃)。一回に一つの銃身から発射し、決して望ましい一撃を発射できるとは限らない。結果を出すためラインツールを使うべきだ
  • Rubyはルビーで覆われた剣。普通はどうやって光輝くかのために使われるのみ
  • PHPはホースだ。普通は自動車の排気ガスにホースの端を差し込み、窓をつたって中に入れ、車に座って、エンジンを入れる
  • Mathematicaは低い地球軌道のプロジェクタイルキャノン。誰でも買う事ができれば、凄い事が起こるのだが
  • C#はロバに載せるレーザライフル、ロバが死ぬと、レーザが機能しなくなる
  • Prologは人工知能兵器。何をすべきか、どちらにすべきかを教えてくれるが、時間をさかのぼって、あなたの母親を殺しにくるターミネータを作ることもある
  • Lispは多くの形状がある(間に合わせの)ナイフ。これを使う人は正気ではなく、危険である
更新 (20140904)

GIGAZINEでも取り上げられていた。