TOC 
Initial PMDP draft, for reference onlyB. Stultiens, Ed.
 Vagrearg
 April 26, 2014


The PingMyDroid™ Protocol

Abstract

Informing the neighborhood using multicast distribution.



Table of Contents

1.  Introduction
2.  Terminology
3.  PMDP Message Format
    3.1.  Message Header
    3.2.  Message Content
        3.2.1.  PMDT_CATEGORY
        3.2.2.  PMDT_SUBCATEGORY
        3.2.3.  PMDT_TEXT
        3.2.4.  PMDT_RESOURCE
        3.2.5.  PMDT_UUID
        3.2.6.  PMDT_TIMESTAMP
        3.2.7.  PMDT_CARDINAL
        3.2.8.  PMDT_INTEGER
        3.2.9.  PMDT_FRACTION
        3.2.10.  PMDT_PADDING
        3.2.11.  PMDT_KEY
        3.2.12.  PMDT_ENCRYPTED
        3.2.13.  PMDT_FINGERPRINT
        3.2.14.  PMDT_SIGNATURE
    3.3.  Message Distribution
    3.4.  Message Content Ordering
4.  Addressing and Service Discovery
5.  DNS as Trust Anchor
6.  Security Considerations
7.  IANA Considerations
8.  Trademark Notice
9.  References
§  Author's Address




 TOC 

1.  Introduction

The PingMyDroid™ protocol (PMDP) is a method for one-to-many information distribution. PMDP multicasts [RFC1112] (Deering, S., “Host extensions for IP multicasting,” August 1989.) UDP packets [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.) on the local network for any and all to receive, see and interpret. The protocol allows information to be distributed to stationary and mobile clients who's target address is unknown.

Many portable devices are available with the proliferation of smartphones and other wearable gadgets. Most of these gadgets have enables wireless communication. However, administration of the network location and associated network addresses of these devices may be difficult and makes them hard to reach using uni-cast communication. Secondly, polling a central server from each client device requires each client to know the server address and creates volumes of unnessecary traffic with increasing numbers of gadgets on the network. PMDP provides a means of information distribution that does not depend on registered location or network addresses of its senders or listeners.



+---------------+      +---------------+
| PMDP Server 1 |      | PMDP Server 2 |
+-------+-------+      +---------------+
        |                    /
        \    ___   ---------/
         \__(   )_/
         (_      _)           \|/ WiFi AP
           (____)              |
           /     \-------------+
          /                                   \|/
  +------+---+                +----------+     |
  | Client A |                | Client B |-----+
  +----------+                +----------+

                             \|/
              +----------+    |
              | Client C |----+
              +----------+
 Figure 1: Typical PMDP network 

Using multicast communication is a logical extension within wireless networks. Most type wireless networks, such as WiFi, share the medium, where multicast communication significantly reduces used bandwidth of the scarce medium resource. The reduced traffic requirements and the address-less targets are preferable. Clients and servers may opt to revert to unicast communication once a communication channel has been established and hence reduce chatter.



 TOC 

2.  Terminology

The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



 TOC 

3.  PMDP Message Format

PMDP messages consist of packets with a fixed 28 octet header followed by zero or more variable size content entries. The maximum message size is 65535 octets. However, fragmentation may not be desireable on all networks and it is RECOMMENDED that messages are smaller than or equal to the path MTU [RFC1191] (Mogul, J. and S. Deering, “Path MTU discovery,” November 1990.) of the covered network.

The header conveys catagorization in terms of severity and may be used as a coarse filter. The content consists of informational records detailing the message. Messages MAY be signed and encrypted by means of the X.509 public key infrastructure. All words/values, in both header and content entries, are transmitted in network order.



A PMDP message informing the activation of the bell at the front door:

