Mpd 4.4.1 User Manual : Internals : RADIUS authentication
Previous: Authentication
Next: External authentication

8.3. RADIUS authentication

This chapter describes implementation specific details of MPD.

RADIUS internals

Mpd supports both user authentication and session accounting using RADIUS. RADIUS-Accounting and RADIUS-Authentication are independant so it is possible to use them in any combination.

All authentication methods are supported with RADIUS (PAP, CHAP, MS-CHAPv1, MS-CHAPv2, EAP). Password changing is currently not supported.

RADIUS attributes supported by mpd:

N   Name                       	   Access	 Accounting
	                	Req	Resp	Req	Resp
1   User-Name			+	+	+	-
2   User-Password		+	-	-	-
3   CHAP-Password		+	-	-	-
4   NAS-IP-Address		+	-	+	-
5   NAS-Port			+	-	+	-
6   Service-Type		+	-	+	-
7   Framed-Protocol		+	-	+	-
8   Framed-IP-Address		-	+	+	-
9   Framed-IP-Netmask		-	+	+	-
12  Framed-MTU			-	+	-	-
18  Reply-Message		-	+	-	-
22  Framed-Route		-	+	-	-
24  State			+	+	+	-
25  Class			-	+	+	-
27  Session-Timeout		-	+	-	-
28  Idle-Timeout		-	+	-	-
30  Called-Station-Id		+	-	+	-
31  Calling-Station-Id		+	-	+	-
32  NAS-Identifier		+	-	+	-
40  Acct-Status-Type		-	-	+	-
42  Acct-Input-Octets		-	-	+	-
43  Acct-Output-Octets		-	-	+	-
44  Acct-Session-Id		-	-	+	-
45  Acct-Authentic		-	-	+	-
46  Acct-Session-Time		-	-	+	-
47  Acct-Input-Packets		-	-	+	-
48  Acct-Output-Packets		-	-	+	-
49  Acct-Terminate-Cause	-	-	+	-
50  Acct-Multi-Session-Id	-	-	+	-
51  Acct-Link-Count		-	-	+	-
52  Acct-Input-Gigawords	-	-	+	-
53  Acct-Output-Gigawords	-	-	+	-
60  CHAP-Challenge		+	-	-	-
61  NAS-Port-Type		+	-	+	-
85  Acct-Interim-Interval	-	+	-	-
95  NAS-IPv6-Address		+	-	+	-
99  Framed-IPv6-Route		-	+	-	-

    Microsoft VSA (311)
1   MS-CHAP-Response		+	-	-	-
2   MS-CHAP-Error		-	+	-	-
7   MS-MPPE-Encryption-Policy	-	+	-	-
8   MS-MPPE-Encryption-Types	-	+	-	-
10  MS-CHAP-Domain		-	+	-	-
11  MS-CHAP-Challenge		+	-	-	-
12  MS-CHAP-MPPE-Keys		-	+	-	-
16  MS-MPPE-Send-Key		-	+	-	-
17  MS-MPPE-Recv-Key		-	+	-	-
25  MS-CHAP2-Response		+	-	-	-
26  MS-CHAP2-Success		-	+	-	-

    mpd VSA (12341)
1   mpd-rule			-	+	-	-
2   mpd-pipe			-	+	-	-
3   mpd-queue			-	+	-	-
4   mpd-table			-	+	-	-
5   mpd-table-static		-	+	-	-
6   mpd-filter			-	+	-	-
7   mpd-limit			-	+	-	-
154 mpd-drop-user		-	-	-	+

Mpd allows RADIUS server to terminate user session by setting vendor specific mpd-drop-user attribute to nonzero value in accounting start/update reply packet.

RADIUS ACL's

Mpd can use the Access Control Lists (ACLs) given by the RADIUS server. This ACLs may include ipfw rules, pipes, queues and tables and also mpd internal traffic filtering/shaping/limiting features. That two sets are redundant. ipfw proposed as standard and universal solution, while internal filter/shaper/limiter based on ng_bpf+ng_car expected to work faster with big number of active links.

To use this features you should add to your RADIUS server such dictionary:

#----------------------------------------------------------
# dictionary.mpd                                                                                   
                                                                                                   
VENDOR          mpd             12341                                                              
                                                                                                   
