SoftEther, Ethernet over TCP/IP via a Virtual Hub
Yasushi Shinjo
先週ですが、SoftEther という、一種のトンネリングのプログラム
（今の所 Windows 用）を、うちの若いものが作って公開しました。
仕掛けとしては、イーサネットに見えるデバイス・ドライバが受け
取ったデータをグローバル・アドレスを持っているハブに投げると
いうものです。TCP か SSL か SSH などで。
グローバル・アドレスを持つハブを経由して、プライベート・アド
レスしか持っていないようなＰＣ同士もつながります。ハブのどっ
かにグローバル・アドレスとＮＡＴするようなルータも置けます。
つまり、プライベート・アドレスのネットワークに、Windows PC
があれば誰でも専用線をプチッと差すことができるようになります。
SoftEther が流行ると、水際作戦、つまり、ファイア・ウォールで
守るという考え方は事実上無効になります。まあ元々のＩＰの思想
には水際作戦という話は無かったので、それに戻ったという言い方
もできるのでしょうけれど。
SoftEther を技術的に止める方法は、ちょっと思いつかないですが、
何かありますかね。インターネット上のハブをもぐらたたきという
のもパッとしないし。
一応、イーサネットなので、Followup-To: fj.net.lan.ethernet
としておきます。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
名称不定
SoftEther の話はセキュリティホール memo で知りました。
ちなみに、会社で使うつもりは無い（ HTTP Proxy 認証が
必要＋ HTTPS も利用申請が必要、それ以前に使用が禁止
されると思う）ですが、ＣＣＮＡとかのルーティングの
勉強用にネットワークを構築するのに役立ちそうですねぇ。
プライベートアドレスしか持ってないＰＣ同士でも繋げると
いうのは嬉しいです。超マイナーなファイル転送ソフトの作者
として、ファイアウォール越えには悩みました。 HTTP CONNECT
で通信するのではなく、 HTTP POST で通信できたらそのまま
使えるんだけどなぁ。 HTTPS を制限している所もあるのよねぇ。
まだ自宅用ＰＣに導入はしていませんが、なんかワクワクです。
今後の発展に大期待♪（＾ｘ＾；
Yasushi Shinjo
In article <bs70v6$eah$1...@news511.nifty.com>
名称不定 <dev_...@anet.ne.jp> writes:
> ちなみに、会社で使うつもりは無い（ HTTP Proxy 認証が
> 必要＋ HTTPS も利用申請が必要、それ以前に使用が禁止
> されると思う）ですが、ＣＣＮＡとかのルーティングの
> 勉強用にネットワークを構築するのに役立ちそうですねぇ。
https の利用申請って、https:// のページが見られないわけね。
昔、fj.* が読めない会社がどうのという話題があったのを思い出
しました。
CCNA って、何ですか？
> HTTP CONNECT
> で通信するのではなく、 HTTP POST で通信できたらそのまま
> 使えるんだけどなぁ。 HTTPS を制限している所もあるのよねぇ。
HTTP POST って、何ですか？
HTTP CONNECT というのは、Proxy に繋ぐ時に CONNECT なんとかと
送るというものですよね。
名称不定
Yasushi Shinjo wrote:
> https の利用申請って、https:// のページが見られないわけね。
はい。
CONNECT を許可してしまうとどんな内容（例えば機密情報が）が
やり取りされていても判らないから、不用意に許可するのは
危険だとセキュリティポリシー制定委員会では考えているのでしょう。
暗号化されてしまってはフィルタリングもできませんし。
http://www.studyinghttp.net/index.html
> CCNA って、何ですか？
Cisco 社の行っているネットワーク技術系資格試験です。
http://www.cisco.com/japanese/warp/public/3/jp/event/tra_ccc/ccc/certprog/lan/programs/ccna.html
> HTTP POST って、何ですか？
「POST http://remotehost/ HTTP/1.1」という意味です。 (^^;;
「GET http://remotehost/ HTTP/1.1」というのはよくあるですが、
これでは大量のデータを送信するのには向かないので。
＃なんとか HTTP POST で HTTP CONNECT の代わりをできないかと悩み続けて、
＃バージョンアップがもう１年以上も滞っています。ほぇ～～～。(^^;;;
> HTTP CONNECT というのは、Proxy に繋ぐ時に CONNECT なんとかと
「CONNECT remotehost HTTP/1.0」のつもりでした。
＃このメアドは、 SWEN.A が殺到するため、現在受信拒否です。
Yasushi Shinjo
In article <bs9b8r$3f7$1...@news511.nifty.com>
=?ISO-2022-JP?B?GyRCTD4+TklURGobKEI=?= <dev_...@anet.ne.jp> writes:
> CONNECT を許可してしまうとどんな内容（例えば機密情報が）が
> やり取りされていても判らないから、不用意に許可するのは
> 危険だとセキュリティポリシー制定委員会では考えているのでしょう。
> 暗号化されてしまってはフィルタリングもできませんし。
なるほど。世の中、一応そこまで来ていたわけですね。そういう所
はあるでしょうね。
> > HTTP POST って、何ですか？
> 「POST http://remotehost/ HTTP/1.1」という意味です。 (^^;;
> 「GET http://remotehost/ HTTP/1.1」というのはよくあるですが、
> これでは大量のデータを送信するのには向かないので。
SoftEther で TCP over HTTP(post) というのは、辛いかもね。
PC->Hub の方向はいいとして、逆向きの Hub->PC が。ポーリング
するのは、かなりつらい。POST で、リターンさせないで止めてお
くといいのかもしれません。中身は、画像かなにかに偽装するのは
簡単なんでしょう。
> ＃なんとか HTTP POST で HTTP CONNECT の代わりをできないかと悩み続けて、
> ＃バージョンアップがもう１年以上も滞っています。ほぇ～～～。(^^;;;
HTTP over HTTP なら、DeleGate でもできますよ。
http://www.delegate.org/delegate/
URL は、こんな感じ。
http://delegate-host/-_-http://url
昔は、公開 DeleGate (主にキャッシュ用)もあったのですが、不正
に使われることが多くてなくなりました。
http://www.rikai.com/perl/Home.pl
http://www.rikai.com/perl/HomePage.pl?Language=Ja
カーソルを単語に合わせただけで、その意味がポップアップで出て
きます。これは公開 proxy としてもまあ使えるのでしょう。
In article <bs70v6$eah$1...@news511.nifty.com>
名称不定 <dev_...@anet.ne.jp> writes:
> SoftEther の話はセキュリティホール memo で知りました。
どういう評価でした？
名称不定
Yasushi Shinjo wrote:
>>＃なんとか HTTP POST で HTTP CONNECT の代わりをできないかと悩み続けて、
>>＃バージョンアップがもう１年以上も滞っています。ほぇ～～～。(^^;;;
> HTTP over HTTP なら、DeleGate でもできますよ。
はい、それは知っていますが、超初心者向けのソフトなので、
DeleGate がインストールされていることを前提にするわけには
ちょっといかないものでして。 (^^;
>>SoftEther の話はセキュリティホール memo で知りました。
> どういう評価でした？
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2003/12.html#20031217_SoftEther
を参照してください。
MAEDA Atusi
問題(下の層の再送制御と上の層の再送制御がうまく同居できないので，通信
エラーがあると通信速度が極端に落ちたり，コネクションが頻繁に切れたりす
る)が起きたりしないでしょうか．
"Why TCP Over TCP Is A Bad Idea"
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
前田敦司
Yasushi Shinjo
In article <m365g6z...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <maeda...@ialab.is.tsukuba.ac.jp> writes:
> L2のデータをTCPパケットにカプセル化して送ると，PPP over SSHとかと似た
> 問題(下の層の再送制御と上の層の再送制御がうまく同居できないので，通信
> エラーがあると通信速度が極端に落ちたり，コネクションが頻繁に切れたりす
> る)が起きたりしないでしょうか．
通信速度は、そこそこ落ちているみたいです。２つのＴＣＰのタイ
マが働くことになって、上の方のＴＣＰは、通信の変動が大きいと
観測して、悪い回線だと思う、ということですよね。
パケットが落ち始めると、急激に悲惨になるというのが予想されま
すが、実際にはパケット落ちが激しそうな無線LANで使っても、圧
縮が効いて速くなったりするみたい。もともと遅いものと比較だか
らかも。
コネクションが切れたりすることは、あんまりないみたい。下のコ
ネクションが切れても、再接続の機能があるので、それで救われて
いるのかもしれませんが。
> "Why TCP Over TCP Is A Bad Idea"
> http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
こういう話を知らないで作り始めたみたいですが、知らなかったこ
とがかえって良かったんじゃないかなあ。
In article <bs9vhk$98m$1...@news511.nifty.com>
名称不定 <dev_...@anet.ne.jp> writes:
> はい、それは知っていますが、超初心者向けのソフトなので、
> DeleGate がインストールされていることを前提にするわけには
> ちょっといかないものでして。 (^^;
DeleGate は、どこかのグローバル・アドレスを持っている所に置
けばいいんですよ。SoftEther のハブと同じで。SoftEther が商売
なるなら、DeleGate でも、HTTP 専用でも商売になるかもね。
> >>SoftEther の話はセキュリティホール memo で知りました。
> > どういう評価でした？
> http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2003/12.html#20031217_SoftEther
> を参照してください。
ポインタだけでなくて、要約と評価の評価も欲しい。
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2003/12.html#20031217_SoftEther
----------------------------------------------------------------------
たいへん使いやすそうな (使いやすすぎる?!) VPN ソフトウェアのようです。
仮想ネットワークデバイスとして見えるようです。そのため、原理的には全て
のアプリケーションが VPN を利用できるのでしょう。要は Ethernet over IP
ってことでしょうか。 P2P な VPN ではなく、仮想 HUB を利用した VPN、と
いうところが新しいのかな。日本語ドキュメントが整備されているのはすばら
しいです。って、悪用するのはかんべんしてほしいですけど。
＜中略＞
少なくとも、仮想 HUB は public にアクセスできる場所にないとまずいの
かな。 public と言っても、TCP の port が 1 つ開いていればそれで十分っ
ぽいけれど。
＜後略＞
----------------------------------------------------------------------
仮想ハブは、グローバル・アドレスを持っていないといけないとい
うのはそうです。ハブのように共有してしまうと、本当は private
network (専用線の意味での)とは、言いにくいかなあ。
OpenVPN との比較もあったのですが、OpenVPN を使ったことがある
人いませんか？
Yasushi Shinjo
経済産業省とかＩＰＡ経由の要請で、ソフトウェアの公開が一時止
まったみたいです。
http://www.softether.com/jp/news/0312243.aspx
近日中に再開ということです。ソフトウェアもそうだけど、経済産
業省やＩＰＡの対応自体も、後々 SoftEther の宣伝という効果だ
けが残りそう。
ちょっと心配なのは、開発者の登さん、口がうますぎるところかな
あ。口がうまいということだと、中央官庁も侮れません。中央官庁
も横綱相撲で相手にしないくらいの対応が良かったんじゃないかなあ。
MAEDA Atusi
> > L2のデータをTCPパケットにカプセル化して送ると，PPP over SSHとかと似た
> > 問題(下の層の再送制御と上の層の再送制御がうまく同居できないので，通信
> > エラーがあると通信速度が極端に落ちたり，コネクションが頻繁に切れたりす
> > る)が起きたりしないでしょうか．
>
> 通信速度は、そこそこ落ちているみたいです。２つのＴＣＰのタイ
> マが働くことになって、上の方のＴＣＰは、通信の変動が大きいと
> 観測して、悪い回線だと思う、ということですよね。
上のタイマのタイムアウトの方が短い状況だと，
・上位での再送がほとんど全てタイムアウトする
→さらに上位で再送が起きる
→下位で送れるより速い速度でパケットが(再送のためだけに)enqueされる
ということを繰り返す状況になって，一種のメルトダウンが起きるというものです．
もっと素朴な話でも，ICMPやら，動画(RTP)やら，TCPのACKやらに対しても下
位で再送制御がかかるというのはちょっとどうよ，と思いますよね．
> パケットが落ち始めると、急激に悲惨になるというのが予想されま
> すが、実際にはパケット落ちが激しそうな無線LANで使っても、圧
> 縮が効いて速くなったりするみたい。もともと遅いものと比較だか
> らかも。
PHSとかで使うとどうですかね？まあ意図とは違うのかも知れませんが．
そういう用途のために，over UDPの解もあると良いかも．でも，危険かな?
> 経済産業省とかＩＰＡ経由の要請で、ソフトウェアの公開が一時止
> まったみたいです。
>
> http://www.softether.com/jp/news/0312243.aspx
>
> 近日中に再開ということです。ソフトウェアもそうだけど、経済産
> 業省やＩＰＡの対応自体も、後々 SoftEther の宣伝という効果だ
> けが残りそう。
良い宣伝ですね．
騒いでいる人は，いったい何が今までのVPNソフト(たとえばPPTPやPPP over
SSH)と違うか，理解していないかも．というか，むしろ登さんが，「今までの
VPNソフトよりはるかに危険である」かのような誤解を煽ったフシが無きにし
もあらず．これもまた新城さんのおっしゃる「口のうまさ」のひとつでしょう
か．
前田敦司
Yasushi Shinjo
In article <m3zndhr...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <maeda...@ialab.is.tsukuba.ac.jp> writes:
> 上のタイマのタイムアウトの方が短い状況だと，
> ・上位での再送がほとんど全てタイムアウトする
> →さらに上位で再送が起きる
> →下位で送れるより速い速度でパケットが(再送のためだけに)enqueされる
> ということを繰り返す状況になって，一種のメルトダウンが起きるというものです．
なるほど。上のＴＣＰの再転送を下で認識して、積極的に落とすと
どうなるんでしょうか。どうせ、下は信頼性があるので、再送はも
ともと不要なはずなので。
メルトダウンが起きるような状況を人工的に作り出して実験してみ
たいですね。どうすればいいですかね。実際の利用状況としては、
どういう時に起きるでしょうか。
> もっと素朴な話でも，ICMPやら，動画(RTP)やら，TCPのACKやらに対しても下
> 位で再送制御がかかるというのはちょっとどうよ，と思いますよね．
はい。まあ、それはそうなんでしょうが、実際には、もともと小さ
いデータが、空いている方向に流れるだけなら、帯域を圧迫すると
いうことは起きないということなんですかね。この辺りの解析がま
だまだ甘いというのは、あります。この辺り、先輩が援助できる所
があります。
下の ack は、データに piggy back されることもありますよね。
なんか別のデータを流した方が速くなるという話も聞いたような気
もします。再現性のある形で再現できるといいんですけどね。
> PHSとかで使うとどうですかね？まあ意図とは違うのかも知れませんが．
PHS のデモは、見たことがあります。別に平気でしたね。使ってい
て、これが SoftEther なしかありかを言い当てるのは見ているだ
けだと難しそう。分かる人はわかるんでしょうけど。
> そういう用途のために，over UDPの解もあると良いかも．でも，危険かな?
UDP が危険というよりは、UDP だと、壁抜けするのには不利なので
やっていないというところでしょう。この辺り、環境が大きく影響
与えています。そのうち、SoftEther の利用が増えて、性能も何と
かしてくれという話が出てくれば、対応してもいいんじゃないかなあ。
> 騒いでいる人は，いったい何が今までのVPNソフト(たとえばPPTPやPPP over
> SSH)と違うか，理解していないかも．
それは大きいと思います。今まで VPN の知名度は低くて、今回の
騒ぎ始めて聞いた一般利用者も多いのでしょう。逆に、「PPTP っ
てそんな危険性があったのか」と認識したり。
> というか，むしろ登さんが，「今までの
> VPNソフトよりはるかに危険である」かのような誤解を煽ったフシが無きにし
> もあらず．これもまた新城さんのおっしゃる「口のうまさ」のひとつでしょう
> か．
プレゼンテーションがうまかったという話の他に、技術的な話とし
ては、敷居が下がったという話はあるかと思います。PPTP は、例
の環境だと敷居が高いし。SSH って、Windows 方面には敷居が高い
みたい。IPsec の敷居の高さは、なんなんでしょうね。敷居を低く
することで、使い方に変化が起きるというのは、よくあるわけです
が、SoftEther もそういう側面は大きいと思います。
そういえば、SoftEther の話は、情報処理学会の新年会、プログラ
ミング・シンポジウムで発表するそうです。前野先生との連続なん
て誰がプログラム作ったんでしょうね。恐ろしい。私が言うのも変
ですが、シンポジウムでは登さんのことをよろしくお願いします。
http://www.ipsj.or.jp/prosym/45/
http://www.softether.com/jp/overview/paper/
MAEDA Atusi
> なるほど。上のＴＣＰの再転送を下で認識して、積極的に落とすと
> どうなるんでしょうか。どうせ、下は信頼性があるので、再送はも
> ともと不要なはずなので。
SoftEtherには輻輳制御(パケットを捨てる)や切断対策(60秒分のパケットをバッ
ファリングする)が入っているみたいなので、それが効いているのかも知れま
せん。このあたりは、研究ネタになるかも。
> メルトダウンが起きるような状況を人工的に作り出して実験してみ
> たいですね。どうすればいいですかね。実際の利用状況としては、
> どういう時に起きるでしょうか。
先に挙げたURLだと、10%～20%のパケットロスがあるような環境では、PPP
over SSHは使い物にならないとありました。PHSや無線で電波状況を悪くして
みるとか、SoftEtherを改造してパケットをランダムに(あるいはバースト的に)
落としてみるとかが思いつきます。
> > そういう用途のために，over UDPの解もあると良いかも．でも，危険かな?
>
> UDP が危険というよりは、UDP だと、壁抜けするのには不利なので
> やっていないというところでしょう。この辺り、環境が大きく影響
> 与えています。そのうち、SoftEther の利用が増えて、性能も何と
> かしてくれという話が出てくれば、対応してもいいんじゃないかなあ。
UDPだと「セッション管理」とか「認証」を自分でやらなければいけませんよ
ね。とくに、個々のパケットがちゃんと認証したセッションの続きであるかど
うか(途中から、偽造パケットが割り込んだりしていないか)の判定は、かなり
注意が必要かと思います。HMACとか使うんでしょうかね。
壁抜けに不利ということは別に無いんじゃないでしょうか。NAT箱でもファイ
アウォールでも、「中からUDPを送ると、しばらくの間そのポートへの返事の
UDPは返す」というのが多いんじゃないですか。
> > 騒いでいる人は，いったい何が今までのVPNソフト(たとえばPPTPやPPP over
> > SSH)と違うか，理解していないかも．
>
> それは大きいと思います。今まで VPN の知名度は低くて、今回の
> 騒ぎ始めて聞いた一般利用者も多いのでしょう。逆に、「PPTP っ
> てそんな危険性があったのか」と認識したり。
> プレゼンテーションがうまかったという話の他に、技術的な話とし
> ては、敷居が下がったという話はあるかと思います。PPTP は、例
> の環境だと敷居が高いし。SSH って、Windows 方面には敷居が高い
> みたい。IPsec の敷居の高さは、なんなんでしょうね。敷居を低く
> することで、使い方に変化が起きるというのは、よくあるわけです
> が、SoftEther もそういう側面は大きいと思います。
確かにSoftEtherのインパクトは敷居の低さかなと思います。
ふつーの研究者なら、既にあるものと組み合わせられる部品だけを作るという
発想になると思います。認証や仮想インターフェースはPPPがあるから作らず、
トランスポートはSSHやSSLにまかせて、仮想ハブだけ作るとか。
All-in-Oneで認証も暗号化も接続もインストールされちゃうというのが大きい
と思いますね。
> そういえば、SoftEther の話は、情報処理学会の新年会、プログラ
> ミング・シンポジウムで発表するそうです。前野先生との連続なん
> て誰がプログラム作ったんでしょうね。恐ろしい。私が言うのも変
> ですが、シンポジウムでは登さんのことをよろしくお願いします。
新年会ですか(笑)。まあ私も参加しますので、いろいろ話が聞けたらいいなと
思っています。
前田敦司
Yasushi Shinjo
In article <m34qvol...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <maeda...@ialab.is.tsukuba.ac.jp> writes:
> 先に挙げたURLだと、10%～20%のパケットロスがあるような環境では、PPP
> over SSHは使い物にならないとありました。PHSや無線で電波状況を悪くして
> みるとか、SoftEtherを改造してパケットをランダムに(あるいはバースト的に)
> 落としてみるとかが思いつきます。
パケットを意図的に落として様子を見るのは、面白そうですね。作
者がどう思うかわからないけれど。こういうのことを面白いと思う
には、修行が必要なんですが、まだ修行が足りないかも。修行とい
うと、policy-mechanism separation というのも勉強して欲しいん
だけど。
それで仮に 10% 落ちる状況でダメとなった時に、考え方として２
つあるのでしょう。
（Ａ）10% で使えなくなるからダメ。
（Ｂ）9%までなら十分使える。
研究者の態度は、だいたい（Ａ）なんですが、（Ｂ）というのもい
いですよね。この間、論文の査読で（Ｂ）として「ここまで使える
という範囲は明確にしろ」と書いたら、それっきり返事がなかった
なあ。範囲があれば採録にしようとおもったのに。
> 壁抜けに不利ということは別に無いんじゃないでしょうか。NAT箱でもファイ
> アウォールでも、「中からUDPを送ると、しばらくの間そのポートへの返事の
> UDPは返す」というのが多いんじゃないですか。
たしかに。もっといろいろな環境を試すといいでしょうね。
前の記事でウケを狙って「壁抜け」と書きましたが、正確にはトン
ネリングです。つまり、ファイア・ウォール等で許されている通信
機能だけを使って、別のプロトコルのデータを流すということです。
そういう意味では、ファイア・ウォールを破壊してしまうというわ
けではありません。その点念のため強調しておきます。
> UDPだと「セッション管理」とか「認証」を自分でやらなければいけませんよ
> ね。とくに、個々のパケットがちゃんと認証したセッションの続きであるかど
> うか(途中から、偽造パケットが割り込んだりしていないか)の判定は、かなり
> 注意が必要かと思います。HMACとか使うんでしょうかね。
なるほど。単にめんどくさいから作ってないいだけかも。誰かが作っ
たものをもらってくれるといいんでしょうね。OpenSSL に入ってい
てもいいような気もするのですけど。
> ふつーの研究者なら、既にあるものと組み合わせられる部品だけを作るという
> 発想になると思います。認証や仮想インターフェースはPPPがあるから作らず、
> トランスポートはSSHやSSLにまかせて、仮想ハブだけ作るとか。
あと、認証系や暗号系を自分で作ると、バグがあった時に困るし。
他人が作ったものなら、他人に責任を押し付けらるということもあ
りますが、多くの人が使っているものなら叩かれてバグが出尽くし
ているという期待もありますし。
あと、責任というと、パッケージングの責任は取らないといけない
んですけれどね。タイヤに欠陥があった時、組み立てたトヨタはど
うするか。その辺りと同じ話になるかと思います。
PKI とか challenge-response も、奥が深いものがあります。直感
的に良さそうでも、形式的に調べたらダメという話を最近よく聞か
されるので。自分で書くのはちょっと怖くなったという所はあります。
NAKAMURA Kazushi
In article <YAS.03De...@kirk.is.tsukuba.ac.jp>
y...@is.tsukuba.ac.jp writes:
>> 先に挙げたURLだと、10%～20%のパケットロスがあるような環境では、PPP
>> over SSHは使い物にならないとありました。PHSや無線で電波状況を悪くして
>> みるとか、SoftEtherを改造してパケットをランダムに(あるいはバースト的に)
>> 落としてみるとかが思いつきます。
>
>パケットを意図的に落として様子を見るのは、面白そうですね。作
FreeBSD,OpenBSDに付属するファイアウォールには、正にこの目的の
トラフィックシェイパ機能が有りますね。音屋さんのluigi教授が
始めたと思うのですが、色々なモデルに従って意図的にパケットを
落すファイアウォールが構築できます。
>それで仮に 10% 落ちる状況でダメとなった時に、考え方として２
>つあるのでしょう。
>
>（Ａ）10% で使えなくなるからダメ。
>（Ｂ）9%までなら十分使える。
>
>研究者の態度は、だいたい（Ａ）なんですが、（Ｂ）というのもい
研究者はそこまで考える必要は無いです。たいていある値に近付くと
急激に性能が低下するので、そのメルトダウンの起こる値を弾き出せば
十分です。その技術をどう使うか、あるいは使うか使わないかは、
ユーザの判断に任せれば良いです。
>あと、責任というと、パッケージングの責任は取らないといけない
>んですけれどね。タイヤに欠陥があった時、組み立てたトヨタはど
>うするか。その辺りと同じ話になるかと思います。
これが一番言いたかったのですが、注意書き、特にセキュリティ問題に
ついてのドキュメントをしっかり付ける必要が有ると思います。
アーカイブにリンクを貼ったHTMLファイルに書いているだけでは不十分
だと思います。他所から勝手に直リンク張られたり、あるいはアーカイブ
だけ勝手に再配布されると無意味なので。アーカイブ自体に含めて欲しい
と思います。
それはともかく、今の若い人で、ちゃんと動く物が作れる人が居るって
いうのは正直羨ましいです。新城先生の指導の賜ですかね。
--
中村和志＠神戸 <mailto:k...@kobe1995.net>
NAKAMURA Kazushi@KOBE <http://kobe1995.net/>
- Break the hate chain. No more kill!
administrator@127.1
Yasushi Shinjo
In article <0401072224...@ns.kobe1995.net>
k...@kobe1995.net (NAKAMURA Kazushi) writes:
> 中村和志＠神戸です。
> >（Ａ）10% で使えなくなるからダメ。
> >（Ｂ）9%までなら十分使える。
> >研究者の態度は、だいたい（Ａ）なんですが、（Ｂ）というのもい
> 研究者はそこまで考える必要は無いです。たいていある値に近付くと
> 急激に性能が低下するので、そのメルトダウンの起こる値を弾き出せば
> 十分です。その技術をどう使うか、あるいは使うか使わないかは、
> ユーザの判断に任せれば良いです。
研究者とユーザの定義の問題かなあ。ユーザは電話をかけるのと同
じくらい考える（電話番号とか電話料金とか盗聴とか）くらいで
いいんじゃないの。後はプロの仕事でしょ。SoftEther の作者はプ
ロでしょ。
「研究者」の理論が使われたかというと、今回の場合は、全然使わ
れていません。つまり、「TCP over TCP はダメ」という「研究者」
の結論があるわけですが、SoftEther の作者はそれを知らずに開発
を始めて、そこそこ使えるものを作ってしまったわけです。こうい
う結果を「研究者」は、どう思うかというと、「やられた」と思う
んじゃないのかなあ。
> これが一番言いたかったのですが、注意書き、特にセキュリティ問題に
> ついてのドキュメントをしっかり付ける必要が有ると思います。
> アーカイブにリンクを貼ったHTMLファイルに書いているだけでは不十分
> だと思います。他所から勝手に直リンク張られたり、あるいはアーカイブ
> だけ勝手に再配布されると無意味なので。アーカイブ自体に含めて欲しい
> と思います。
ドキュメントか。それはそうなんだけど。もう少しいい方法を追求
したいです。単に「ドキュメントを読め」だとユーザに責任を転嫁
するようなものなので、私はあまり好みません。Windows Update
しないユーザが悪いんじゃなくて、バグを入れた Microsoft が悪
いわけだし。VPN 単体ではなくて、ＯＳとかファイア・ウォールと
か大局的になんとかしないといけないですね。
> それはともかく、今の若い人で、ちゃんと動く物が作れる人が居るって
> いうのは正直羨ましいです。新城先生の指導の賜ですかね。
おっと。新城先生は、指導はしていません。
名称不定
Yasushi Shinjo wrote:
> れていません。つまり、「TCP over TCP はダメ」という「研究者」
TCP (with Nagle disabled) over TCP (with Nagle enabled) でも
ダメなんでしょうか？試したことないですが、いくらか遅延を
減らせないのかなぁ？
Yoshihiko SARUMARU
fj.net.lan.ethernet の <YAS.04Ja...@kirk.is.tsukuba.ac.jp> の記事において
2004-01-10(土) 07:05頃、y...@is.tsukuba.ac.jpさんは書きました。
> 「研究者」の理論が使われたかというと、今回の場合は、全然使わ
> れていません。つまり、「TCP over TCP はダメ」という「研究者」
> の結論があるわけですが、SoftEther の作者はそれを知らずに開発
> を始めて、そこそこ使えるものを作ってしまったわけです。こうい
> う結果を「研究者」は、どう思うかというと、「やられた」と思う
> んじゃないのかなあ。
http://www.itmedia.co.jp/lifestyle/articles/0401/08/news095_2.html
に作者のそのへんの苦労話が載ってますね。
--
猿丸芳彦 (Yoshihiko Sarumaru)
mail: mis...@imasy.or.jp web: http://www.imasy.or.jp/~mistral/
SoftEther の port 番号 7777 は cvsync と重なっているらしい
Yasushi Shinjo
予想通り、IPA/経済産業省のおかけで SoftEther はすっかり有名
になってしまいました。
In article <m3isjke...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <maeda...@ialab.is.tsukuba.ac.jp> writes:
> 前田です。
> とても全部は紹介できないのですが、19歳とは思えない落ち着いた発表ぶりが
> 特に印象的でした。おおむね非常にポジティブな反応でした。
それは、何よりです。同じセッションの前野先生を恐れていたんですが。
> 昼の技術的な発表では、TCP over TCP の問題点に関する言及もありました。
> パケットのまとめ方や捨て方などのパラメータ調節によって実用的には解決し
> たということですが、研究としてはもう少し考察が必要かなと感じました。
何か研究にして発表するなら、英語で書いて国際会議というのが狙
い目かなあという感じはします。日本語だと「過去のこれと比べて
これだけいい」みたいな話にしないといけないような気がするので。
査読者の自信がないせいか、「これは面白い」という評価を下せな
いんですよね。面白いのは面白いと認めていいんだと思うんだけど。
> まだ1年生ですからね。誰に研究指導を受けてるというわけでもないでしょう
> ね。彼も含めて、優秀な人を退屈させないような大学側の体制も考えなきゃい
> けないかも知れないけど、そういう人達は、大学なんていう枠を気にせずに色々
> と活動していくかもしれません。
大学と個人で相互にブランドが高め合えればベストですね。
というわけで、次の目標は世界を目指すとことに決まりました。