این کار به چند دلیل مفید خواهد بود: این باعث می‌شود Tor بتواند پروتکل‌‌های جدید مانند VoIP را بهتر مدیریت کند. این کار می‌تواند کل نیاز برنامه‌ها به استفاده از SOCKS را برطرف کند. رله‌های خروج نیز نیازی به تخصیص تعداد زیادی توصیفگر فایل برای تمامی اتصالات خروج نخواهند داشت.

ما در حال حرکت به این سو هستیم. برخی از مسائل دشوار عبارتند از:

  1. بسته‌های IP ویژگی‌های سیستم‌عامل را آشکار می‌کند. ما همچنان باید نرمال‌سازی بسته‌ها در سطح IP را انجام دهیم تا مواردی مانند حملات انگشت‌نگاری TCP را متوقف سازیم. این‌طور به نظر می‌رسد که با توجه به تنوع و پیچیدگی پشته‌های TCP همراه با حملات انگشت‌نگاری دستگاه، بهترین شرط ما ارسال پشتهٔ TCP در فضای کاربری خودمان باشد.

  2. جریان‌های در سطح برنامه هنوز نیاز به پاک‌سازی دارند. ما همچنان به برنامه‌های سمت کاربر مانند Torbutton نیاز خواهیم داشت. بنابراین موضوع تنها گرفتن بسته‌ها و ناشناس‌سازی آن‌ها در لایهٔ IP نخواهد بود.

  3. بعضی از پروتکل‌ها همچنان اطلاعات را نشت می‌دهند. برای مثال، ما باید درخواست‌های DNS را بازنویسی کنیم تا به‌جای سرور DNS در ISP کاربر، به یک سرور DNS که به کاربر قابل‌پیوند نباشد، تحویل داده شوند؛ بنابراین، باید به پروتکل‌هایی که انتقال می‌دهیم آگاه باشیم.

  4. DTLS (داده‌نگار TLS) اساساً کاربر ندارد و IPsec قطعاً بزرگ است. اکنون که اجازهٔ دفع، ارسال‌های مجدد، و جز آن‌ها را می‌دهیم، همین‌که یک سازوکار حامل را انتخاب کردیم، باید یک پروتکل Tor سر-تا-سری جدید برای جلوگیری از حملات برچسب‌گذاری و سایر مشکل‌های بالقوهٔ ناشناسی و صحت طراحی کنیم.

  5. سیاست‌های خروج برای بسته‌های IP اختیاری به معنای ساختن یک سامانهٔ تشخیص نفوذ امن (IDS) است. اپراتورهای گرهٔ ما به ما می‌گویند که سیاست‌های خروج، یکی از دلایل اصلی است که آن‌ها مایل به اجرای Tor هستند. افزودن یک IDS به سیاست‌های خروج، پیچیدگی امنیتی Tor را افزایش خواهد داد و به هر حال , همانطور که در کل زمینهٔ IDS و اوراق ضد IDS مشهود است، احتمالاً عملی نخواهد بود . بسیاری از مشکلات بالقوه سوء استفاده با این واقعیت حل می‌شوند که Tor تنها جریان‌های TCP معتبر را منتقل می‌کند ( برخلاف IP اختیاری شامل بسته‌های معیوب و سیل‌ IP . ) در حالی که قابلیت انتقال بسته‌های IP را پیدا می‌کنیم، سیاست‌های خروج اهمیت بیشتری پیدا می‌کنند. ما همچنین باید سیاست‌های خروج را به‌طور فشرده در شاخهٔ Tor توصیف کنیم تا کلاینت‌ها بتوانند پیش‌بینی کنند که کدام گره‌ها به بسته‌هایشان اجازه خروج می‌دهند . کلاینت‌ها همچنین باید تمام بسته‌هایی را که می‌خواهند قبل از انتخاب گرهٔ خروجی خود در یک نشست ارسال کنند، پیش‌بینی نمایند!

  6. فضاهای نام داخلی Tor باید بازطراحی شوند. ما نشانی‌های سرویس پیازی «onion.» را هنگامی که به مشتری Tor ارسال می‌شوند، با رهگیری نشانی‌ها پشتیبانی می‌کنیم. انجام این کار در سطح IP به رابط پیچیده‌تری بین Tor و تحلیل‌گر DNS محلی نیاز دارد.