--- 1/draft-ietf-radext-dtls-04.txt 2013-05-02 08:32:58.493464787 +0100 +++ 2/draft-ietf-radext-dtls-05.txt 2013-05-02 08:32:59.573491724 +0100 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: October 2, 2013 -2 April 2013 + +Expires: October 17, 2013 +17 April 2013 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-04 + draft-ietf-radext-dtls-05 Abstract The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes @@ -62,44 +62,45 @@ 1. Introduction ............................................. 4 1.1. Terminology ......................................... 4 1.2. Requirements Language ............................... 5 2. Building on Existing Foundations ......................... 6 2.1. Changes to RADIUS ................................... 6 2.2. Similarities with RADIUS/TLS ........................ 7 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 2.2.2. Reinforcement of RADIUS/TLS .................... 8 3. Transition Path .......................................... 8 - 3.1. Server Transition to DTLS ........................... 8 -4. Client Transition ........................................ 9 -5. Connection Management .................................... 10 - 5.1. Server Connection Management ........................ 11 - 5.1.1. Session Management ............................. 11 - 5.1.2. Protocol Disambiguation ........................ 13 - 5.1.3. Processing Algorithm ........................... 14 - 5.2. Client Connection Management ........................ 15 -6. Implementation Guidelines ................................ 16 - 6.1. Client Implementations .............................. 17 - 6.2. Server Implementations .............................. 17 -7. Implementation Experience ................................ 18 -8. Diameter Considerations .................................. 18 -9. IANA Considerations ...................................... 18 -10. Security Considerations ................................. 18 - 10.1. Legacy RADIUS Security ............................. 19 - 10.2. Resource Exhaustion ................................ 20 - 10.3. Network Address Translation ........................ 20 - 10.4. Wildcard Clients ................................... 21 - 10.5. Session Closing .................................... 21 - 10.6. Clients Subsystems ................................. 22 -11. References .............................................. 22 - 11.1. Normative references ............................... 22 - 11.2. Informative references ............................. 23 + 3.1. DTLS Port and Packet Types .......................... 9 + 3.2. Server Transition to DTLS ........................... 9 +4. Client Transition ........................................ 10 +5. Connection Management .................................... 12 + 5.1. Server Connection Management ........................ 12 + 5.1.1. Session Management ............................. 13 + 5.1.2. Protocol Disambiguation ........................ 14 + 5.1.3. Processing Algorithm ........................... 15 + 5.2. Client Connection Management ........................ 17 +6. Implementation Guidelines ................................ 18 + 6.1. Client Implementations .............................. 18 + 6.2. Server Implementations .............................. 19 +7. Implementation Experience ................................ 19 +8. Diameter Considerations .................................. 20 +9. IANA Considerations ...................................... 20 +10. Security Considerations ................................. 20 + 10.1. Legacy RADIUS Security ............................. 21 + 10.2. Resource Exhaustion ................................ 22 + 10.3. Network Address Translation ........................ 22 + 10.4. Wildcard Clients ................................... 23 + 10.5. Session Closing .................................... 23 + 10.6. Clients Subsystems ................................. 23 +11. References .............................................. 24 + 11.1. Normative references ............................... 24 + 11.2. Informative references ............................. 25 1. Introduction The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, some specifications such as [RFC5176] have recommended using IPSec to secure RADIUS traffic. @@ -198,25 +199,23 @@ packet to a DTLS layer for encapsulation. DTLS then acts as a transport layer for RADIUS, hence the names "RADIUS/UDP" and "RADIUS/DTLS". The requirement that RADIUS remain largely unchanged ensures the simplest possible implementation and widest interoperability of this specification. We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations - MUST support DTLS packets totalling 4096 octets in length, with a - corrsponding decrease in the maximum size of the encapsulated - packets. Implementations SHOULD support encapsulated RADIUS packets - of 4096 in length, with a corresponding increase in the maximum size - of the encapsulated DTLS packets. + MUST support encapsulated RADIUS packets of 4096 in length, with a + corresponding increase in the maximum size of the encapsulated DTLS + packets. The only changes made from RADIUS/UDP to RADIUS/DTLS are the following two items: (1) The Length checks defined in [RFC2865] Section 3 MUST use the length of the decrypted DTLS data instead of the UDP packet length. (2) The shared secret secret used to compute the MD5 integrity checks and the attribute encryption MUST be "radius/dtls". @@ -243,141 +242,205 @@ Those changes are sufficient to cover the majority of the differences between the two specifications. The next section reviews some more detailed changes from [RFC6614], giving additional commentary only where necessary. 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS This section describes where this specification is similar to [RFC6614], and where it differs. - Section 2.1 does not apply to RADIUS/DTLS. The relationship between - RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from - RADIUS/UDP. + Section 2.1 applies to RADIUS/DTLS, with the exception that the + RADIUS/DTLS port is UDP/TBD. Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be preconfigured to use RADIUS/DTLS for a given endpoint. Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be interpreted as applying to DTLS session initiation, instead of TCP connection establishment. Item (2) applies, except for the recommendation that implementations "SHOULD" support TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed shared secret is "radius/dtls", as described above. - Section 2.4 does not apply to RADIUS/DTLS. + Section 2.4 applies to RADIUS/DTLS. Client identies can be + determined from TLS parameters, instead of relying solely on the + source IP address of the packet. Section 2.5 does not apply to RADIUS/DTLS. The relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/UDP. Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS packet is encapsulated in one DTLS packet, and there is no "stream" of RADIUS packets inside of a TLS session. Implementors MUST enforce the requirements of [RFC2865] Section 3 for the RADIUS Length field, using the length of the decrypted DTLS data for the checks. This check replaces the RADIUS method of using the length field from the UDP packet. - Section 3.4 item (3) does not apply to RADIUS/DTLS. The relationship - between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged - from RADIUS. + Section 3.4 item (3) applies to RADIUS/DTLS when the new port is + used. When DTLS is used over the existing RADIUS/UDP ports, the + relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS + is unchanged from RADIUS. - Section 3.4 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS - still uses UDP for a transport, the use of negative ICMP responses is - unchanged from RADIUS. + Section 3.4 item (4) applies to RADIUS/DTLS when the new port is + used. When DTLS is used over the existing RADIUS/UDP ports, the use + of negative ICMP responses is unchanged from RADIUS. + + Section 3.4 item (5) applies to RADIUS/DTLS when the new port is + used. When DTLS is used over the existing RADIUS/UDP ports, the use + of negative ICMP responses is unchanged from RADIUS. Section 4 does not apply to RADIUS/DTLS. Protocol compatibility considerations are defined in this document. 2.2.2. Reinforcement of RADIUS/TLS We re-iterate that much of [RFC6614] applies to this document. Specifically, Section 4 and Section 6 of that document are applicable - in their entirety to RADIUS/DTLS. + to RADIUS/DTLS. 3. Transition Path Transitioning to DTLS is a process which needs to be done carefully. A poorly handled transition is complex for administrators, and - potentially subject to security downgrade attacks. This section - describes how clients and servers should transition to DTLS. + potentially subject to security downgrade attacks. It is not + sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That + approach would result in timeouts, lost traffic, and network + instabilities. -3.1. Server Transition to DTLS + The end result of this specification is that nearly all RADIUS/UDP + implementations should transition to using a secure alternative. In + some cases, RADIUS/UDP may remain where IPSec is used as a transport, + or where implementation and/or business reasons preclude a change. + However, long-term use of RADIUS/UDP is NOT RECOMMENDED. - As this specification permits server implementations to accept both - RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a - method to disambiguate packets between the two protocols. This - method is applicable only to RADIUS/DTLS servers. + This section describes how clients and servers should transition to + DTLS. There is a fair amount of discussion around this transition, + as it is critical to get it correct. We expect that once + implementations have transitioned to RADIUS/DTLS, the text in this + section will no longer be relevant. - RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for - each client that indicates if it requires a client to use - RADIUS/DTLS. The interpretation of this flag is as follows. If the - flag is "true" then the client supports RADIUS/DTLS, and all packets - from that client MUST be processed as RADIUS/DTLS. If the flag is - "false", then the client supports RADIUS/UDP, but may still support - RADIUS/DTLS. Packets from the client need to be examined to see if - they are RADIUS/UDP or RADIUS/DTLS. +3.1. DTLS Port and Packet Types + + The default destination port number for RADIUS/DTLS is UDP/TBD There + are no separate ports for authentication, accounting, and dynamic + authorization changes. The source port is arbitrary. The text above + in Section 2.2.1 describes issues surrounding the use of one port for + multiple packet types, by referencing [RFC6614] Section 3.4. + +3.2. Server Transition to DTLS + + When a server receives packets on the assigned RADIUS/DTLS port, all + packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT + be accepted on this port. The transition path described in this + section MUST NOT be used for that port. + + Servers MAY accept DTLS packets on the old RADIUS/UDP ports. In that + case, we require a method to disambiguate packets between the two + protocols. This method is applicable only to RADIUS/DTLS servers. + + The disambiguation method leverages the RADIUS/UDP requirement that + clients be known by source IP address. RADIUS/DTLS servers MUST + treat packets from unknown IP addresses as being DTLS. This + requirement does not mean that the server is required to accept these + packets. It means that if the server chooses to accept them, they + are to be treated as being DTLS. + + For packets from known IP addresses RADIUS/DTLS servers MUST maintain + a boolean "DTLS Required" flag for each client that indicates if it + requires a client to use RADIUS/DTLS. If the flag is "true" then all + packets from that client MUST be processed as RADIUS/DTLS. + + The transition to RADIUS/DTLS is performed only when the "DTLS + Required" flag is "false". This setting means that the client is + known to support RADIUS/UDP, but may also support RADIUS/DTLS. + Packets from the client need to be examined to see if they are + RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method + outlined below in Section 5.1.2 MUST be used to determine how + received packets are treated. The "DTLS Required" flag MUST be exposed to administrators of the server. As clients are upgraded, administrators can then manually mark them as using RADIUS/DTLS. The default value for the flag SHOULD be "false". DTLS configuration parameters (e.g. certificates, pre-shared keys, etc.) SHOULD be exposed to the administrator, even if the "DTLS Required" flag is set to "false". Adding these parameters means that the client may use DTLS, though it is not required. It is RECOMMENDED that the default value for the "DTLS Required" flag be set to "true" when this specification has acheived wide-spread adoption. Once a RADIUS/DTLS server has established a DTLS session with a - client that previously had the flag set to "false", the server MUST - set the "DTLS Required" flag to "true". This change requires all + client that previously had the flag set to "false", the server SHOULD + set the "DTLS Required" flag to "true". This change suggests that subsequent traffic from that client to use DTLS, and prevents bidding-down attacks. The server SHOULD also notify the administrator that it has successfully established the first DTLS session with that client. + The above requirement means that RADIUS/DTLS servers are subject to + downbidding attacks. A client can use DTLS for a period of time, and + then subsequently revert to using UDP. This attack is permitted in + order to allow an transition period from UDP to DTLS transport. It + is RECOMMENDED that administators set the "DTLS Required" flag + manually for each client after is has been seen to be using DTLS. + + The above requirement is largely incompatible with the use of + multiple RADIUS/UDP clients behind a Network Address Translation + (NAT) gateway, as noted below in Section 10.3. + Note that this last requirement on servers can impose significant changes for clients. These changes are discussed in the next section. 4. Client Transition - As this specification permits client implementations to to send both - RADIUS/UDP and RADIUS/DTLS packets from the same address, we require - guidelines for when to use one or the other. This method is - applicable only to RADIUS/DTLS clients. + When a client sends packets to the assigned RADIUS/DTLS port, all + packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this + port. The transition path described in this section MUST NOT be used + for packets sent to that port. + + Servers MAY accept DTLS packets to the old RADIUS/UDP ports. In that + case, we require guidelines for when to use one or the other. This + method is applicable only to RADIUS/DTLS clients. RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for each server that indicates if that server requires it to use - RADIUS/DTLS. The interpretation of this flag is as follows. If the - flag is "true" then the server supports RADIUS/DTLS, and all packets - sent to that server MUST be RADIUS/DTLS. If the flag is "false", - then the server supports RADIUS/UDP, but may still support - RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP. + RADIUS/DTLS. If the flag is "true" then the server supports + RADIUS/DTLS, and all packets sent to that server MUST be RADIUS/DTLS. + If the flag is "false", then the server supports RADIUS/UDP, but may + still support RADIUS/DTLS. Packets sent to that server MUST be + RADIUS/UDP. The "DTLS Required" flag MUST be exposed to administrators of the client. As servers are upgraded, administrators can then manually mark them as using RADIUS/DTLS. The default value for the flag SHOULD be "false". DTLS configuration parameters (e.g. certificates, pre-shared keys, etc.) SHOULD be exposed to the administrator, even - if the "DTLS Required" flag is set to "false". Adding these - parameters means that the client MUST start using DTLS to the server - for all new requests. The client MUST, however, accept RADIUS/UDP - responses to any outstanding requests. + if the "DTLS Required" flag is set to "false". + + Adding DTLS configuration parameters means that the client MUST start + using DTLS to the server for all new requests. The client MUST, + however, accept RADIUS/UDP responses to any outstanding RADIUS/UDP + requests. It is RECOMMENDED that a client wait for all responses to + RADIUS/UDP requests before sending RADIUS/DTLS traffic to a + particular server. This suggestion means that the server sees a + "clean" transition from one protocol to another. Having the client + send a mix of RADIUS/UDP and RADIUS/DTLS traffic is problematic. It is RECOMMENDED that the default value for the "DTLS Required" flag be set to "true" when this specification has acheived wide-spread adoption. RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport. Doing so would cause servers to immediately require that all new packets from the client use DTLS. This requirement may be difficult for a client to satisfy. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured. @@ -397,20 +460,28 @@ management of the DTLS session in the application layer. This section describes logically how this tracking is done. Implementations may choose to use the method described here, or another, equivalent method. We note that [RFC5080] Section 2.2.2 already mandates a duplicate detection cache. The connection tracking described below can be seen as an extension of that cache, where entries contain DTLS sessions instead of RADIUS/UDP packets. + [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests + result in the retransmission of a previously cached RADIUS/UDP + response. Due to DTLS sequence window requirements, a server MUST + NOT retransmit a previously sent DTLS packet. Instead, it should + cache the RADIUS response packet, and re-process it through DTLS to + create a new RADIUS/DTLS packet, every time a retransmitted response + is sent. + 5.1. Server Connection Management A RADIUS/DTLS server MUST track ongoing client connections based on a key composed of the following 4-tuple: * source IP address * source port * destination IP address * destination port @@ -421,44 +492,43 @@ Protocol Type A flag which is either "RADIUS/UDP" for old-style RADIUS traffic, or "RADIUS/DTLS" for RADIUS/DTLS connections. DTLS Data An implementation-specific variable containing information about the active DTLS connection. For non-DTLS connections, this variable MUST be empty. -Last Packet - A variable containing a timestamp which indicates when the last - valid packet was received for this connection. Packets which are - "silently discarded" MUST NOT update this variable. +Last Taffic + A variable containing a timestamp which indicates when this + connection last received valid traffic. Each entry may contain other information, such as idle timeouts, connection lifetimes, and other implementation-specific data. 5.1.1. Session Management Session tracking is subject to Denial of Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a ClientHello packet has been received with an appropriate Cookie value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the same port makes this recommendation difficult to implement in practice. Server implementation SHOULD therefore have a way of tracking partially setup DTLS connections. Servers SHOULD limit both the number and impact on resources of partial connections. Sessions (both key and entry) MUST deleted when a TLS Closure Alert - ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section - 7.2.2) is received. When a session is deleted due to failed + ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] + Section 7.2.2) is received. When a session is deleted due to failed security, the DTLS session MUST be closed, and any TLS session resumption parameters for that session MUST be discarded, and all tracking information MUST be deleted. Sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message- Authenticator, or invalid Request Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying session as described above. @@ -470,31 +540,32 @@ specification is for RADIUS, and there is no reason to allow non- RADIUS traffic over a RADIUS/DTLS connection. A session MUST be deleted when RADIUS traffic fails to pass security checks. There is no reason to permit insecure networks. A session SHOULD NOT be deleted when a well-formed, but "unexpected" RADIUS packet is received over it. Future specifications may extend RADIUS/DTLS, and we do not want to forbid those specifications. Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two - servers. A server may also use watchdog packets from the client to - determine that the connection is still active. + servers. A server SHOULD also use watchdog packets from the client + to determine that the connection is still active. As UDP does not guarantee delivery of messages, RADIUS/DTLS servers - MUST also maintain a "Last Packet" timestamp per DTLS session. The - timestamp SHOULD be updated on reception of a valid RADIUS/DTLS - packet. The timestamp MUST NOT be updated in other situations. When - a session has not received a packet for a period of time, it is - labelled "idle". The server SHOULD delete idle DTLS sessions after - an "idle timeout". The server MAY cache the TLS session parameters, - in order to provide for fast session resumption. + which do not implement an application-layer watchdog MUST also + maintain a "Last Traffic" timestamp per DTLS session. The timestamp + SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a + DTLS heartbeat. The timestamp MUST NOT be updated in other + situations. When a session has not received a packet for a period of + time, it is labelled "idle". The server SHOULD delete idle DTLS + sessions after an "idle timeout". The server MAY cache the TLS + session parameters, in order to provide for fast session resumption. This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum value useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section. RADIUS/DTLS servers SHOULD also monitor the total number of sessions they are tracking. They SHOULD stop the creating of new sessions @@ -583,25 +654,23 @@ If the "DTLS Required" flag is set to "false" and no matching entry has been found, then the first octet of the packet is examined. If it has value 22, then the packet MUST be processed as RADIUS/DTLS. Otherwise, the packet MUST be processed as RADIUS/UDP. In all cases, the packet MUST be checked for correctness. For RADIUS/UDP, any packets which are silently discarded MUST NOT affect the state of any variable in session tracking entry. For RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST NOT affect the state of any variable in the session tracking entry. - For RADIUS/DTLS, any RADIUS packets which are subsequently silently - discarded MUST result in the removal of the associated entry and key. When the packet matches an existing key, and is accepted for - processing by the server, the "Last Packet" timestamp is updated in + processing by the server, it is processed via the method indicated in that entry. Where the packet does not match an existing key, a new entry is created for that key. The "Protocol Type" flag for that entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by examining the first octet of the packet. When a server has the clients "DTLS Required" flag set to "false", it MUST set the flag to "true" after establishing a DTLS session with that client. It MUST NOT set the flag to "true" until a DTLS session has been fully established. Doing so would mean that attackers could perform a DoS attack by sending forged DTLS ClientHello packets to a @@ -627,34 +696,47 @@ That proxy can then track the ports which it uses, and ensure that re-use of 4-tuples is avoided. The exact process by which this tracking is done is outside of the scope of this document. 5.2. Client Connection Management Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine the PMTU between the client and server, prior to sending any RADIUS traffic. Once a DTLS session is established, a RADIUS/DTLS client SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity - between the two servers. Alternatively, RADIUS/DTLS clients may use + between the two systems. Alternatively, RADIUS/DTLS clients may use the application-layer watchdog algorithm defined in [RFC3539] to determine server responsiveness. The Status-Server packet defined in [RFC5997] SHOULD be used as the "watchdog packet" in any application- layer watchdog algorithm. RADIUS/DTLS clients SHOULD pro-actively close sessions when they have been idle for a period of time. Clients SHOULD close a session when the DTLS Heartbeat algorithm indicates that the session is no longer active. Clients SHOULD close a session when no traffic other than watchdog packets and (possibly) watchdog responses have been sent for three watchdog timeouts. This behavior ensures that clients do not waste resources on the server by causing it to track idle sessions. + A client may choose to avoid DTLS heartbeats and watchdog packets + entirely. However, DTLS provides no signal that a session has been + closed. There is therefore the possibility that the server closes + the session without the client knowing. When that happens, the + client may later transmit packets in a session, and those packets + will be ignored by the server. The client is then forced to time out + those packets and then the session, leading to delays and network + instabilities. + + For these reasons, it is RECOMMENDED that RADIUS/DTLS clients + implement DTLS heartbeats and/or watchdog packets for all DTLS + sessions. + DTLS sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator, or invalid Response Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying DTLS session. RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS packets over the same key of (source IP, source port, destination IP, destination port) as defined in Section 4.1, above . Doing so would @@ -696,21 +778,21 @@ RADIUS/DTLS clients SHOULD use connected sockets where possible. Use of connected sockets means that the underlying kernel tracks the sessions, so that the client subsystem does not need to. It is a good idea to leverage existing functionality. RADIUS/DTLS clients SHOULD use one source when sending packets to a particular RADIUS/DTLS server. Doing so minimizes the number of DTLS session setups. It also ensures that information about the home server state is discovered only once. - In practive, this means that RADIUS/DTLS clients SHOULD use a local + In practice, this means that RADIUS/DTLS clients SHOULD use a local proxy which arbitrates all RADIUS traffic between the client and all servers. The proxy SHOULD accept traffic only from the authorized subsystems on the client machine, and SHOULD proxy that traffic to known servers. Each authorized subsystem SHOULD include an attribute which uniquely identifies that subsystem to the proxy, so that the proxy can apply origin-specific proxy rules and security policies. We suggest using NAS-Identifier for this purpose. The local proxy SHOULD be able to interact with multiple servers at the same time. There is no requirement that each server have its own @@ -772,22 +854,23 @@ requirement is satisfied by leveraging DTLS. 8. Diameter Considerations This specification defines a transport layer for RADIUS. It makes no other changes to the RADIUS protocol. As a result, there are no Diameter considerations. 9. IANA Considerations - This specification does not create any new registries, nor does it - require assignment of any protocol parameters. + This specification allocates a new UDP port, called "RADIUS-DTLS". + The references to "UDP/TBD" in this document need to be updated to + use the allocated port number. 10. Security Considerations This entire specification is devoted to discussing security considerations related to RADIUS. However, we discuss a few additional issues here. This specification relies on the existing DTLS, RADIUS/UDP, and RADIUS/TLS specifications. As a result, all security considerations for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the @@ -863,23 +946,29 @@ security of DTLS. 10.2. Resource Exhaustion The use of DTLS allows DoS attacks, and resource exhaustion attacks which were not possible in RADIUS/UDP. These attacks are the similar to those described in [RFC6614] Section 6, for TCP. Session tracking as described in Section 5.1 can result in resource exhaustion. Servers MUST therefore limit the absolute number of - sessions that they track. Servers MUST limit the number of partially - open DTLS sessions. These limits SHOULD be exposed to the - administrator as configurable settings. + sessions that they track. When the total number of sessions tracked + is going to exceed the configured limit, servers MAY free up + resources by closing the session which has been idle for the longest + time. Doing so may free up idle resources which then allow the + server to accept a new session. + + Servers MUST limit the number of partially open DTLS sessions. These + limits SHOULD be exposed to the administrator as configurable + settings. 10.3. Network Address Translation Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the shared secret for the client, and NAT hides many clients behind one source IP address. The migration flag described above in Section 3 is also tracked per source IP address. Using a NAT in front of many RADIUS clients