無印吉澤(※新エントリはhatenablogに掲載中)

吉澤です。このサイトではIPv6やP2Pなどの通信技術から、SNSやナレッジマネジメントなどの理論まで、広い意味での「ネットワーク」に関する話題を扱っていたのですが、はてなブログに引っ越しました
最新の記事は http://muziyoshiz.hatenablog.com/ でご覧ください。
RSSフィードは http://muziyoshiz.hatenablog.com/feed に手動で変更するか、
Feedly or Live Dwango Reader を使っている方は以下のボタンで変更ください。
follow us in feedly Subscribe with Live Dwango Reader
最新 追記

2006/04/05

[P2P]ネットワーク技術の発展を阻害するのは警察か、それともISPか?

前回の日記では、最近のWinny騒動について個人的な考えを書いてみましたが、実を言うと、あの意見に僕自身が諸手を挙げて賛成できるかというとそういうわけでもなくて……本当に政府があんなことを始めたら、やっぱり「過激すぎる!」って文句を言うと思います*1

そんな過激な意見を何故わざわざ書いたのか? それは、一部のISPが実施しているようなP2P帯域制御が常態化すると、金子氏の逮捕なんて比じゃないくらいネットワーク技術の発展を阻害すると思っているからです。代替案という形で書いてみたのは、ただ文句を言っても仕方ないという気持ちからでした。

とにかく、個人的にはどうしても「そんな危険な方向に進む前に、何か出来る事はないのか?」ということを考えずにはいられません。その理由として、僕がいま考えている事をつらつら書いてみます。

----

■ 通信プロトコルの「冤罪」は誰が防ぐのか?

先にお断りしておきますと、僕はISPによる帯域制御全般に不満があるわけではないです。むしろ、設備維持を目的とした転送量制限は必要だと思ってますし、例えばP2Pの帯域制限を宣言しているプロバイダ一覧にあるIIJやUSENなどの例は、十分妥当だと考えています。

しかし、ぷららやNiftyのように、アプリケーションレベルまでパケットを調べて、特定プロトコルのパケットを「遮断」するのは問題だと思っています。

それは、「何GB以上はダメ!という転送量制限の内部処理」なら僕でも簡単に想像できますけど、「Winny通信だけを遮断するための内部処理」なんてどうなってるのかなかなか想像できないからです……いや、冗談ではないですよ。

例えば、ぷららが採用している帯域制御装置はCiscoのService Control Engine (SCE) 2020という製品なのですが、これについてウェブ上では以下の資料を見る事が出来ます(他にもっといいのがあったら是非教えて下さい!)。ちょっと読んでみてください。

Cisco SCE 2000 シリーズ - シスコシステムズ
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/sce/sce2000/prodlit/sce2000_ds.shtml

導入事例 : 株式会社ぷららネットワークス (1/4) - Japan - Cisco Systems
http://www.cisco.com/jp/news/cisco_news_letter/mail/0401/special/

さて、上記の資料を見たという前提で聞きますけど、これらの情報から「この装置はWinny以外のトラフィックまで誤って遮断することはない」と断言できますか? また、通信アプリケーションの動作に問題があった場合に、この装置が原因であるかどうか利用者が判断するにはどうしたらいいんでしょうか? この種の帯域制御装置の動作は非常に不透明です。

「内部動作が不透明って言ったって、私はこのルータが何してるかさえ分からないわよ!」と言う方は、NAT(Network Address Translator)のことを思い浮かべて下さい。

当初、NATは「Webとメールさえ出来れば十分」という要求から作られました。しかし、各メーカが作るNATの内部動作はそれぞれ微妙に異なっていたため、後になって「やっぱりend-to-endの通信も必要だ」とみんなが考えるようになると、様々なバッドノウハウが必要になってしまいました。ここで言うバッドノウハウとは、UDP hole punchingなどのNAT越え技術のことです(※詳しい人のための注:Symmetric NATではないからといって必ずしもUDP hole punchingが使えるわけではないそうです。それくらいややこしいんです)。

NATによって引き起こされたNAT越え問題は、現在までに蓄積されたバッドノウハウや、IETFでのNAT動作の標準化活動*2などによって徐々に解決に向かっています。しかし、アプリケーションレベルまで検査する帯域制御装置があらゆるプロバイダで採用されてしまうと、NAT越え問題以上に重大で、解決しづらい問題が引き起こされる可能性があります。僕はそれが心配です。

■ ISPには通信プロトコルを裁く権利があるのか?

以下は、ぷららバックボーンにおけるWinny規制に関するニュースリリースです。

