draft-ietf-radext-status-server-03.txt		draft-ietf-radext-status-server-04.txt
	Network Working Group Alan DeKok		Network Working Group Alan DeKok
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Category: Proposed Standard		Category: Informational
	<draft-ietf-radext-status-server-03.txt>		<draft-ietf-radext-status-server-04.txt>
	Expires: June 16, 2009		Expires: September 1, 2009
	16 December 2008
	Use of Status-Server Packets in the		Use of Status-Server Packets in the
	Remote Authentication Dial In User Service (RADIUS) Protocol		Remote Authentication Dial In User Service (RADIUS) Protocol
			This Internet-Draft is submitted to IETF in full conformance with the
			provisions of BCP 78 and BCP 79. This document may contain material
			from IETF Documents or IETF Contributions published or made publicly
			available before November 10, 2008. The person(s) controlling the
			copyright in some of this material may not have granted the IETF
			Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
			the person(s) controlling the copyright in such materials, this
			document may not be modified outside the IETF Standards Process, and
			derivative works of it may not be created outside the IETF Standards
			Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 16, 2009.		This Internet-Draft will expire on September 1, 2009.
	Copyright Notice		Copyright Notice
	This Internet-Draft is submitted to IETF in full conformance with the		Copyright (c) 2009 IETF Trust and the persons identified as the
	provisions of BCP 78 and BCP 79.		document authors. All rights reserved.
	Copyright (c) 2008 IETF Trust and the persons identified as the		This document is subject to BCP 78 and the IETF Trust's Legal
	document authors. All rights reserved. This document is subject to		Provisions Relating to IETF Documents in effect on the date of
	BCP 78 and the IETF Trust's Legal Provisions Relating to IETF		publication of this document (http://trustee.ietf.org/license-info).
	Documents (http://trustee.ietf.org/license-info) in effect on the		Please review these documents carefully, as they describe your rights
	date of publication of this document. Please review these documents		and restrictions with respect to this document.
	carefully, as they describe your rights and restrictions with respect
	to this document.
	Abstract		Abstract
	RFC 2865 defines a Status-Server code for use in RADIUS, but labels		RFC 2865 defines a Status-Server code for use in RADIUS, but labels
	it as "Experimental" without further discussion. This document		it as "Experimental" without further discussion. This document
	describes a practical use for the Status-Server packet code, which is		describes a practical use for the Status-Server packet code, which is
	to let clients query the status of a RADIUS server. These queries,		to let clients query the status of a RADIUS server. These queries,
	and responses (if any) enable the client to make more informed		and responses (if any) enable the client to make more informed
	decisions. The result is a more stable, and more robust RADIUS		decisions. The result is a more stable, and more robust RADIUS
	architecture.		architecture.
	skipping to change at page 3, line 16		skipping to change at page 3, line 16
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Terminology ......................................... 4		1.1. Terminology ......................................... 4
	1.2. Requirements Language ............................... 5		1.2. Requirements Language ............................... 5
	2. Problem Statement ........................................ 6		2. Problem Statement ........................................ 6
	2.1. Overloading Access-Request .......................... 6		2.1. Overloading Access-Request .......................... 6
	2.1.1. Recommendation against Access-Request .......... 7		2.1.1. Recommendation against Access-Request .......... 7
	2.2. Overloading Accounting-Request ...................... 7		2.2. Overloading Accounting-Request ...................... 7
	2.2.1. Recommendation against Accounting-Request ...... 8		2.2.1. Recommendation against Accounting-Request ...... 8
	2.3. Status-Server as a Solution ......................... 8		2.3. Status-Server as a Solution ......................... 8
	2.3.1. Status-Server to the RADIUS Authentication port. 8		2.3.1. Status-Server to the RADIUS Authentication port 8
	2.3.2. Status-Server to the RADIUS Accounting port .... 9		2.3.2. Status-Server to the RADIUS Accounting port .... 9
	3. Packet Format ............................................ 9		3. Packet Format ............................................ 9
	3.1. Single definition for Status-Server ................. 11		3.1. Single definition for Status-Server ................. 11
	4. Implementation notes ..................................... 11		4. Implementation notes ..................................... 11
	4.1. Client Requirements ................................. 12		4.1. Client Requirements ................................. 12
	4.2. Server Requirements ................................. 14		4.2. Server Requirements ................................. 14
	4.3. More Robust Fail-over with Status-Server ............ 15		4.3. More Robust Fail-over with Status-Server ............ 15
	4.4. Proxy Server handling of Status-Server .............. 16		4.4. Proxy Server handling of Status-Server .............. 16
	4.5. Realm Routing ....................................... 16		4.5. Realm Routing ....................................... 16
	4.6. Management Information Base (MIB) Considerations .... 18		4.6. Management Information Base (MIB) Considerations .... 18
	4.6.1. Interaction with RADIUS Server MIB modules ..... 18		4.6.1. Interaction with RADIUS Server MIB modules ..... 18
	4.6.2. Interaction with RADIUS Client MIB modules ..... 19		4.6.2. Interaction with RADIUS Client MIB modules ..... 19
	5. Additional considerations ................................ 19		5. Table of Attributes ...................................... 19
	5.1. Local site testing .................................. 19		6. Examples ................................................. 20
	5.2. RADIUS over reliable transports ..................... 21		6.1. Minimal Query to Authentication Port ................ 20
	5.3. Other uses for Status-Server ........................ 21		6.2. Minimal Query to Accounting Port .................... 21
	6. Table of Attributes ...................................... 21		6.3. Verbose Query and Response .......................... 22
	7. Examples ................................................. 22		7. IANA Considerations ...................................... 22
	7.1. Minimal Query to Authentication Port ................ 22		8. Security Considerations .................................. 23
	7.2. Minimal Query to Accounting Port .................... 23		9. References ............................................... 23
	7.3. Verbose Query and Response .......................... 24		9.1. Normative references ................................ 23
	8. IANA Considerations ...................................... 25		9.2. Informative references .............................. 23
	9. Security Considerations .................................. 25
	10. References .............................................. 25
	10.1. Normative references ............................... 25
	10.2. Informative references ............................. 25
	1. Introduction		1. Introduction
	The RADIUS Working Group was formed in 1995 to document the protocol		The RADIUS Working Group was formed in 1995 to document the protocol
	of the same name, and created a number of standards surrounding the		of the same name, and created a number of standards surrounding the
	protocol. It also defined experimental commands within the protocol,		protocol. It also defined experimental commands within the protocol,
	without elaborating further on the potential uses of those commands.		without elaborating further on the potential uses of those commands.
	One of the commands so defined was Status-Server ([RFC2865] Section		One of the commands so defined was Status-Server ([RFC2865] Section
	3.).		3.).
	skipping to change at page 12, line 9		skipping to change at page 12, line 9
	implementing support for Status-Server. This section describes		implementing support for Status-Server. This section describes
	implementation details and requirements for RADIUS clients and		implementation details and requirements for RADIUS clients and
	servers that support Status-Server.		servers that support Status-Server.
	The following text applies to the authentication and accounting		The following text applies to the authentication and accounting
	ports. We use the generic terms below to simplify the discussion:		ports. We use the generic terms below to simplify the discussion:
	* Request packet		* Request packet
	An Access-Request packet sent to an authentication port, or		An Access-Request packet sent to an authentication port, or
	an Accounting-Request packet sent to an accounting port		an Accounting-Request packet sent to an accounting port.
	* Response packet		* Response packet
	An Access-Accept, Access-Challenge, or Access-Reject packet sent		An Access-Accept, Access-Challenge, or Access-Reject packet sent
	from an authentication port, or an Accounting-Response packet		from an authentication port, or an Accounting-Response packet
	sent from an accounting port.		sent from an accounting port.
	We also refer to "client" as the originator of the Status-Server		We also refer to "client" as the originator of the Status-Server
	packet, and "server" as the receiver of that packet, and the		packet, and "server" as the receiver of that packet, and the
	originator of the Response packet.		originator of the Response packet.
	Using generic terms to describe the Status-Server conversations is		Using generic terms to describe the Status-Server conversations is
	simpler than duplicating the text for authentication, and accounting		simpler than duplicating the text for authentication and accounting
	packets.		packets.
	4.1. Client Requirements		4.1. Client Requirements
	Clients SHOULD permit administrators to globally enable or disable		Clients SHOULD permit administrators to globally enable or disable
	the generation of Status-Server packets. The default SHOULD be that		the generation of Status-Server packets. The default SHOULD be that
	it is disabled. As it is undesirable to send queries to servers that		it is disabled. As it is undesirable to send queries to servers that
	do not support Status-Server, clients SHOULD also have a per-server		do not support Status-Server, clients SHOULD also have a per-server
	configuration indicating whether or not to enable Status-Server for a		configuration indicating whether or not to enable Status-Server for a
	particular destination. The default SHOULD be that it is disabled.		particular destination. The default SHOULD be that it is disabled.
	skipping to change at page 18, line 48		skipping to change at page 18, line 48
	combination of these two practices will maximize network reliability		combination of these two practices will maximize network reliability
	and stability.		and stability.
	4.6. Management Information Base (MIB) Considerations		4.6. Management Information Base (MIB) Considerations
	4.6.1. Interaction with RADIUS Server MIB modules		4.6.1. Interaction with RADIUS Server MIB modules
	Since Status-Server packets are sent to the defined RADIUS ports,		Since Status-Server packets are sent to the defined RADIUS ports,
	they can affect the [RFC4669] and [RFC4671] RADIUS server MIB		they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
	modules. [RFC4669] defines a counter named		modules. [RFC4669] defines a counter named
	radiusAuthServTotalUnknownTypes, that counts "The number of RADIUS		radiusAuthServTotalUnknownTypes that counts "The number of RADIUS
	packets of unknown type that were received". [RFC4671] defines a		packets of unknown type that were received". [RFC4671] defines a
	similar counter named radiusAcctServTotalUnknownTypes.		similar counter named radiusAcctServTotalUnknownTypes.
	Implementations not supporting Status-Server, or implementations that		Implementations not supporting Status-Server, or implementations that
	are configured to not respond to Status-Server packets MUST use these		are configured to not respond to Status-Server packets MUST use these
	counters to track received Status-Server packets.		counters to track received Status-Server packets.
	If, however, Status-Server is supported and the server is configured		If, however, Status-Server is supported and the server is configured
	to respond as described above, then the counters defined in [RFC4669]		to respond as described above, then the counters defined in [RFC4669]
	and [RFC4671] MUST NOT be used to track Status-Server requests or		and [RFC4671] MUST NOT be used to track Status-Server requests or
	responses to those requests. That is, when a server fully implements		responses to those requests. That is, when a server fully implements
	skipping to change at page 19, line 32		skipping to change at page 19, line 32
	Clients implementing Status-Server MUST NOT increment [RFC4668] or		Clients implementing Status-Server MUST NOT increment [RFC4668] or
	[RFC4670] counters upon reception of Response packets to Status-		[RFC4670] counters upon reception of Response packets to Status-
	Server queries. That is, when a server fully implements Status-		Server queries. That is, when a server fully implements Status-
	Server, the counters defined in [RFC4668] and [RFC4670] MUST be		Server, the counters defined in [RFC4668] and [RFC4670] MUST be
	unaffected by the transmission or reception of packets relating to		unaffected by the transmission or reception of packets relating to
	Status-Server.		Status-Server.
	If an implementation supports Status-Server and the [RFC4668] or		If an implementation supports Status-Server and the [RFC4668] or
	[RFC4670] MIB modules, then it SHOULD also support vendor-specific		[RFC4670] MIB modules, then it SHOULD also support vendor-specific
	MIB extensions containing similar information as those MIB modules,		MIB extensions dedicated solely to tracking Status-Server requests
	but which are instead dedicated solely to tracking Status-Server		and responses. Any definition of the client MIB module extensions
	requests and responses. Any definition of the client MIB module		for Status-Server is outside of the scope of this document.
	extensions for Status-Server is outside of the scope of this
	document.
	5. Additional considerations
	There are additional topics related to the use of Status-Server that
	may be covered. As those topics do not fit well into the preceding
	sections, they are covered herein.
	5.1. Local site testing
	There is at least one situation where using Access-Request or
	Accounting-Request packets may be useful, despite the recommendations
	above in Section 2.1.1 and Section 2.2.1. That situation is local
	site testing, where the RADIUS client, server, and user store are
	under the control of a single administrator or administrative entity.
	In that situation, administrators MAY configure a well-known "test"
	user to enable local site testing.
	The advantage to creating such a local user is that it is now
	possible for the administrator to send a RADIUS request that performs
	end-to-end testing of the RADIUS server. As above with Status-
	Server, this testing includes RADIUS server responsiveness. It may
	also include querying databases of user authentication credentials,
	or storing accounting data to a billing database. The information
	obtained from performing those queries is that the entire RADIUS
	server infrastructure, including all of its dependencies, is
	functioning as expected. These queries are most useful in
	deployments where an administrator has internal RADIUS servers that
	proxy to other internal RADIUS servers, such as for load balancing or
	fail over.
	If used, the names utilized for these test users SHOULD be difficult
	to guess by an attacker. An Access-Request packet for a test user
	otherwise should be treated as follows, depending on its origin:
	o Packets from localhost (127.0.0.1 or ::1): RADIUS servers
	SHOULD treat the request according to local site policy.
	o Packets from NASes that normally originate Access-Request
	packets (i.e. not proxy servers): RADIUS servers SHOULD respond
	with an Access-Reject packet, as the use of Status-Server is
	preferred.
	o Packets from other machines controlled by the administrator:
	RADIUS servers SHOULD treat the request according to local site
	policy.
	o Packets originating from machines not controlled by the
	administrator: RADIUS servers MUST respond with an Access-Reject
	packet.
	If a RADIUS server is configured to support test users for
	Accounting-Request packets, it MAY respond with an Accounting-
	Response packet, independent of the origin of the request. However,
	any subsequent analysis of the accounting data such as billing or
	usage MUST NOT include the data for the test user.
	If these recommendations are implemented, then it may be possible in
	some situations to safely query a RADIUS server for responsiveness
	using Access-Request or Accounting-Request packets. However, this
	behavior is still NOT RECOMMENDED.
	5.2. RADIUS over reliable transports
	Although RADIUS has been assigned two TCP ports (1812/tcp and
	1813/tcp) in addition to the commonly used UDP ports, there has been
	as yet no specification for using TCP as a reliable transport for
	RADIUS. If such a specification were to be created, then the
	transport issues discussed in [RFC3539] would apply.
	Further, when RADIUS is run over reliable transports, the watchdog
	algorithm described in [RFC3539] Section 3.4 MUST be used rather than
	the algorithm described above. For the reasons outlined above in
	Section 2, Status-Server packets SHOULD be used as the watchdog
	request, in preference to Access-Request or Accounting-Request
	packets.
	Clients sending Status-Server over reliable transport MUST ensure
	that the Identifier field is unique for all requests on a particular
	connection, independent of the packet code. That is, if a Status-
	Server with a particular value in the Identifier field is sent to a
	server, the client MUST NOT simultaneously send an Access-Request or
	Accounting-Request packet with that same Identifier value, on that
	connection. Once the client has either received a response to the
	Status-Server packet, or has determined that the Status-Server packet
	has timed out, it may reuse that Identifier in another packet.
	5.3. Other uses for Status-Server
	While other uses of Status-Server are possible, uses beyond those
	specified here are beyond the scope of this document. It may be
	tempting to increase the utility of Status-Server by having the
	responses carry additional information, but implementors are warned
	that such uses have not been analyzed for potential security issues
	or network problems.
	Specifically, it may seem useful to leverage a combination of Status-
	Server and CoA ports in order to send realm routing information
	"upstream" from the home servers to the proxy servers, and finally to
	the NAS. This use of Status-Server is NOT RECOMMENDED, as there has
	been insufficient analysis and deployment experience to know if it is
	useful, or even if it makes the network less reliable.
	6. Table of Attributes		5. Table of Attributes
	The following table provides a guide to which attributes may be found		The following table provides a guide to which attributes may be found
	in Status-Server packets, and in what quantity. Attributes other		in Status-Server packets, and in what quantity. Attributes other
	than the ones listed below SHOULD NOT be found in a Status-Server		than the ones listed below SHOULD NOT be found in a Status-Server
	packet.		packet.
	Status- Access- Accounting-		Status- Access- Accounting-
	Server Accept Response # Attribute		Server Accept Response # Attribute
	0-1 0 0 4 NAS-IP-Address [Note 1]		0-1 0 0 4 NAS-IP-Address [Note 1]
	skipping to change at page 22, line 26		skipping to change at page 20, line 15
	NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one		NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one
	of (NAS-IP-Address or NAS-IPv6-Address).		of (NAS-IP-Address or NAS-IPv6-Address).
	The following table defines the meaning of the above table entries.		The following table defines the meaning of the above table entries.
	0 This attribute MUST NOT be present in packet.		0 This attribute MUST NOT be present in packet.
	0+ Zero or more instances of this attribute MAY be present in packet.		0+ Zero or more instances of this attribute MAY be present in packet.
	0-1 Zero or one instance of this attribute MAY be present in packet.		0-1 Zero or one instance of this attribute MAY be present in packet.
	1 Exactly one instance of this attribute MUST be present in packet.		1 Exactly one instance of this attribute MUST be present in packet.
	7. Examples		6. Examples
	A few examples are presented to illustrate the flow of packets to		A few examples are presented to illustrate the flow of packets to
	both the authentication and accounting ports. These examples are not		both the authentication and accounting ports. These examples are not
	intended to be exhaustive, many others are possible. Hexadecimal		intended to be exhaustive, many others are possible. Hexadecimal
	dumps of the example packets are given in network byte order, using		dumps of the example packets are given in network byte order, using
	the shared secret "xyzzy5461".		the shared secret "xyzzy5461".
	7.1. Minimal Query to Authentication Port		6.1. Minimal Query to Authentication Port
	The NAS sends a Status-Server UDP packet with minimal content to a		The NAS sends a Status-Server UDP packet with minimal content to a
	RADIUS server on port 1812.		RADIUS server on port 1812.
	The Request Authenticator is a 16 octet random number generated by		The Request Authenticator is a 16 octet random number generated by
	the NAS. Message-Authenticator is included in order to authenticate		the NAS. Message-Authenticator is included in order to authenticate
	that the request came from a known client.		that the request came from a known client.
	0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02		0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
	18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43		18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
	skipping to change at page 23, line 4		skipping to change at page 20, line 40
	that the request came from a known client.		that the request came from a known client.
	0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02		0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
	18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43		18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
	82 20 97 c8 4f a3		82 20 97 c8 4f a3
	1 Code = Status-Server (12)		1 Code = Status-Server (12)
	1 ID = 218		1 ID = 218
	2 Length = 38		2 Length = 38
	16 Request Authenticator		16 Request Authenticator
	Attributes:		Attributes:
	18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3		18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
	The Response Authenticator is a 16 octet MD5 checksum of the code		The Response Authenticator is a 16 octet MD5 checksum of the code
	(2), id (218), Length (20), the Request Authenticator from above, and		(2), id (218), Length (20), the Request Authenticator from above, and
	the shared secret.		the shared secret.
	02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8		02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
	b5 41 1d 66		b5 41 1d 66
	1 Code = Access-Accept (2)		1 Code = Access-Accept (2)
	1 ID = 218		1 ID = 218
	2 Length = 20		2 Length = 20
	16 Request Authenticator		16 Request Authenticator
	Attributes:		Attributes:
	None.		None.
	7.2. Minimal Query to Accounting Port		6.2. Minimal Query to Accounting Port
	The NAS sends a Status-Server UDP packet with minimal content to a		The NAS sends a Status-Server UDP packet with minimal content to a
	RADIUS server on port 1813.		RADIUS server on port 1813.
	The Request Authenticator is a 16 octet random number generated by		The Request Authenticator is a 16 octet random number generated by
	the NAS. Message-Authenticator is included in order to authenticate		the NAS. Message-Authenticator is included in order to authenticate
	that the request came from a known client.		that the request came from a known client.
	0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7		0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
	ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f		ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f
	skipping to change at page 24, line 10		skipping to change at page 22, line 5
	02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a		02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
	48 60 66 9c		48 60 66 9c
	1 Code = Accounting-Response (5)		1 Code = Accounting-Response (5)
	1 ID = 179		1 ID = 179
	2 Length = 20 16 Request Authenticator		2 Length = 20 16 Request Authenticator
	Attributes:		Attributes:
	None.		None.
	7.3. Verbose Query and Response		6.3. Verbose Query and Response
	The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS		The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS
	server on port 1812.		server on port 1812.
	The Request Authenticator is a 16 octet random number generated by		The Request Authenticator is a 16 octet random number generated by
	the NAS.		the NAS.
	0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13		0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13
	f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec		f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec
	61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2		61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
	skipping to change at page 25, line 5		skipping to change at page 22, line 45
	38 3a 34 30		38 3a 34 30
	1 Code = Access-Accept (2)		1 Code = Access-Accept (2)
	1 ID = 71		1 ID = 71
	2 Length = 52		2 Length = 52
	16 Request Authenticator		16 Request Authenticator
	Attributes:		Attributes:
	32 Reply-Message (18)		32 Reply-Message (18)
	8. IANA Considerations		7. IANA Considerations
	This specification does not create any new registries, nor does it		This specification does not create any new registries, nor does it
	require assignment of any protocol parameters.		require assignment of any protocol parameters.
	9. Security Considerations		8. Security Considerations
	This document defines the Status-Server packet as being similar in		This document defines the Status-Server packet as being similar in
	treatment to the Access-Request packet, and is therefore subject to		treatment to the Access-Request packet, and is therefore subject to
	the same security considerations as described in [RFC2865], Section		the same security considerations as described in [RFC2865], Section
	8. Status-Server packets also use the Message-Authenticator		8. Status-Server packets also use the Message-Authenticator
	attribute, and are therefore subject to the same security		attribute, and are therefore subject to the same security
	considerations as [RFC3579], Section 4.		considerations as [RFC3579], Section 4.
	We reiterate that Status-Server packets MUST contain a Message-		We reiterate that Status-Server packets MUST contain a Message-
	Authenticator attribute. Early implementations supporting Status-		Authenticator attribute. Early implementations supporting Status-
	Server did not enforce this requirement, and may have been vulnerable		Server did not enforce this requirement, and may have been vulnerable
	to DoS attacks as a result.		to DoS attacks as a result.
	Where this document differs from [RFC2865] is that it defines a new		Where this document differs from [RFC2865] is that it defines a new
	request/response method in RADIUS; the Status-Server request. As		request/response method in RADIUS; the Status-Server request. As
	this use is based on previously described and implemented standards,		this use is based on previously described and implemented standards,
	we know of no additional security considerations that arise from the		we know of no additional security considerations that arise from the
	use of Status-Server as defined herein.		use of Status-Server as defined herein.
	10. References		9. References
	10.1. Normative references		9.1. Normative references
	[RFC2865]		[RFC2865]
	Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.		Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
	[RFC4282]		[RFC4282]
	Aboba, B., and Beadles, M. at al, "The Network Access Identifier",		Aboba, B., and Beadles, M. at al, "The Network Access Identifier",
	RFC 4282, December 2005.		RFC 4282, December 2005.
	10.2. Informative references		9.2. Informative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March, 1997.		Requirement Levels", RFC 2119, March, 1997.
	[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.		[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
	[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and		[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and
	Accounting (AAA) Transport Profile", RFC 3539, June 2003.		Accounting (AAA) Transport Profile", RFC 3539, June 2003.
	[RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In		[RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In
End of changes. 23 change blocks.
	150 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/