Once upon a time Carl Rigney shaped the electrons to say...
>Add the following lines to your RADIUS dictionary:
>
>VALUE Service-Type Call-Check 10
>VALUE NAS-Port-Type Virtual 5
>
>ATTRIBUTE Tunnel-Type 64 integer
>ATTRIBUTE Tunnel-Medium-Type 65 integer
>ATTRIBUTE Tunnel-Server-Endpoint 67 string
>ATTRIBUTE Tunnel-Password 69 string
>VALUE Tunnel-Type L2TP 3
>VALUE Tunnel-Medium-Type IP 1
>
>The RADIUS daemon must be stopped and restarted to read the new
>dictionary.
Tunnel-Password in the RADIUS Tunnelling draft requires special intelligence
on the RADIUS server. The Server is supposed to encode the password
before sending it. Is ComOS compliant with the draft? If so, is
RADIUS 2.1b6 able to do the encoding? The older RADIUS servers would not
be, and just adding this to the dictionary wouldn't be enough.
5.5. Tunnel-Password
Description
This Attribute may contain a password to be used to authenticate
to a remote server. It may only be included in an Access-Accept
packet.
A summary of the Tunnel-Password Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
69 for Tunnel-Password
Length
>= 3
Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is less than or equal to
0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
eral alternatives) this attribute pertains; otherwise, it SHOULD
be ignored.
Salt
The Salt field is two octets in length and is used to ensure the
uniqueness of the encryption key used to encrypt each instance of
the Tunnel-Password attribute occurring in a given Access-Accept
packet. The most significant bit (leftmost) of the Salt field
MUST be set (1). The contents of each Salt field in a given
Access-Accept packet MUST be unique.
String
The plaintext String field consists of three logical sub-fields:
the Data-Length and Password sub-fields (both of which are
required), and the optional Padding sub-field. The Data-Length
sub-field is one octet in length and contains the length of the
unencrypted Password sub-field. The Password sub-field contains
the actual tunnel password. If the combined length (in octets) of
the unencrypted Data-Length and Password sub-fields is not an even
multiple of 16, then the Padding sub-field MUST be present. If it
is present, the length of the Padding sub-field is variable,
between 1 and 15 octets. The String field MUST be encrypted as
follows, prior to transmission:
Construct a plaintext version of the String field by concate-
nating the Data-Length and Password sub-fields. If necessary,
pad the resulting string until its length (in octets) is an
even multiple of 16. It is recommended that zero octets (0x00)
be used for padding. Call this plaintext P.
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required. Encryption
is performed in the following manner ('+' indicates concatena-
tion):
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
The resulting encrypted String field will contain
c(1)+c(2)+...+c(i).
On receipt, the process is reversed to yield the plaintext String.
For that matter, the Tunnel attributes as suppose to have Tag fields
when sent, Older servers wouldn't add them, does 2.1b6? The basic
question is - is ComOS compliant with the drafts?
>3. Address Redirection to Perform Server Maintenance Using an IRX-211:
>
>The following two servers on your Ether1 provide inbound FTP and Web
>service:
>
>* primary.web.com at 129.65.2.1
>
>* backup.web.com at 129.65.2.2
>
>The IP addresses of primary and backup are global IP addresses.
>However, you need to take primary off-line to perform some maintenance
>work. Just before shutting down primary, you configure an inbound map
>on Ether0 that statically maps primary's address to backup. You use a
>basic NAT setup as follows:
>
> add map ether0.inmap
> set map ether0.inmap 1 addressmap 129.65.2.1 129.65.2.2
> set ether0 nat inmap ether0.inmap
> reset nat
Ok - now my quesiton is, what about people running generic proxies?
Can I do something like this:
set map ether0.inmap 1 static-tcp-udp-portmap 0.0.0.0:80 129.65.2.2:80
The basic idea being that all traffic destined for port 80 is sent to
the proxy instead.
-MZ
-- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>