ニュースリリース(2006.3.16)
http://www.plala.or.jp/access/living/releases/nr06_mar/0060316_2.html

しかしながら、昨今、ウイルスに感染したパソコンから「Winny」を介した、意図せぬ個人情報または機密情報の流出が相次いでおります。こうした社会問題を憂慮すべき事態と捉え、皆様に安心してご利用いただけるネットワーク環境を提供することが通信事業者としての責務であるとの考えから検討を行ってまいりましたが、「Winny」による通信を完全に規制する決定をいたしました。

このニュースリリースにあるように、ISPによる今回のWinny規制の背景には「Winnyトラフィック自体がウィルスやSPAMのようなもの」という思想があって、その上で、アンチウィルスソフトがウィルス入りメールを全て除去するのと同じ理屈に従ってWinnyトラフィックを除去しているように見えます。

ただ、通信事業者が特定のプロトコルに対してそういうレッテルを貼って規制することは、検閲とは言えませんが、越権行為ではないのでしょうか? このレッテルを貼る権利がプロバイダにある、ということになると、例えば他のプロトコル(Skypeとか)に対しても自分の判断でレッテルを貼っていいということになってしまいます。

最近アメリカではネットの中立性をめぐる議論が激化している*3そうですが、今回のWinny規制はこのネットの中立性が侵害される第一歩になってしまうのではないでしょうか? 少なくとも、特定トラフィックの遮断を許可していいかどうか、プロバイダの外の消費者や組織、または政府が審査する仕組みが必要なのでは? 言ってみれば、こちらも透明性の問題ですね。

そういう意味では、Winny規制を行うと発表*4しておきながら、自社サイトにニュースリリースも載せないNiftyの態度は非常によろしくないと思います。問題の重要さを認識してない、と言っているようなものでしょう。

----

とはいえ、これは個人個人が何を一番重要だと思うか、という思想上の問題に過ぎないのかもしれません。

少し前にアリエルネットワークの徳力さんが「Winnyに関する議論が噛み合わない5つの理由」という文章を公開されていましたが、議論がかみ合わない理由ははっきりしています。

1つには、Winnyが投げかけている問題は複数ある、ということ(徳力さんは5つの軸で整理してますね)。2つ目は、各人の重要視している問題が違っている、ということ。そして最後に、重要視している問題について話すときも残りの問題に触れざるを得ないから話がややこしくなる、ということだと僕は思っています。ちなみに、前回の僕の日記は「1. 著作権問題」「4.情報漏えい問題」「5. ソフトウェア開発の責任問題」にまたがった主張でした。

一度に全部の問題を解決するなんて、どだい無理な話です。そこで、今回は僕が最も重要だと思う「帯域制御の透明性」の問題に関する個人的な考えを書いてみました。この話題については、常にご意見をお待ちしています。

----

(2006/04/06追記)
今回の話題にちょうど合っていたので、ISPによるWinny規制が良くない理由をちゃんと考えよう:武田圭史にトラックバックを飛ばしてみました。


2006/04/13

[P2P]ISPによる過去のワーム対策と、Winnyの共通点

前回の日記で「ISPには、特定のパケットを遮断する権利があるのか?」という話題を書いたところ、mmasudaさんからこんなコメントを頂きました(ありがとうございます)。2004年1月に開催されたJANOG13で、類似する議論が行われていたというタレコミです。

事例的には古めの話題ですが、xSP がフィルタすべきか否かという議論については、JANOG13 の"To filter or not to filter"パネルセッションが一応ありますとタレ込んでみるテスト。
http://www.janog.gr.jp/meeting/janog13/program.html

上記サイトによると、このパネルセッション"To filter or not to filter"では

CiscoのVulnerabilityやBlasterに対して各ISPがバックボーンやカスタマエッヂで
とった対策はまちまちだった。このパネルでは様々な立場の人から

・そのときに取った行動
・今後同じような自体が起きたときにどのような対策をとるのか

を意見してもらい、Filterするべきか、せざるべきかの議論を行った。

というテーマで、レイヤ3(IPヘッダ)でのフィルタリングの是非が議論されたようです。つまり、ネットワーク装置(Ciscoルータや、Windows PC)の脆弱性を利用したワームによって引き起こされた大量のトラフィックを、果たしてISPはフィルタしていいのか?という議論ですね*1

詳しくは公開されている議事録と資料(参照:JANOG13 Meeting Session Abstract)を読むといろいろ分かるのですが、全体的にフィルタ否定派が多く、「ワーム対策としてやむなく一部フィルタリングしているが、なるべく避けたい」というネットワークオペレータの方の本音が伝わってきました。

