RFC 5355
Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
RFC 5355: Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats 🎀
okay bestie, let's set the scene ✨ This is RFC 5355, and it's all about the security threats that come with Reliable Server Pooling (RSerPool) and what security needs to happen to stop them. It was published in September 2008 and it's Informational, so it's sharing info and isn't a standard 💅. The authors are M. Stillman, Ed. (Nokia), R. Gopal (Nokia Siemens Networks), E. Guttman (Sun Microsystems), S. Sengodan (Nokia Siemens Networks), and M. Holdrege. The title block doesn't list anything it obsoletes or updates.
Status of This Memo ✨
This memo gives information to the Internet community 🌸. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract 🦋
RSerPool is an architecture plus a set of protocols for managing and accessing server pools that support highly reliable applications, and for the ways clients reach a server pool 💖. This doc describes the security threats to the RSerPool architecture and sets out requirements for security that thwart those threats 🔥.
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Conventions ................................................4
2. Threats .........................................................4
2.1. PE Registration/De-Registration Flooding --
Non-Existent PE ............................................4
2.2. PE Registration/De-Registration Flooding --
Unauthorized PE ............................................5
2.3. PE Registration/De-Registration Spoofing ...................6
2.4. PE Registration/De-Registration Unauthorized ...............6
2.5. Malicious ENRP Server Joins the Group of Legitimate
ENRP Servers ...............................................7
2.6. Registration/De-Registration with Malicious ENRP Server ....7
2.7. Malicious ENRP Handlespace Resolution ......................8
2.8. Malicious Node Performs a Replay Attack ....................9
2.9. Re-Establishing PU-PE Security during Failover .............9
2.10. Integrity ................................................10
2.11. Data Confidentiality .....................................10
2.12. ENRP Server Discovery ....................................11
2.13. Flood of Endpoint-Unreachable Messages from the
PU to the ENRP Server ....................................12
2.14. Flood of Endpoint Keep-Alive Messages from the
ENRP Server to a PE ......................................12
2.15. Security of the ENRP Database ............................13
2.16. Cookie Mechanism Security ................................13
2.17. Potential Insider Attacks from Legitimate ENRP Servers ...14
3. Security Considerations ........................................15
4. Normative References ...........................................171. Introduction ✨
The RSerPool architecture [RFC5351] is all about high availability and load balancing 💖. It lets a pool user work out the most appropriate server in the server pool at any given time. The architecture is built around a bunch of basic goals: application-independent protocol mechanisms, separating server naming from IP addressing, using the end-to-end principle so nothing depends on intermediate equipment, keeping session availability and failover separate from the application itself, supporting different server selection policies, supporting a set of application-independent failover capabilities, and having a peer-to-peer structure.
RSerPool gives you a session layer for robustness 🧚. That session layer can redirect communication transparently to upper layers, which changes the direct one-to-one association that clients and servers usually have. Secure operation of protocols often depends on assumptions at different layers about who the communicating party is and whether communication between endpoints stays continuous. RSerPool's own operation also has security implications and risks. And because the session layer operates dynamically, there are extra concerns for the overall security of the end-to-end application 😭.
This document looks at the security implications of RSerPool, both from its own functions and from the fact that it sits between applications and transport interfaces 🫶.
This doc is related to the ASAP [RFC5352] and ENRP [RFC5353] documents. They describe, in their Security Considerations sections, the mechanisms for meeting the security requirements here. TLS [RFC5246] is the security mechanism that was chosen for RSerPool to meet all the requirements in this document. The Security Considerations sections of ASAP and ENRP explain how TLS is actually used to provide the security discussed here 👑.
1.1. Definitions
This document uses the following terms:
Endpoint Name Resolution Protocol (ENRP): Within the operational scope of RSerPool, ENRP[RFC5353] defines the procedures and message formats of a distributed fault-tolerant registry service. It stores, keeps the books on, retrieves, and distributes pool operation and membership information.
Aggregate Server Access Protocol (ASAP): ASAP [RFC5352] is a session layer protocol that uses ENRP to provide a high-availability handlespace. ASAP handles the abstraction of the underlying transport technologies, load distribution management, and fault management, and it presents a unified primitive interface to the upper layer (that is, the ASAP User).
Operational scope: The part of the network that pool users can see through a specific instance of the Reliable Server Pooling protocols.
Pool (or server pool): A collection of servers that provide the same application functionality.
Pool handle: A logical pointer to a pool. Each server pool will be identifiable within the operational scope of the system by a unique pool handle.
ENRP handlespace (or handlespace): A cohesive structure of pool names and relations that a client can query. In this context, a client is an application that accesses another remote application running on a server over a network.
Pool element (PE): A server entity that has registered to a pool.
Pool user (PU): A server pool user.
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Threats 💅
2.1. PE Registration/De-Registration Flooding -- Non-Existent PE
2.1.1. Threat
A malicious node could send a stream of false registrations/de-registrations on behalf of non-existent PEs to ENRP servers at a very rapid rate, creating unnecessary state in an ENRP server 🙈.
2.1.2. Effect
The malicious node will corrupt the pool registrar database and/or disable the RSerPool discovery and database function. This is a denial-of-service attack, because the PU would potentially get an IP address of a non-existent PE in response to an ENRP query.
2.1.3. Requirement
An ENRP server that receives a registration/de-registration MUST NOT create or update state information until it has authenticated the PE. TLS with a pre-shared-key (PSK) is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. The justification for PSK is that we assume one administrative domain will control and manage the server pool. This allows PSK to be implemented and managed by a central security administrator 🔐.
2.2. PE Registration/De-Registration Flooding -- Unauthorized PE
2.2.1. Threat
A malicious node or PE could send a stream of registrations/de-registrations that it is not authorized to make to ENRP servers at a very rapid rate, creating unnecessary state in an ENRP server.
2.2.2. Effect
This attack will corrupt the pool registrar database and/or disable the RSerPool discovery and database function. There is the potential for two types of attacks: denial of service and data interception. In the denial-of-service attack, the PU gets an IP address of a rogue PE in response to an ENRP query, and that rogue PE might not provide the actual service. Also, a flood of messages could stop legitimate PEs from registering. In the data interception attack, the rogue PE does provide the service as a man in the middle (MITM), which lets the attacker collect data 😱.
2.2.3. Requirement
An ENRP server that receives a registration/de-registration MUST NOT create or update state information until the authentication information of the registering/de-registering entity is verified.
TLS is used as the authentication mechanism between the ENRP server and PE. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool 🦋.
2.3. PE Registration/De-Registration Spoofing
2.3.1. Threat
A malicious node could send false registrations/de-registrations to ENRP servers concerning a legitimate PE, creating false state information in the ENRP servers.
2.3.2. Effect
This would generate misinformation in the ENRP server concerning a PE, and that misinformation would be propagated to other ENRP servers, corrupting the ENRP database. Distributed Denial of Service (DDoS) could result: if a PE that is a target for a DDoS attack on some popular high-volume service is involved, the attacker can register a PE that a lot of PUs will try to connect to. This allows man-in-the-middle or masquerade attacks on the service provided by the legitimate PEs. If an attacker registers its own server address as a PE and handles the requests, it can eavesdrop on service data 👀.
2.3.3. Requirement
An ENRP server that receives a registration/de-registration MUST NOT create or update state information until it has authenticated the PE. TLS is used as the authentication mechanism between the ENRP server and the PE. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. A PE can register only for itself and cannot register on behalf of other PEs 🧚.
2.4. PE Registration/De-Registration Unauthorized
2.4.1. Threat
A PE that is not authorized to join a pool could send registrations/de-registrations to ENRP servers, creating false state information in the ENRP servers 🌈.
2.4.2. Effect 🎀
okay so this attack is giving misinformation 😭. the ENRP server gets totally bamboozled about a PE, and then it spreads the wrong info to the other ENRP servers too 💀. so the whole ENRP database gets corrupted 🥀. that opens the door for man-in-the-middle or masquerade attacks on the service the legit PEs provide 🙈. and if an attacker registers its own server address as a PE and handles the requests?? they can eavesdrop on service data. not me being dramatic, it's literally that bad 🫣
2.4.3. Requirement 💖
an ENRP server that gets a registration/de-registration MUST NOT create or update state information until it has authorized the requesting entity 🛑. TLS is used as the authentication mechanism here, and TLS with PSK is mandatory to implement 🔐. for PSK, having a pre-shared-key counts as authorization ✨. the network administrators of a pool need to decide which nodes are authorized to participate in the pool 👑.
2.5. Malicious ENRP Server Joins the Group of Legitimate ENRP Servers 🌸
2.5.1. Threat 🧚
a malicious ENRP server joins the group of legit ENRP servers, aiming to push inaccurate updates and corrupt the ENRP database 😈. the attacker sets up an ENRP server and tries to talk to the other ENRP servers 📡.
2.5.2. Effect
the result would be Inconsistent ENRP database state 🌀.
2.5.3. Requirement
ENRP servers MUST perform mutual authentication 🤝. that stops the attacker from getting its ENRP server into the pool 🚫. TLS is used as the mutual authentication mechanism, and TLS with PSK is mandatory to implement as the authentication mechanism. for PSK, having a pre-shared-key constitutes authorization. the network administrators of a pool need to decide which nodes are authorized to participate in the pool 👑.
2.6. Registration/De-Registration with Malicious ENRP Server 🦋
2.6.1. Threat
a PE unknowingly registers/de-registers with a malicious ENRP server 😬.
2.6.2. Effect
the registration might not be properly processed, or it might just get ignored 🫠. a rogue ENRP server can return any address to a user asking for service 🚨. that could mean denial of service, or a connection to a rogue PE the attacker picked 💀.
2.6.3. Requirement
The PE MUST authenticate the ENRP server 🔒. TLS is the mechanism used for that, and TLS with PSK is mandatory to implement as the authentication mechanism. for PSK, having a pre-shared-key constitutes authorization. the network administrators of a pool need to decide which nodes are authorized to participate in the pool. this requirement stops malicious outsiders and insiders from adding their own ENRP server to the pool 🙅.
2.7. Malicious ENRP Handlespace Resolution 🎀
2.7.1. Threat
ASAP gets a handlespace resolution response from an ENRP server, but the ENRP server is malicious and returns random IP addresses or an inaccurate list in response to the pool handle 🤡.
2.7.2. Effect
the PU application talks to the wrong PE or can't find the PE at all, since the response wrongly says a PE with that handle doesn't exist 😵. a rogue ENRP server can return any address to ASAP when it asks for an address list, which could mean denial of service or a connection to a rogue PE of the attacker's choice 💔. from the PE, the attacker could eavesdrop on or tamper with the application 👀.
2.7.3. Requirement
ASAP SHOULD authenticate the ENRP server 🔐. TLS with certificates is the mandatory-to-implement mechanism used for authentication. the administrator uses a centralized Certificate Authority (CA) to generate and sign certificates. the certificate is stored on the ENRP server. a CA trusted root certification authority certificate is sent to the client out of band, and the certificate signature on the ENRP server certificate is checked for validity during the TLS handshake. this authentication stops malicious outsiders and insiders from adding an ENRP server to the pool that may be accessed by ASAP 📜.
2.8. Malicious Node Performs a Replay Attack 🔁
2.8.1. Threat
a malicious node could replay the entire message a legit entity sent earlier 🎬. this could create false/unnecessary state in the ENRP servers when the replay is for registration/de-registration or update 🙃.
2.8.2. Effect
the result is that false/extra state gets maintained by ENRP servers 📦. this would most likely be used as a denial-of-service attack if the replay is used to de-register all PEs 💀.
2.8.3. Requirement
The protocol MUST prevent replay attacks 🛑. the replay attack prevention mechanism in TLS meets this requirement ✅.
2.9. Re-Establishing PU-PE Security during Failover 🔄
2.9.1. Threat
the PU fails over from PE A to PE B. in the case that the PU had a trusted relationship with PE A, the PU will likely not have the same relationship established with PE B 🥺.
2.9.2. Effect
if there was a trust relationship involving security context between PU and PE A, the equivalent trust relationship will not exist between PU and PE B 😬. this will violate security policy. for example, if the security context with A involves encryption and the security context with B does not, then an attacker could take advantage of the change in security 🕵️.
2.9.3. Requirement
The application SHOULD be notified when failover occurs, so it can take appropriate action to establish a trusted relationship with PE B 📣. ENRP has a mechanism to perform this function ✨.
2.10. Integrity 🧩
2.10.1. Threat
the following are all instances of the same class of threats, and they all have similar effects 👯.
- a. ENRP response to pool handle resolution is corrupted during transmission.
- b. ENRP peer messages are corrupted during transmission.
- c. PE sends an update for values, and that information is corrupted during transmission.
2.10.2. Effect
ASAP ends up receiving corrupt info for pool handle resolution, which the PU believes is accurate 🫤. that corrupt info could be an IP address that doesn't resolve to a PE, so the PU would not be able to contact the server 🥲.
2.10.3. Requirement
An integrity mechanism MUST be present 🛡️. corrupted data passed to the PU means the PU can't rely on it. the consequence is that the IP addresses passed to the PU might be wrong, in which case the PU won't be able to reach the PE 💔. The interfaces that MUST implement integrity are PE to ENRP server and ENRP to ENRP server 🔗. the integrity mechanism in TLS is used for this 🙌.
2.11. Data Confidentiality 🤫
2.11.1. Threat
an eavesdropper that can snoop on fields within messages in transit may be able to gather information such as topology, location, IP addresses, etc., which may not be something anyone wants divulged 👀.
2.11.2. Effect
information an administrator doesn't wish to divulge gets divulged 😱. the attacker gains valuable info that can be used for financial gain or attacks on hosts 💸.
2.11.3. Requirement
A provision for data confidentiality service SHOULD be available 🔏. TLS provides data confidentiality in support of this mechanism ✨.
2.12. ENRP Server Discovery 🔍
2.12.1. Threats
- a. Thwarting successful discovery: When a PE wishes to register with an ENRP server, it needs to discover an ENRP server. an attacker could thwart the successful discovery of ENRP server(s), thereby inducing the PE to believe that no ENRP server is available. for instance, the attacker could reduce the returned set of ENRP servers to null or a small set of inactive ENRP servers. the attacker performs a MITM attack to do this 😤.
- b. A similar thwarting scenario also applies when an ENRP server or ASAP on behalf of a PU needs to discover ENRP servers.
- c. Spoofing successful discovery: An attacker could spoof the discovery by claiming to be a legitimate ENRP server. when a PE wishes to register, it finds the spoofed ENRP server. an attacker can only make such a claim if no security mechanisms are used 🎭.
- d. A similar spoofing scenario also applies when an ENRP server or ASAP on behalf of a PU needs to discover ENRP servers.
2.12.2. Effects (Letters Correlate with Threats above) 💅
- a. A PE that could have been in an application server pool does not become part of a pool. the PE does not complete the discovery operation. this is a DoS attack.
- b. An ENRP server that could have been in an ENRP server pool does not become part of a pool. a PU is unable to utilize services of ENRP servers.
- c. This malicious ENRP would either misrepresent, ignore, or otherwise hide or distort information about the PE to subvert RSerPool operation.
- d. Same as above.
2.12.3. Requirement
A provision for authentication MUST be present, and a provision for data confidentiality service SHOULD be present. TLS has a mechanism for confidentiality 🔐.
2.13. Flood of Endpoint-Unreachable Messages from the PU to the ENRP Server 🌊
2.13.1. Threat
Endpoint-unreachable messages are sent by ASAP to the ENRP server when it is unable to contact a PE. there is the potential that a PU could flood the ENRP server, intentionally or unintentionally, with these messages. the non-malicious case would require an incorrect implementation. the malicious case would be caused by writing code to flood the ENRP server with endpoint unreachable messages 🤖.
2.13.2. Effect
the result is a DoS attack on the ENRP server. the ENRP server would not be able to service other PUs effectively and would not be able to take registrations from PEs in a timely manner. further, it would not be able to communicate with other ENRP servers in the pool to update the database in a timely fashion 🐢.
2.13.3. Requirement
The number of endpoint unreachable messages sent to the ENRP server from the PU SHOULD be limited 🚦. this mechanism is described in the ASAP [RFC5352] protocol document 📖.
2.14. Flood of Endpoint Keep-Alive Messages from the ENRP Server to a PE 💓
2.14.1. Threat
Endpoint Keep-Alive messages would be sent from the ENRP server to the PEs during the process of changing the Home ENRP server for this PE 🔄.
2.14.2. Effect
if the ENRP server maliciously sent a flood of endpoint Keep-Alive messages to the PE, the PE would not be able to service clients 😵. the result is a DoS attack on the PE.
2.14.3. Requirement
ENRP MUST limit the frequency of Keep-Alive messages to a given PE to prevent overwhelming the PE 🛑. this mechanism is described in the ENRP [RFC5353] protocol document 📖.
2.15. Security of the ENRP Database 🗄️
2.15.1. Threat
another consideration involves the security characteristics of the ENRP database 🧐. suppose that some of the PEs register with an ENRP server using security and some do not. in this case, when a client requests handlespace resolution information from ENRP, it would have to be informed which entries are "secure" and which are not 🤔.
2.15.2. Effect
this would not only complicate the protocol, but actually bring into question the security and integrity of such a database. what can be asserted about the security of such a database is a very thorny question 🌵
2.15.3. Requirement 🔒
okay so the rule for the ENRP database is super strict 👑. Either the entire ENRP server database MUST be secure, which means every registration came from a PE that used security mechanisms, OR the entire database MUST be insecure, which means every registration came from a PE that used no security mechanisms. no mixing, no in-between, no cap 🙅♀️
ENRP servers that support security MUST reject any PE server registration that does not use the security mechanisms. Likewise, ENRP servers that support security MUST NOT accept updates from other ENRP servers that do not use security mechanisms. TLS is the security mechanism here, so any information that isn't sent using TLS to a secure ENRP server MUST be rejected 🔐 it's giving bouncer energy, lol 💅
2.16. Cookie Mechanism Security 🍪
the application layer is out of scope for RSerPool 🙈 but people have raised some questions about how safe the cookie mechanism is, so we're gonna address them ✨
Cookies get passed over the ASAP control channel. If TCP is picked as the transport, then the data and control channel MUST be multiplexed 🧶 so these cases:
a.control channel is secured; data channel is notb.data channel is secured; control channel is not
are not possible, because squishing everything onto one TCP port means both channels get security or neither one does 🫶
The multiplexing requirement leaves you with these cases:
- the multiplexed control channel-data channel is secure; or
- the multiplexed control channel-data channel is not secured.
This applies to cookies too, in the sense that if you choose to secure your control-data channel, then the cookies are secured 🍓
A second issue is that the PE could choose to sign and/or encrypt the cookie. In this case, it must share keys and other information with other PEs. This application-level state sharing is out of scope of RSerPool 🧚
2.17. Potential Insider Attacks from Legitimate ENRP Servers 😈
okay this is the spicy part 🌶️ the previous text doesn't cover every byzantine attack that could come from legitimate ENRP servers. True protection against misbehavior by authentic (but rogue) servers is beyond what TLS can do. Authentication using TLS doesn't protect against byzantine attacks, since authenticated ENRP servers might have been maliciously hacked. Protections against insider attacks are generally specific to the attack, so more experimentation is needed. For example, the following discusses two insider attacks and potential mitigations 👀
One issue is that legit users may choose not to follow the proposed policies about picking servers (namely, members in the pool). If the "choose a member at random" policy is used, then a pool user can always set its "random choices" so it picks a particular pool member. That bypasses the "load sharing" idea behind the policy 🙃 Another issue is that a pool member (or server) may report a wrong policy to a user.
To mitigate the first attack, the protocol may require the pool user to "prove" to the pool member that the pool member was chosen "randomly", say by demonstrating that the random choice was the result of applying some hash function to a public nonce. Different methods may be appropriate for other member scheduling policies 🎲
To mitigate the second attack, the protocol might require the PE to sign the policy sent to the ENRP server. During pool handle resolution, the signed policy needs to be sent from an ENRP server to an ASAP endpoint in a way that will allow the user to later hold the server accountable to the policy 📜 accountability arc, iconic 👑
3. Security Considerations 🛡️
this is an informational document, and it characterizes potential security threats targeting the RSerPool architecture 🦋 The security mechanisms required to mitigate these threats are summarized for each architectural component. It will be noted which mechanisms are required and which are optional.
From the threats described in this document, the security services required for the RSerPool protocol suite are given in the following table 💜
+--------------+----------------------------------------------------+
| Threat | Security mechanism in response |
+--------------+----------------------------------------------------+
| Section 2.1 | ENRP server authenticates the PE. |
| Section 2.2 | ENRP server authenticates the PE. |
| Section 2.3 | ENRP server authenticates the PE. |
| Section 2.4 | ENRP server authenticates the PE. |
| Section 2.5 | ENRP servers mutually authenticate. |
| Section 2.6 | PE authenticates the ENRP server. |
| Section 2.7 | The PU authenticates the ENRP server. If the |
| | authentication fails, it looks for another ENRP |
| | server. |
| Section 2.8 | Security protocol that has protection from replay |
| | attacks. |
| Section 2.9 | Either notify the application when failover |
| | occurs so the application can take appropriate |
| | action to establish a trusted relationship with PE |
| | B *or* re-establish the security context |
| | transparently. |
| Section 2.10 | Security protocol that supports integrity |
| | protection. |
| Section 2.12 | Security protocol that supports data |
| | confidentiality. |
| Section 2.11 | The PU authenticates the ENRP server. If the |
| | authentication fails, it looks for another ENRP |
| | server. |
| Section 2.13 | ASAP must control the number of endpoint |
| | unreachable messages transmitted from the PU to |
| | the ENRP server. |
| Section 2.14 | ENRP server must control the number of |
| | Endpoint_KeepAlive messages to the PE. |
+--------------+----------------------------------------------------+The first four threats, combined with the sixth threat, result in a requirement for mutual authentication of the ENRP server and the PE 🤝
To summarize, the first twelve threats require security mechanisms that support authentication, integrity, data confidentiality, and protection from replay attacks. For RSerPool, we need to authenticate the following:
PU -----> ENRP Server(PU authenticates the ENRP server)PE <----> ENRP Server(mutual authentication)ENRP server <-----> ENRP Server(mutual authentication)
Summary by component:
RSerPool client 💻: mandatory-to-implement authentication of the ENRP server is required for accurate pool handle resolution. This is to protect against threats from rogue ENRP servers. On top of that, confidentiality, integrity, and protection from replay attacks are also mandatory to implement, to protect against eavesdropping, data corruption, or false data transmission. Confidentiality is mandatory to implement and is used when privacy is required 🔒
PE to ENRP communications 🔄: mandatory-to-implement mutual authentication, integrity, and protection from replay attack is required for PE to ENRP communications. This is to protect the integrity of the ENRP handlespace database. Confidentiality is mandatory to implement and is used when privacy is required 🌸
ENRP to ENRP communications 🌐: mandatory-to-implement mutual authentication, integrity, and protection from replay attack is required for ENRP to ENRP communications. This is to protect the integrity of the ENRP handlespace database. Confidentiality is mandatory to implement and is used when privacy is required ✨
4. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", RFC 5351, September 2008.
Authors' Addresses 🎀
Maureen Stillman, Ed.
Nokia
1167 Peachtree Court
Naperville, IL 60540
USA
EMail: maureen.stillman@nokia.com
Ram Gopal
Nokia Siemens Networks
12278 Scripps Summit Drive
San Diego, CA 92131
USA
EMail: ram.gopal@nsn.com
Erik Guttman
Sun Microsystems
Eichhoelzelstrasse 7
74915 Waibstadt
DE
EMail: Erik.Guttman@sun.com
Senthil Sengodan
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
USA
EMail: Senthil.sengodan@nsn.com
Matt Holdrege
EMail: Holdrege@gmail.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦄
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌
📦 where this page comes from
- ietf: rfc5355 2008-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms