這項做確實是會因為下列幾項原因而讓實用性大增: 可以讓洋蔥路由更輕易的處理較新的網路協定,像是VoIP網路語音串流。 可以避免要求每個應用程式都必須走SOCKS介面。 出口節點也不再需要去為每個出口連線配置檔案描述子。

這是我們目前努力的方向,而幾個較困難的挑戰是:

  1. IP網路封包會揭露作業系統的特徵。 我們會需要處理IP層的網路封包正規化,以防堵像是TCP特徵值分析之類的攻擊。 有鑑於TCP堆疊層的多元性與複雜性,在加上裝置特徵值分析攻擊的考量,目前最好的作法應該會是在作業系統的使用者權限層級載送自己的TCP堆疊。

  2. 應用程式層級的串流資料仍須經過淨化。 我們仍然需要像是Torbutton之類的使用者端的應用程式。 因此它並不只是單純的捕捉封包並在IP層進行匿名化處理而已。

  3. 有些通訊協定仍然會洩漏資訊。 舉例來說,我們必須要重新開發DNS請求模組,以便讓相關請求可以送到無法被識別關聯的DNS伺服器,而不是直接送網使用者的網路服務供應商的預設伺服器。因此,我們就必須要知悉我們所傳送的網路連線是哪種通訊協定。

  4. 目前DTLS(資料包傳輸層安全協定)已經無人使用,而IPsec又是個龐然大物。 一旦我們選定了某個傳輸層的機制,就必須要設計一個全新的端對端洋蔥路由協定,以防堵標記攻擊或者是其他與匿名性或完整性有關的問題,因為我們必須要允許封包丟失與重送等機制。

  5. 對特定的IP封包賦予不同的出口政策就意謂著要開發一套安全的入侵偵測系統(IDS)。 我們的中繼節點架設者告訴我們說,出口政策機制的設計是他們會願意架設 Tor 節點的主要原因之一。 在出口政策機制裡加入入侵偵測系統無疑會增加洋蔥路由的安全性複雜度,且有鑑於大量有關入侵偵測系統研究領域的論文,這個策略也不可能無效。 由於洋蔥路由只允許傳輸有效的TCP資料串流,杜絕了許多可能的濫用問題(例如特定的IP包裝特製的惡意封包以及IP洪氾。) 若要允許傳送IP封包的話,那出口政策就會便得更加重要。 我們也必須要以更精實的形式將個節點的出口政策呈現在洋蔥路由目錄中,以便讓客戶端程式得以預測哪些節點能夠轉送它們的網路封包。 客戶端程式也必須在選定出口節點的時候,就能夠精準預測在該工作階段中會需要傳送的網路封包型態!

  6. 洋蔥路由的內部命名空間需要重新設計。 我們目前支援洋蔥服務的「.onion」位址的方式,是在請求通過 Tor 客戶端程式時,攔截捕捉該位址。 若要在IP層去處理這項工作,必須要再設計一個位於洋蔥路由與本地端DNS解析器間更加複雜的介面。