また、このパネルセッションにはゲーム会社(セガ)の方が参加していて、ここで話題にしているレイヤ3のフィルタでもネットゲームに悪影響を及ぼしていることが言及されています。僕自信はほとんどネトゲをやらないのであまり知りませんでしたが、この問題は2年以上前から深刻に認識されていたようです*2

その他には、以下のような話題が議事録に残されています。

  • フィルタを実施するとユーザ対応が大変(Web告知、メール、サポート強化)。ISP単独では限界がある
  • フィルタをいつ誰が実施し、いつ外すかの判断が難しい
  • フィルタの影響により、Mobile IPv4を使えないプロバイダがあった(今もある?)
  • ポリシを周知するためのフォーマットがない。ICMPなどを使ってパケットに語らせるべきか?
  • エンドユーザにフィルタを選択させるシステムは?
  • ネットワーク家電やゲーム専用機はリソースに限りがあるので、トンネリング等でフィルタを回避するのも難しい

ともあれ、レイヤ3のフィルタに対してもこれだけ抵抗感があるってことは、常識的なISPならレイヤ7(アプリケーションレイヤ)のフィルタなんて全く考えられないでしょうね……。

----

と、僕はちょっと安心しかけていたのですが、今日Silphiumのながせあきひろさんがこんな記事を公開しているのを見て、また分からなくなってきました。

Winnyを禁止すべきたった一つの理由(Silphium Diary)
http://aki.nekoruri.jp/diary/200604b#D13_2

現在、Winnyの作者はその開発に関する公判が進行中であり、 なおかつ開発を停止するという念書の存在もあることから、 どんなセキュリティホールが存在したとしてもそれがしばらくは改善される見込みがない。 このようなリスクが発覚した場合、Winnyの利用を積極的に禁止するのは正しい。

このような理由による、ISPによる停止としては、 同様にSQL Slammerによる1434/udpや、 広義にはOP25B等を含めても良いかもしれない。 Winnyを瞬殺して乗っ取るワームが実際に登場した場合、 「15分で全世界を制圧するウイルス」論文が現実になってもおかしくない。

これは、Winnyがワームの温床になる可能性を考えると、("To filter or not to filter"で議論していたような)ワーム対策としてのフィルタリングをWinnyに対しても行わざるを得ないだろう、という洞察です。

実際のところ、現在のWinny騒ぎで話題になっている情報漏洩は、Winny自体の脆弱性によって引き起こされたものではありません。この点はessaさんによるWinnyが残したもの(アンカテ(Uncategorizable Blog))など、色々なブログで言及されているところです。

しかし、Winny開発者の金子氏がいくら天才だとしても、Winnyにセキュリティホールが1つも無いとはとても思えません。これだけ衆目が集まってくれば、セキュリティホールが見つかるのもおそらく時間の問題でしょう。50万以上と言われているWinnyノードが一斉にDDoS攻撃を開始したらどんなことになるのか……。

そう考えると、常識的なISPでもいずれWinnyトラフィック自体をワームに類するものと見なし、レイヤ7のフィルタリングを開始せざるを得なくなってしまうのでしょうか? ぷららの言う「ユーザのため」という言い訳は僕には全く納得できませんけど、インターネット全体のユーザのためにそういうフィルタリングが必要だ、と言われたら、それは確かに少し納得できます。

ネットワーク技術者は「Winnyトラフィックをフィルタする未来」を当然のものとして認めた上で、今のぷららや@Niftyが抱えている「フィルタのポリシをどう周知するのか」、「そのフィルタをいつ外すのか」といった透明性の問題に取り組むべきなのでしょうか……?

なんだか頭がクラクラしてきました。

----

(2006/04/15追記)
この日記への反応として、アンカテ(Uncategorizable Blog)のessaさんが面白い話を書かれていました。

Winnyトラフィック遮断の思想的な意味(アンカテ(Uncategorizable Blog))
http://d.hatena.ne.jp/essa/20060414/p1

