wakatonoの戯れメモ

はてなダイアリーから引っ越してきました。

今日はSEA & FSIJ 合同フォーラムの日

SEA & FSIJ 合同フォーラム〜知った気になれる（？）WebDAV基礎知識〜という感じでお話しをさせていただきます。
もしかしたらオレへらっとしてるかもしれませんが、実はオレ的大舞台だったりします。気合も入るー！
何度も言いますが、「知った気に〜」という（ある意味おちゃらけたような）ネーミングセンスはオレのモンです (^^;*1。

*1:ふざけたタイトルにしやがってー！という苦情は甘んじてお受けいたします (_ _)

CVS版のbsfilterをlensに組み込むその後

雑

結論から言うと、うまくいきました。
2004年3月22日分の日記に対するnabekenさんのコメントに従い、bsfilterを1.50.2.8にして試してみました。結果はOK。
nabekenさん、ホントにありがとうございます (_ _)。この場を借りてお礼を申し上げます (_ _)

単体で動かしてOKだったので、

  • bsfilterのファイルを/usr/local/lib/site_ruby/1.6 配下に bsfilter.rb という名前でコピー
  • .lensrcに定義されたspam_contentsメソッドを以下のように差し替え、bsfilterをrequireする（以下のような感じ）。



require 'bsfilter'
class Message

  def spam_contents?

    bsfilter = Bsfilter::new

    bsfilter.setup(["-q", "-m", "rf"])

    # bsfilter.run([path])

    bsfilter.run([text])

  end

end
これで問題ありませんでした。
元気に動いております。

Low-Level Virtual Machine(LLVM)

オープンソース

from Yendot。
ざっと見ると、VMWareとかBochsみたいなVMよりはむしろ、Java VMのようなイメージの方が近いかな。

  • VMの上で動くインストラクションセットを定義し
  • 一つのプログラムをさまざまなアーキテクチャのマシン上で動かせるようにする

というように見える。

クララオンラインの社長（家本さん）の行動

雑

Googleで評判をチェックするあたりに親近感が (^^;
冗談抜きで、自分たちがどう見られているかを振り返ることができるトップであれば、ユーザやユーザ予備軍はちゃんと支持してくれると思います*1。
家本さんと会ったことはないけど、某氏から聞いた限りはblog通りの人かなぁ、と思ったり。

*1:これは、別に自分（オレ）が正しい（支持される）とかいうことを言ってるものではないです。あくまで行動が一部似てるなぁ、というところであって、オレがちゃんとした人であるということを言うものではないです（むしろ小心者の方向で＞オレ）。念のため

「(Linuxの)IPsecの困難」を何度か読み返して…

セキュリティ

オレも前に書いたが、IPsecを取り巻く環境がナニである、というのはyomoyomoさんも自身のコラムで書かれている。
この状態を承知の上で、IPsecがv2からv3へ、IKEがv1からv2へと移行するにあたって、スムーズに移行（もしくは共存）できるための方法を妄想してみよう。

自分で書いておいてなんだが、IKE v2になり、IPsec v3になったとして、もしかしたらそんなに大変なことにはならないかもしれない。

IKE v2 & IPsec v3 になったとして、おそらく一番大変なのはやっぱりIKEの実装だろう。もちろん、これらのバージョン（IKE v2 & IPsec v3 の組み合わせ）だけしかサポートしなければ、多分まだラクだ。ただ、IKEでやりとりされるメッセージのフォーマットを見ると、なるほどIKEのバージョンを扱うフィールドがある。

まず1つ、これでIKEについては解決された（いいのか？）。ではIPsec v3の方はどうだろう…

ここではESPについてのみ扱ってみる。

通常このテのプロトコルを扱う場合には、後方互換性を考慮する必要があるか、全く考慮する必要がない（別モノ）として扱う必要がある。どっちのアプローチが正しく、どっちのアプローチが間違ってるということはない。決めの問題である…と個人的には思う。そう思ってみてみたところ、IPsec v3については後前者のアプローチを取っているようだ。ヘッダについてはフォーマットを変えず、他の部分でなんかやっている。具体的には

  • シーケンス番号のサイズは32bitから64bitに増えている
  • シーケンス番号の下位32bitは、IPsec v2のシーケンス番号と同じところに位置する
  • シーケンス番号の上位32botは、パケットの後ろに位置する

なるほど、こうすれば暗号化されたペイロードの位置は変わらない。
ついでにいうならば、シーケンス番号はあくまでリプレイアタックを防ぐためのものであり、パケットを送るごとに増分されるもんであるから、通常の処理をする上で普段見なければならないカウンタは下位32bitのみでOK。上位のカウンタを参照したり更新したりする時は

  • リプレイアタックよろしく同じシーケンス番号のものが出てくるような時
  • 下位32bitがオーバフローした時

というようにすればいいだけか。

これは「カウンタは必ず連続したビットで保持されなければならない」というオレの思い込みを見事に打ち砕いた結果になる（いや、たいしたことはないのだけど）。

なんのことはない、ちゃんと考えてはあるのだ。
このあたり、要らぬ憶測により混乱をさせてしまったことについて、深くお詫び申し上げたい。

で、ここからが本題なのだが…（前振りが長い）。

IPsec v3が実装され、IKE v2が実装された際に、その中に互換性に関する規定はあるのか？といわれると、多分ないだろう。しかし、ESP v3のパケット構成中の「Integrity Check Value(ICV)」と呼ばれるフィールドの構成によっては互換性を保つことも可能に見える。

ESP v2 についてはこのフィールドは「Authentication Data (variable)」と呼ばれる。どっちにしても可変である。

ただ、ヘタにスタックに互換性を持たせようとすると、おそらくESP v2の認証とICVの構成をまたなんかしないといけないとかいう話になるが、この部分の処理は間違いなくバージョンに依存するだろう（多分いっしょには出来ない）。

すると、IPsec通信を行うにあたって必要となるSA(Security Association)の情報に埋めておいた方が、実装する側もラクになる。こんなのは、IKEでやりとりする情報を1つ増やしてやればいいだけの話だ。

ただしこれは、ある一対の通信相手の間で複数のバージョンのESPパケットが流れないという前提のもとに成立するものである。ここまで縛ってたかどうかはちょっとドラフトを読みきってないのでなんともいえない…。もしかしたら重大な勘違いしてるかもしれないし＞オレ

そうなると、パケットそのものにバージョン情報を持たせる、というのが最も有力な解になるのだが、ざっと調べた限りはICVがその鍵を握るような気がしてきた。

このあたりは、IETFの報告会の資料だけを斜め読みしていたバチがあたったともいえるが、実はESPとIKEの新しいバージョンに関するドラフトは、意外に練ってあるように見えてきたというのが正直なオレの感想である。

しかしこれはあくまで現状の話であり、今後どのように変わるかは全くわからない。
オレは「ICVが鍵を握る気がする」といってるが、もしかしたらICVそのものを使わないという解もありうるのだ。

さて、実装に目を落とすと、おそらくIKEv3の実装は必然的にIKEv2についても解釈できるようにしておくのではないか。これについては、CISCOやNOKIAをはじめとするVPNソリューションを売っている会社に対するカスタマの要望として出ることが予想される。

そうなると、IPsecスタックについても同様のことが出てくるだろう。

今後、ドラフトを実装したものが出てくるだろうが、それらが出てきてから改めて考察してみることとしたい。

＃もちろん、今後またドラフトを読むチャンスがあったらそうしてみるが…。

無印吉澤＠はてなダイアリーさんの日記より

セキュリティ

ひととおり書きあがった後で気づく（滝汗）。
コメントがあるかといわれると…あるんですが（大汗）*1。

  • アプリケーションからわかりづらい

これはもともと「アプリケーションに暗号化通信を行っていることを意識させない」というのがIPsecのデザインポリシーだった（と思ってますが）からだとオレは思ってます。
言い方を変えるならば、「アプリケーションやその設定に一切の手を加えることなく安全な通信を行えるようにする」ともいえるでしょう。

鍵交換はあるものの、それが終了した後のIPsecの利点は「レイヤ3のみで完結する暗号化通信」という一点に尽きます。
これが例えばSSL-VPNのようなものになると、TCP over TCPという構図が成り立ちますが、TCP over TCPは、下位レイヤとなるTCP（SSLセッション）の安定性に大きく依存します。
これは、通常の通信路の信頼性に加え、途中にあるネットワーク機器（ファイアウォールのセッションタイムアウト時間や、ProxyのKeepAliveの回数制限*2など）の影響も大きいです。
さらに、SSLセッションでのデータの欠損があると、輻輳が簡単に起きる危険性があります。
IPsecの場合は、上位のTCPレイヤでの話はあるものの、基本的にはピアもしくはゲートウェイの間に介在するネットワーク機器は、このセッションの存在を知ることが出来ません。
セッションがないのでタイムアウトもなく、下位レイヤでちゃんとパケットを届けてくれればOKだし、そうでなくとも普通に上位レイヤの再送機能が働いてくれます。レイヤ3レベルのパケットを1対1に暗号化するため、輻輳は最小限に抑えられるかな、と。

もっとも、個人的に恐いのは、IPsecだろうとSSL-VPNだろうと「だれても簡単に使える」ようになったら「踏み台が増えるのではないか」というところだったりします。

*1:ごめんなさい(_ _)

*2:これについては実際カウントしてるものがないという噂もある

岩田さん逝く…

…

…
昨年夏に、背中がイテェとかいいつつ元気に飛び回るじじぃを見たのが最後になってしまった…
受けた恩を返しきらんうちに…
とかいうのはオレもヤだし、じーさんもヤだろー（すげぇ罰当たり＆勝手な論理）。
夏はちょうど盆の季節だし、降りて来て下さいな（笑）。
冬はきついかもしれないけど（汗）。

岩田さんとオレ

…

ちょっと暗いょ。
接点はありそでなさそであったりという不思議な状態でしたが…。
いっしょに現場仕事やったこともあったし、サークルの立場に立って最善を尽くす、というスタイルは、岩田さんの影響も多分にあります。
オレはあまり現場に立つことはなくなっちゃいましたが（ロートルだし（笑））、現場に臨む時はこのスタンスを忘れずにいますよ。
そういや昨年の夏に、

  • オレ：こんな本（DAV本ではない共著の書籍）出たっす〜
  • 岩田さん：へー、いい感じの本だなぁ

的な会話。
自分がかかわった書籍を（岩田さんの経験に照らし合わせて）評価していただき、とってもうれしく思ったな…。

いや、虫の知らせみたいなのはあったのよ。リファラ見たら妙に「岩田次夫」の名前で検索したあげくにここにたどり着いた痕跡が…。
「まさか…」と思いながらすごしてると、岩田さんの訃報が…。

50になり、天命を知る歳に逝ったじーさん。
…とりあえず、気長にまっててくだせぇ（笑）。こっちの時間で100年も経てば、多分みんなそっちに行ってるから（激烈に不謹慎）。