webp2p

INTERNET DRAFT Jesús Leganés Combarro "piranna" Document: draft-piranna-webp2p-01 (independent) webp2p Abstract This draft describes a protocol by which two machines can discover and interconnect themselves using WebRTC to create a P2P network, being able to use for handshaking a third party server independently of its protocol or other intermediary peers already connected on the network. This protocol is based on public-key encrypted messages and allow to do the connections anonymously and at the same time to authenticate trusted peers. Status of this Memo This Internet-Draft is work-in-progress. Copyright Notice Copyright (c) 2014 the persons identified as the document authors. All rights reserved. Table of Contents 1. Introduction....................................................1 2. Terminology.....................................................2 3. Encryption scheme...............................................3 4. Messages........................................................3 4.1 Presence.....................................................3 4.1.1 Presence message format..................................4 4.2 Handshaking..................................................5 4.2.1 Offer....................................................5 4.2.2 Answer...................................................5 5. References......................................................6 6. Authors' addresses..............................................6 1. Introduction This specification describes a protocol to create and interconnect several machines on a P2P network using WebRTC DataChannel objects. It could also be used over any other bidirectional, message oriented and binary capable transport layer like BoSH or as a WebSockets sub-protocol. To do the initial bootstrapping of the network it is required an external service to connect the peers between them, being this protocol agnostic about the mechanism used by it (for example a peers's pool or a PubSub system), being the only require that it can send anonymous one-to-many messages between the peers. piranna [Page 1] Internet-Draft webp2p February 2014 The actions the interface exposes are: * presence: announce our presence so other older peers can send us a request to create a connection. This message is only used on handshake servers and it's not required when using other intermediary peers for the initial connection handshake. * offer: ask to a peer to create a connection. This message has the minimal information to create it, if more data is need to be exchanged to create the connection as required by the user, this will be send later in-wire using 'candidate' messages. * answer: response to a previous offer message. As with the 'offer' message, this one has the minimal information to create the connection and if more data is need to be exchanged it will be send later in-wire using 'candidate' messages. * authenticate: send a signed message so receiver can check if it knows and can trust to that peer. This message is send by both peers to each other only one time as the first message once the connection between them has been established. * candidate: message send in-wire to exchange pending data from 'offer' and 'answer' messages required to establish the connection as required by the user. * error: response to a previous failed request message, for example an 'offer' or a 'candidate' one. The exact details of these three actions are described in this specification. 2. Terminology 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 RFC 2119 [WORDS]. "SHOULD" and "SHOULD NOT" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure. "Handshake server" is a third party service external to the P2P network used to help on the initial bootstrapping of the peers. It can use any message oriented transport layer that allow one-to-many communications in an anonymous way. Examples of this (but not limited to) are anonymous XMPP servers, private timelines on microblogging sites, or mDNS/ZeroConf, UPnP and PubSub protocols. piranna [Page 2] Internet-Draft webp2p February 2014 "SessionID" is an unique ID that identify the peer on all the network. It correspond to a per-session randomly created public-key, but it can also be statically set by the user to be easily reacheable. Being a public-key, other peers use it to encrypt the messages when sending them to that peer. "UserID" is an unique ID that is based on a persistent randomly created public-key and so it identify the peer between sessions. It is used to authenticate and trust the peer against others, and due to this it's never transmitted on the wire. 3. Encryption scheme Sessions made use of RSA 2048, leading to a length of SessionIDs of 256 bytes. 4. Messages Communication is message based using a binary format with fixed length fields except the last one in some of them (specified later), where it's length is correspond to the pending bytes until the end of the message. To be able to send them inside a unique IP package both using a handshake server or a DataChannel connection, the messages max length will not be greater that the [SCTP payload], being this of a size of 1192 bytes. Communication is done in an asynchronous way, not waiting for a response and processing all the messages in the order they are being received since this can arrive at any moment. First byte of the message correspond to the 'ttl' (Time-to-life) field of the message, stored as a unsigned char. Only values greater than zero are valid ones, being the zero a exceptional case for the 'presence' message (defined later). All the bytes after the first one up to the end of the message correspond to the encrypted data field (defined later) if other thing is not specified. 4.1. Presence Presence message is used to notify our presence when connecting to a handshake server so other (older) peers connected to it can send to us a connection offer, and due to this it SHOULD NOT be used when using intermediary peers to interconnect two of them already on the P2P network. After sending the presence message, the peer keeps waiting listening for the arrival of presence messages from new peers, choosing to send them a connection offer or not according to the number of newer peers it got connected thanks to this handshake server. This number is related to each handshake server limits. When detecting that a new peer has connected to a handshake server, the algorithm to choose if a peer should connect to this new peer or not is left to the developer and should adjust it to the limits of the particular handshake server used, but the next three algorithms are proposed: piranna [Page 3] Internet-Draft webp2p February 2014 * connect to all newer peers. This allow to quickly increase the number of connections with newer peers, but all of them would be located in a reduced slice of time. * connect randomly: this allow a greater arity distribution of the network over time, but would be slower to get a peers critic mass on that handshake server and disconnect from it. * connect on increasing intervals: increase progressively the number of "leap" peers when connecting to them, both randomly or numerically. This would spend a lot of time to get the full critic mass, but also will assure that we got a big enought number of peers just after connecting to the handshake server and also distribute them homogeneity. When the peer got connected to that predefined number of newer peers (a "critic mass") over a particular handshake server, it disconnect itself from it and start using preferentially the P2P network to connect to other peers, allowing to other new peers to use the handshake server and increasing the network arity. After disconnecting from the handshake server, it's left to the developer or user decision if the peer should connect to a new handshake server (if available) after it gets disconnected from one of them or not. Also, it could be defined to connect to several of them at the same time. It's recommended that if possible, don't disconnect from handshake servers and protocols without usage limits like the ones working on a LAN network. 4.1.1. Presence message format The message is identified by having zero as 'ttl' as an exceptional value (otherwise an invalid one) and the encrypted data field length equal to the length of a SessionID, doing in that case the functionality of 'from' field and having the newly connected peer SessionID in clear stored in raw binary format. This is later used by the other peers to encrypt their connection requests in the 'offer' messages. * ttl: [1 byte] = 0 * from: [256 bytes] = sessionID (session public-key) Total message size: 1+256 = 257 bytes +-------+ 0 | ttl=0 | |-------| 1-257 | from | +-------+ piranna [Page 4] Internet-Draft webp2p February 2014 4.2. Handshaking 4.2.1. Offer When a peer want to connect to another one, both on the initial handshake with a new peer after being notified of its presence or to make a transfer, it sends an 'offer' message. It has the destination UID as first argument, the offer SDP as second one and an array as third one having a list of the peers where the message have been routed, being empty on first instance. An example message would be: ["offer", "550e8400-e29b-41d4-a716-446655440000", <offer SDP string>, []] After checking that we don't really have a connection to that peer, in case the connection is for a new peer it is send directly over the handshake server connection where we got notified about it, otherwise it is broadcasted over all our current connections. When the offer message reaches a peer check if it's the one desired (the one on the destination field) and if not, append the UID of the peer where we receive it on the route field. Handshake server are considered regular peers for routing purposes, so they have a descriptor (usually the service name) as UID. Later the peer check in the destination field its one of its connections. If so, it sends the message directly to him but if not, it broadcast the message over all its current connections (except the one where it got the message or the ones already routed) as it was done with the original message flooding all the P2P network just to find a route to it, if it really exists. To prevent the message to being running infinitelly on the network, previously to being processed and dispatched it is check if our peer UID is on the route argument, showing us that this message have been previously routed by us and discarding it. When the offer message reaches the desired peer a new PeerConnection is created to hold the connection with the requested peer if we don't have it already, and apply to it the SDP from the message. 4.2.2. Answer After processing the offer message, a new 'answer' message is generated. This message has the origination (the UID of the peer that send the answer message) as the first parameter, the answer SDP and the offer route, so it can be runned backward looking the peer that sended the offer message. An example message would be: piranna [Page 5] Internet-Draft webp2p February 2014 ["answer", "1a66b984-89d3-11e2-8bc3-4f265af2680c", <answer SDP string>, ["550e8400-e29b-41d4-a716-446655440000", "1b70093e-89d3-11e2-90c8-2f82ef7d7182"]] When a peer receive an answer message it check if it was sended back to us or the route array got empty and we don't know where to send it, so it's ignored. After that, we check if it was send to us (looking if the first UID on the route array if ours) so connection can be stablished with the SDP that's attached on the message, or we can re-send it back running over the route array. In that case, run over all the UIDs on the route array looking for possibly newly connected peers while the offer/answer dance was being done that would allow some shortcuts on the route sending back the answer message, and send to them it. In case no connected peer was found on the route (maybe they got disconnected), then send the message by broadcast so the message can look the path to the offering peer. When a connection is stablished between two PeerConnection objects, is suggested that both ends create new DataChannels that can be used for routing purposses to increase the network arity. This newly created DataChannels can be used for application specific usage too. 5. References [SCTP payload] https://groups.google.com/d/msg/discuss-webrtc/LZsm-jbP0zA/Tim9ODhWsI8J [WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6. Authors' addresses Jesús Leganés Combarro "piranna" (independent) Email: piranna@gmail.com piranna [Page 6]