支持隧道協議的RADIUS屬性

摘要
該文檔定義了一組Radius屬性，用于支持撥號網絡中的強制隧道。

1、目的（Motivation）
許多隧道協議的應用，例如L2TP,都包括撥號網絡接入。一部分被定義為非強制隧道，例如通過
Inte.net提供安全接入到企業網：只有用戶申請后才被創建。另外一部分是強制隧道：
隧道直接被創建，不用用戶的任何動作，也不用用戶做任何選擇。為了提供這種功能，
需要定義一些用于從RADIUS服務器傳送隧道信息到隧道另一端的新的RADIUS屬性。
該文檔定義了這些屬性。有關這些用于L2TP屬性的更詳細的描述請參考RFC2809。

2、要求規范
Inthisdocument,thekeywords"MAY","MUST,"MUSTNOT","optional",
"recommended","SHOULD",and"SHOULDNOT",aretobeinterpretedas
describedin[14].

3、屬性
下面定義的每個屬性有可能在同一個RADIUS報文中被包含多次。在這種情況下，它們各自屬性
中Tag域的值必需相同。否則，就不要使用Tag域。
如果RADIUS服務器返回的屬性中描述了多條隧道，則隧道的創建者會把它解釋成可選擇的。
服務器應該在每組隧道屬性集合中包含一個Tunnel-Preference屬性。 同樣，如果客戶端
在Access-Request報文中包含了多組隧道屬性集合，則所有屬于同一隧道的屬性的Tag域
的值應該相同，并且每組屬性集合應該包含一個帶有合適值的Tunnel-Preference屬性。

3.1.Tunnel-Type

描述
該屬性描述了將被使用的隧道協議（隧道創建者[tunnelinitiator]）或者是已經被使用的
隧道協議（隧道終結者[tunnelterminator]）。該屬性可以被包含在Access-Request,
Access-Accept和Accounting-Request報文中。如果該屬性是被包含在隧道創建者發送
的Access-Request報文中，則是暗示RADIUS服務器隧道終點（thetunnelend-point)
所能支持的隧道協議；但是，RADIUS服務器可以忽視這個。隧道創建者并不要求實現所有的隧
道類型。如果隧道創建者收到的一個Access-Accept報文中包含了不知道或者是不支持的隧道
類型，則它按照收到一個Access-Reject報文處理。

如果一個隧道終結者發送的Access-Request報文中包含了Tunnel-Type屬性，則該屬性應該
是表示當前正在使用的隧道協議。這中情況下，如果RADIUS服務器認為該協議沒有被授權，
它會返回一個Access-Reject報。如果一個隧道終結者收到包含有一個或者是多個
Tunnel-Type屬性的Access-Accept報文，但是其中任何一種類型都沒有被使用，則隧道
終結者必需按照收到一個Access-Reject報文處理。

該報文的結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value(cont)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
64

Length
6

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，其取值范圍從0x01
到0x1f，包括0x01和0x1f。如果沒有使用該域，則必需填0。

Value
該域長度是三個字節，用于指定隧道類型，其取值如下：
1Point-to-PointTunnelingProtocol(PPTP)[1]
2LayerTwoForwarding(L2F)[2]
3LayerTwoTunnelingProtocol(L2TP)[3]
4AscendTunnelManagementProtocol(ATMP)[4]
5VirtualTunnelingProtocol(VTP)
6IPAuthenticationHeaderintheTunnel-mode(AH)[5]
7IP-in-IPEncapsulation(IP-IP)[6]
8MinimalIP-in-IPEncapsulation(MIN-IP-IP)[7]
9IPEncapsulatingSecurityPayloadintheTunnel-mode(ESP)[8]
10GenericRouteEncapsulation(GRE)[9]
11BayDialVirtualServices(DVS)
12IP-in-IPTunneling[10]


3.2.Tunnel-Medium-Type

