RFC 5765
Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications
Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications ✨
Okay bestie, this is RFC 5765 and it's giving research-group main character energy 🧚. Here's the title block tea:
- Stream: Internet Research Task Force (IRTF) 🌸
- Authors: H. Schulzrinne (Columbia University), E. Marocco (Telecom Italia), and E. Ivov (SIP Communicator) 🫶
- Category: Informational 📚
- Date: February 2010 📅
- ISSN: 2070-1721
- Obsoletes / Updates: neither shows up in the header, so this one doesn't replace or update any other RFC 💅
Abstract 🦋
Okay so P2P networks have gotten super popular for a bunch of reasons: fault tolerance, economics, and legal stuff 💜. That made it totally reasonable for resource-hungry, usually centralized apps like Voice over IP (VoIP) and realtime communication in general to glow up and use P2P too ✨. But this migration brings a whole new set of P2P-specific security problems 😭. This doc goes through some of the known issues in common P2P networks, checks how much each one matters, and asks whether existing fixes actually work when P2P is used for realtime communication 🔥. It's a product of the P2P Research Group, so yes, it's legit 💅.
Status of This Memo 🌈
This one is not an Internet Standards Track spec. It's published just for information 📖.
It's a product of the Internet Research Task Force (IRTF), which shares the results of Internet-related research and development. Those results might not be ready for deployment 🙈. This RFC reflects the consensus of the Peer-to-Peer Research Group of the IRTF 🫶. Documents the IRSG approves for publication are not a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧐.
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc5765 🔗.
Copyright Notice ©️
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved ✨.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this doc was published. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 📜.
Table of Contents 🎀
1. Introduction ....................................................4
1.1. Purpose of This Document ...................................6
1.2. Structure of This Document .................................7
2. The Attackers ...................................................8
2.1. Incentive of the Attacker ..................................8
2.2. Resources Available to the Attacker ........................9
2.3. Victim of the Attack ......................................10
2.4. Time of Attack ............................................10
3. Admission Control ..............................................10
4. Determining the Position in the Overlay ........................11
5. Resilience against Malicious Peers .............................12
5.1. Identification of Malicious Peers .........................13
5.1.1. Proactive Identification ...........................13
5.1.2. Reactive Identification ............................13
5.2. Reputation Management Systems .............................14
5.2.1. Unstructured Reputation Management .................14
5.2.2. Structured Reputation Management ...................14
6. Routing and Data Integrity .....................................15
6.1. Data Integrity ............................................15
6.2. Routing Integrity .........................................15
7. Peer-to-Peer in Realtime Communication .........................16
7.1. Peer Promotion ............................................17
7.1.1. Active vs. Passive Upgrades ........................17
7.1.2. When to Upgrade ....................................18
7.1.3. Which Clients to Upgrade ...........................18
7.1.4. Incentives for Clients .............................19
7.2. Security ..................................................19
7.2.1. Targeted Denial of Service .........................19
7.2.2. Man-in-the-Middle Attack ...........................20
7.2.3. Trust between Peers ................................20
7.2.4. Routing Call Signaling .............................20
7.2.5. Integrity of Location Bindings .....................21
7.2.6. Encrypting Content .................................21
7.2.7. Other Issues .......................................22
8. Open Issues ....................................................22
9. Security Considerations ........................................23
10. Acknowledgments ...............................................23
11. Informative References ........................................23Part 1 of 7 done, bestie 💖 more parts coming!
1. Introduction ✨
Okay so P2P (peer-to-peer) overlays are literally everywhere 💅 They blew up with file-sharing apps like Napster [NAPSTER], KaZaa [KAZAA], and BitTorrent [BITTORRENT]. They slayed at file-sharing and content distribution [Androutsellis-Theotokis], and now P2P networks are also being used for stuff like Voice over IP (VoIP) [SKYPE] [Singh] and television [PPLIVE] [COOLSTREAM] 📺🎀
Here's the tea though 🫖 most of these systems are not purely P2P. They have centralized parts, like the login server in Skype [Baset] or the moderators and trackers in BitTorrent [Pouwelse]. So securing pure P2P networks is still a super active research area 🔥 [Wallach]
P2P overlays can be sorted into structured and unstructured [RFC4981], depending on how they route stuff 🗺️ Unstructured overlays are usually pretty simple, but their searches, which are usually based on flooding, tend to be inefficient 😭 Structured P2P overlays use distributed hash tables (DHTs) [Stoica] [Maymounkov] [Rowstron] to do directed searches, which makes lookups way more efficient when finding data ✨ This document is mostly going to focus on DHT-based P2P overlays 🦋
When you're looking at the attacks that are possible on P2P systems, it's important to first understand what the attackers are motivated by, and what resources they'd have to work with (like computation power, or access to different IP subnets) 🧐
Once you've identified the threat, admission control is a first step towards security that can help avoid a substantial number of attacks [Kim] 🛡️ Most solutions rely on the assumption that malicious nodes are only a small fraction of all peers, so it's important to restrict how many of them get into the overlay 🙈
Other P2P-specific security problems discussed here include attacks on the routing of queries, targeted denial-of-service attacks, and attacks on data integrity 💀
In the rest of this document, we go over the main security issues and proposed solutions for P2P systems 💜 After that, we zoom in on a particular class of P2P applications that provide realtime communications. Realtime communications use the same DHTs that file-sharing apps use, but the data stored in those DHTs is different 🧚 In realtime communications, the stuff stored in the DHTs is user location, and the DHT is standing in for a centralized registration server 📍
At first glance, you might think requirements for P2P systems for realtime communication services are no different from those for file-sharing services. Table 1 shows that there are sizeable differences related to privacy and availability, plus a marked increase in general security requirements 👑
+-----------------+-----------------------+-------------------------+
| | File-sharing | Realtime communication |
+-----------------+-----------------------+-------------------------+
| Distributed | Shared file locations | User locations are |
| database | are indexed in a | indexed in a table |
| | table distributed | distributed among |
| | among peers; often | peers; rarely more than |
| | hundreds or thousands | one per peer. |
| | per peer. | |
| Availability | Same files are | Users are unique; |
| | usually available at | attacks targeting |
| | multiple locations | single users may be |
| | and failures | addressed both to the |
| | involving single | distributed index and |
| | instances are | to the user's device |
| | overcome by abundancy | directly. |
| | of resources; attacks | |
| | targeting single | |
| | files need to be | |
| | addressed to the | |
| | distributed index. | |
| Integrity | Attackers may want to | Attackers may want to |
| | share corrupted files | impersonate different |
| | in place of popular | users in order to |
| | content, e.g., to | handle calls directed |
| | discourage users from | to them; constitute a |
| | acquiring copyrighted | particular threat for |
| | material; constitute | the user as, in case of |
| | a threat for the | success, the attacker |
| | service, but not for | acquires full control |
| | the users. | on the victim's |
| | | personal |
| | | communications. |
| Confidentiality | Shared files are, by | Communications are |
| | definition, readable | usually meant to be |
| | by all users; in some | private and need to be |
| | cases, encryption is | encrypted; |
| | used to avoid | eavesdropping may |
| | elements not involved | reveal sensitive data |
| | in the service to | and is a serious threat |
| | detect traffic. | for users. |
| Bitrate and | The file-transfer use | Realtime traffic almost |
| latency | case is particularly | always requires a |
| | tolerant to unstable | constant minimum |
| | bitrates and ability | bitrate and low latency |
| | to burst on and off | in order to avoid |
| | as peers disappear or | problems like jitter. |
| | new ones become | While this is not |
| | available. | directly related to a |
| | | specific sort of |
| | | attacks, it is a |
| | | significant constraint |
| | | to the design of |
| | | certain design |
| | | solutions, and in |
| | | particular those that |
| | | somehow affect routing. |
| Peer lifetime | File-sharing users do | Realtime communication |
| | not need to stay in | applications need not |
| | the overlay more than | leave the overlay for |
| | the time required for | as long as the user |
| | downloading the | wants to stay connected |
| | content they are | and be reachable. This |
| | looking for. | gives the attackers |
| | | longer time for |
| | | conducting successful |
| | | targeted attacks. |
+-----------------+-----------------------+-------------------------+
Table 1: Main differences between P2P applications used for
file-sharing and for realtime communication.1.1. Purpose of This Document 🎀
The goal of this document is to give authors of P2P protocols for realtime communications some background they might find useful while designing security mechanisms for specific cases 💖 It was discussed in depth during face-to-face meetings and on the P2PRG mailing list 🫶 Two members of the research group reviewed it, both substantially and editorially, and it reflects the consensus of the group ✨
The content of this document was partly derived from the article "Peer-to-peer Overlays for Real-Time Communication: Security Issues and Solutions," published in IEEE Surveys & Tutorials, Vol. 11, No. 1, and originally written by Dhruv Chopra, Henning Schulzrinne, Enrico Marocco, and Emil Ivov 📚🌸
It's really important to note that this document looks at "security" from the perspective of application developers and protocol architects 🧠 So it's entirely agnostic to any legislation that might apply when protecting applications against a specific attack, like in the case of lawful interception ⚖️ Not the vibe we're going for here 🙅♀️
1.2. Structure of This Document 🗺️
okay so the doc is laid out in a specific order, and I'm about to spill the whole tea 🫖. Section 2 is all about P2P security attackers: what they're motivated by, what resources they'd have, who their victims are, and when they strike ⚔️. Section 3 is admission control problems 🚪. Section 4 is where a node joins the overlay, and the problem that comes with it 🧩. Section 5 covers identifying malicious nodes and spreading that info around 🕵️♀️. Section 6 is routing and data integrity in P2P networks 🛣️. And finally Section 7 looks at how everything from before applies to P2P overlays for realtime communication 📞✨
There are also two index tables that are seriously so helpful. Table 2 and Table 3 give you an index of the attacks and the solutions talked about in the rest of the doc, so you can jump straight to what you need 🦋
+---------------------------------------+---------------------------+
| Attack name | Referring sections |
+---------------------------------------+---------------------------+
| botnets (use of) | Section 2.1, Section 2.2 |
| denial of service (DoS) | Section 2.1, |
| | Section 7.2.1 |
| man in the middle (MITM) | Section 7.2.2 |
| poisoning | Section 6.1, |
| | Section 7.2.2 |
| pollution | Section 2.1, Section 6.1 |
| sybil | Section 2.2, Section 4 |
| targeted denial of service | Section 7.2.1 |
+---------------------------------------+---------------------------+Table 2: Index of some of the more popular attacks and problems discussed in this document.
+---------------------------------------+---------------------------+
| Solution name | Referring sections |
+---------------------------------------+---------------------------+
| admission control | Section 3 |
| anonymity | Section 5.2 |
| asymmetric key pair | Section 7.2.5 |
| CAPTCHA | Section 3 |
| certificates | Section 7.2.3 |
| CONNECT (SIP method) | Section 7.2.4 |
| cryptographic puzzles | Section 4 |
| diametrically opposite IDs | Section 4 |
| end-to-end encryption | Section 7.2.4 |
| group authority | Section 3 |
| group charter | Section 3 |
| iterative routing | Section 7.2.2 |
| no profit for newcomers | Section 5.2 |
| online phone book | Section 7.2.5 |
| passive upgrades | Section 7.1.1 |
| peer promotion | Section 7.1 |
| proactive identification | Section 5.1.1 |
| reactive identification | Section 5.1.2 |
| recommendation | Section 3 |
| reputation management systems | Section 5.2 |
| self-policing | Section 5.2 |
| signatures | Section 3 |
| social networks (using) | Section 4, Section 6.2, |
| SRTP | Section 7.2.6 |
| structured reputation management | Section 5.2.2 |
| SybilGuard (protocol) | Section 4 |
| transitivity of trust | Section 5.2.2 |
| trust and distrust vectors | Section 5.2.1 |
| trust and trusted nodes | Section 3, Section 6.2, |
| | Section 7.2.3 |
| unstructured reputation management | Section 5.2.1 |
| voluntary moderators | Section 6.1 |
+---------------------------------------+---------------------------+Table 3: Index of some of the more popular solutions discussed in this document.
2. The Attackers 😈
2.1. Incentive of the Attacker 💸
attacks on networks happen for all kinds of reasons 🎭 like making money, holding a grudge against someone, or just wanting clout in the hacker community 👑
there are quite a few well-known cases of denial-of-service attacks used for extortion in the client-server model [McCue] 😬 one of the best things about the P2P model is that its services are more robust against failure 💪 but denial-of-service attacks are still possible against individuals inside the overlay if the attackers have enough resources 🥶 for example, a network of worm-infected malicious nodes spread across the Internet and controlled by one attacker (often called a botnet) could all hit lookup queries for one particular key in the DHT at the same time 🤖 the peer responsible for that key would then get buried under a ton of load and could crash [Sit] 💀 but if key-value pairs get replicated at multiple locations, those threats can be mitigated ✨
attackers can also have incentives that are indirectly about money 🤑 with all the illegal sharing of copyrighted files going on, record companies have been known to pollute content in the overlays by putting up nodes with corrupt chunks of data but with correct file names 🙃 the goal is to degrade the service [Liang] and hope users get so frustrated they stop using it 😤 competition between different communication service providers, whether both are based on P2P technologies or just one of them, along with how hard it is to trace attacks aimed at single users, could also be a motive for trying to disrupt the service 📉
attacks can also come from novice attackers who are just attacking the overlay for fun or to get fame in a community 🎮 these are probably less likely to succeed or do real damage, since their resources tend to be pretty limited 🥺
2.2. Resources Available to the Attacker 🧰
resource constraints play a big role in deciding what kind of attack you're dealing with 🎯 an attacker who controls a botnet can use an Internet relay channel and launch distributed denial-of-service attacks against another node 🌐 when it comes to attacks where one node impersonates multiple identities, like the Sybil attack [Douceur] described in Section 4 🎭 IP addresses are also a super important resource for the attacker 🔑 that's because in DHTs like Chord [Stoica], a node's position in the overlay is determined by running a base hash function such as SHA-1 [SHA1] on the node's IP address 🧮
the cryptographic puzzles [Rowaihy] that people sometimes suggest to deter Sybil attacks, by making the join process harder, are totally futile 🙅♀️ against an attacker with a botnet and virtually unlimited computation power 🖥️ Douceur [Douceur] proves that even if attackers only have minimum resources at their disposal, it is not possible to defend against them in a pure P2P system 😭 it's giving impossible 🫠
2.3. Victim of the Attack 🎯
the victim of an attack could be an individual node, a particular content entry, or the entire overlay service 🫧 if malicious nodes are strategically placed in the overlay, they can block a node from using its services 🚫 attacks could also be aimed at specific content [Sit] or even the whole overlay service 🌊 for example, if the malicious nodes are randomly placed in the overlay and drop packets or upload malicious content, then the quality of the overlay would deteriorate 📉💔
2.4. Time of Attack ⏰
a malicious node could start misbehaving the second it enters the overlay 😈 or it could follow the overlay's rules for a finite amount of time and then attack 🫣 the latter could be even more harmful if the overlay design suggests building up trust in peers based on how long they've been present and/or not misbehaving 🧠 in Kademlia [Maymounkov], for instance, the routing tables get populated with nodes that have been up for a certain amount of time 🕰️ this gives some robustness against attacks where malicious nodes start dropping routing requests right from the moment they enter 🛡️ but it would take time for the algorithm to adapt to nodes that start misbehaving at a later stage (i.e., after they've already been recorded in routing tables) 😬 similarly for reputation management systems, it's important that they adapt to a peer's current behavior 🔄💅
3. Admission Control ✨
Okay so admission control is basically about two things: who decides whether a node gets in, and how that "yes" actually gets granted 💅 Kim et al. [Kim] answer both questions without tying themselves to any particular environment or application, which is so iconic. They define two basic elements for admission in a peer group. The first is a group charter, an electronic document that spells out the procedure for getting into the overlay 📜 The second is a group authority, an entity that can certify group admission. A prospective member grabs a copy of the group charter, meets the requirements, and approaches the group authority. The group authority then verifies the admission request and grants a group membership certificate 🎀
The group charter and the authority verification can come from a centralized certificate authority or a trusted third party, or the peers can handle it themselves by voting 🗳️ The first option is more practical and makes the certification process simpler, although it violates the pure P2P model and exposes the system to attacks typical of server-based solutions (e.g., denial-of-service attacks targeted to the central authority) 💀 In the voting case, the group authority could be either a fixed number of peers or a dynamic number based on the total membership of the group. The authors argue that even if the group charter requires a prospective member to get votes from peers, the group membership certificate must be issued by a distinct entity. The reason is that voters need to attach a certificate to their votes that proves their own membership 🫶 Plain digital signature, threshold signature, and accountable subgroup multisignature are all described as possible signature schemes for voting. Saxena et al. [Saxena] ran experiments with the different signature schemes and suggest using plain signatures for groups of moderate size where bandwidth is not a concern. For larger groups where bandwidth is a concern, they suggest threshold signature [Kong] and multisignature schemes [Ohta] 🌸
Another way to handle admission is mechanisms based on trust and recommendation, where each new applicant has to be known and vouched for by at least N existing members 🦋 The difficulties these models bring include identity assertion and preventing bot/worm attacks 🙈 A compromised node could have a valid certificate identifying a trustworthy peer, and it would be difficult to detect this, which is lowkey terrifying. Possible solutions include sending graphic or logic puzzles that are easily addressed by humans but hard to solve by computers, also known as CAPTCHA [Ahn]. However, the reliability of such mechanisms is, at the time of writing, a topic of lively debate [Tam] [Chellapilla] 🔥
4. Determining the Position in the Overlay
Okay, so for ring-based DHT overlays like Chord [Stoica], Kademlia [Maymounkov], and Pastry [Rowstron], when a node joins the overlay, it uses a numeric identifier (ID) to figure out its position in the ring 💍 The positioning of a node determines what information it stores and which nodes it serves. To give things some robustness, content and services are often replicated across multiple nodes. However, an adversary with sufficient resources can undermine that redundancy by representing multiple identities. This is called a Sybil attack [Douceur], and it's exactly why the assignment of IDs is so important 😭
One possible scheme to tackle Sybil attacks on the ID mapping is a temporal mechanism where nodes need to re-join the network after some time [Condie] [Scheideler]. Honestly, though, these temporal solutions have a drawback: they increase the maintenance traffic and can deteriorate the efficiency of caching 🥴 Danezis et al. [Danezis] suggest mechanisms that mitigate the effect of Sybil attacks by reducing the amount of information received from malicious nodes. Their idea is to vary the nodes used for routing over time. This helps avoid trust bottlenecks, which can occur when applications only route traffic through a limited set of highly trusted nodes 🧚 Other solutions make the joining process harder by introducing cryptographic puzzles, as suggested by Rowaihy et al. [Rowaihy]. The assumption there is that the adversary has limited computational resources, which may not be true if the adversary controls a botnet. Another drawback is that non-malicious nodes would also have to do the extra computations before they can join the overlay 💀
A possible heuristic to hamper Sybil attacks is to employ redundancy at nodes with diametrically opposite IDs (in the DHT ID space) instead of successive IDs, as in Chord 👑 The idea behind choosing diametrically opposite nodes is that a malicious peer can grant admission to others as its successor without them actually possessing the required IP address (whose hash is adjacent to the former's). Then they can cooperate to control access to that part of the ring. If, however, admission decisions and redundant content (for robustness) also involve the nodes that are farthest away (diametrically opposite) from a given position, the adversary would need double resources (IP addresses) to attack. This happens because the adversary would need presence in the overlay at two independent positions in the ring 🌈
Another approach, proposed by Yu et al. [Yu], limits Sybil attacks by using the social relations between users. It exploits the fact that, as a result of Sybil attacks, affected P2P overlays end up containing a large set of Sybil nodes connected to the rest of the peers through an irregularly small number of edges. The SybilGuard protocol [Yu] defines a method that allows discovering these kinds of discontinuities in the topology by using a special kind of verifiable random walk, so no single node needs a global view of the graph 🕸️
It's also worth mentioning that in DHT overlays using different geometric concepts (e.g., hypercubes instead of rings), peer positions are usually not related to identifiers. In the content addressable network (CAN) [Ratnasamy], for example, the position of an entering node may either be selected by the node itself or, with little modification to the original algorithm, be assigned by peers already in the overlay. However, even when malicious nodes don't know their position before joining, the overlay is still vulnerable to Sybil attacks 🥺
5. Resilience against Malicious Peers
Making overlays robust against even a small percentage of malicious nodes is difficult [Castro], so it's super important for other peers to identify those nodes and keep track of how many there are 🫠 There are two aspects to this problem. One is the identification itself, and the other is disseminating this information amongst the peers. Different metrics need to be defined for the former, depending on the peer group, and reputation management systems are needed for the latter 🎀
5.1. Identification of Malicious Peers
Before you can label a node as malicious, malicious activity has to be observed first. This can be done in either a proactive way or a reactive way 👀
5.1.1. Proactive Identification
When acting proactively, peers perform periodic operations to detect malicious activity. A malicious node could prevent access to content it's responsible for (e.g., by claiming the object doesn't exist), or return references to content that doesn't match the original queries [Sit]. With this approach, publishers of content can later perform lookups for it at periodic intervals and verify the integrity of whatever comes back. Any inconsistencies could then be interpreted as malicious activity. The problem with proactive identification is managing the overhead it implies: if checks are performed too often, they may actually hinder scalability, while if they're performed too rarely, they would probably be useless 😩
An additional approach for mitigating routing attacks and identifying malicious peers is sending multiple copies of the same message on different paths. With this approach, implemented for example in Kademlia [Maymounkov], the sending peer can spot anomalies by comparing responses coming in from different paths 🕵️♀️
5.1.2. Reactive Identification
In a reactive strategy, peers perform normal operations, and if they happen to detect some malicious activity, they can label the responsible node as malicious and avoid sending it any further messages 🚫 In a file-sharing application, for example, after downloading content from a node, if the peer observes that the data doesn't match its original query, it can identify the corresponding node as malicious. Poon et al. [Poon] suggest a strategy based on the forwarding of queries. If routing is done in an iterative way, then dropping packets, forwarding to an incorrect node, and delay in forwarding all arouse suspicion, and the corresponding peer is identified as malicious 🚨
5.2. Reputation Management Systems
Reputation management systems let peers share information about other peers based on their own experience, which helps them make better judgments 🧠 Most reputation management systems proposed in the literature for file-sharing applications [Uzun] [Damiani] [Lee] [Kamvar] aim to stop misbehaving peers with low reputation from rejoining the network with a different ID and starting from a clean slate, which is such a classic move 🙄 To achieve this, Lee et al. [Lee] store not only the reputation of a peer but also the reputation of files, based on file name and content, to avoid spreading a bad file. Another method is to make the reputation of a new peer the minimum possible. Kamvar et al. [Kamvar] define five design considerations for reputation management systems:
- The system should be self-policing.
- The system should maintain anonymity.
- The system should not assign any profit to newcomers.
- The system should have minimal overhead in terms of computation, infrastructure, storage, and message complexity.
- The system should be robust to malicious collectives of peers who know one another and attempt to collectively subvert the system.
5.2.1. Unstructured Reputation Management
Unstructured reputation management systems have been proposed by Uzun et al. [Uzun] and Damiani et al. [Damiani]. The basic idea is that each peer maintains information about its own experience with other peers and resources, and shares it with others on demand 🤝 In the system proposed by Uzun et al. [Uzun], each node maintains trust and distrust vectors for every other node it has interacted with. When reputation information about a peer is required, a node first checks its local database. If insufficient information is present, it sends a query to its neighbors, just as it would when looking up content. However, such an approach requires peers to get reputation information from as many sources as possible; otherwise, malicious nodes may successfully place targeted attacks returning false values for their victims 😱
5.2.2. Structured Reputation Management ✨
okay so the problem with unstructured reputation systems is that they either only ask a few peers for feedback, or if they ask everyone, the traffic overhead is literally insane 😭. [Lee] and [Kamvar] tried to fix this in a more structured way 🧠. The eigen trust algorithm [Kamvar] runs on transitivity of trust: if a node trusts peer X, then it also trusts the feedback X gives about other peers 💅. A node builds this info iteratively, and to keep it organized the authors suggest using a content addressable network (CAN) DHT [Ratnasamy] 🦋. Each peer's info gets stored and replicated on different peers, which gives robustness against malicious nodes 🛡️.
They also suggest favoring peers probabilistically with high trust values instead of doing it deterministically 🎲. This way new peers can slowly develop a reputation instead of getting locked out 🌱. And finally, they suggest incentives for peers with high reputation values 👑. ngl this is giving very "earn your glow-up" energy ✨.
6. Routing and Data Integrity ✨
Preserving the integrity of routing and data (aka making sure peers don't return corrupt responses to queries, and don't route through malicious peers) is a big security issue in P2P networks 🚨. What the data looks like depends on the application using the overlay. For file-sharing, the data is the files themselves, their location, and owner information 📁. For realtime communication, it includes user location bindings and other routing information 📞. We get into these data integrity issues in Section 7 🎀.
6.1. Data Integrity 🍓
For file-sharing apps, inserting wrong content (like files that don't match their names or descriptions) and introducing corrupt data chunks (often called poisoning and pollution) are a major problem 😤. BitTorrent uses voluntary moderators to weed out bogus files, and the SHA-1 algorithm to compute the hash of each piece of a file so integrity can be verified 🔍. If a peer detects a bad chunk, it can download that chunk from another peer 🔁. With this strategy, different peers download different pieces of a file before the original peer leaves the network 🌈. Here's the catch though: if a malicious peer modifies the pieces that are only available on it, and the original peer disappears, then the object distribution will fail [Zhang] 💀. An analysis of BitTorrent in terms of integrity and performance can be found in the work of Pouwelse et al. [Pouwelse] 📚.
6.2. Routing Integrity 🧭
To boost routing integrity, it's important to reduce the number of queries forwarded to malicious nodes 🚫. Marti et al. [Marti] built a system that uses social network information to route queries over trusted nodes 🫶. Their algorithm uses trusted nodes to forward queries (if one exists and is closer to the required ID in the ID space) 🎯. Otherwise, it falls back to the regular Chord [Stoica] routing table 🔄. Their results show good average performance, but it can't guarantee log(N) hops for all cases 😬.
Danezis et al. [Danezis] suggest a method for routing when there are a large number of Sybil nodes 👥. Their approach makes sure a peer queries a diverse set of nodes and doesn't put too much trust in any single node 🧩. Both of those works are described based on Chord. But unlike Chord, DHTs like Pastry [Rowstron] and Kademlia [Maymounkov] have flexibility in selecting nodes for any row in a peer's routing table 🌸. Potentially many nodes share a common ID prefix of a given length, and they're all candidates for routing a given query 💜. To exploit social network information and still guarantee log(N) hops, a peer should select its friends to route a query, but only when they're present in the appropriate row selected by the DHT algorithm 👑.
7. Peer-to-Peer in Realtime Communication 📞
Using P2P in realtime communication basically means distributing the centralized entities from conventional architectures over P2P overlays 🌐. That cuts deployment costs and increases the reliability of the different services ✨. Initiatives like the P2PSIP working group in the IETF [P2PSIP] are working on this right now by using a DHT for services like registration, location lookup, and support for NAT traversal, which are normally handled by dedicated servers 🖥️.
Even though they're built on the same technology, overlays for realtime communication are different from file-sharing ones in at least two ways 🙈:
- Resource consumption. File-sharing systems use the DHT to store huge amounts of data (even if the distributed database only stores file locations, each user usually indexes hundreds or thousands of files 📚). Realtime communication overlays only need a subset of the resources available at any given time, since users only register a limited number of locations (rarely more than one) 📱.
- Confidentiality. In file-sharing apps, eavesdropping and identity theft aren't real threats, because files are supposed to be publicly available 🌍. That is not true for realtime communication, where the privacy and confidentiality of participants are of paramount importance 🤫. The notion of identity also plays a big role here, since it's the basis for starting a communication session 🪪. So it's essential to have mechanisms that unequivocally assert identities in realtime communication systems 💖.
In this section we go over the admission issues and security problems from the previous sections, and talk about solutions that would apply to realtime communication in P2P 🎀.
7.1. Peer Promotion 🦋
To stay compatible with existing user agents, P2P communication architectures would have to let certain nodes use their services without actually using overlay-specific semantics 🫧. One way to do that would be for overlay-agnostic nodes to register with an existing peer or a dedicated proxy via a standard protocol like SIP [RFC3261] 📲. Throughout the rest of this document, we'll call nodes that access the service without actually joining the overlay "clients" 🏷️.
In most cases, users could benefit from the overlay just by acting as clients 🥰. But to keep the solution scalable, at some point clients would have to be promoted to peers (admission to the DHT) ⬆️. This requires addressing the following issues 👀.
7.1.1. Active vs. Passive Upgrades 💌
Most existing P2P networks [KAZAA] [BITTORRENT] [PPLIVE] generally leave it up to the clients to decide if and when they apply to become peers 🙋. A well-known exception is the Skype network [SKYPE], arguably one of the most popular overlay networks for realtime communication today 🌟. Skype instances are supposed to operate as either super-nodes (directly contributing to the distributed provision of the service) or ordinary-nodes (just using the service), and the "promotions" are decided by the higher levels of the hierarchy [Baset] 🏰. Even if it doesn't make much difference to a client whether it has to actively ask for authorization to join or passively wait for an invitation, the passive approach has some perks that fit well in overlays where only a subset of peers is needed to provide the service (like realtime communication) 🎁:
- An attacker cannot estimate in advance when, or if, it would be invited to join the overlay as a peer 🕵️.
- It lets peers run long-lasting measurements on sets of candidates, so they can accurately pick the most appropriate ones for upgrading and only invite them when they're "ready" 📊. The opposite approach, where clients initiate the join themselves, adds an extra constraint for the peer that has to act on the request, since it doesn't know if and when the peer will try to join again 😩.
- It discourages malicious peers from attempting Sybil and, more generally, brute force attacks, since only a small ratio of clients has a chance to join the overlay (possibly after an accurate examination) 🚧.
7.1.2. When to Upgrade ⏰
To answer this, you'd have to define criteria that let you determine the load on a peer, plus a reasonable threshold 📏. When the load goes over that threshold, a client is invited to become a peer and share the load 🤝. Several mechanisms to diagnose the status of P2P systems have recently been proposed [P2PSIP-DIAG] 🩺. In general, reasonable criteria for determining load can be:
- Number of clients attached.
- Bandwidth usage for DHT maintenance, forwarding requests, and responses to and from peers and from the attached clients 📶.
- Memory usage for the DHT routing table, the DHT neighborhood table, application-specific data, and information about the attached clients 🧠.
7.1.3. Which Clients to Upgrade 🔝
Picking which clients to upgrade means defining and tracking new metrics 📈. The exact set of metrics, and how they influence decisions, should be the subject of serious analysis and experimentation 🔬. These could be based on the following observations 👇:
- Uptime. A peer could easily record how long it has been maintaining a connection with a client, and factor that in when deciding whether to upgrade it ⏳.
- Level of activity. It's reasonable to assume that the more a client uses the service (e.g., making phone calls), the less willing they'd be to see it degraded 📞💕.
- Keeping track of history. Peers could record the history of the clients they invite and how those clients contribute to the overlay 📖.
Other metrics, like public vs. private IP addresses, computation power, and bandwidth, should also be taken into account, even though they don't necessarily have a direct impact on security 🔐.
Note however that a set of colluded malicious peers can manufacture basically any criteria considered for the upgrade 🙃. Sophisticated peers can also overload the system or run denial-of-service attacks against existing super-nodes to improve their chances of being upgraded 💀.
7.1.4. Incentives for Clients 🎁
Clients need incentives to accept upgrades, so they don't put an excessive burden on existing peers 🫶. One way to handle this is to maintain separate incentive management through the use of currency or credits 🪙. Another option is to embed these incentives inside the protocol itself 🧩:
- Peers share only a fraction of their bandwidth (uplink and downlink) with clients. This results in higher latency when using the overlay's services as a client, and better service quality for peers 🐢.
- Peers could restrict the number or types of calls they allow clients to make 📵.
Introducing incentives like this may turn out to be somewhat risky, though 😬. Differences in quality would probably be noticeable to end users, who wouldn't always understand the difference between the roles their user agent is playing in the overlay 🤷♀️. That behavior could therefore be interpreted as arbitrary, and make the service look unreliable 📉.
7.2. Security 🔒
7.2.1. Targeted Denial of Service 💀
okay so besides the flood of queries from Section 2, there's another denial-of-service move that can hit one specific node in DHTs 😭 It works if the peers surrounding a particular ID are compromised. Those peers act as proxy servers for the victim, and they can fake the victim's responses by sending fictitious error messages back to peers trying to establish a session. Yikes. The good news is that Danezis et al.'s solution [Danezis] can also protect against these attacks, since in their solution peers vary the nodes they use in queries 🛡️
7.2.2. Man-in-the-Middle Attack 🕵️♀️
this one is giving drama. Seedorf [Seedorf1] describes the man-in-the-middle attack well for P2PSIP [P2PSIP] specifically, and it exploits the lack of integrity in routing information 🥀 A malicious node could return the IP addresses of other malicious nodes when someone queries for a particular ID. The requesting peer then sets up a session with a second malicious node, which hands back another "poisoned" reply. And it can keep going until the Time to Live (TTL) runs out and the requester gives up on the "wild goose chase" [Danezis] 🙃 A simple way to check that a routing lookup is legit is to use iterative routing and confirm that the node-ID of every returned routing hop gets closer to the desired ID with each hop. However, this is not a strong check, and it can be defeated [Seedorf1]. not me getting beaten by a "simple" check 💅
7.2.3. Trust between Peers 🤝
the effect of malicious peers could be softened by bringing the idea of trust into an overlay 🫶 There are a few different ways to do this:
- Using certificates assigned by an external authority. The drawback here is that it requires a centralized element, which kinda defeats the whole P2P vibe 😬
- Using certificates reciprocally signed by peers. This is pretty similar to PGP [Zimmermann] 🔐 Every peer signs the certificates of its "friend" peers, and it trusts any other peer that has a certificate signed by one of its friends. The catch? Even though it might be theoretically possible, in reality it is extremely difficult to get long enough trust chains 💀
7.2.4. Routing Call Signaling 📞
one way to build realtime communication overlays (like we've mentioned in earlier sections) is to just swap the centralized entities in signaling protocols like SIP [RFC3261] for distributed services ✨ Sometimes that means reusing existing protocol mechanisms for routing signaling messages. With SIP, it would mean treating peers as SIP proxies. BUT the design of SIP assumes those proxies are trusted, and it lets them fork requests or change their destination, add or remove header fields, act as the remote party, and basically manipulate message content and semantics. Not it. 🙅♀️
in a P2P environment, messages can get routed through tons of successive peers, and some of them might be compromised. So it's really important not to treat them as trusted proxies 🚨 One way to limit what peers can do is to protect signaling with some kind of end-to-end encryption 🔒
Another option is to extend existing signaling protocols and change how they route messages, so they can guarantee secure end-to-end transmission. Gurbani et al. [Gurbani] define a similar mechanism for SIP. It lets nodes set up a secure channel by sending a CONNECT SIP request, then tunnel all SIP messages through that channel. It uses a similar mechanism to the one used for upgrading from HTTP to HTTPS [RFC2818] 🌈
7.2.5. Integrity of Location Bindings 📍
it's super important that the location a user registers (usually a (URI, IP) pair) is the same thing that gets returned to the requesting party 👀 Or else, the entities making the lookup request need some way to verify the integrity of that pair. Seedorf et al. [Seedorf2] present a pure P2P approach for verifying the integrity of location binding information. The idea is that an entity picks an asymmetric key pair and hashes its public key to generate its URI. Then it signs its present location with its private key and registers the quadruple (URI, IP, signature, public key). Any entity that looks up the URI and receives that quadruple can verify its integrity by using the public key and the certificate 🔑 Another possible perk is that you can identify malicious nodes and keep a black list 🚫
BUT the resulting URIs are not easy to remember or to associate with entities 😩 So discovering these URIs and linking them to entities would need some sort of directory service. The authors suggest using existing authentication infrastructure for this, like a certified web service using SSL that publishes an "online phone book" mapping users to URIs 📖
7.2.6. Encrypting Content 🔐
using P2P overlays for realtime communication means content is likely to pass through numerous intermediate peers before it reaches its destination 🚶♀️ A typical example is using peers as media relays to traverse NATs in VoIP calls.
Unlike publicly shared files, communication sessions are in most cases expected to be private 🤫 So it's really important to make sure no media leaves the client application without being encrypted and securely transported through a protocol like SRTP [RFC3711]. Now, the processing needed by the encryption algorithms, plus the extra resources required to manage the keying material (e.g., for retrieving public keys when interacting with unknown peers), can be expensive, especially for mobile devices 📱⚡
7.2.7. Other Issues 🧐
details on cost and payment regimes could help identify even more threats 💸 They could also matter when figuring out the impact of a potential attack in the context of the specific business models behind particular overlays. In many cases, answers to these simple questions really help with designing protection mechanisms:
- Whom do the users pay?
- Do the users only pay when accessing the public telephone network?
- Is the billing done per call or is it fixed?
for instance, whether an attack like taking control of another's user agent or identity and using it for outbound calls is worth it depends on whether it would be economically advantageous for the attacker 🤑 Baumann et al. [Baumann] suggest that, to prevent unwanted communication costs, gateways for the public telephone network should only be accessible via authenticated servers, and dialing authorizations should be enforced. Also, it seems like billing would be difficult to do in a pure P2P manner, since it would mean keeping billing details with untrusted peers 🙈
8. Open Issues 🔮
existing systems for file-sharing, media streaming, and realtime communications all reach a reasonable level of security by relying on centralized components (e.g., login servers in Skype [Baset], moderators and trackers in BitTorrent [Pouwelse]) 🏢 So securing pure P2P networks is still a very active research field. At the time of writing, the main open issues fall into five areas:
- Secure assignment of node IDs.
- Entity-identity association.
- Distributed trust among peers.
- Resistance against malicious peer collusion.
- Robustness and damage recovery.
in general, P2P overlays are designed to work when the vast majority of their peers are interested in the service and act benevolently 🌸 Understanding how operations in different overlays get perturbed as the number of malicious or compromised peers grows is another interesting area of research 🧠 Also, a widely adopted methodology for evaluating and classifying security solutions would probably help P2P security research move forward much more efficiently 🚀
9. Security Considerations 🚨
this document is tutorial in nature, and it discusses some of the security issues of P2P systems used for realtime communications 📚 It does not aim to identify all possible threats and their solutions. Instead, starting from an analysis of the attackers, it digs into some important aspects of P2P security. It references the most relevant works published at the time of writing and discusses how they apply (or could apply) to realtime communications. Take this part seriously, bestie 😤💜
10. Acknowledgments 🎀
the authors are especially grateful to Dhruv Chopra, who contributed to the writing of the article "Peer-to-peer Overlays for Real-Time Communication: Security Issues and Solutions" (IEEE Surveys & Tutorials, Vol. 11, No. 1), which this work is partially derived from 🫶
The authors would also like to thank Vijay Gurbani and Song Haibin for reviewing the document, and the many others who provided useful comments 🌷
11. Informative References ✨
Okay bestie, this is the reading list 📚💅 Every paper, website and standard the RFC leans on lives here, so if you ever want the receipts, this is where they hide. I'm keeping every entry exactly as written, including the little typos, because the whole point is that you can find the original sources.
[Ahn] Ahn, L., Blum, M., and J. Langford, "Telling humans
and computers apart automatically", Communications of
the ACM, vol. 47, no. 2, February 2004.
[Androutsellis-Theotokis]
Androutsellis-Theotokis, S. and D. Spinellis, "A
survey of peer-to-peer content distribution
technologies", ACM CSUR, vol. 36, no. 4,
December 2004.
[BITTORRENT] "BitTorrent", <http://www.bittorrent.com/>.
[Baset] Baset, S. and H. Schulzrinne, "An analysis of the
skype peer-to-peer internet telephony protocol",
Proceedings of IEEE INFOCOM 2006, April 2006.
[Baumann] Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP
- Security and SPIT", Technical Report, University of
Berne, September 2006.
[COOLSTREAM] "COOLSTREAMING", <http://www.coolstreaming.us>.
[Castro] Castro, M., Druschel, P., Ganesh, A., Rowstron, A.,
and D. Wallach, "Secure routing for structured
peer-to-peer overlay networks", Proceedings of 5th
symposium on Operating systems design and
implementation, December 2002.
[Chellapilla] Chellapilla, K. and P. Simard, "Using Machine Learning
to Break Visual Human Interaction Proofs (HIPs)",
Proceedings of Advances in Neural Information
Processing Systems, December 2004.
[Condie] Condie, T., Kacholia, V., Sankararaman, S.,
Hellerstein, J., and P. Maniatis, "Maelstorm: Churn as
Shelter", Proceedings of 13th Annual Network and
Distributed System Security Symposium, November 2005.
[Damiani] Damiani, E., Vimercati, D., Paraboschi, S., Samarati,
P., and F. Violante, "A Reputation-Based Approach for
Choosing Reliable Resources in Peer-to-Peer Networks",
Proceedings of Conference on Computer and
Communications Security, November 2002.
[Danezis] Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R.
Anderson, "Sybil-resistant DHT routing", Proceedings
of 10th European Symposium on Research in Computer
Security, September 2005.
[Douceur] Douceur, J., "The Sybil Attack", Revised Papers
from First International Workshop on Peer-to-Peer
Systems, March 2002.
[Gurbani] Gurbani, V., Willis, D., and F. Audet,
"Cryptographically Transparent Session Initiation
Protocol (SIP) Proxies", Proceedings of IEEE ICC '07,
June 2007.
[KAZAA] "KaZaa", <http://www.kazaa.com/>.
[Kamvar] Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The
EigenTrust Algorithm for Reputation Management in P2P
Networks", Proceedings of 12th international
conference on World Wide Web, May 2003.
[Kim] Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission
Control in Peer Groups", Proceedings of Second IEEE
International Symposium on Network Computing and
Applications, April 2003.
[Kong] Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang,
"Providing robust and ubiquitous security support for
MANET", Proceedings of 9th International Conference on
Network Protocols, November 2001.
[Lee] Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation
Management System in Structured Peer-to-Peer
Networks", Proceedings of 14th IEEE International
Workshops on Enabling Technologies: Infrastructure for
Collaborative Enterprise, June 2005.
[Liang] Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution
in p2p file sharing systems", Proceedings of IEEE
INFOCOM 2005, March 2005.
[Marti] Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT:
P2P Routing with Social Networks", Proceedings
of First International Workshop on Peer-to-Peer and
Databases, March 2004.
[Maymounkov] Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer
Information System Based on the XOR Metric",
Proceedings of First International Workshop on
Peer-to-peer Systems, March 2002.
[McCue] McCue, Andy., "Bookie reveals 100,000 cost of
denial-of-service extortion attacks", available from
http://www.silicon.com, June 2004.
[NAPSTER] "Napster", <http://www.napster.com/>.
[Ohta] Ohta, K., Micali, S., and L. Reyzin, "Accountable
Subgroup Multisignatures", Proceedings of 8th ACM
conference on Computer and Communications Security,
November 2001.
[P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP)
IETF Working Group",
<http://www.ietf.org/html.charters/
p2psip-charter.html>.
[P2PSIP-DIAG] Yongchao, S., Jiang, X., Even, R., and D. Bryan,
"P2PSIP Overlay Diagnostics", Work in Progress,
December 2009.
[PPLIVE] "PPLive", <http://www.pplive.com>.
[Poon] Poon, W. and R. Chang, "Robust Forwarding in
Structured Peer-to-Peer Overlay Networks", Proceedings
of ACM SIGCOMM 2004, August 2004.
[Pouwelse] Pouwelse, J., Garbacki, P., Epema, D., and H. Sips,
"The Bittorent P2P File-Sharing System: Measurements
and Analysis", Proceedings of 4th International
Workshop of Peer-to-peer Systems, February 2005.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC4981] Risson, J. and T. Moors, "Survey of Research towards
Robust Peer-to-Peer Networks: Search Methods",
RFC 4981, September 2007.
[Ratnasamy] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and
S. Shenker, "A Scalable Content-Addressable Network",
Proceedings of ACM SIGCOMM 2001, January 2001.
[Rowaihy] Rowaihy, H., Enck, W., McDaniel, P., and T. Porta,
"Limiting Sybil attacks in structured peer-to-peer
networks", Proceedings of IEEE INFOCOM 2007, May 2007.
[Rowstron] Rowstron, A. and P. Druschel, "Pastry: Scalable,
distributed object location and routing for
large-scale peer-to-peer systems", Proceedings of 18th
IFIP/ACM International Conference on Distributed
Systems Platforms (Middleware 2001), November 2001.
[SHA1] 180-1, FIPS., "Secure Hash Standard", April 2005.
[SKYPE] "Skype", <http://www.skype.com/>.
[Saxena] Saxena, N., Tsudik, G., and J. Yi, "Admission Control
in Peer-to-Peer: Design and Performance Evaluation",
Proceedings of 1st ACM workshop on Security of ad hoc
and sensor networks, October 2003.
[Scheideler] Scheideler, C., "How to Spread Adversarial Nodes?:
Rotate!", Proceedings of 37th Annual ACM Symposium on
Theory of Computing, May 2005.
[Seedorf1] Seedorf, J., "Security Challenges for Peer-to-Peer
SIP", IEEE Network, vol. 20, no. 5, September 2006.
[Seedorf2] Seedorf, J., "Using Cryptographically Generated
SIP-URIs to Protect the Integrity of Content in
P2P-SIP", Proceedings of 3rd Annual VoIP Security
Workshop, June 2006.
[Singh] Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet
Telephony using SIP", Proceedings of International
Workshop on Network and Operating System Support for
Digital Audio and Video, June 2005.
[Sit] Sit, E. and R. Morris, "Security considerations for
peer- to-peer distributed hash tables", Revised Papers
from First International Workshop on Peer-to-Peer
Systems, March 2002.
[Stoica] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and
H. Balakrishnan, "Chord: A Scalable Peer-to-peer
Lookup Service for Internet Applications", Proceedings
of Applications, Technologies, Architectures, and
Protocols for Computer Communication 2001, May 2001.
[Tam] Tam, J., Simsa, J., Hyde, S., and L. Ahn, "Breaking
Audio CAPTCHAs with Machine Learning Techniques",
Proceedings of Advances in Neural Information
Processing Systems, December 2009.
[Uzun] Uzun, E., Pariente, M., and A. Selpk, "A
Reputation-Based Trust Management System for P2P
Networks", Proceedings of International Symposium on
Cluster Computing and the Grids, April 2004.
[Wallach] Wallach, D., "A Survey of Peer-to-Peer Security
Issues", Proceedings of International Symposium of
Software Security 2002, November 2002,
<http://www.cs.rice.edu/~dwallach/pub/
tokyo-p2p2002.pdf>.
[Yu] Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman,
"SybilGuard: Defending Against Sybil Attacks via
Social Networks", Proceedings of ACM SIGCOMM 2006,
September 2006.
[Zhang] Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data
Authenticity and Integrity in P2P Systems", IEEE
Internet Computing, vol. 9, no. 6, September 2005.
[Zimmermann] Zimmermann, Philip., "Pretty good privacy: public key
encryption for the masses", Building in big brother:
the cryptographic policy debate pag. 103-107, 1995.Authors' Addresses 🦋
Okay and these are the humans who wrote it! 🫶 Here's where you can reach them.
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: hgs@cs.columbia.edu
Enrico Marocco
Telecom Italia
Via G. Reiss Romoli, 274
Turin 10148
Italy
EMail: enrico.marocco@telecomitalia.it
Emil Ivov
SIP Communicator / University of Strasbourg
4 rue Blaise Pascal
Strasbourg Cedex F-67070
France
EMail: emcho@sip-communicator.orgThat's the whole RFC, bestie! 🌈✨ Thanks for hanging out with me through all seven parts 💖
📦 where this page comes from
- ietf: rfc5765 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms