我們得出結論，正確的短期行為是設計LLID，假定它們都公正的短期存在，在短期行運行，默許更長的有效期。這意味著我們可以得到一個適當的長期機制，首先，操作上將具備更低的安全級別。當我們有了更好的自動安裝的工具，我們可以在個人基礎上縮短有效期，而不需要在包的前進路徑上替換機制。
* 安裝反應時間
傳統的互聯網在終結點之間的通信路徑上沒有任何等待時間，支持快速處理的經典的數據模式等等都作為一項功能被保留了下來。
為使安裝預先完成，雙方都要通過管理接口或后臺的終結點。反應時間一般在響應特殊應用請求的動態預約時發生。
我們觀察到當反應時間是密鑰的結果時，它不會被安全關系所影響。像RSVP和ST－II的資源附加協議的設計者現在爭論協議的等待時間，缺少安全。作為證明人的補充請求消息需要增加使請求生效的加工，并且可能通過證明服務包含信息交換。但無法在安裝階段及時的完成實體交換。因為可能已經在安裝階段有了來回路程上的延遲。但對于安裝協議的高級別的鑒定和授權方法必須了解這個過程，當不需要知道每一個包的處理級別的時候，有時仍然需要該過程。
處理安裝過程的請求的方法是建立請求和在后臺執行確認。這會在短時間內限制來自不利安裝的破壞。注意，即使如此，系統對于一系列的安裝請求仍然是脆弱的，在短時間內可能有未經授權的訪問。
注意，使用無效的安裝請求可能導致安裝過程的溢出。所以過程都必須被處理或溢出。這可使有效使用者建立任何狀態。即使如此，否定服務攻擊建立在溢出級別的非常巨大的“指紋”：他們沒有經常受到巨大的威脅。如果這是一個問題，等同于指紋的安裝處理過程級別的機制上組成公司。限制在包裝級別的破壞攻擊。
4.5 接受端初始安裝
最近工作在QOS Internet 擴展，補充了RSVP協議，使用接受者接收資源的模式。這種機制與現存的IP通訊機制相一致，需要接收人參加通訊組。接收方存儲資源保證通訊運輸達到接收方在預期的QOS下。在這種情況下，需要接收方的證書（HLIDs）提示進入安裝階段。
注意接收方初始化請求在顯示安裝階段。假定是隱藏安裝，且在現有的包內。通過特殊的接收方沒有特定的關聯包，在通訊中。接收方的地址不在包中出現。
進一步的說，沒有可能在這種情況下執行“預先”安裝。除非發送方和接收方非常緊密的協調。否則，接收方預先不知包中有LLID。的確可能的是，這種情況下，接收方為通訊傳輸建立半永久附加條款。不是安全發行；不存在補充的安全關系。但是安全建筑必須考慮在內。
4.6 其他問題
4.6.1加密防火墻和輔助通路
我們的安全觀點，終接點和網絡保護。包括防火墻的使用，需要或多或少的分配網絡區域。在軍事和信息組中加密防火墻模式的使用很普遍：紅色（信任）網絡從黑色（不信任）網絡分開。非常有效的區別是，在軍事模式中，分割使用加密編碼通過黑色網絡到紅色網絡是可能的。因此，加密目的單元，在其他中，提供非常高度的保護以防止在紅色網絡中泄漏數據。與之相反，我們的防火墻保護信任（紅色）區域的范圍免受攻擊。當它進入和離開時。在網絡信任部分的結點和不信任部分的結點不可以進行交流。
在軍事加密防火墻的情況下，我們可以采用我們的安全QOS模式。即使如此，這種加密通過我們的安全資源管理仍然出現一個問題。討論上面的內容，包括安全處理和分類兩個階段。這種結構是有問題的，因為它需要信息從紅色區域到黑色區域清晰的通過。這些信息包括安裝包本身，如果安裝從終結點和數據包的分組區域（LLIDs）動態完成。顯然，當信息從紅色網絡區域出來時不能加密，因為它對黑色區域是無意義的，因此黑色區域不能把資源分配決策建立在它的上面。
為了對控制方案進行分組，它需要加密設備執行特定的包裹和在包裹內區域來通過加密。加密操作的輔助通道極度不良。在安全要求很高的情況下，處理生成的輔助信息可能被破壞，所導致的結果是，可被控制的信息從安全網絡中通過輔助通路區域包的隱藏刪除。
我們因此得出結論，輔助通路問題是無論如何也不能克服的。關鍵是，對于所有情況的輔助通路來講，限制比完全取締要好。信息可以清晰的通過，為了限制信息需要輔助通路，在黑色環境中一個就可以作為管理程序完全執行安裝，或者把處理分兩步走。第一步，在黑色環境中再一次完全的定義安裝情況的限制數目。第二步，包括發送來自紅色網絡一個非常小的信息用來選擇一個請求在預先定義的設備中傳送。
更麻煩的是包頭的LLIDs，如果LLID 是一個明顯區域（我們過去所討論的，但是看下面），它在各個包中再提示一個新的區域，可能有32bits。因此限制路徑的方法可以使用。但當終結點執行安裝，它將指定LLID的使用。這種情況可在紅色或黑色加密單元看見，這些單元能夠限制構件區域到達正在使用的值。進一步改善的情況，加密單元可能被用于在黑色區域中一個流程到另一個流程總計出一個數量。這將進一步減少明顯的LLIDs的數量，離開紅色區域。
協議的細節，包括一些重要的發行例如LLIDs的持續時間，必須進一步考慮。即使如此，輔助通道的初始化結論可被引入到通常的資源控制機構，這是令人鼓舞的。因為它表明無論是軍用還是民用安全構成都能在相同的建筑模塊上建立。
4.6.2 相容特權的原理
比較好理解的安全原理是最新的特權原理。它表明當系統的組件需要最少的特權時它是最健壯的。
我們所觀察的與之相關的規則原理是特權的一致性。這在拒絕服務時可被簡單的說明。這里是特別相關的。對于單個規則，沒有假定的服務能夠分開，除非我們相信路由器發送包。如果一個路由器被破壞并且不能發送包，唯一的解決方法是找到另一個路由器。在協議中當一個路由器損壞時我們并不關心找到另一個路由器，因為這與我們的主題不符，網絡安全構架。我們	僅僅關心是否從路由器得到服務。如果路由器損壞，并不關心是否會襲擊我們。因此，路由器是轉發路徑的一部分（通常是多點傳送轉發樹）。我們不能在其他方式取得信任，例如取得共享資源密鑰或LLID驗證。
這些說明了相容特權的原理。這些原理在通訊樹中用于點對點或成對使LLIDs生效的機制。如果對一完整的樹發行單一密鑰，且特權不相容。我們只需相信樹中路由器在它以下的結點。如果它在預期的傳輸中失效，它僅僅在這些結點中有效。但是如果我們給它一組密鑰，然后它能夠假的傳輸并能在樹中任何結點注入，影響樹中其他部分的傳輸。如果，另一方面，我們使用成對的密鑰，然后一個被破壞的結點使用傳輸密鑰產生一個假的它能直接收到的傳輸，它是樹中能夠被任何方式破壞的部分。
另一個我們必須放在網絡設計的要求。如果一個防火墻安放后，我們必須相信沒有構件繞過防火墻。一個方法是在區域內消除任何通過防火墻的物理路徑。可以操作的技巧需要容許簡單的物理限制。
4.6.3 隱含的LLID's
我們感覺到在包內地址和用于包分類的LLID間明顯的概念區別。這種區別是非常重要的，但是在受限制的情況下是可以忽略一些包區域和當前包頭所建立的LLID的。例如，當前包按IPv4分類，這是不安全的但是可以將包分為不同的服務類別，使用大量的包區域作為LLID：源及目的IP地址和協議類型的端口。
“隱含”的LLID分類必須是短期的，特別是如果主機能夠在移動時改變IP地址。但是，如果LLID是通過一些動態安裝協議建立的，如果需要，它可能會重新建立LLID。
當前的IPv4頭沒有認證者區域使LLID生效。一個認證者區域是可選擇的；增加網絡的穩定性。在建立認證者時任何機制描述都可以被用到，除了簡單的密碼認證者被使用，它必須是一個明顯的分離區域，因為LLID不能隨機選擇。
4.6.4 不需要設置的安全
當我們描述構架時，安裝步驟是基本的序列部分。這表明當前的Internet未安裝的協議，不能抵抗拒絕服務的攻擊。了解這些要點的限制是非常重要的。當我們強調上面時，安裝出現在許多方式中。路由器現在建立在協議類型上提供管理選擇區分包并且在頭上找到其他區域，使用這個分類建立一個公平的隊列級，這能夠防止一種類相對于其他類超載。
這里有兩個問題。第一個是對于一個完成的安裝使用管理接口，在資源和路由器之間分享的使LLID有效的秘密必須在很長的一段時間內保持有效，且必須手工配置。第二個問題是種類的間隔尺寸必須近似。即使如此，它只是建議。在Radia Perlman的論文中，對每一個源地址都必須隱含的建立分離隊列類。這種方法，作為隱含LLID使用地址，必須對健壯性有一定的構件形式。但是如果LLID可被信任，提供傳輸分類的機制僅僅建立在一個隱含安裝操作上。對任何的QOS區別分類的間隔尺寸沒有提供足夠的支持。這個目標僅僅是保證從一個源到另一個源的傳輸。
4.6.5 生效的地址
我們在這里聲明如果LLID和地址在包中只是概念上的區別，并且如果有合適的手段使LLID生效，且沒有理由使地址生效。例如，一個失敗的源地址的包不再提示任何安全問題，如果它的LLID可被置為有效。
一個意外可能會在與移動主機的交流中出現，但是它需要一個完全的威脅模式和在移動環境中確定的需求。即使如此，我們聲明，作為討論的起始點，如果LLIDs與地址區別開來，很多與移動安全相關的內容可能會減少并且被移除。這一點通過移動問題的細節考慮生效。
4.7結論
a） 從概念上區分LLID（低級標志符）在包內從地址攜帶。
b） 在每個包內都有一個單一的LLID。雖然與多重LLIDs相比可能會在路由器隱藏一些額   
外的情況，但是使用僅僅一個LLID選擇是可伸縮的。
c） 連續跳躍的LLID機制可能提供一個高度的可伸縮的方法，這個方法限制秘密的分配。
即使如此，穩健性必須徹底的調查。
d） 統計抽樣和背景探測機制可能會被路由器調用進行地址查詢。
5.一個鑒定服務
一個鑒定服務的目的就像鑒定名字一樣簡單，或精確鑒定產地“信息”。與鑒定服務的區別決定了對加密名字有效。我們希望鑒定是世界范圍內的服務，當鑒定相對于經過授權的訪問資源來說是特殊的。
這種“識別”函數用于許多場合，例如：
* 一個時間口令：“對問題的反應是真實的<huitema@inria.fr>”
* 訪問防火墻：“對試圖傳送數據到主機A的a端口是真實的<huitema@inria.fr>”
有許多Internet對象需要我們命名，例如：
主機名：sophia.inria.fr
機器名：jupiter.inria.fr
服務名：www.sophia.inria.fr（事實上的數據庫）
使用者：huitema@sophia.inria.fr
處理：p112.huitema@sophia.inria.fr    p112.sophia.inria.fr
通用資源定位器：http//www.sophia.inria.fr:222/tmp/foobar 
我們試圖相信鑒定服務僅僅關心個人的名字，只有人是“有責任的”，一個處理過程獲得訪問權利因為它代表一個人。即使如此，這將導致潛在的誤導。我們可能鑒定“機器”或者硬件組件。例如：
* 當機器引導為了配置自己訪問資源時，但是它沒有被任何一個人所“使用”：沒有使用者。
* 在一個“分布式處理器”上，組件CPU可能需要彼此互相鑒定。
機器與使用者區分開來：機器不能像人那樣保證它們的“秘密”。即使如此，使用一個簡單的可擴充的名字空間是有巨大意義的。
5.1名字和證書
我們假設授權服務將使用“訪問控制目錄”（ACLs）。例如：一些關于一批授權用戶的定義。一個用來描述允許使用“通配符”授權的這樣一種設備的簡潔的方法， 例如，“在 <Bellcore.com> 的任何人，或“<INRIA.FR> 的任何機器””。認證服務應被設計為便于授權服務的實現，并且應該支持“通配符”。
然而， 通配符一般是不夠的。假設我們有一個分層的名字空間，限制命名層次的通配符的入口。例如，象 <huitema@sophia.inria.fr> 一樣的一個名字能由通配符<*@sophia.inria.frr> 匹配。只要一個通配符在 INRIA 中，這種情況成立，但是不能解決通用的問題。假定在 CNRI 的一個 IETF 文件服務器將由所有的 IAB 成員訪問：它的 ACL 將明確地列出成員的名字。
命名的經典的途徑，例如X.500 模型，是考慮那個人有一個“著名的名字”。一旦一個通配符通過一些這樣的“白頁” 服務，發現了一個名字，就能使用它作為一種全球名錄的存取密鑰。
個人可以從許多渠道獲得授權。使用一個純的、基于身份的存取控制系統， 用戶將必須獲得多重的身份 ( 即，特別的名字 )，相應地，它在其被授權存取不同的服務角色。我們在下一節討論這個方法。
一條選擇途徑作為有身份的一個很小的數字的用戶，并且有授權問題( 簽名 )的授予者同意用戶的憑證，連接到了它的 ID 。這些附加簽署的憑證以“能力”被告之。然后，用戶能通過一個通用的身份憑證建立它的身份， 例如，X.509 認證，并且作為請求的發送能力建立授權。在一個驅動程序的許可證上被連接到名字的信用卡的一個通配符，與此有點類似，并且發送合適的信用卡， 加上為身份的圖像證實的許可證。
5.2  基于身份的授權
讓我們打開一個普通人的錢包：我們從中發現若干“信用卡”。我們都有許多“信用卡”， 例如，公司卡， 信用卡， 航空公司的飛行會員卡， 駕駛許可證。這些卡事實上是的一種標志關系的聯系：持有者填寫的那張支票的銀行證明可用于交易， 持有者了解了當局證明的車輛如何駕駛，等等。這是基于身份授權的一個例子，每個人通過不同關系相對應的不同名字進入。
如果我們想象名字空間基于 DNS ( 域 ) 名字之上，那么，涉及到以上的人與名字能被證實：
               customer@my-big-bank.com
               customer@frequent-flyer.airline.com
我們這里使用模型是“名字是一個協會”。這與名字證實過程是一致的， 從中一個人在用戶和“資源代理人”之間建立“信任鏈”。由在信任圖跟隨一條特別的路徑，一個人就能建立信任并且顯示出用戶屬于一個“授權的組”。
一個人的“多重的名字”的存在可以暗示一個“等價”的存在關系。知道 <huitema@sophia.inria.fr> 和 <huitema@iab.isoc.org> 是一樣的人的 2 個名字，可以是有用的，但是有許多情況下用戶不想要他的所有的標志可見。
5.3  選擇憑證
讓我們再考慮在 CNRI 中，克里斯琴·休泰馬存取一個文件的的例子。他將必須與 Inria 的輸出防火墻和 Cnri 的輸入控制交流。不考慮是否授權依賴于能力或多重的協會名字，一個不同的憑證可以被路徑上的每個防火墻所需要。例如，假定多重的名字被使用，他將使用一個 INRIA 名，<huitema@sophia.inria.fr>，通過 INRIA 使用網絡資源，并且他將使用一個 IAB 名字，<huitema@iab.isoc.org>， 來存取文件服務器。這樣，顯然有一個問題：他如何位特殊的防火選擇特別的憑證？更確切地說，管理連接的計算機程序怎么發現這個憑證，即即將向 Inria 的防火墻挑戰和另外一個到 Cnri 的請求的相應？有許多可能的答案。程序能簡單地傳遞所有的用戶憑證，并且讓遠程的機器選擇其中一個。但是，該工作提出一些效率問題：傳遞所有的可能的名字是麻煩的， 瀏覽許多名字是累贅的。為許多名字做廣告，也因為隱私和安全原因而很不受歡迎。一個人不想在遠程服務器上，在一個特別的用戶可以有的所有憑證上，收集統計。
另外的可能性是讓請求一張授權通行證的代理人接受，愿意的憑證