描述
隧道協議（例如L2TP）能運行在多種傳輸媒體（transportmedium）上，
Tunnel-Medium-Type屬性指示創建隧道時用的是哪一種傳輸媒體。該屬性可以
包含在Access-Request或者是Access-Accept報文中。如果它出現在
Access-Request報文中，則用于提示RADIUS服務器隧道終點所支持的
隧道媒體類型。RADIUS服務器也可以忽略這個提示。

該屬性的報文結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value(cont)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
65

Length
6

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，其取值范圍從0x01
到0x1f，包括0x01和0x1f。如果沒有使用該域，則必需填0。

Value
該域長度是3個字節，其取值范圍在參考文檔[14]中的"AddressFamilyNumber"
列表下。下面是關于該列表的一個摘要：
1IPv4(IPversion4)
2IPv6(IPversion6)
3NSAP
4HDLC(8-bitmultidrop)
5BBN1822
6802(includesall802mediaplusEthernet"canonicalformat")
7E.163(POTS)
8E.164(SMDS,FrameRelay,ATM)
9F.69(Telex)
10X.121(X.25,FrameRelay)
11IPX
12Appletalk
13DecnetIV
14BanyanVines
15E.164withNSAPformatsubaddress

3.3.Tunnel-Client-Endpoint

描述
該屬性包含了創建端的地址。它可以被包含在Access-Request和Access-Accept報文中，
用于指示要創建隧道的對端的地址。如果Tunnel-Client-Endpoint屬性如果出現在
Access-Request報文中，RADIUS服務器可以將它看做一個暗示，但是也可以忽略它。
該屬性應該被包含在一個帶有Acct-Status-Type屬性的Accounting-Request的報文中，
其中，Acct-Status-Type的取值可以是Start或者是Stop。這種情況下，Tunnel-Client-Endpoint
屬性要創建隧道的對端地址。Tunnel-Client-Endpoint、Tunnel-Server-Endpoint和
Acct-Tunnel-Connection-ID能提供一種唯一的用于標識隧道的方法，可用于記費和查賬。

該屬性的報文結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
66

Length
>=3

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，如果該域的值大于0x00，
且小于或者等于0x1F，則被解釋成指示該屬性所屬的隧道。如果該域的值大于0x1F，
則被解釋成String域的第一個字節。

String
該域的值的格式決定于Tunnel-Medium-Type屬性的取值。

如果Tunnel-Medius-Type的值是IPv4(1),該域可以是隧道客戶端機器的完整域名
（FQDN），或者是IP地址（點分十進制形式）。實現要求一定要（MUST）實現點分十進制形式，
建議（SHOULD）也實現FQDN格式。

如果Tunnel-Medius-Type的值是IPv6(2)，該域可以是FQDN格式，或者是用字符串形式表現
的優先的或者是可選的地址〔17〕。實現要求一定要（MUST）支持優先格式的地址，建議（SHOULE）
實現可選格式的或者是FQDN格式的地址。、

如果Tunnel-Medium-Type既不是IPv4，也不是IPv6，該域指出本地RADIUS客戶端的關于接口
和媒體特有的地址的配置數據。

3.4.Tunnel-Server-Endpoint

描述
該屬性描述的是隧道服務器端的地址。該屬性可以被包含在Access-Request報文中。如果希望建立一個
隧道，則在Access-Request報文中一定要包含該屬性。如果一個Accounting-Request報文帶有值是
Start或者是Stop的Acct-Status-Type的屬性，且該報文屬于一個隧道會話(tunnelsession)，則
該報文也應該包含Tunnel-Server-Endpoint屬性。Tunnel-Client-Endpoint、Tunnel-Server-Endpoint
和Acct-Tunnel-Connection-ID能提供一種唯一的用于標識隧道的方法，可用于記費和查賬。

該屬性的報文結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
67

Length
>=3

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，如果該域的值大于0x00，
且小于或者等于0x1F，則被解釋成指示該屬性所屬的隧道。如果該域的值大于0x1F，
則被解釋成String域的第一個字節。

String
該域的值的格式決定于Tunnel-Medium-Type屬性的取值。