ATTRIBUTE       mpd-rule        1       string          mpd                                        
ATTRIBUTE       mpd-pipe        2       string          mpd                                        
ATTRIBUTE       mpd-queue       3       string          mpd 
ATTRIBUTE       mpd-table       4       string          mpd 
ATTRIBUTE       mpd-table-static       5       string          mpd 
ATTRIBUTE       mpd-filter      6       string          mpd 
ATTRIBUTE       mpd-limit       7       string          mpd 
ATTRIBUTE	mpd-drop-user	154	integer		mpd
#----------------------------------------------------------

ipfw

You can write in your RADIUS configuration something like:

mpd-table += "1=10.0.0.1",
mpd-table += "1=10.0.0.15",
mpd-pipe += "1=bw 10Kbyte/s",
mpd-pipe += "5=bw 20Kbyte/s",
mpd-rule += "1=pipe %p1 all from any to table\\(%t1\\) in",
mpd-rule += "2=pipe %p5 all from table\\(%t1\\) to any out",
mpd-rule += "100=allow all from any to any",

When mpd receives these parameters it will call ipfw(8) to create firewall rules, pipes and queues with unique numbers starting from 10000 (configurable via 'set global start...'). To the end of each rule will be added "via ngX" to make the rule apply only to that client's networking interface.

As a result of this example we would get these commands executed:

ipfw table 32 add 10.0.0.1
ipfw table 32 add 10.0.0.15
ipfw pipe 10000 config bw 10Kbyte/s
ipfw pipe 10001 config bw 20Kbyte/s
ipfw add 10000 pipe 10000 all from any to table\(32\) in via ng0
ipfw add 10001 pipe 10001 all from table\(32\) to any out via ng0
ipfw add 10002 allow all from any to any via ng0
Note: As soon as mpd executes ipfw commands using shell, shell's special characters like "(" and ")" must be slashed.

When the link goes down, all created rules will be removed.

internal (ng_bpf/ng_car)

Mpd can create complex per-interface traffic filtering/limiting engines inside netgraph when it is requested by mpd-filter and mpd-limit RADIUS attributes.

mpd-filter attribute is a packet filter declaration for using in mpd-limit. mpd-filter consists of two main parts: match/nomatch verdict and the condition. tcpdump (libpcap) expression syntax used for conditions.

mpd-filter: match|nomatch {condition}

mpd-limit attribute is an action which should be done for packet. It consists of two main parts: filter and action.

mpd-limit: {filter} {action}

Filter can be or "all" (any packet) or "fltX" (packets matching to specified mpd-filter).

filter: any|fltX

Action can be: "pass" (stop processing and pass packet), "deny" (stop processing and drop packet), "rate-limit" (do Cisco-like rate-limit), "shape" (do simple RED aware traffic shaping).

Actions "rate-limit" and "shape" can have optional "pass" suffix to stop processing after doing this action.

action: pass | deny | rate-limit {rate(bits/s)} [{normal burst(bytes)} [{extended burst(bytes)}]] [pass] | shape {rate(bits/s)} [{burst(bytes)}] [pass]

As example you can write in your RADIUS configuration something like:

mpd-filter += "1#1=nomatch src net 10.0.0.0/24",
mpd-filter += "1#2=match src net 10.0.0.0/10",
mpd-filter += "2#1=match dst net 10.0.0.0/16",
mpd-filter += "2#2=match dst net 11.0.0.0/8",
mpd-limit += "in#1=flt1 pass",
mpd-limit += "in#2=flt2 shape 64000 4000 pass",
mpd-limit += "in#3=all deny",
mpd-limit += "out#1=flt2 pass",
mpd-limit += "out#2=all rate-limit 1024000 150000 300000",
mpd-limit += "out#3=all pass",

As result, one ng_bpf node will be created to implement traffic filters and several (two for this example) ng_car nodes for traffic shaping and rate-limiting. Incoming traffic from 10.0.0.0/10 except 10.0.0.0/24 will be passed, traffic to 10.0.0.0/16 and 11.0.0.0/8 will be shaped to 64Kbits/s, all other will be denied. Outgoing traffic to 10.0.0.0/16 and 11.0.0.0/8 will be passed, all other will be limited to 1024Kbit/s.


Mpd 4.4.1 User Manual : Internals : RADIUS authentication
Previous: Authentication
Next: External authentication