上記エントリでは、ネットワークオペレータの方々がフィルタに対して否定的である理由を、「ポステルの頑健性原則」 (Postel's Robustness Principle)に触れながら推測しています。詳しくはリンク先をどうぞ。

*1 ちなみに、議事録を見る限りではWinnyやその他ファイル共有ソフトの話は見あたりませんでした。JANOG13が開催されたのは2004年1月とあるので、時期的には、既にWinny利用者2名が逮捕された後(逮捕は2003年11月)です。

*2 ネットゲームと帯域制御装置の関係については、Tomo's Hotlineの最近の記事「プロバイダがWinnyを規制する本当の思惑とは?」でも言及されていました。


2006/04/22

[P2P]さよならウィニー

前回の日記でも書いたようにいずれセキュリティホールが見つかるとは思ってましたけど、意外と早かったですね。いや、最終バージョンの公開から2年半近く経っている*1ことを考えれば遅いくらいなんですけど……。

「Winnyのセキュリティ・ホールは危険」,発見者が警告(ITpro)
http://itpro.nikkeibp.co.jp/article/NEWS/20060422/235987/

米eEye Digital Security(以下,eEye)は現地時間4月21日,ファイル共有ソフト「Winny(ウィニー)」に見つかったセキュリティ・ホールの概要を公表した。同社によると,細工が施されたデータを送信されるだけで悪質なプログラム(ウイルスやボットなど)を実行される恐れがある,危険なセキュリティ・ホールであるという。

この件については、セキュリティホール memoの記事も詳しいです。

過去の報道*2によると、Winny開発者の金子氏は京都府警に「今後、Winnyの改良を行わない」という誓約書を書かされているそうなので、このセキュリティホールが塞がれる見込みはないでしょう。IPA(情報処理推進機構)セキュリティセンターが「Winny(ウィニー)の安全上の問題箇所(脆弱性)の公表について」という文書で

開発者による修正方法は公表されていませんので、回避方法は「Winny利用の中止」です。

と発表しているとおり、もうWinnyは全く使えなくなってしまったわけです。さよならウィニー。

もちろん、アプリケーションとしてのWinnyにバグがあっても、プロトコルとしてのWinnyの価値は失われないのですが*3、現在のユーザベースが失われるという意味では、Winnyの終焉が訪れたと言って差し支えないでしょう。

----

しかし考えてみれば、金子氏がWinnyのアップグレードを禁止され、ソースコードも押収されてしまった2年半前の時点で、Winnyというアプリケーションは既に終わってしまっていたわけで。下記記事のようにWinnyで培われた技術の応用が進みつつある今となっては、こういう形でWinnyというアプリケーション(あるいはネットワーク)の明確な終わりが訪れることは却って良い事なのかもしれません。

Winnyの金子氏も開発に参画したコンテンツ配信システム「SkeedCast」(INTERNET Watch)
http://internet.watch.impress.co.jp/cda/news/2006/04/18/11686.html

恐らく内閣官房は、Winnyそのものに脆弱性が存在する事実*4を元にして、再度国民にWinny利用自粛の呼びかけを行うでしょう。「ユーザは多いのに脆弱性を直すのは禁じられている」という奇妙な話が知れ渡ることで、せめて、ソフトウェア開発者の逮捕という暴挙に走った京都府警の馬鹿馬鹿しさが、世間に伝わる事を祈ります。

その他関連記事:Winnyにバッファオーバーフローの脆弱性(スラッシュドット ジャパン)
http://slashdot.jp/security/06/04/21/1518212.shtml

*1 Winny2 Web Siteによると、Winny v2.0b7.1の公開日は2003年11月16日。

*2 Winny開発の金子氏が講演--情報漏えい対策「技術的に可能だが、身動き取れない」(ZDNet Japan)

*3 この日記でも過去に取り上げたポエニー等で、プロトコルとしてのWinnyは生き続けています。

*4 僕はこの脆弱性は存在すると信じていますけれど、Winnyの脆弱性を信じるか信じないか(デー)によると、2ちゃんねるではこの脆弱性情報を疑う向きも多いようです。


2006/04/28

[tDiary]tDiary 2.1.4へアップグレード

ちょっと風邪で寝込んでて暇だったので、今までの安定版(2.0.2)からちょっと妖しい開発版のtDiary 2.1.4にアップグレードしてみました。

開発版での大きな変化は「前7日分」のリンクが出るようになったのと、日記の編集画面で「ちょっとした修正(RSSを更新しない)」というチェックボックスが使えるようになったことでしょうか。他にもいろいろ機能は変わってるんでしょうけど、元はてなダイアリー市民としてはそんなところにばかり目が行ってしまいます(まあ、もう市民権は剥奪されてるんですけれども)。

とりあえず問題なくアップグレードできたと思うのですが、何か不具合がありましたらコメント等で教えてやってください。


2004|06|07|09|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|10|11|
2009|01|02|03|04|05|07|08|10|
2010|01|03|
2015|03|
スパム対策のため、60日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。
また、この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。ご了承ください。