如果Tunnel-Medius-Type的值是IPv4(1),該域可以是隧道客戶端機器的完整域名
（FQDN），或者是IP地址（點分十進制形式）。實現要求一定要（MUST）實現點分十進制形式，
建議（SHOULD）也實現FQDN格式。

如果Tunnel-Medius-Type的值是IPv6(2)，該域可以是FQDN格式，或者是用字符串形式表現
的優先的或者是可選的地址〔17〕。實現要求一定要（MUST）支持優先格式的地址，建議（SHOULE）
實現可選格式的或者是FQDN格式的地址。、

如果Tunnel-Medium-Type既不是IPv4，也不是IPv6，該域指出本地RADIUS客戶端的關于接口
和媒體特有的地址的配置數據。

3.5.Tunnel-Password

描述
該屬性包含一個用于到遠端服務器上去認證的密碼。它可以被包含在Access-Accept報文中。

該屬性的報文結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt(cont)|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
69

Length
>=5

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性。其有效值范圍從0x01
到0x0f,包含0x01和0x0F。如果該域的值是0x00到0x0F之間，包含0x0F，它
應該被解釋成指示該屬性所屬的隧道，否則，該域被忽略。

Salt
Salt域是兩個字節長度，用于確保在一個Access-Accept報文中用于給Tunnel-Password
加密的密鑰的唯一性。該域最重要的一位（最左邊的）必需被設置（1）。在一個
Access-Accept報文中，每個salt域的內容必需是唯一的。

String
該明文字符串由三個邏輯子域組成：Data-Length子域、Password子域（這兩個是必需的），
以及一個可選的Padding子域。Data-Length子域的長度是一個自己，包含Password
子域的長度。Password子域包含實際的隧道密碼。如果Data-Length域和Password域的
總長度不是16的整數倍，就在后面添加Padding子域。該域的長度是可變的，從1到15（字節）。
String必需按照如下方式加密，優先傳輸：

通過連接Data-Length和Password子域，給String域構造一個明文，如果需要的
話，用填充字符給該明文加長到16的整數倍。推薦用ox00作為填充字符。我們
把該明文叫做P。
報共享密鑰叫做S，隨機產生的128－bit的Request-Authenticator(在對應的
Access-Request報文中)叫做R，Salt域的內容叫做A。將P按照16個字節劃分
成p(1),p(2),...p(i)(i=p的長度/16)。把密碼塊叫做c(1)、c(2)...c(i),
最終的密碼叫做C。還需要中間值b(1)、b(2)...c(i)。按照如下方式加密（'+'
表示串聯）
b(1)=MD5(S+R+A)c(1)=p(1)xorb(1)C=c(1)
b(2)=MD5(S+c(1))c(2)=p(2)xorb(2)C=C+c(2)
..
..
..
b(i)=MD5(S+c(i-1))c(i)=p(i)xorb(i)C=C+c(i)
最終的密碼包括c(1)+c(2)+...+c(i)。

接收端按照相反的過程處理得到明文。

3.6.Tunnel-Private-Group-ID

描述
該屬性指示一個特定的隧道會話的group-ID。如果一個隧道創建者能從一個特定
的連接中確定組的結果(thegroupresulting),則該屬性可以包含在Access-Request報文中，
如果這個將被創建的隧道會話屬于一個特定的私有組，則Access-Accept報文中應該包含
該屬性。 使用組可以用來將一個隧道會話和一組特定用戶相關聯。例如，它會用于通過一個特定的
接口路由一個沒有注冊的IP地址。如果一個Accounting-Request報文包含Acct-Status-Type
屬性（該屬性的值是Start或者Stop)，且屬于一個隧道會話，則該報文應該包含
Tunnel-Private-Group-ID屬性。

該報文的結果如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
81

Length
3

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，如果該域的值大于0x00，
且小于或者等于0x1F，則被解釋成指示該屬性所屬的隧道。如果該域的值大于0x1F，
則被解釋成String域的第一個字節。

String
該域是必需的，代表特定的組。關于它的格式沒有特定的限制。

