Hacker Working Group FX Request for Comments: 0x7dd Phenoelit Updates: 0x7dc Category: Informational February 2013 Phenoelit eXchange Event Status of this Memo This memo provides information for the hacker community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) Phenoelit Group - This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License, but who cares? Motivation In extensive testing, it has been noticed that the information sharing and learning during gatherings of interested and skilled individuals, commonly referred to as conferences, changes for any particular individual over time. While initially, the most insights are gained by attending presentations and working through the presented material afterwards, over years the individual, striving for a more efficient information retrieval approach, resorts to what is known as the hallway track. Historical Context Previous re-designs and re-implementations of the conference concept, commonly referred to as PH-Neutral events, have shown that it is beneficial for the general research process to occasionally rework the basic concepts by reduction. The implementation of PXE (see CFP RFC 0x7dc) has demonstrated through proof of concept convincingly enough that the approach is at least worth exploring more. In the good tradition of academic research, teenage sex experiences, HTTP server implementations and Java Specification releases, we propose to try it multiple times, in order to see whether the results are reproducible. Proposal The goal of the proposed implementation is to maximize the information sharing bandwidth and throughput during a defined time frame. In order to accomplish this, the format uses a canvas LOC that represents the "hallway", but in contrast provides superior support, including easily accessible food, drinks and sanitary facilities, as well as a smoking and a non smoking section. The time frame is set to be 8 to 10 standard hours, beginning at the point in time denoted as PIT. Participants in the format shall be denoted nodes in this proposal. Nodes are introduced by being added into the general pool. It should be noted that this is a different approach than CFP RFC 0x7dc. The pool is seeded by arbitrary nodes, who respond to this proposal by using a SMTP transfer to the host reported in the MX record of the Internet domain phenoelit.de, addressing the recipient user fx. Said response shall include a topic of research, which the node is willing to explain in ad-hoc sessions to other nodes during the execution of PXE. The content shall be explainable in 10-15 standard minutes and the node shall be willing and prepared to explain it as often as required during the entire event. A suggested list of topics may be found in the following section Edge Communication. Edge Communication For the maximum transfer to work, nodes must strive to create as many communication graph edges with other nodes as possible during PXE. The content of the edge communication may include: - Code and tools that facilitate computer security research and hacking, both offensive and defensive in nature - Concepts, algorithms, procedures that aid research - Reports on research experiences, preferably including a time line of steps and their success or lack thereof - Of special interest are reports on FAILED RESEARCH, meaning that the intended goal was not reached - For particularly unimaginative nodes, the standard currency of hackers is also accepted (note: that's 0days, not bitcoin!) - Particularly brave nodes (an example incarnation is known as Inverse Path) have shown using their own implementation that edge communication about unfinished research, while theoretically being at risk of being stolen, is likely to be enhanced during the process All nodes shall bring sufficient material and equipment in order to participate in maximum transfer communication. The goal is to achieve a fully meshed graph with MAX^2 edges within the time frame of PXE. Graceful Shutdown It is understood that nodes willing to participate in PXE may suffer from mental overload and smoking brain matter after execution. Therefore, a graceful shutdown is provided by migrating nodes into a dancing event within LOC that is populated by other carbon based life forms not designated as nodes in this proposal. Potentially not fulfilled expectations of brain damage during PXE execution will be administered PIT+1day in a separate mission, Phenoelit style. Security Considerations Recent security considerations shall not be ignored by this proposal. Accordingly, the following security mechanisms are proposed, most of them modeling adapted approaches in the spirit of this proposal. All of the security mechanisms listed below run on the base media of mutual respect. However, since implicit and/or proprietary protocols fail to work, this proposal opts for an explicit and open protocol design, especially in regards to security mechanisms. 1) Creeper Move Messaging Since other implementations have been observed to suffer from retrospective black-listing approaches of not appreciated edge communication and this proposal aims at maximizing edge communication regardless of content, it proposes a remote indication system: If your edge communication to another node is not within the bounds of your submitted content but could be classified as recipient node specific, you MUST use CMM (Creeper Move Messaging). This out-of-band signaling uses indications in the form of cardboard rectangles, colored according to the following table. The coloring follows RFC 1896, section "Font-Alteration Commands", sub-section "Color". Color 0000,FFFF,0000: The node signaling this would like to initiate a special edge communication and is, after thorough consideration, entirely sure that this would not be received as unwanted. Color FFFF,FFFF,0000: The node signaling this would like to initiate an edge communication, but was not able to determine beforehand to its own satisfaction whether this communication could be considered unwanted. Color FFFF,0000,0000: The node signaling this is completely aware that the edge communication it would like to initiate is completely unwanted and/or not appropriate. It uses said signaling instead, in order to perform the creeper move from a pleasantly large distance, but still wants to communicate the fact per se, taking chances that the communication may not be as unwanted as concluded initially. Recipients SHOULD consider non-lethal responses. If the out-of-band signaling is not positively acknowledged, the edge communication MUST be considered unwanted. If the out-of-band signaling is not acknowledged, the sender MUST suspend sending non-content communication to this particular node for the remaining protocol run. If the out-of-band signaling is positively acknowledged, the respective nodes MAY have fun. In the case that the receiving node considers the signaling node non-compliant to the above described protocol, the reasoning of this conclusion immediately becomes the receiving node's secondary edge communication content, which is handled equally to the primary one, i.e. other nodes are free to request that content to be presented. 2) Anti Policy Harassment Policy Nodes in previous as well as alternative implementations have been observed to suffer from rejection states within their edge communication handling engines when received content includes domestic or foreign policy and strategy considerations. Discovered in the wild were error messages of types ENOTCOOL and EEVILGOVERNMENT as well as ECYBER. Nodes in running the protocol proposed here SHOULD implement handling such edge communication the same way other edge communications are. 3) Booth Babe Damping Booth Babe Damping or Scene Whore Damping is a common edge communication limiter employed by nodes with the goal of freeing resources for more channels with a perceived higher throughput. Nodes within the proposed protocol MUST NOT implement this mechanism, as it has been shown to be inferior (see [1], section 4). All nodes SHOULD revisit concepts and their weaknesses as described in [2], section 4.1.3, before engaging. 4) Root Node Intervention Emergency edge communication channels MUST BE reserved towards the root node. If initiated, the root node MAY isolate an offending node from the network immediately, migrate one or more involved nodes to different platforms or react otherwise. The root node SHOULD NOT be expected to implement any form of democratic concepts. In the current version of this proposal, the root node has a fixed value of RNI. All other nodes are equal. Nodes SHOULD NOT expect priority use of emergency edge communication based on some node property they MAY think to have. Constants LOC - Frannz Club (http://www.frannz.de/), Berlin, Germany PIT - 2013 May 31, begin 11:00 CET (11 standard hours after midnight!) MAX - 0x64 RNI - 41414141 References 1: http://www.ripe.net/ripe/docs/ripe-378 2: http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt