はじめに

(ここに述べるのは、私個人の意見と、Project MAC におけるネットワーク・ワーキング・グループの合意を代表すると私が考える意見の双方である。代名詞「私」と「私たち」は両者を区別するために用いている。)

4 月 21 日と 23 日、Thomas P. Skinner と私は、UCLA の Steve Crocker とネットワーク・プロトコルについて、とりわけ NWG/RFC 46 における我々の提案について電話で話し合った。議論した項目は以下のとおりである。(Steve には、私が彼の言葉を言い間違えていたら許していただきたい。)

Steve は、動的再接続の必要性は後にネットワーク参加者に認識されるようになるだろうと述べた。しかし合意が得られていないため、当初の実装には含めない。(我々 Project MAC は、最初は含めないというこの方針を支持する。)
Steve は、NWG/RFC 46 に記述された INT ネットワーク・コマンドの実装を支持した。

このコマンドにより、ソケット接続上で割り込みを受け入れることに同意したプロセスは、他端のプロセスから確実に割り込まれることができる。割り込みは、プロセスに現在の実行を中断させ、INT ハンドラとして指定した手続きを実行させる。(NCP は INT ハンドラを規定しない。それは上位プロトコルの役割である。)

INT コマンドは、第三レベルのユーザー制御通信 (UCC) プロトコルが「終了」信号を実装するために使うことを想定して設計されている。そのようなプロトコルでは、要求側と生成された側のプロセスが、特定のソケット接続に関わる INT を NCP 制御リンクを通じて生成されたプロセスへ送ることを標準の「終了」信号とみなすことに合意する。生成されたプロセスは、この「終了」機能を実装する INT ハンドラを提供する。(これは、他の第三レベル・プロトコルが INT を別様に解釈することを妨げるものではない。)

多くのシステムは「終了」をテレタイプ入力ストリーム中の制御文字として実装しているが、CTSS や Multics などのシステムは回線上の 200 ms の間隔として実装している。我々 MAC は、前者はネットワーク内では望ましくない実装だと考えている (後者は不可能である)。私がその理由をいくつか挙げた (Steve も同意したと思う)。

(a) 終了文字を伝送するリンクがブロックされている可能性がある。

(b) 割り込みは NCP 内で実装するのが最も効果的であるが、NCP が伝送中のデータに特定の構造を課すのは望ましくない。(以下の議論を参照。) 制御文字を求めてデータ・ストリームを走査するとなれば、それは必要になる。

Steve は、INT を「終了」として実装しても、HOST が入力ストリーム中の制御文字を同じく「終了」と解釈することを必ずしも排除しない、と指摘した。

Steve は、インスタンス・タグをソケット識別子に含めることにも、将来の定義のために識別子にヌル・フィールドを予約することにも反対している。彼は理由をいくつか挙げた。

(a) 一人のユーザーの複数のプロセスは、外部のプロセスからは区別できないべきである。(プロセスが共同作業のために調整されている場合には、私もこれを認める。しかし、同じユーザーの二つのプロセスがそれぞれ独立してネットワークを使いたい場合はどうか。)

(b) 外部ユーザーのプロセスの一つに接続したいプロセスは、目的の特定プロセスのインスタンス・タグを知らず、容易に知ることもできない。

Tom は、ユーザー・コードの下位 3 ビットを、後にインスタンス・タグとして解釈するために予約してはどうかと述べた。彼は、独立したフィールドはあまり重要ではないと考えている。

Steve の論拠には一理あるように思える。Tom の提案が進むべき道かもしれない。この件について私はまだ決めかねている。

我々は皆 (Steve と MAC)、NCP レベルでは伝送されるデータに特別な構造を課すべきではないという点で一致しているようである。NCP にとって、伝送されるデータはすべて任意長のビット列である。一つ嬉しい結果は、文字集合という難しい問題をこのプロトコル・レベルで解決しなくてよいことである。NCP レベルに文字集合の指定を含めれば、プロトコルについての合意が遅れ、その文字集合は変更に対してより抵抗が強くなる。(標準の文字集合を定めるなら、我々は ASCII を望む。何しろそれは、我々の後援機関が好む標準なのである。)

我々はまた、NCP プロトコル・レベルではメッセージの任意のエコーを行うべきではないという点で Steve に同意する。(これは RFC 44 における SDC の人々の立場でもある。)

Shoshani、Long、Landsberg も (RFC 33)、二重パディングではなくメッセージをワード境界で終わるように整列させることを好むと述べている。Steve も、二重パディングを好まない点で我々と一致している。
我々の提案 (RFC 46) では、RFC は開いているソケットに対してのみキューに入れ、非活動状態または接続済みのソケット宛ての RFC は CLS コマンドによって自動的に拒否することにしている。Steve は、これらのソケット宛ての RFC を短時間キューに入れることを提案する。RFC が到着した後、ソケットが特定の期間にわたって受け入れがたい状態のままであれば、それは拒否される。この方式により、危急な競合を伴う特定の種類のネットワーク・コマンド相互作用が実装可能になる。このような限定されたキューの方式は、私には不合理とは思えない。
Steve、Tom、そして私は、ユーザー制御通信 (UCC) プロトコルの戦略について議論した。Steve は、我々の UCC 戦略 (RFC 46) が、要求側プロセスへの二つの全二重接続を維持し、その間で切り替えることを要求するので好まない、と述べた。