3.7.Tunnel-Assignment-ID

描述
該屬性用來將一個將被分配會話的特定隧道告訴隧道創建者。一些隧道協議，象L2TP、
PPTP，允許會話通過相同的隧道在兩個相同的隧道終端之間被復用。該屬性給RADIUS
提供了一種可以用于通知隧道創建者（e.g.PAC、LAC）將會話分配給可復用隧道還是
專用隧道（aseparatetunnel）的方法。而且，也允許將共享復用隧道的會話分配
給不同的復用隧道。 一個特定的實現可以將不同的特性分配給特定的隧道。例如，不同
的隧道被賦予不同的 QOS參數。這樣的隧道可以用來承載單個或者是多個會話。
Tunnel-Assignment-ID屬性還允許RADIUS服務器指示一個特定的會話被分配給一個
提供合適等級服務的隧道。希望將來定義的用于隧道的且與QOS相關的RADIUS屬性都能
通過該屬性給出的ID相關聯。同時，任何有關特定ID串的含義留給隧道創建者的本地
配置處理。

該屬性可以被包含在Access-Accept報文中。隧道創建者收到該屬性后，可以忽視它，
將會話安排到兩者之間的任意一個復用或者是專用隧道。如果一個Accounting-Request
報文包含Acct-Status-Type 屬性（該屬性的值是Start或者Stop)，且屬于一個隧道會
話，則該報文應該包含該屬性。

如果一個隧道創建者支持Tunnel-Assignment-ID屬性，那他需要按照如下的方式將
一個會話分配給隧道：

如果在與一個ID指定的終端之間，該屬性和隧道都已經存在，那么這個會話被
分配給該隧道。
如果在與一個ID指定的終端之間，該屬性已經存在，但是沒有隧道，那么將會為
該會話建立一個隧道，并且一個ID被分配給該隧道。
如果該屬性不存在，這該會話被分配到一個未命名的隧道。如果該隧道還沒有建立，
那么建立該隧道，并且用于該會話以及后面沒有Tunnel-Assignment-ID屬性的
會話。一個隧道創建者不能將一個沒有Tunnel-Assignment-ID屬性的會話分配
給一個命名隧道（例如一個由具有該屬性的會話創建的隧道）。
注意不同的終端之間的隧道可能具有相同的ID。

該報文的結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
82

Length
>=3

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，如果該域的值大于0x00，
且小于或者等于0x1F，則被解釋成指示該屬性所屬的隧道。如果該域的值大于0x1F，
則被解釋成String域的第一個字節。
String
該域是必需的，代表隧道ID。對于該ID的格式沒有任何限制。

3.8.Tunnel-Preference

描述
如果RADIUS服務器返回多組隧道屬性，則應當在每組屬性中包含該屬性，用于指示
分配給每個隧道的相對參數（relativepreference）。例如，假設服務器返回
兩條隧道的屬性，其中一條隧道是PPTP類型的，另一種是L2TP類型的。如果隧道
創建者只支持其中的一種，那么它就只創建該種類型的隧道。如果這兩種類型的隧道
它都支持，那么它根據Tunnel-Preference屬性來決定創建哪種類型的隧道。
如果該屬性的取值越低，那么其被創建的優先級越高。如果在某個Access-Accept
報文中幾個Tunnel-Preference的取值相等，那么隧道的創建者要根據本地的配置
來決定該使用哪組屬性來創建隧道。該屬性也可以被包含在Access-Request報文中，
用于給服務器一個提示，但是服務器可以忽略這個提示。

該屬性的報文結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value(cont)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
83

Length
6

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，其取值范圍從0x01
到0x1f，包括0x01和0x1f。如果沒有使用該域，則必需填0。

Value
該屬性長度是三個字節，用于指示該屬性所屬的隧道的優先級，優先級越高，
則該屬性的取值越低。0x000000具有最高優先級，0xFFFFFF具有最低優先級。

3.9.Tunnel-Client-Auth-ID

