這項做確實是會因為下列幾項原因而讓實用性大增：
可以讓洋蔥路由更輕易的處理較新的網路協定，像是VoIP網路語音串流。
可以避免要求每個應用程式都必須走SOCKS介面。
出口節點也不再需要去為每個出口連線配置檔案描述子。
這是我們目前努力的方向，而幾個較困難的挑戰是：
IP網路封包會揭露作業系統的特徵。
我們會需要處理IP層的網路封包正規化，以防堵像是TCP特徵值分析之類的攻擊。
有鑑於TCP堆疊層的多元性與複雜性，在加上裝置特徵值分析攻擊的考量，目前最好的作法應該會是在作業系統的使用者權限層級載送自己的TCP堆疊。
應用程式層級的串流資料仍須經過淨化。
我們仍然需要像是Torbutton之類的使用者端的應用程式。
因此它並不只是單純的捕捉封包並在IP層進行匿名化處理而已。
有些通訊協定仍然會洩漏資訊。
舉例來說，我們必須要重新開發DNS請求模組，以便讓相關請求可以送到無法被識別關聯的DNS伺服器，而不是直接送網使用者的網路服務供應商的預設伺服器。因此，我們就必須要知悉我們所傳送的網路連線是哪種通訊協定。
目前DTLS(資料包傳輸層安全協定)已經無人使用，而IPsec又是個龐然大物。
一旦我們選定了某個傳輸層的機制，就必須要設計一個全新的端對端洋蔥路由協定，以防堵標記攻擊或者是其他與匿名性或完整性有關的問題，因為我們必須要允許封包丟失與重送等機制。
對特定的IP封包賦予不同的出口政策就意謂著要開發一套安全的入侵偵測系統(IDS)。
我們的中繼節點架設者告訴我們說，出口政策機制的設計是他們會願意架設 Tor 節點的主要原因之一。
在出口政策機制裡加入入侵偵測系統無疑會增加洋蔥路由的安全性複雜度，且有鑑於大量有關入侵偵測系統研究領域的論文，這個策略也不可能無效。
由於洋蔥路由只允許傳輸有效的TCP資料串流，杜絕了許多可能的濫用問題(例如特定的IP包裝特製的惡意封包以及IP洪氾。)
若要允許傳送IP封包的話，那出口政策就會便得更加重要。
我們也必須要以更精實的形式將個節點的出口政策呈現在洋蔥路由目錄中，以便讓客戶端程式得以預測哪些節點能夠轉送它們的網路封包。
客戶端程式也必須在選定出口節點的時候，就能夠精準預測在該工作階段中會需要傳送的網路封包型態！
洋蔥路由的內部命名空間需要重新設計。
我們目前支援洋蔥服務的「.onion」位址的方式，是在請求通過 Tor 客戶端程式時，攔截捕捉該位址。
若要在IP層去處理這項工作，必須要再設計一個位於洋蔥路由與本地端DNS解析器間更加複雜的介面。
不行，您不能夠信任網路所選出的路徑。
因為惡意的中繼節點可以藉機將您的連線流量導入他的同夥所架設的節點中。
這樣就會使惡意人士有能力監控到您完整連線的兩個端點了。
若將每個洋蔥路由使用者都設計成中繼節點的話，是可以將整個網路擴充到足以容納我們的所有使用者，並且架設自己的洋蔥路由中繼節點亦可強化匿名性。
然而，並非每個洋蔥路由使用者都能夠成為優良的中繼節點，舉例來說，在那些在有防火牆過濾封鎖的區域網路中，或是透過數據機連上網等網路環境的主機執行 Tor 程式的話，它們並沒有辦法正常的轉送他人的網路流量。
為這些客戶端程式提供服務，是與對所有人提供有效的匿名保護同等關鍵，因為許多洋蔥路由使用者的網路環境都會受到這類的侷限，若將這些客戶端程式囊括進來的話，能夠有效擴大整個網路的匿名集合。
有鑑於此，我們也同時也鼓勵洋蔥路由使用者去架設中繼節點，因此我們的方向是將中繼節點的架設與維運工作盡可能的簡化。
在過去幾年我們也已經在簡化設定方面有了許多進展，現在 Tor 程式可以自動偵測其所在的網路環境以及可用的頻寬。
要達成此目標必須經過四個階段的工作：
第一個階段的工作，是要將可用頻寬自動估算的機制再強化，使其推估結果能夠更精準。
或許切換到UDP傳輸會是最簡單的解決方式，然而事實並非是這麼單純。
第二個階段則是，要想辦法提昇可擴充性，這包括對於網路(如何能夠不用要求所有洋蔥路由中繼節點必須與其他所有節點連通)，以及對於目錄(如何能夠不用要求所有洋蔥路由使用者取得所有洋蔥路由中繼節點資訊)。
這類的變動可能會對目前的匿名保護機制造成巨大的衝擊。
細節可參考挑戰這篇論文的第5章節。
再次強調，採用UDP傳輸是會有幫助的。
第三階段的工作，我們仍需要更深入研究一種情境的風險，就是在允許攻擊者發動網路流量通過您的中繼節點時，您又同時發動自己的匿名連線的情況下。
有三份不同的研究論文提出了幾個方法，可以藉由發動網路連線通過幾個預選的中繼節點，即可藉由觀測該些連線的流量悸動來識別出其他迴路所使用的中繼節點。
在洋蔥路由的環境中，只要中繼節點本身不要同時扮演客戶端程式的功能，那這類的堵塞攻擊法其實並不可怕。
但是今天如果我們要鼓勵更多的客戶端程式啟用中繼節點功能的話(不論是橋接中繼站還是普通的中繼節點)，那就必須要先深入了解這種威脅模型的風險，進而去降低風險程度。
第四階段的工作，我們會需要提供一些誘因，以鼓勵更多人願意為他人轉送網路流量，甚至是成為出口節點。
這是我們目前想到的誘因。
還請您盡可能的協助！
假使能夠讓中繼節點維護者直接在出口政策裡做像是reject www.slashdot.org的設定(或是封鎖其他網站的IP位址)，完全不需要去查詢該網域中使用了哪些IP位址的話，那當然是最好不過得事了。
然而，這樣子是會有兩個問題。
第一個是，使用者仍然是可以繞過這些封鎖。
例如說，他們的 Tor網路連線，可以直接針對IP位址來發送請求而非主機名稱。
這個意思就是說，節點維護者還是必須要查出該網域中的所有IP位址才行。
第二個問題是，這樣的設計會讓針對特定網站的審查過濾攻擊變成可能。
例如當洋蔥路由節點管理員針對www1.slashdot.org進行封鎖時，那如果有攻擊者去篡改洋蔥路由中繼節點的DNS，或者將該網域名稱解析出的IP位址置換成某個主流新聞網站，此時該洋蔥路由中繼節點就會變成是在封鎖該新聞網站了。