これは、特定のアプリケーションを念頭に置いていないと答えにくいですが、一般的なヒントをいくつか挙げてみます。
接続が許可されているすべてのクライアントのすべてのアドレスを格納するコンテナーを作成します (ログインの成功後)。
これは、悲しいことにまだ使用されており、IPv4 の枯渇のために実際に増加している NAT のため、単純に機能しません。少なくとも src-ip+src-port が必要です。それでも、モバイル ユーザーを考慮すると、IP をセッション ID として使用したくない場合があります。平均的なスマートフォンは、セルラー ネットワークと WiFi ネットワークを非常に簡単に切り替えますが、ほとんどの場合、IP スタックが完全に再起動されるため、新しいトラフィックを以前のトラフィックと関連付ける方法はありません。これは問題になる場合とそうでない場合がありますが、IP アドレスを制御できない限り、このアプローチを使用することはありません。
すべてのセッション ID を格納するコンテナーを作成します (セッション ID はすべてのパケットで送信されます)
これは実際には一般的なソリューションです。最初のソリューションは、source-ip をセッション ID として使用する特定の実装です。セッション ID の管理が心配な場合は、UUIDを使用してください。セッション ID 間の衝突の可能性は非常に低くなります。または、公開鍵/秘密鍵の暗号化を使用する場合、ユーザーの公開鍵をセッション ID として使用できます。
ここで重要な部分は、セッション ID をネゴシエートする方法です。ユーザーに選択させたい場合や、サーバーに選択させるために「特別な」セッション ID (たとえば 0) を使用したい場合があります。何が最適かは、アプリケーションによって異なります。
誰かがパケットの送信者のアドレスを変更できますか? （私はそう仮定します）
確かに、これは中間者攻撃(転送中のパケットに対して行われる場合) またはIP アドレス スプーフィング(偽の IP を含むパケットを送信する場合) と呼ばれ、ほとんどのエンド ユーザーには検出されません。多くのネットワークではこれに対する保護がありますが、たとえばReverse Path Forwardingを使用しています。
セッション ID が傍受される可能性があります。（この問題を抱えているいくつかの大企業を覚えています）
暗号化されている場合: たぶん (後述)。暗号化されていない場合: 確かに。
次に、暗号化の質問の全体について：
通常、通常のトラフィックには対称キー暗号化スキームを使用する必要があります。AES は良い選択ですが、他にもあります。調査を行ってください。
ただし、暗号化の設定に問題があります。一般に、暗号化キーは盗み見されることなく、両側で安全に取得する必要があります。キーを航空便で送ろうとすることもできますが、ほとんどのユーザーがそれをユーザーフレンドリーだと思うとは思えませんし、それでさえ本当に安全ではありません.
そこで、非対称キー暗号化スキームの出番です。通常、RSA のようなものを使用して初期接続 (セッション ID、暗号化キー、おそらくいくつかのアカウンティングなど) をネゴシエートし、対称キーが実際のトラフィックを引き継ぐようにします。人気のあるスキームはDiffie-Hellman 鍵交換ですが、これ以外にも他にもあります。
チャネルを非常にうまく保護できると言われていますが、中間者攻撃は常に懸念事項です. どちらか一方 (クライアント) を制御できないため、実際にこれを防ぐためにできることはほとんどないことがわかりました。感染したマシンである場合、すべての賭けは無効になります。
- 着信セッションで検証できる、ユーザーごとに事前に配布された固有の秘密鍵を使用します。これにより、他の方法でそのキーを取得しない場合、mitm 攻撃が難しくなりますが、自動生成されていない秘密キーは、多くの場合、使いやすさと組み合わせるのが困難です。それらを配布する方法（くそ、そこでmimをどのように処理すればよいですか？）、それらをユーザーに保存する方法（ああ、彼はラップトップ、iPhoneとiPadを使用しています）、紛失した場合にそれらを回復する方法に問題があります。 ..
- すべてのトラフィックがクライアントによって開始され、サーバーの公開鍵ですぐに暗号化されることを確認してください。秘密鍵を配布する必要がないため、これは簡単です。ただし、ハッカーはサーバーの公開鍵を独自の鍵に置き換えることができますが、それは非常に困難であり、正しく行うとクライアント コンピューターにウイルスをインストールすることになります。
- クライアント アプリケーションでサニティ チェックを実行します。たとえば、サーバー IP の既知のプールに接続していることを確認し、DNS クエリが正しいかどうかなどを確認します。フェイルセーフとは言えませんが、潜在的なハッカーを思いとどまらせる簡単な検証です。
- ユーザーを教育します。これは、多くの銀行が行っていることです (少なくとも私が住んでいる場所では)、定期的なウイルス対策チェックを行い、信頼できる WiFi ネットワークのみを使用し、DNS サーバーを検証します... . もちろん、教えるのが難しいこともありますが、少しの常識があれば、長い道のりを歩むことができます。
ああ、最後に、UDP の部分について実際にコメントしたいのですが、本当によろしいですか? このスキームのほとんどすべて、さらにはさらに多くのものがTLSでカバーされているため、これはboost asioに統合されています。トラフィックがそれほど低レートである場合、UDP が提供する利点を必要とするアプリケーションであるとはほとんど想像できません。voip を保護したい場合を除きます。これは既に行われています。車輪を再発明しないでください。