描述
建立隧道時，在認證階段，該屬性代表隧道創建者的名字。Tunnel-Client-Auth-ID
可以作為給服務其一個提示而被包含在Access-Request報文中，如果希望得到
一個不同于缺省的認證名，則該屬性必需被包含在Access-Accept報文中。如果
一個Accounting-Request報文包含Acct-Status-Type屬性（該屬性的值是
Start或者Stop)，且屬于一個隧道會話，則該報文應該包含該屬性。

該屬性的報文結構如下：

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
90

Length
>=3

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，如果該域的值大于0x00，
且小于或者等于0x1F，則被解釋成指示該屬性所屬的隧道。如果該域的值大于0x1F，
則被解釋成String域的第一個字節。

String
該域是必需的。它包含了隧道創建者用于認證的認證名。建議該認證名的格式用UTF-8。

3.10.Tunnel-Server-Auth-ID

描述
建立隧道時，在認證階段，該屬性代表隧道終結者的名字。Tunnel-Client-Auth-ID
可以作為給服務其一個提示而被包含在Access-Request報文中，如果希望得到
一個不同于缺省的認證名，則該屬性必需被包含在Access-Accept報文中。如果
一個Accounting-Request報文包含Acct-Status-Type屬性（該屬性的值是
Start或者Stop)，且屬于一個隧道會話，則該報文應該包含該屬性。

該報文的結構如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Tag|String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
91

Length
>=3

Tag
該域長度是一個字節，用于組織屬于同一隧道的一組屬性，如果該域的值大于0x00，
且小于或者等于0x1F，則被解釋成指示該屬性所屬的隧道。如果該域的值大于0x1F，
則被解釋成String域的第一個字節。

String
該域是必需的。它包含了隧道終結者用于認證的認證名。建議該認證名的格式用UTF-8。

4.屬性列表
下面的列表表示了上面的屬性能被包含在那些屬性中，以及在該報文中能出現的次數。
RequestAcceptRejectChallengeAcct-Request#Attribute
0+0+000-164Tunnel-Type
0+0+000-165Tunnel-Medium-Type
0+0+000-166Tunnel-Client-Endpoint
0+0+000-167Tunnel-Server-Endpoint
00+00069Tunnel-Password
0+0+000-181Tunnel-Private-Group-ID
00+000-182Tunnel-Assignment-ID
0+0+00083Tunnel-Preference
0+0+000-190Tunnel-Client-Auth-ID
0+0+000-191Tunnel-Server-Auth-ID

5.安全因素
Tunnel-Password屬性有可能包含一些只有隧道端點才能知道的信息，但是現在用于隱藏該屬性的值
的方法會使得中間的RADIUS代理也知道其中的內容。由于這個原因，Tunne-Password屬性不應該
被包含在Access-Accept報文中，因為該報文有可能通過一個不可信任的RADIUS代理。另外，
Tunnel-Password屬性不應該被返回到一個沒有認證的終端；如果對應的Access-Request報文沒有
包含一個能被證實的簽名屬性[15],則Access-Accept報文中就不應該包含Tunnel-Password屬性。

隧道協議提供從沒有安全保護（如PPTP）到最強的安全保護（如IPSec）等不同的安全等級。但是，
需要注意的是，在強制隧道中，任何安全措施只應用于隧道端點之間的傳輸。特別是終端用戶不應該依
賴隧道的安全性來保護它們自己的數據。隧道傳輸的加密保護不能替代點到點之間的安全。

6.IANA考慮事項
該文檔定義了一系列有IANA維護的魔術數（magicnumber）。這一節解釋了IANA分配這些數字的標準。
下面的每個子節解釋了關于在本文檔其它地方定義的名字空間的分配原則。

6.1.Tunnel-Type屬性值
Tunnel-Type屬性的的取值1-12已經在5.1節定義。剩下的值有IANA根據IETF的意見分配[16]。

6.2.Tunnel-Medium-Type屬性值
Tunnel-Medium-Type屬性的取值1-15已經在5.2定義。剩下的值有IANA根據IETF的意見分配[16]。