Steve は別案を提示した。外部の HOST にユーザー・プロセスを生成したいプロセスは、そのプロセスを生成したいユーザーに属するソケット 0 と 1 に RFC を発行する。これらのソケットが非活動状態であれば、NCP はこれらの要求を自動的に外部 HOST のロガー・プロセスへ向ける。ロガーは接続を受け入れ、ログインの儀式を行う。成功すれば、ロガーはユーザー・プロセスを生成し、奪ったソケットを手放して、生成されたプロセスがそれらを使って要求側プロセスと通信できるようにする。(これはネットワーク・レベルでの再接続を用いていないことに注意する。ロガーは最終的なユーザーに属するソケットを使うからである。ただし、内部的な再接続は伴う。)

Tom と私は、これが UCC プロトコルを NCP レベルに持ち込むとして反対した。(NCP は、非活動状態のソケット 0 と 1 宛てのすべての RFC をロガー・プロセスへ向けなければならない。) 私は、我々の二つの提案を組み合わせ、要求側が UCC プロセスの「信号」ソケットへ「シグナリング」RFC を発行するようにしてはどうかと、その場で提案した。UCC はその RFC を拒否するが、誰が呼んでいるかは記憶する。次に、生成されるプロセスの二つのソケットを要求側のソケットに接続しようと試み、それらを通じてログインの儀式を行う。Steve はこれを気に入り、私に書き記すよう勧めた。

会談の後、私はこの UCC 戦略にいくつかの欠点があると考えた。

(a) 生成されたプロセスの制御ソケットが 0 と 1 に限られると、正当なユーザーが外部の UCC と通信できない可能性がある。UCC がすでにそれらのソケットを偽装者との通信に使っているからである。ロガーはこれを見つけて偽装者を切断するが、これは腹立たしいセキュリティ上の破れである。悪意あるプロセスが同時に複数の要求を発行してソケットを占有し、正当なユーザーのアクセスを妨げることもあり得る。より良い解決策は、潜在的なユーザー・プロセスの任意のソケット対を制御経路として使えるようにすることである。そうすれば UCC は、競合する要求側を同時に取り調べることができる。

(b) Crocker の方式と統合方式の双方に共通する欠点は、ログインさせようとするユーザーを、特定のユーザーに属するソケットを与えることで指定する点である。ロガーは、自分がログインさせているユーザーが、実際に通話に用いているソケット対に属することを追加で確認しなければならない。これは、ユーザーを識別してからそのソケット識別子のユーザー・コードを求めるという、我々が好む手順の逆であるように思える。

(c) ユーザーは、外部 HOST でログインさせたいユーザーのソケット・ユーザー・コードを知らないかもしれない。(何しろ、要求側が外部のロガーを満足させる限り、要求側と生成されたプロセスが同じユーザー・コードを持つべき基本的な理由はない。)

(d) 統合戦略では、要求側がどのソケット・ユーザー・コードを望むかを指定する方法がない。UCC ができる唯一の想定は、要求側プロセスが自分と同じソケット・ユーザー・コードを持つプロセスをログインさせたいのだろうというものである。(これはあまり重要でないように思えるかもしれないが、私は、ローカル HOST に接続されたコンソールがローカルでログインせずに外部 HOST にログインできるようにするローカル・プロセスが存在する方式を思い描いている。)

(e) プロセスが自分のソケット・ユーザー・コードを使って、ネットワーク内で別のプロセスになりすますこと (たとえ最善の意図であっても) を許す考えは、潜在的に危険なセキュリティ上の破れをもたらす。私は、いかなるプロセスも、自分のものではないユーザー・コードを持つソケット上で接続を要求・受諾したり、データを送受信したりしてはならない、というのが基本のプロトコル法であるべきだと考える。これは、そのような伝送に責任を持つ NCP プロセスには当てはまらず、特権プロセスが外部プロセスと別のローカル・プロセスとの間の接続を閉じたり拒否したりすることも妨げない。

私は依然として、RFC 46 で我々が提案した UCC 方式が実行可能な良い方式だと考えている。ソケット再接続 (ネットワーク全体で明示的に、あるいは NCP 内部で暗黙に) を必要とせず、上に挙げた反対意見のいずれも当てはまらない。私が思う唯一の不利な点は、要求側プロセスが二つの全二重接続を維持して切り替えることを要求されることである。私はこれを重大な妨げとは考えない。特にこの点について、ネットワーク参加者の意見を聞きたい。

幸いなことに UCC は第三レベルのプロトコルである。第二レベルの NCP は、我々が UCC について最終的な合意に達する前に規定できる。ただし、その NCP が実行可能な UCC の実装を許す限りにおいてである。

Steve は、最初から標準の UCC がある必要はなく、複数の UCC があり得るとの考えを述べた。我々 MAC は反対である。もし我々が皆互いに、ネットワーク内の限られた HOST の部分集合の間だけでなく話すのであれば、全員が実装する初期の標準 UCC がなければならない。(他の実験的な UCC も実装され得るという Steve の指摘はもちろん正しい。)

理論的には、各 HOST が複数のソフトウェア一式を提供し、要求側プロセスが異なる UCC を実装する HOST のロガーと通信できるようにすることは可能である。実際にはそうはならないと私は考える。各 HOST は自分にとって最も好ましい UCC プロトコルを実装し、ソフトウェア一式を一つだけ提供して、要求側プロセスが同様の UCC を実装する HOST とのみ通信できるようにするだろう。

我々自身と話すためだけに非標準の UCC を実装することに、Project MAC にはさほど熱意がないと私は考える。我々は、すべてのサイトで支持される単一の UCC を実装し、このプロトコルを使ってすべての HOST にログインでき、すべての外部 HOST のユーザーが我々にログインできるようにしたい。

注: この RFC は、オンライン RFC アーカイブへの登録のために、Altair Petrofsky によって 7/97 に機械可読形式にされた。