2

C# と .NET Framework 4.5 を使用してICE-TCP (RFC 6544 https://www.rfc-editor.org/rfc/rfc6544 ) を実装するのに忙しいです。ただし、次のようなプロトコルレイヤリングに関連する非常に難しい問題に直面しています。

ICE-TCP RFC は次のように述べています。

「ICE では、エージェントが STUN とアプリケーション層のトラフィックを逆多重化する必要があります。これらは同じポートに現れるからです。この逆多重化は [RFC5245] で説明されており、メッセージのマジック クッキーやその他のフィールドを使用して行われます。
ストリーム指向トランスポートは、STUN パケットをアプリケーション層トラフィックから区別するために、アプリケーションと STUN パケットを抽出できるように接続をフレーム化する方法を必要とするため、別の問題をもたらします。
このため、ICE を利用する TCP メディア ストリームは、アプリケーション層プロトコルが RTP でなくても、 RFC 4571 ( https://www.rfc-editor.org/rfc/rfc4571#section-2 ) で提供される基本的なフレーミングを使用します。 </p>

フレーミング方法は次のようになります。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 ---------------------------------------------------------------
|             LENGTH            |  RTP or RTCP packet ...       |
 ---------------------------------------------------------------

また、実装で TLS を使用したいのですが、ICE-TCP RFC には次のように書かれています。

Transport Layer Security (TLS) または Datagram Transport Layer Security (DTLS) が使用される場合、それらは RFC 4571 フレーミング シム上でも実行されますが、STUN は (D)TLS 接続の外部で実行されます。結果の ICE TCP プロトコル スタックを図 1 に示します。左側に (D)TLS があり、右側に (D)TLS がありません。」</p>

最後に、ICE TCP スタックは次のようになります。

                   +----------+
                   |          |
                   |    App   |
        +----------+----------+     +----------+----------+
        |          |          |     |          |          |
        |   STUN   |  (D)TLS  |     |   STUN   |    App   |
        +----------+----------+     +----------+----------+
        |                     |     |                     |
        |      RFC 4571       |     |      RFC 4571       |
        +---------------------+     +---------------------+
        |                     |     |                     |
        |         TCP         |     |         TCP         |
        +---------------------+     +---------------------+
        |                     |     |                     |
        |         IP          |     |         IP          |
        +---------------------+     +---------------------+

だから私は図の左側に興味があります。この図は、フレーミング ヘッダーが TLS 暗号化の範囲外にあり、暗号化されていないヘッダーをストリームに書き込む必要があることを示しています。

現在、私のアプリケーションは、TCPClient から取得した NetworkStream をラップした SslStream クラスを使用しています。私の最初の意図は、フレーミング ヘッダーを NetworkStream に書き込み、その後、暗号化されたアプリケーション データを SslStream に書き込むことでした。いくつかの調査の後、私はこれを見つけました：

「AuthenticateAsClient/Server の後、接続は SSL で保護されます。その場合、Socket または NetworkStream メソッドを呼び出さないでください。これにより、SslStream が壊れます。」出典: C# Sockets and SslStreams

そのため、SSL 接続が確立されると NetworkStream に書き込むことができません。

私の質問は、TCP (NetworkStream) と TLS (SslStream) の間にヘッダーを「配置」する方法はありますか?

前もって感謝します。

よろしくお願いします

マーカス

4

1 に答える 1

2

インスタンスは、インスタンスSslStreamの上に自分自身を重ねていNetworkStreamます。SSL ストリームに書き込むデータはすべて SSL ストリームによって処理され、生成されたデータはすべてNetworkStreamインスタンスに書き込まれます。

への参照を保持すると、SSL ストリームをバイパスして、必要に応じNetworkStreamて に直接読み書きできます。NetworkStream

に直接書き込んだものが接続の両側でNetworkStream読み取られないようにしている限り、は正しく動作し続けます。SslStreamSslStream

事実上、2 つのバイト ストリームを 1 つのストリームに多重化します。これらのバイト ストリームの 1 つは SSL ストリームになり、もう 1 つは他のストリームと同じになります。接続の両端が 2 つのストリームを切り替えるタイミングを認識している限り、問題はありません。

于 2013-10-21T20:16:29.673 に答える