7.參考

[1]Hamzeh,K.,Pall,G.,Verthein,W.,Taarud,J.,Little,W.and
G.Zorn,"Point-to-PointTunnelingProtocol(PPTP)",RFC2637,
July1999.

[2]Valencia,A.,Littlewood,M.andT.Kolar,T.,"CiscoLayerTwo
Forwarding(Protocol)'L2F'",RFC2341,May1998.

[3]Townsley,W.,Valencia,A.,Rubens,A.,Pall,G.,Zorn,G.and
B.Palter,"LayerTwoTunnellingProtocol(L2TP)",RFC2661,
August1999.

[4]Hamzeh,K.,"AscendTunnelManagementProtocol-ATMP",RFC
2107,February1997.

[5]Kent,S.andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.

[6]Perkins,C.,"IPEncapsulationwithinIP",RFC2003,October
1996.

[7]Perkins,C.,"MinimalEncapsulationwithinIP",RFC2004,
October1996.

[8]Atkinson,R.,"IPEncapsulatingSecurityPayload(ESP)",RFC
1827,August1995.

[9]Hanks,S.,Li,T.,Farinacci,D.andP.Traina,"GenericRouting
Encapsulation(GRE)",RFC1701,October1994.

[10]Simpson,W.,"IPinIPTunneling",RFC1853,October1995.

[11]Zorn,G.andD.Mitton,"RADIUSAccountingModificationsfor
TunnelProtocolSupport",RFC2867,June2000.

[12]Rigney,C.,Willens,S.,Rubens,A.andW.Simpson,"Remote
AuthenticationDialinUserService(RADIUS)",RFC2865,June
2000.

[13]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.

[14]Reynolds,J.andJ.Postel,"AssignedNumbers",STD2,RFC1700,
October1994.

[15]Rigney,C.,Willats,W.andP.Calhoun,"RADIUSExtensions",RFC
2869,June2000.

[16]Narten,T.andH.Alvestrand,"GuidelinesforwritinganIANA
ConsiderationsSectioninRFCs",BCP26,RFC2434,October1998.

[17]Hinden,R.andS.Deering,"IPVersion6Addressing
Architecture",RFC2373,July1998.

8.Acknowledgements

ThankstoDaveMittonforpointingoutanastycirculardependencyin
theoriginalTunnel-Passwordattributedefinitionand(inno
particularorder)toKoryHamzeh,BertrandBuclin,AndyValencia,
BillWestfield,KrisMichielsen,GurdeepSinghPall,RanAtkinson,
AydinEdguer,andBernardAbobaforusefulinputandreview.

9.Chair'sAddress

TheRADIUSWorkingGroupcanbecontactedviathecurrentchair:

CarlRigney
LivingstonEnterprises
4464WillowRoad
Pleasanton,California94588

Phone:+15104260770
EMail:cdr@livingston.com

10.Authors'Addresses

Questionsaboutthismemocanalsobedirectedto:

GlenZorn
CiscoSystems,Inc.
500108thAvenueN.E.,Suite500
Bellevue,Washington98004
USA

Phone:+14254388218
FAX:+14254381848
EMail:gwz@cisco.com


DoryLeifer
AscendCommunications
1678Broadway
AnnArbor,MI48105

Phone:+17347476152
EMail:leifer@del.com

JohnShriver
IntelCorporation
28CrosbyDrive
Bedford,MA01730

Phone:+17816871329
EMail:John.Shriver@intel.com


AllanRubens
AscendCommunications
1678Broadway
AnnArbor,MI48105

Phone:+13137616025
EMail:acr@del.com


MattHoldrege
ipVerse
223XimenoAve.
LongBeach,CA90803

EMail:matt@ipverse.com


IgnacioGoyret
LucentTechnologies
OneAscendPlaza
1701HarborBayParkway
Alameda,CA94502

Phone:+15107696001
EMail:igoyret@lucent.com

11.FullCopyrightStatement

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.