Header  (PMDS_INFO, timestamp, flags, sequence,
         xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
Content (PMDT_TIMESTAMP, knock_timestamp)
Content (PMDT_CATEGORY, PMDC_LOCAL)
Content (PMDT_SUBCATEGORY, PMDC_LOCAL_BELL)
Content (PMDT_CARDINAL, front_door_id)
Content (PMDT_TEXT, "Knock, knock!")

If someone was to press ". . . - - - . . ." on the bell button, it might be appropriate to change the severity level from PMDS_INFO to PMDS_CRITICAL.

 Figure 2 



A PMDP message informing of a temperature event from a monitoring system:

Header  (PMDS_WARNING, timestamp, PMDF_SILENT, sequence,
         xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
Content (PMDT_TIMESTAMP, detection_timestamp)
Content (PMDT_CATEGORY, PMDC_MONITOR)
Content (PMDT_SUBCATEGORY, PMDC_MONITOR_TEMPERATURE)
Content (PMDT_FRACTION, 420, 10)
Content (PMDT_RESOURCE, "scheme://serverhost.example.com/path")
Content (PMDT_TEXT, "Temperature elevated")
Content (PMDT_FINGERPRINT, ...)
Content (PMDT_SIGNATURE, ...)
 Figure 3 



 TOC 

3.1.  Message Header

The format of the message header is depicted in Figure 4 below:



0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    | Sev |F|  Seq  |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Microseconds              |  Res  | Timestamp(hi) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Timestamp (low 32 bits)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-                                                             -+
|                      UUID (16 octets)                         |
+-                                                             -+
|                                                               |
+-                                                             -+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 4 

Version, 8 bits:

Protocol version, currently 2

Sev[erity], 3 bits:

The severity of the message according to RFC 5424 section 6.2.1 table 2 (Gerhards, R., “The Syslog Protocol,” March 2009.) [RFC5424] and are summarized in table Table 1 below. The severity level may not be required for some categories, in which case the severity MUST be set to level PMDS_INFO.



ValueName
0 PMDS_EMERGENCY
1 PMDS_ALERT
2 PMDS_CRITICAL
3 PMDS_ERROR
4 PMDS_WARNING
5 PMDS_NOTICE
6 PMDS_INFO
7 PMDS_DEBUG

 Table 1 

F[orce silent] flag, 1 bit:

The force silent flag instructs the client to alert in a non-audible way. This is useful in public areas where noise may be an unwanted disturbance. The client MUST honor this flag.

Seq[uence], 4 bits:

A sequence number, counting from 0, indicating the resending of the same message. The sequence field MUST be incremented each time the server resends the same message, as identified by its UUID, so that clients may detect reception of duplicate messages. See section Section 3.3 (Message Distribution) below.

Reserved, 16 bits:

Reserved bits MUST be set to zero

Microseconds, 20 bits:

The microsecond fraction of the timestamp. Valid range of values is [0..999999]. Servers with little computational power, such as small embedded systems, MAY set the microseconds field to zero if time resolution is of no concern.

Res[erved], 4 bits:

Reserved bits MUST be set to zero

Timestamp, 40 bits:

The sender's timestamp in the format of the UNIX Epoch in seconds (UTC). Only the 40 least significant bits of the 64 bit time_t type variable are used. Systems that only have a 32 bit time_t type MUST take into account that a 32 bit Epoch representation expires in year 2038 or 2106, depending on whether time_t is interpreted signed or unsigned. Servers MAY set the timestamp field to zero if no local time source is available, such as in small embedded systems without time reference. If the timestamp field is set to zero, then the microseconds field MUST also be set to zero. Servers SHOULD set the timestamp to the current time when ever possible, even in cases where absolute time is of no importance.

UUID, 16 octets:

The UUID is a universally unique identifier according to [RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.) in binary form. The UUID uniquely identifies the message as a whole. The UUID in combination with the Seq[uence] field enable identification of duplicate messages.



 TOC 

3.2.  Message Content

Each message header is followed by zero or more message content structures consisting of type, length and data fields as shown in Figure 5. The start of each message content structure MUST be 32 bit word aligned. The last message content in the packet may ommit the padding to reduce the packet's size to the minimum required size to fit the data.



  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Type              |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...                                                             ...
 |                             Data                              |
...                                                             ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Data     |    Padding    |    Padding    |    Padding    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     <next content>                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ...                                                           ...
 Figure 5 

Type, 16 bits:

The message content type as described in table Table 2



ValueNameDescription
0 PMDT_CATEGORY 32 bit unsigned integer indicating the main category
1 PMDT_SUBCATEGORY 32 bit unsigned integer indicating the sub-category
2 PMDT_TEXT Text (UTF-8)
3 PMDT_RESOURCE Resource (URI)
4 PMDT_UUID Binary UUID (16 octets)
5 PMDT_TIMESTAMP Target timestamp of event
6 PMDT_CARDINAL 32 bit unsigned integer quantity
7 PMDT_INTEGER 32 bit signed integer quantity
8 PMDT_FRACTION 32 bit signed dividend/unsigned 32 bit divisor
9..49151 Available for assignment
49152..65279 Experimental
65280..65530 Reserved
65531 PMDT_PADDING Padding fill
65532 PMDT_KEY Encryption key
65533 PMDT_ENCRYPTED Encrypted content
65534 PMDT_FINGERPRINT Signator's certificate fingerprint
65535 PMDT_SIGNATURE Signature (must be last content)

 Table 2 

Length, 16 bits:

The message content length. The length does not include Type, Length and Padding fields. A zero (0) length message is allowed, resulting in a four octet content structure. The maximum supported length is 65535 octets.

Data, {Length} octets:

The content to be interpreted as described below.

Padding, 0..3 octets:

Padding to start the next message on a 32 bit word boundary. The maximum number of padding octets is three (3). Padding octets MUST NOT be interpreted as data and serves only for alignment. The padding octets MAY have any value. Using random data supports the encrypted form of the content.

Message content types describe a variety of data. The order of the message content structures MUST be observed. Types in different orders have distinct meaning and convey specific information as described in Section 3.4 (Message Content Ordering).



 TOC 

3.2.1.  PMDT_CATEGORY

The PMDT_CATEGORY describes the primary classification of the message indicating the context of the message. See table Table 3 below for values.



ValueNameDescription
0 PMDC_LOCAL Local scope for private use, often not signed
1 PMDC_MONITOR Messages from monitor systems (e.g. Nagios)
2 PMDC_LOG Logging messages; f.ex. from a syslog server
3 PMDC_TRAFFIC Traffic announcements
4 PMDC_PUBLIC General public announcements
128 PMDC_COMMERCIAL Commercial interests
129 PMDC_SERVICE Automated services

 Table 3 



 TOC 

3.2.2.  PMDT_SUBCATEGORY

The PMDT_SUBCATEGORY describes the secondary classification of the message indicating the purpose of the message.

A sub-category with the most significant bit set is considered to be an experimental sub-category and is exclusively reserved for local use. A server setting the experimental sub-category flags may use any sub-category value. Interpretation of the sub-category and any following data SHALL be limited to the locally administered network. Servers that require a distinct category and/or sub-category SHOULD request an assignment from the available pool. See table Table 4 below for known values.



ValueNameDescription
0x00000000 PMDC_x_NONE Unspecified sub-category
PMDC_LOCAL
0x00000001 PMDC_LOCAL_BELL Bell ring (front door knock)
0x00000002 PMDC_LOCAL_DINNER Dinner is ready, stop gaming and eat
PMDC_MONITOR
0x00000001 PMDC_MONITOR_TEMPERATURE A temperature monitoring message
0x80000000 - 0xffffffff PMDC_EXPERIMENTAL Local experimental sub-category

 Table 4 



 TOC 

3.2.3.  PMDT_TEXT

The PMDT_TEXT content exists of a character string in the UTF-8 character set [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The string is delimited by the Length field and does not contain any terminator character. The character string MAY NOT include the nul-character.

A PMD_TEXT content MAY be of length zero. A zero length string may indicate the lack of additional information from the source, and, as such, possibly convey useful information.



 TOC 

3.2.4.  PMDT_RESOURCE

The PMDT_RESOURCE content is to be interpreted as a URI string [RFC1630] (Berners-Lee, T., “Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web,” June 1994.). The resource string is delimited by the Length field and does not contain any terminator character. The resource string MAY NOT include the nul-character. Any valid resource identifier string can be used. Example:

http://www.example.com/get_more_info?id=xyz

A PMDT_RESOURCE content MAY be of length zero. A zero length resource indicates the lack of information. The interpretation varies on the context of the message as a whole.



 TOC 

3.2.5.  PMDT_UUID

The PMDT_UUID content is the binary form of a universally unique identifier [RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.). The content size MUST be set to 16.



 TOC 

3.2.6.  PMDT_TIMESTAMP

The PMDT_TIMESTAMP content is used to convey additional timestamp information. The timestamp SHOULD represent the exact time at which the event causing the message occurred. The content size MUST be set to 8. The PMDT_TIMESTAMP is to be interpreted as a delimiter if multiple messages are combined into one packet. The format is:



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         PMDT_TIMESTAMP        |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Microseconds             |  Res  | Timestamp(hi) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Timestamp (low 32 bits)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 6 

The timestamp is the lower 40 bits of the UNIX Epoch in seconds (UTC) and a high resolution 20 bit microsecond field (range 0..999999). The 'Res' field indicates reserved bits and MUST be set to zero.

If no PMDT_TIMESTAMP is present, then the client SHOULD use the message header's timestamp for reference. If multiple PMDT_TIMESTAMP content are present, the timestamp SHALL relate to the content that follows.



 TOC 

3.2.7.  PMDT_CARDINAL

The PMDT_CARDINAL content conveys a 32 bit unsigned quantity. The content size MUST be set to 4.



 TOC 

3.2.8.  PMDT_INTEGER

The PMDT_INTEGER content conveys a 32 bit signed quantity. The content size MUST be set to 4.



 TOC 

3.2.9.  PMDT_FRACTION

The PMDT_FRACTION content conveys a fractional number defined by a 32 bit signed dividend divided by an unsigned 32 bit divisor. Plus and minus infinity are defined by setting the divisor to zero and the dividend to a positive (+infinity) or negative (-infinity) value. A not-a-number (NAN) value is defined by setting both dividend and divisor to zero. The content size MUST be set to 8.



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         PMDT_FRACTION         |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Dividend                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Divisor                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 7 



 TOC 

3.2.10.  PMDT_PADDING

The PMDT_PADDING adds non-interpretable data solely for purpose of alignment. Appending PMDT_PADDING content in an encrypted message may be used to add entropy to the encrypted data. The data should preferably be taken from a good random source.



 TOC 

3.2.11.  PMDT_KEY

The PMDT_KEY content conveys the encryption method, key and the initialization vector (iv) of the following PMDT_ENCRYPTED message content. The PMDT_KEY content is encrypted using the public key of the certificate, identified by the PMDT_FINGERPRINT content following the PMDT_ENCRYPTED content, using mode RSAES-PKCS1-v1_5 (section 7.2) (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447].



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PMDT_KEY           |        variable length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             CRC               |            Type               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Key                              |
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              IV                               |
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 8 

The PMDT_KEY content in unencrypted form is layed out as follows:

CRC

16-bit CRC value of Type, Key and IV fields, using the CCITT polynomial and -1 as initialization. The CRC field must be set to 0 is no CRC is calculated.

Type

16-bit unsigned number with the logical or of the encryption algorithm and feedback mode as detailed in tables Table 5 and Table 6.

Key

the key for use with specified algorithm

IV

an initialization vector for use with specified algorithm

The CRC field, if non-zero, may be used in decryption to check in a quick manner whether the certificate's private key unsuccesfully decrypted the key and IV from a valid, however unlikely, PKCS1 decryption result.

The sizes of the key and IV are dependent on the encryption algorithm used. The key and IV SHOULD be randomly generated for each PMDT_ENCRYPTED content.



ValueNameDescription
0x0000   reserved
0x0001 PMDE_ALGO_AES128 AES with 128-bit keys
0x0002 PMDE_ALGO_AES192 AES with 192-bit keys
0x0003 PMDE_ALGO_AES256 AES with 256-bit keys
0x0004 PMDE_ALGO_CAMELLIA128 CAMELLIA with 128-bit keys
0x0005 PMDE_ALGO_CAMELLIA192 CAMELLIA with 192-bit keys
0x0006 PMDE_ALGO_CAMELLIA256 CAMELLIA with 256-bit keys

 Table 5 



ValueNameDescription
0x0000   reserved
0x0100 PMDE_FB_CBC Cipher-block chaining
0x0200 PMDE_FB_CFB Cipher feedback

 Table 6 

Implementation of PMDT_KEY is OPTIONAL, however it is strongly encouraged.



 TOC 

3.2.12.  PMDT_ENCRYPTED

The PMDT_ENCRYPTED content encapsulates encrypted data. The PMDT_FINGERPRINT content MUST follow the PMDT_ENCRYPTED content to indicate which certificate is required for decryption and a PMDT_KEY MUST preceed PMDT_ENCRYPTED to indicate the encryption key. A second PMDT_FINGERPRINT content may be provided if the packet is signed with a different certificate than the encryption certificate. The intended recipient(s) should have the proper decryption certificate stored in a secure manner. Transfer and storage of the decryption certificate is beyond the scope if this memo.

The decrytped content MUST be in the same message content format as described by this section Section 3.2 (Message Content).

Encrypted data must often be aligned to a certain multiple. PMDT_PADDING content may be added to the encrypted data to ensure proper alignment for encryption and add extra entropy.

Implementation of PMDT_ENCRYPTED is OPTIONAL, however it is strongly encouraged.



 TOC 

3.2.13.  PMDT_FINGERPRINT

The PMDT_FINGERPRINT content encapsulates the X.509 digest of the signator's certificate. It's purpose is to convey a pointer to a possible set of certificates associated with the current sender network. If the client already has retreived the certificate for the current sender network, then the fingerprint provides an index into the client's local database.

If a PMDT_FINGERPRINT content is sent, which is not associated with a PMDT_ENCRYPTED content, then the message MUST be signed and the fingerprint MUST match the signing certificate's fingerprint.

The fingerprint's length depends on the certificate and algorithms used, which are dictated by the used certificate. The fingerprint is transmitted in binary form.



 TOC 

3.2.14.  PMDT_SIGNATURE

The PMDT_SIGNATURE content provides a means of authenticating the sender. The PMDT_SIGNATURE content MUST be the last in the packet. The signature is calculated over the packet data starting from the PMD header's UUID field up to, but not including the PMDT_SIGNATURE content. Possible padding between the preceding PMDT_FINGERPRINT and the PMDT_SIGNATURE is part of the data to sign (this can only happens if an odd fingerprint algorithm may become part of the specification). A client SHOULD verify the signature of the packet if the PMDT_SIGNATURE content is provided.

The signature is transmitted in binary form. The size of the signature depends on the signing certificate's key size. A minimum key size of 1024 bits SHOULD be used, resulting in a 128 octet signature. However, it is recommended to use a 2048 bits or 4096 bits key size, resulting in a 256 or 512 octet signature. Larger key sizes are permissible, but place a limit on the packet's size due to limited MTU.

A practical key size limit, without forcing fragmentation, is 8192 bits, resulting in a 1024 octet signature, which would fill just over two-thirds of an ethernet frame of 1500 octets.



 TOC 

3.3.  Message Distribution

Each PMDP message is sent from one or more servers to all clients connected to the network. The distribution of messages is only bound by the propagation rules for multicast, which are set by the network administrator. PMDP servers usually limit the scope of the network by adjusting the Time-To-Live at the IP level to one (1) or two (2) [RFC0791] (Postel, J., “Internet Protocol,” September 1981.). It is RECOMMENDED that PMDP servers use a Time-To-Live value of one (1), where ever possible, to prevent multicast traffic to exit the local network due to misconfiguration.

Reception of UDP multicast packets is by definition unreliable due to hubs, switches and routers dropping packets or mid-air collisions. There is no guarantee that a message will be received by anyone. However, it is generally enough to ensure that there is a sigificant chance of reception. Servers SHOULD resend the same message several times with a set or random interval that is short enough to keep the message's timestamp within reasonable limit. The sequence number and UUID of the message header are provided so that clients can detect whether the message has been received before or is a new one. The RECOMMENDED strategy for sending messages is:

  1. Create a UUID for the specific message;
  2. Set the sequence number to zero;
  3. Send the message;
  4. Increment sequence number, quit if number exceeds resending limit;
  5. Delay 100...2000 milliseconds;
  6. Goto step 3.

There is no need for the message to be re-signed for each send, as the signature does not include the sequence number nor the header's timestamp. The server SHOULD update the header's timestamp before sending the same message with updated sequence if a distinctive PMDT_TIMESTAMP content is part of the message. If no PMDT_TIMESTAMP is part of the message, then the server MAY update the header's timestamp if the original timestamp is not paramount.

It is RECOMMENDED to resend each message between 3 and 10 times. Messages with high severity, such as PMDS_EMERGENCY or PMDS_CRITICAL, may need to be sent more often than low severity messages to improve the chance of reception, unlike messages with severity level PMDS_INFO,. The message content MAY NOT change between packets sent on the network.

Clients MUST NOT take the IP address of the sending host into account when detecting duplicate messages. When multiple servers are employed, overlap between networks may occur and the same PMDP message may be seen through different channels. This is also true if the client is multi-homed and different servers forward the same PMDP message on different networks.



 TOC 

3.4.  Message Content Ordering

Content ordering is required for isolating related message boundaries.

  1. If multiple independent events or messages are combined in one physical PMDP message, then the PMDT_TIMESTAMP MUST be used as a delimiter. The PMDT_TIMESTAMP MUST be the first content to declare the beginning of a context. It is RECOMMENDED that each PMDP message at least has one PMDT_TIMESTAMP content.
  2. Each event SHOULD contain one (1) PMDT_CATEGORY and one (1) PMDT_SUBCATEGORY message. If either or both are ommited, an implicit value of zero (0) MUST be assumed. Any ordering of PMDT_CATEGORY and PMDT_SUBCATEGORY should be accepted within the same event.
  3. A signed PMDP message MUST include the PMDT_SIGNATURE content as the last content in the PMDP message. The PMDT_SIGNATURE MUST be preceded by a PMDT_FINGERPRINT content to identify the signator's certificate.
  4. PMDT_ENCRYPTED MUST be preceded by a PMDT_KEY content and MUST be followed by a PMDT_FINGERPRINT content to identify the key and decryption certificate. Messages containing PMDT_ENCRYPTED content MAY be signed with the same certificate as the one used for encryption. In that case, only one PMDT_FINGERPRINT is required, but it MUST be followed by the PMDT_SIGNATURE content as stated above. If the encryption certificate differs from the signing certificate, then the signator's certificate is determined by the PMDT_FINGERPRINT preceding the PMDT_SIGNATURE content.
  5. Specific combination of PMDT_CATEGORY and PMDT_SUBCATEGORY MAY have specific requirements in which other content must be present. The actual grammar and semantics of the category/subcategory interpretation is published in the PingMyDroid™ content registry.


 TOC 

4.  Addressing and Service Discovery

PMDP services default to multicast address 239.255.0.1 for IPv4, ff14::1 for IPv6 and UDP port 48657 (0xbe11). The multicast address ought be part of the local administrative scope ([RFC2365] (Meyer, D., “Administratively Scoped IP Multicast,” July 1998.), [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.) and [RFC5771] (Cotton, M., Vegoda, L., and D. Meyer, “IANA Guidelines for IPv4 Multicast Address Assignments,” March 2010.)). Deployment of one or more other multicast address(es) or port(s) may be facilitated by publishing one or more SRV RRs [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) in the local DNS database.

Administrators MAY opt to include SRV RRs in the in-addr.arpa./ip6.arpa. trees to fasclitate network prefix divisions.

Local networks bound to the domain suffixes "wifi.example.com." and "service.example.com." using distinct IPv4/IPv6 transport addresses and ports:

$ORIGIN wifi.example.com.
_pmdp._udp  SRV  0 0 48657 pmdpmcaddr2.example.com.

$ORIGIN service.example.com.
_pmdp._udp  SRV  0 0 12345 pmdpmcaddr1.example.com.
_pmdp._udp  SRV  0 0 48657 pmdpmcaddr3.example.com.

pmdpmcaddr1 A    239.255.0.1
pmdpmcaddr1 AAAA ff14::1
pmdpmcaddr2 A    239.192.0.42
pmdpmcaddr2 AAAA ff15::69:42
pmdpmcaddr3 A    239.255.123.45

Clients located in the domain "service.example.com." will be directed to listen on different addresses than those located in the "wifi.example.com." domain.

Clients SHOULD query DNS for any SRV RRs and SHOULD join all multicast groups as indicated by the SRV RRs.

The SRV RR's priority and weight fields are not used for server selection. The SRV RRs are used for locating all available multicast address with corresponding ports for the local domain. Both priority and weight fields SHOULD be set to 0 (zero).

Adding SRV RRs to the DNS tree does not hide services in any particular useful way. It is trivial for a client to traverse an entire DNS tree for resources. The SRV RRs are only useful for automatic client configuration once they enter a network scope.



 TOC 

5.  DNS as Trust Anchor

When the client receives an unsigned message, no sender authentication is possible. It is up to the client and user to accept or reject these messages. However, if the message includes a PMDT_SIGNATURE, then the client SHOULD verify the signature. The message MUST include a PMDT_FINGERPRINT if it also contains a PMDT_SIGNATURE. Trusting the certificate source is still up to the client, but employing DNS ensures a reasonable secure network-wide trust anchor.

If messages are signed by the server, then the server MUST have at least one associated CERT Resource Record [RFC4398] (Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” March 2006.) located at the service locator DNS tree of the client's domain name. The CERT RR refers to a X.509 public certificate, which is to be used to verify the message's signature. Multiple certificates may be present for each server.

Also, the same CERT RR MUST be entered at the in-addr.arpa. or ip6.arpa. tree at the server's address. Clients MAY retrieve all certificates beforehand on a new network if the user wants to receive PMDP messages from the current network.

Clients MAY use both or either service-locator or in-addr.arpa./ip6.arpa. trees to retrieve the certificate(s) and are encouraged to cross-check the CERT RRs from both trees. Clients MUST NOT trust servers that are not located in the same broadcast domain, solely based on the in-addr.arpa./ip6.arpa. tree's CERT RR. Servers outside the broadcast domain MUST be identifyable from certificates in the service-locator tree and SHOULD have matching certificate in the in-addr.arpa./ip6.arpa. trees.

Additionally, the DNS entry for the pmdp service SHOULD include a TXT RR in the form of a TXT based key/value (Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery,” February 2013.) [RFC6763] record with the key set at "pmdpurl" and the value indicating a web site where the sender details its being.

An example DNS tree for two servers located at 10.254.0.2, fd36:5ec5:52bc:7461::3 and 10.254.1.99, using both IPv4 and IPv6 and indirect certificate storage. The client is located at a network with domain name wifi.example.com:

$ORIGIN 254.10.in-addr.arpa.
2.0        PTR  server1.pmdp.example.com.
2.0        CERT IPKIX 0 0 <base64(url of cert_1.crt)>
99.1       PTR  server2.pmdp.example.com.
99.1       CERT IPKIX 0 0 <base64(url of cert_2.crt)>
99.1       CERT PKIX  0 5 <base64(cert_3.der)>

$ORIGIN 0.0.0.0.0.0.97.116.188.82.197.94.54.253.ip6.arpa.
3.0        PTR  server1.pmdp.example.com.
3.0        CERT IPKIX 0 0 <base64(url of cert_1.crt)>

$ORIGIN wifi.example.com.
_pmdp._udp CERT IPKIX 0 0 <base64(url of cert_1.crt)>
_pmdp._udp CERT IPKIX 0 0 <base64(url of cert_2.crt)>
_pmdp._udp CERT PKIX  0 5 <base64(cert_3.der)>
_pmdp._udp TXT  "\x09txtvers=2\x20pmdpurl=http://pmdp.example.com/"

$ORIGIN pmdp.example.com.
@          CNAME  server1.pmdp.example.com.
server1    A      10.254.0.2
server1    AAAA   fd36:5ec5:52bc:7461::3
server2    A      10.254.99.1

The CERT RR may be of type IPKIX or PKIX. The PKIX RR returns the entire certificate in one DNS request. However, not all resolver implementations can handle large DNS packet loads and may choke on large certificates. See RFC 4034 appendix A.1 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) [RFC4034] for the algorithm field. IPv6 servers have their address in the ip6.arpa. tree, otherwise there is no difference between IPv4 and IPv6 servers.

All acceptable server certificates are returned for the client's domain name. The client is responsible for determining which certificate matches the PMDT_FINGERPRINT. If no match is found, then the message may be corrupt, sent from a rogue server or a misconfiguration at the server or DNS. Either way, the message should be dropped if the signature cannot be verified.

The following procedure at the client is recommended:

  1. Determine the domain name of the local network. The domain name may already be supplied from a DHCP server, in which case it MAY be used. Otherwise, the client performs a PTR RR lookup of its own IP address and extracts the domain name from the returned name.
  2. Perform a CERT RR lookup at the _pmdp._udp service tree level for the domain and retrieve all certificates. The fingerprint is calculated for each certificate and matched against the message's PMDT_FINGERPRINT. If a match is found, the client may proceed to verifying the signature.
  3. Perform a CERT RR lookup at the in-addr.arpa. or ip6.arpa. tree for the sending server's address and retrieve all certificates. The fingerprint is calculated for each certificate and matched against the message's PMDT_FINGERPRINT. If a match is found, the client may proceed to verifying the signature.
  4. If still no matching certificate is found, drop the message.

The client is RECOMMENDED to cache retrieved certificates. It is also RECOMMENDED that client-cached certificates be tagged with the domain name of the local network including the SSID if the certificates were retrieved over a wireless network, effectively pinning the certificates to the local network. Pinning certificates makes it easier to detect unwanted or inadvertent changes to the network setup and limit impact of possible rogue pmdp servers on the network. In any case, the user SHOULD be informed of newly retrieved certificates and allowed to accept or reject them.

Comparing a certificate's Common Name (CN) with the local domain name, as is common with SSL/TLS hostname verification, may not always prove successfull because PMDP messages may span across network segments with different domainname suffixes and should therefore not solely be used to reject a certificate. However, well controlled environments should add all alternative names to the certificate to span the intended range of domains.



 TOC 

6.  Security Considerations

It is inherently unsafe to accept any information without source verification. This may not be a great problem on local and tightly controlled networks, such as at home, but the possibility for abuse is present. All messages should, whenever possible, at least be signed, so that the client has the oppertunity to reduce the risk.

A rogue DHCP server on the client's network may invalidate the trust of the DNS because the rogue server may redirect the client to compromised servers and sites. However, it should be noted that the PMD protocol would probably be the least of concerns in such compromized network. For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) should be used where the authenticity of information is important.

Refer to section 7 of [RFC4398] (Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” March 2006.) for a discussion about the security of CERT RR in DNS zones.



 TOC 

7.  IANA Considerations

TBD: request port assignment 48657 for service pmdp

TBD: request well-known multicast address/group ID (?)



 TOC 

8.  Trademark Notice

The trademark PingMyDroid™ may be used in the form "PingMyDroid™ Compatible" or "PingMyDroid™ Compliant" by anyone who distributes software implementing the PMD protocol if the implementation is fully compliant with the PMD protocol as described in this memo.



 TOC 

9. References

[RFC0768] Postel, J., “User Datagram Protocol,” STD 6, RFC 768, August 1980 (TXT).
[RFC0791] Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT).
[RFC1112] Deering, S., “Host extensions for IP multicasting,” STD 5, RFC 1112, August 1989 (TXT).
[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery,” RFC 1191, November 1990 (TXT).
[RFC1630] Berners-Lee, T., “Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web,” RFC 1630, June 1994 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2365] Meyer, D., “Administratively Scoped IP Multicast,” BCP 23, RFC 2365, July 1998 (TXT, XML).
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, February 2000 (TXT).
[RFC3447] Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” RFC 3447, February 2003 (TXT).
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT).
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT).
[RFC4122] Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” RFC 4122, July 2005 (TXT, HTML, XML).
[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, February 2006 (TXT).
[RFC4398] Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” RFC 4398, March 2006 (TXT).
[RFC5424] Gerhards, R., “The Syslog Protocol,” RFC 5424, March 2009 (TXT).
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, “IANA Guidelines for IPv4 Multicast Address Assignments,” BCP 51, RFC 5771, March 2010 (TXT).
[RFC6763] Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery,” RFC 6763, February 2013 (TXT).


 TOC 

Author's Address

  Bertho Stultiens (editor)
  Vagrearg
Email:  pmdp@vagrearg.org