Internet Draft S. Hanna draft-hanna-marp-00.txt Sun Microsystems, Inc. SML Document #98-0046 30 January 1998 Expires: 30 July 1998 Multicast Address Request Protocol (MARP) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Multicast Address Request Protocol (MARP) serves as a front end to the Multicast Address Allocation Architecture. Any host that wishes to allocate a multicast address may contact a Multicast Address Allocation Server and use MARP to request an address allocation for a specific interval, scope, etc. Later, the host may request an extension of the address allocation or deallocate the address if it is no longer needed. 1 Introduction Dynamically allocating multicast addresses on a global scale while providing high reliability, low probability of clashes, good utilization, and aggregation to reduce routing overhead is a complicated matter. The Multicast Address Allocation Architecture [1] describes a multicast address allocation system that meets these requirements. The Multicast Address Request Protocol (MARP) serves as a front end to this multicast address allocation system. Any host that wishes to allocate a multicast address may contact a Multicast Address Allocation Server and use MARP to request an address allocation for a Hanna [Page 1] Internet Draft draft-hanna-marp-00.txt January 1998 specific lifetime, scope, etc. Later, the host may request an extension of the address lifetime or deallocate the address if it is no longer needed. MARP plays the same role as MDHCP [2], but has certain advantages as described in section 5. Basically, it is simpler and more efficient because it doesn't have to maintain compatibility with DHCP. This document is an initial proposal intended to stimulate debate. There are still open issues, which are discussed in section 8. 1.1 Terminology MARP is used by an IP host that wants to allocate an IP multicast address from a pool of dynamically allocated addresses (or request other multicast address allocation services). The host requesting address allocation services is known as the "MARP client" or simply "client" and the host supplying these services is known as the "MARP server" or simply "server." 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. 2 Protocol Overview All MARP packets are unicast UDP datagrams. There are three types of MARP packets: requests, responses, and ACKs. When a MARP client wishes to make a request, it sends a request packet to a MARP server. In the simplest and most common case, the server responds with a response packet and the client completes the exchange by sending an ACK packet. Thus, a typical MARP exchange consists of three packets: a request, a response, and an ACK. If packets are lost or a request takes a long time to process, more packets may be required. Requests and ACKs are sent to a reserved port on the server. For now, port number 7342 should be used. If this document reaches RFC status, a port number will be assigned by the IANA. Responses are sent to the port and IP address from which the corresponding request was received. All MARP packets have a common format, described in section 3. The packet type field is a single octet that marks the type of the packet. While there are many possible values for this field (256, to be exact), they are divided into ranges that allow any MARP client or server to identify the packet and determine its appropriate behavior. The ranges of packet types are: Request, Response - Permanent Error, Hanna [Page 2] Internet Draft draft-hanna-marp-00.txt January 1998 Response - Transient Error, Response - Success, Response - Progress Report, ACK, and Reserved. The next few sections describe these types and the appropriate behavior of a MARP client or server receiving a packet with this type. For more information about specific types, see section 4. 2.1 Requests A request packet is sent by the client when it wants to initiate a request. If no response is received for 10 seconds, the request packet MAY be retransmitted. See section 2.5 for more details on retransmitting requests. Each request includes a sequence number assigned by the client, which is included in each response or ACK that corresponds to that request so that they may be matched with the request. The client MUST NOT reuse a sequence number for at least 2 hours, as described in more detail in section 3.5. If a MARP server receives a request whose type it does not recognize or cannot process and does not expect to ever do so, it MUST send back a Cannot Process response (type 81, a Permanent Error). Servers MUST support at least the Allocate Multicast Address request. If a MARP client receives a request, it MUST ignore it. 2.2 Responses A response packet is sent by a server to a client that has sent a request. There are four kinds of responses: Response - Permanent Error, Response - Transient Error, Response - Success, and Response - Progress Report. The first three are called terminal responses. There are generic and specific versions of each of these kinds. The specific versions convey extra information (such as the reason for an error or a multicast address for an Address Allocated response). 2.2.1 Sending Responses There are three reasons to send a response packet: when a request is completed (successfully or unsuccessfully), when a request is still ongoing and more than 3 seconds has passed since the request was received or the last response was sent (whichever is later), and when a retransmitted request is received. In the first case, a terminal response is sent. In the second case, a progress report is sent. In the third case, the last response sent (which may be terminal or not) is retransmitted. Hanna [Page 3] Internet Draft draft-hanna-marp-00.txt January 1998 To reiterate, after a request is completed, a MARP server MUST send a terminal response to the client. After this, no more responses are sent for this request (unless a retransmitted request is received). If a request takes longer than 3 seconds to complete, the server MUST send a Progress Report Response. This informs the client that the request is still being processed. The Progress Report includes an estimate of when the request will complete. If the request takes longer than this estimate, the server MUST send another Progress Report and continue this process until the request has completed, at which time it MUST send a terminal response. 2.2.2 Handling Responses If a MARP client receives a Permanent Error Response, it should conclude that its request cannot be completed and this is a permanent condition. The client MAY send the request to another MARP server. It SHOULD NOT send the same request to the same server again to see if the condition clears up. If a MARP client receives a Transient Error Response, it should conclude that its request cannot be completed, but this may be a transient condition. The client MAY send the request to another MARP server or it MAY send the same request to the same server again to see if the condition clears up. If it sends the same request to the same server, it SHOULD use an exponential backoff timer to avoid swamping the server with the same request. If a MARP client receives a Success Response, it should conclude that its request was completed successfully. Certain request types should result in only certain response types, which may include valuable data. If such a request type was used and the response type is a Success Response, but not one of those expected, the client SHOULD behave as if a Permanent Error Response had been received. If a MARP client receives a Progress Report, it MUST reset its request retransmission timer to 10 seconds after the estimated completion time included in the Progress Report. If a MARP client receives a response whose specific type it does not recognize, it MUST treat it as the generic version of its type (e.g. an unrecognized type in the Response - Permanent Error range must be treated as a Generic Permanent Error packet). MARP clients MAY only recognize the generic responses. If a MARP server receives a response, it MUST ignore it. 2.3 ACKs Hanna [Page 4] Internet Draft draft-hanna-marp-00.txt January 1998 A client MUST send an ACK packet when it receives a terminal response packet. This informs the server that the client has received a terminal response packet and the server MAY discard any state corresponding to this request (such as entries in its request cache). If a MARP server receives an ACK whose request sequence number it does not recognize, it MUST ignore it. If a MARP client receives an ACK, it MUST ignore it. 2.4 Reserved or Invalid Packets If a MARP client or server receives a packet with a type in the Reserved range or a packet that is otherwise invalid (too short, for instance), it MUST ignore it. 2.5 Retransmitting Requests To handle lost packets, the client SHOULD retransmit its request if no response is heard for an interval of 10 seconds (or 10 seconds after the estimated completion time included in a Progress Report). If no response is heard to a request retransmission, the client MAY retransmit its request up to 9 more times at 10 second intervals. At any point during this process, the client MAY (and after the tenth retransmission MUST) decide that the exchange has failed and send the request to another server or abort the request. The server MUST maintain a request cache (or equivalent) so that it can recognize retransmitted requests and resend the most recent response. Items in this cache MUST be retained for at least 120 seconds and no more than 2 hours after the terminal response is sent (unless an ACK for an item is received, in which case the item MAY be removed at that time). A retransmitted request packet MUST be exactly the same as the original. The server MUST check the source IP address, port, and sequence number when recognizing retransmitted requests. When a signature is present, this MUST also be checked. 2.6 Finding a MARP Server Before it can send MARP requests, a MARP client must find a MARP server. There are several ways that this can be done. 1) The DNS host name or IP address of the MARP server MAY be statically configured or entered as a command line argument or via some other means. 2) A DHCP server or some other dynamic configuration mechanism MAY be Hanna [Page 5] Internet Draft draft-hanna-marp-00.txt January 1998 employed to find the IP address or DNS host name of the MARP server. 3) The MARP client MAY monitor Address Allocation Protocol (AAP) [3] messages on the multicast address used by AAP servers within the scope zone from which an address is to be allocated and choose one of the servers that are sending ADDRESS-IN-USE messages. The third technique is preferred. If this method is used, the MARP client SHOULD choose randomly among the AAP servers heard from. This helps to avoid overloading the AAP servers. 2.7 Discovering Scopes The set of scope zones in use may be statically configured or discovered by monitoring MZAP [4] transmissions. Dynamic discovery is more robust, but takes time. A scope discovery message could be added to MARP, but it is important to be sure the MARP server has the same set of scopes as the MARP client and this is difficult to do without knowing what the scope zones are (circular problem) or statically configuring the MARP server address in the client (painful). 2.8 MARP Times MARP packets contain a number of places where absolute times must be represented. These time values are represented as unsigned 32-bit integers in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This is the same time value that is used in the Address Allocation Protocol [3]. Two special time values are defined. A time value of 0 (also known as TIME_ASAP) means as early as possible. A time value of 2^32 - 1 (all ones, also known as TIME_ALAP) means as late as possible. These values are only allowed where explicitly stated. If the clocks on the MARP client and MARP server are set differently, problems can occur (like clients using addresses at the wrong time). To prevent substantial clock skew, the MARP client includes its idea of the current time in each Allocate Multicast Address request. If this differs from the server's current time when the request is received by more than 90 minutes, the server sends back a Clock Skew Permanent Error. To avoid problems caused by clock skew of less than 90 minutes (and network delays), the MARP client SHOULD allocate addresses for at least 2 hours earlier and 2 hours later than will be needed and let the address sit idle for these hours. This will take care of two Hanna [Page 6] Internet Draft draft-hanna-marp-00.txt January 1998 clients that have almost 90 minutes of clock skew from the server in opposite directions and one hour of network delays, multicast routing latency, etc. 3 Generic Packet Format All MARP packets are unicast UDP datagrams. Requests and ACKs are sent to a reserved port on the server. Responses are sent to the port and IP address from which the corresponding request was received. All MARP packets share a common format, shown in Figure 1 (omitting UDP headers). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Version| Flags | +-+-+-+-+-+-+-+-+ |Sec. Hdr. (opt)| +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ | Request | | Sequence Num. | +-+-+-+-+-+-+-+-+ | Data Length | | (N) | +-+-+-+-+-+-+-+-+ | | + Data + ... + (N bytes) + | | +-+-+-+-+-+-+-+-+ Figure 1 3.1 Version (4 bits) The Version field is always 0 for this version of MARP. If another value is seen, the packet MUST be ignored. MARP should be extensible enough so that the version need never be changed. New request and response types may be added easily and handled properly by older clients and servers that don't recognize them. 3.2 Flags (4 bits) The most significant bit of the Flags field (marked 4 above) is the Security bit (described in section 3.3, Security Header). The three Hanna [Page 7] Internet Draft draft-hanna-marp-00.txt January 1998 least significant bits MUST be sent as zero (0) and ignored on reception. This allows for future extensions of the protocol in a backward compatible fashion. 3.3 Security Header (variable length) If the Security bit in the Flags field is set to 1, a Security Header appears after the Flags field. The format of the Security Header is shown in Figure 2. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Sig. Type | +-+-+-+-+-+-+-+-+ | Sig. Length | | (SL) | +-+-+-+-+-+-+-+-+ | | + Sig. Data + ... + (SL bytes) + | | +-+-+-+-+-+-+-+-+ | Encr. Type | +-+-+-+-+-+-+-+-+ | Encr. Length | | (EL) | +-+-+-+-+-+-+-+-+ | | + Encr. Data + ... + (EL bytes) + | | +-+-+-+-+-+-+-+-+ Figure 2 3.3.1 Signature If the Signature Type field is zero, no digital signature is included in this packet. The Signature Length field must be zero and the Signature Data field must be omitted. Otherwise, the Signature Type field identifies the type of digital signature used. The Signature Data field includes the digital signature of all bytes in the packet after the Signature Data field. The Signature Length field includes the number of bytes of data in the Signature Data field. Hanna [Page 8] Internet Draft draft-hanna-marp-00.txt January 1998 If a MARP server receives a packet whose Signature Type field it does not support, it MUST send back a Signature Type Not Supported Permanent Error packet. If it supports the Signature Type but cannot verify the signature, it SHOULD send back a Signature Not Verified Permanent Error packet. However, if the packet also uses encryption and cannot be decrypted, the decryption errors described in section 3.3.2 MUST be sent instead. If a MARP server receives a request whose Signature Type field it supports, it SHOULD use the same Signature Type in its response since the MARP client clearly supports this Signature Type. If a MARP client receives a packet whose signature it cannot verify, it SHOULD ignore it. MARP servers and clients MAY be configured to support any set of signature types, based on administrative decisions. 3.3.1.1 DSA Signature A packet whose Signature Type is 1 is signed with DSA (Digital Signature Standard). The Signature Data field contains the name associated with the private key used to sign the data and the signature itself. No certificates are included with this type of signature. The recipient is expected to have access to a public key infrastructure or other mechanism for finding and verifying the public key associated with a name. 3.3.2 Encryption If the Encryption Type field is zero, encryption is not used on this packet. The Encryption Length field must be zero and the Encryption Data field must be omitted. Otherwise, the Encryption Type field identifies the type of encryption used. The Encryption Data field includes data which is specific to the encryption method used. The Encryption Length field includes the number of bytes of data in the Encryption Data field. All bytes in the packet after the Encryption Data field are ciphertext (including the Type and Request Sequence Number). If a MARP server receives a packet whose Encryption Type field it does not support, it MUST send back a Encryption Type Not Supported Permanent Error packet. Since it cannot decrypt the packet, it cannot read its Type or Request Sequence Number fields. It MUST use sequence number 0 in its response and MUST NOT cache this response. If a MARP server receives a packet whose Encryption Type field it Hanna [Page 9] Internet Draft draft-hanna-marp-00.txt January 1998 supports but which it cannot decrypt, it MUST send back a Decryption Failed Permanent Error packet. Since it cannot decrypt the packet, it cannot read its type or request sequence number. It MUST use sequence number 0 in its response and MUST NOT cache this response. If a MARP server receives a request whose Encryption Type field it supports, it SHOULD use the same Encryption Type in its response since the MARP client clearly supports this Encryption Type. If a MARP client receives a packet whose Encryption Type field it does not support or which it cannot decrypt, it MUST ignore the packet. MARP servers and clients MAY be configured to support any set of encryption types, based on administrative decisions. 3.3.2.1 Triple DES Encryption A packet whose Encryption Type is 1 is encrypted with Triple DES (DES- EDE as per spec - 168 bit key derived from 192) using a key that is randomly selected by the MARP client on a per-request basis (called the request key). For requests, the request key is encrypted with the public key of the MARP server and included in the Encryption Data field. For responses and ACKs, the same key is used, but it is not transmitted in the response or ACK packet. Cipher Block Chaining (CBC) is used with a 64 bit (8 byte) initialization vector (IV) chosen randomly by the client and included in the Encryption Data field. The same IV is used in a response or ACK, but not transmitted in the response or ACK packet. Because DES-3EDE-CBC requires the length of the plaintext to be a multiple of 64 bits (8 bytes), padding is added to the plaintext as necessary until it reaches such a length. The number of pad bytes added is included in the Encryption Data field so that they may be stripped off after decryption. The pad bytes have values 1, 2, 3, and so forth (up to a maximum of 7) until the plaintext reaches a multiple of 8 bytes. In a request packet, the Encryption Data field contains the request key (encrypted with the public key of the server) followed by the name that is associated with the server's public key (preceded by a length byte), the IV, and a single byte with the number of pad bytes. In a response or ACK packet, the Encryption Data field contains the number of pad bytes and the Encryption Length field is 1. 3.4 Type (1 byte) The Type field indicates what type of MARP packet this is. There are Hanna [Page 10] Internet Draft draft-hanna-marp-00.txt January 1998 several ranges of type values so that more types may be defined in the future and older implementations will be able to respond in a well- defined manner. These ranges are listed in Figure 3 and described in more detail in sections 2 and 4. Type Range Meaning ---------- ------- 00 - 3f Request 40 - 7f Response - Success 80 - 9f Response - Permanent Error a0 - bf Response - Transient Error c0 - df Response - Progress Report e0 ACK e1 - ff Reserved Figure 3 3.5 Request Sequence Number (2 bytes) The request sequence number is a 2 octet number chosen by the MARP client and sent in the initial request packet. The same sequence number is included in each response, ACK, or retransmitted request that corresponds to the initial request. The sequence number 0 MUST NOT be sent in a request, since the MARP server uses this value for responding to encrypted packets that it could not decrypt and whose sequence number it therefore could not read. It is undesirable to have the same sequence number used for two different requests from the same source IP address and port within a few hours, as packets from the old request may be hanging around the network or (within a few minutes) the server's request cache. Therefore, a MARP client MUST NOT reuse a request sequence number with the same source IP address and port within 2 hours of the initial request. Also, a MARP client SHOULD choose its request sequence numbers in such a way that it is unlikely that another MARP client with the same source IP address and port used the same sequence number within the past 2 hours. One simple way to do this is to choose the initial sequence number randomly, then increment it for subsequent requests from the same client. As long as the client is not sending more than 32,768 requests per hour there will be no problem. 3.6 Data Length and Data Hanna [Page 11] Internet Draft draft-hanna-marp-00.txt January 1998 The Data Length field is an unsigned two octet number in network byte order that specifies how many bytes of data are included in the packet. This field is followed by the specified number of bytes of data. The meaning of the data depends on the packet type. 4 Specific Packet Types This section describes the meaning of specific values of the Type field in a MARP packet. 4.1 Requests 4.1.1 Allocate Multicast Address (type 00) The Allocate Multicast Address request asks the MARP server to allocate a multicast address. If the request succeeds, a Multicast Address Allocation Success response MUST be returned. If the request fails because no addresses are available that would satisfy the request, the No Addresses Available Transient Error response SHOULD be returned. The Data Length varies depending on the address type. The format of the data is shown in Figure 4. If an Allocate Multicast Address request is signed, the MARP server SHOULD remember the identity that signed it so that it may use this information to control who may deallocate the address or change its interval. To avoid malicious users allocating all the addresses on a MARP server, several techniques may be employed. The MARP server MAY limit the number of addresses that may be allocated in an hour. It MAY limit address allocation based on identity (as verified by signature). Both of these are good techniques. If a MARP server limits address allocation based on identity, it SHOULD cache requests for at least two hours to avoid replay attacks (replaying an authorized allocation request to use up someone's allocation). Hanna [Page 12] Internet Draft draft-hanna-marp-00.txt January 1998 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Address Type | +-+-+-+-+-+-+-+-+ | Address Count | +-+-+-+-+-+-+-+-+ | | + Scope + ... + (size varies + |with addr type)| +-+-+-+-+-+-+-+-+ | Current | | Time | | | | | +-+-+-+-+-+-+-+-+ | Requested | | Address | | Start | | Time | +-+-+-+-+-+-+-+-+ | Requested | | Address | | End | | Time | +-+-+-+-+-+-+-+-+ | Required | | Address | | Start | | Time | +-+-+-+-+-+-+-+-+ | Required | | Address | | End | | Time | +-+-+-+-+-+-+-+-+ Figure 4 4.1.1.1 Address Type (1 byte) The Address Type field indicates the type of addresses being requested. It is 0 for IPv4 multicast addresses and 1 for IPv6 multicast addresses. All other values are reserved. Clients MUST not send them and servers MUST ignore requests that contain them. 4.1.1.2 Address Count (1 byte) Hanna [Page 13] Internet Draft draft-hanna-marp-00.txt January 1998 The Address Count field indicates the number of addresses being requested. It may have any value from 1 to 255. The value 0 is reserved. Clients MUST not send it and servers MUST ignore requests that contain it. 4.1.1.3 Scope (variable length) The Scope field is the first IP address in the scope zone from which the address must be allocated. The length of the Scope field is 4 if the Address Type field is 0 and 16 if the Address Type field is 1. If the Scope field is all 0s, global scope is implied. The MARP server and client must both be in the scope zone requested. This is guaranteed if the client uses AAP to find MARP servers. 4.1.1.4 Current Time (4 bytes) The Current Time is the client's idea of the current time when the request was first made. This value does not change when a request is retransmitted, so it may be a few minutes old when received by the server. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here. If a MARP server receives an Allocate Multicast Address request that includes a current time that differs from its own by more than 90 minutes, it MUST return a Clock Skew Permanent Error response. This avoids misunderstandings caused by substantial clock skew. If a MARP server caches requests for two hours, this will also prevent replay attacks. 4.1.1.5 Requested Address Start Time (4 bytes) The Requested Address Start Time is the time at which the client would like the allocation to start. This is a MARP time, as described in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. 4.1.1.6 Requested Address End Time (4 bytes) The Requested Address End Time is the time at which the client would like the allocation to end. This is a MARP time, as described in section 2.7. This value MUST be greater than the requested address start time. A time value of 2^32 - 1 (TIME_ALAP) is valid here, but 0 (TIME_ASAP) is not. 4.1.1.7 Required Address Start Time (4 bytes) The Required Address Start Time is the latest time that the client is Hanna [Page 14] Internet Draft draft-hanna-marp-00.txt January 1998 willing to accept as an address start time. If the server cannot supply an address whose start time is at least this early, it MUST send a failure response. This is a MARP time, as described in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. TIME_ASAP here means that only a time value of TIME_ASAP may be returned. 4.1.1.8 Required Address End Time (4 bytes) The Required Address End Time is the earliest time that the client is willing to accept as an address end time. If the server cannot supply an address whose end time is at least this late, it MUST send a failure response. This is a MARP time, as described in section 2.7. This value MUST be greater than the required address start time. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here. 4.1.2 Deallocate Multicast Address (type 01) The Deallocate Multicast Address request asks the MARP server to deallocate a multicast address. If the request succeeds, a Generic Success response MUST be returned. The Data Length varies depending on the address type. The format of the data is shown in Figure 5. It is strongly suggested that MARP servers require Deallocate Multicast Address requests to be signed and make sure that they are signed by an identity with permission to deallocate the address (such as the same identity that allocated the address). Otherwise, malicious users may change the interval of addresses allocated by others. Hanna [Page 15] Internet Draft draft-hanna-marp-00.txt January 1998 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Address Type | +-+-+-+-+-+-+-+-+ | Allocated | + Address + ... + (size varies + |with addr type)| +-+-+-+-+-+-+-+-+ | Address | | Start | | Time | | | +-+-+-+-+-+-+-+-+ | Address | | End | | Time | | | +-+-+-+-+-+-+-+-+ Figure 5 4.1.2.1 Address Type (1 byte) The Address Type field indicates the type of address being deallocated. It is 0 for IPv4 multicast addresses and 1 for IPv6 multicast addresses. All other values are reserved. Clients MUST not send them and servers MUST ignore requests that contain them. 4.1.2.2 Allocated Address (variable length) The Allocated Address field is the address being deallocated. The length of the Allocated Address field is 4 if the Address Type field is 0 and 16 if the Address Type field is 1. 4.1.2.2 Address Start Time (4 bytes) The Address Start Time is the address start time for this address. It MUST match the value included in the most recent Multicast Address Allocation Success Response or Change Address Interval Success Response sent by the server for this address. A MARP server MAY omit checking this value if it does not allocate a given address more than once for different intervals. The time value 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. 4.1.2.3 Address End Time (4 bytes) Hanna [Page 16] Internet Draft draft-hanna-marp-00.txt January 1998 The Address End Time is the address end time for this address. It MUST match the value included in the most recent Multicast Address Allocation Success Response or Change Address Interval Success Response sent by the server for this address. A MARP server MAY omit checking this value if it does not allocate a given address more than once for different intervals. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here. 4.1.3 Change Interval (type 02) The Change Interval request asks the MARP server to change the start and end time of a multicast address that has already been allocated with this MARP server. If the request succeeds, a Change Interval Success response MUST be returned. If the request fails, the address remains allocated with the old interval. It is strongly suggested that MARP servers require Change Interval requests to be signed and make sure that they are signed by an identity with permission to change the interval of the address (such as the same identity that allocated the address). Otherwise, malicious users may change the interval of addresses allocated by others. The Data Length varies depending on the address type. The format of the data is shown in Figure 6. Hanna [Page 17] Internet Draft draft-hanna-marp-00.txt January 1998 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Address Type | +-+-+-+-+-+-+-+-+ | Allocated | + Address + ... + (size varies + |with addr type)| +-+-+-+-+-+-+-+-+ | Address | | Start | | Time | | | +-+-+-+-+-+-+-+-+ | Address | | End | | Time | | | +-+-+-+-+-+-+-+-+ | Requested | | Address | | Start | | Time | +-+-+-+-+-+-+-+-+ | Requested | | Address | | End | | Time | +-+-+-+-+-+-+-+-+ | Required | | Address | | Start | | Time | +-+-+-+-+-+-+-+-+ | Required | | Address | | End | | Time | +-+-+-+-+-+-+-+-+ Figure 6 4.1.3.1 Address Type (1 byte) The Address Type field indicates the type of address whose interval is to be changed. It is 0 for IPv4 multicast addresses and 1 for IPv6 multicast addresses. All other values are reserved. Clients Hanna [Page 18] Internet Draft draft-hanna-marp-00.txt January 1998 MUST not send them and servers MUST ignore requests that contain them. 4.1.3.2 Allocated Address (variable length) The Allocated Address field is the address whose interval is to be changed. The length of the Allocated Address field is 4 if the Address Type field is 0 and 16 if the Address Type field is 1. 4.1.3.3 Address Start Time (4 bytes) The Address Start Time is the address start time for this address. It MUST match the value included in the most recent Multicast Address Allocation Success Response or Change Address Interval Success Response sent by the server for this address. A MARP server MAY omit checking this value if it does not allocate a given address more than once for different intervals. The time value 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. 4.1.3.4 Address End Time (4 bytes) The Address End Time is the address end time for this address. It MUST match the value included in the most recent Multicast Address Allocation Success Response or Change Address Interval Success Response sent by the server for this address. A MARP server MAY omit checking this value if it does not allocate a given address more than once for different intervals. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here. 4.1.3.5 Requested Address Start Time (4 bytes) The Requested Address Start Time is the time at which the client would like to start using the address. This is a MARP time, as described in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. 4.1.3.6 Requested Address End Time (4 bytes) The Requested Address End Time is the time at which the client would like to stop using the address. This is a MARP time, as described in section 2.7. This value MUST be greater than the requested address start time. A time value of 2^32 - 1 (TIME_ALAP) is valid here, but 0 (TIME_ASAP) is not. 4.1.3.7 Required Address Start Time (4 bytes) The Required Address Start Time is the latest time that the client is willing to accept as an address start time. If the server cannot Hanna [Page 19] Internet Draft draft-hanna-marp-00.txt January 1998 supply an address whose start time is at least this early, it MUST send a failure response. However, the address MUST remain allocated with the old interval. This is a MARP time, as described in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. TIME_ASAP here means that only a time value of TIME_ASAP may be returned. 4.1.3.8 Required Address End Time (4 bytes) The Required Address End Time is the earliest time that the client is willing to accept as an address end time. If the server cannot supply an address whose end time is at least this late, it MUST send a failure response. However, the address MUST remain allocated with the old interval. This is a MARP time, as described in section 2.7. This value MUST be greater than the required address start time. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here. 4.2 Responses This section describes the meaning of specific responses. For a description of how to handle responses in general, see section 2.2.2. 4.2.1 Generic Success (type 40) The Generic Success response indicates that a request completed successfully. No data is included. 4.2.2 Multicast Address Allocation Success (type 41) The Multicast Address Allocation Success response indicates that an Allocate Multicast Address request completed successfully. The data contains the addresses allocated and the interval during which they are allocated. The Data Length varies depending on the address type (given in the request). The format of the data is shown in Figure 7. The MARP server does not have to return the number of addresses requested. It MAY return any number of addresses from 1 to the number requested in a Multicast Address Allocation Success Response. However, it MUST NOT return more addresses than requested. The addresses returned do not have to be contiguous, although they may be. There is no way for a MARP client to request contiguous addresses or to request that a specific multicast address be allocated. MARP clients SHOULD NOT assume or attempt to achieve such conditions. Hanna [Page 20] Internet Draft draft-hanna-marp-00.txt January 1998 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Address | | Start | | Time | | | +-+-+-+-+-+-+-+-+ | Address | | End | | Time | | | +-+-+-+-+-+-+-+-+ | Address Count | +-+-+-+-+-+-+-+-+ | Allocated | + Addresses + ... + (size varies + |with addr type)| +-+-+-+-+-+-+-+-+ Figure 7 4.2.2.1 Address Start Time (4 bytes) The Address Start Time is the time at which the client MAY start using the allocated addresses. This is a MARP time, as described in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. TIME_ASAP means that the addresses may be used immediately. The MARP server SHOULD return TIME_ASAP instead of the current time, as this value removes any confusion caused by clock skew. 4.2.2.2 Address End Time (4 bytes) The Address End Time is the time at which the client MUST stop using the allocated addresses. This is a MARP time, as described in section 2.7. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here. 4.2.2.3 Address Count (1 byte) The Address Count is the number of addresses that the MARP server has allocated. 4.2.2.4 Allocated Addresses (variable length) The Allocated Addresses field contains the addresses that have been allocated. The length of each address is 4 if the address type Hanna [Page 21] Internet Draft draft-hanna-marp-00.txt January 1998 specified in the request is 0 (IPv4 addresses) and 16 if the address type is 1 (IPv6 addresses). 4.2.3 Change Interval Success (type 42) The Change Interval Success response indicates that a Change Interval request completed successfully. The data contains the new interval during which the address is allocated. The Data Length is always 8. The format of the data is shown in Figure 8. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Address | | Start | | Time | | | +-+-+-+-+-+-+-+-+ | Address | | End | | Time | | | +-+-+-+-+-+-+-+-+ Figure 8 4.2.3.1 Address Start Time (4 bytes) The Address Start Time is the time at which the client may start using the allocated address. This is a MARP time, as described in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 (TIME_ALAP) is not. TIME_ASAP means that the address may be used immediately. The MARP server SHOULD return TIME_ASAP instead of the current time, as this value removes any confusion caused by clock skew. 4.2.3.2 Address End Time (4 bytes) The Address End Time is the time at which the client may stop using the allocated address. This is a MARP time, as described in section 2.7. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here. 4.2.4 Generic Permanent Error (type 80) The Generic Permanent Error response indicates that a request cannot be completed and this is a permanent condition. No data is included. For a description of how to handle this response, see section 2.2.2. Hanna [Page 22] Internet Draft draft-hanna-marp-00.txt January 1998 4.2.5 Cannot Process Permanent Error (type 81) The Cannot Process Permanent Error response indicates that a request cannot be processed because it is unrecognized or unsupported and this is a permanent condition. No data is included. For a description of how to handle this response, see section 2.2.2. 4.2.6 Encryption Type Not Supported Permanent Error (type 82) The Encryption Type Not Supported Permanent Error response indicates that a packet cannot be processed because the MARP server does not support the value in the Encryption Type field. Since the MARP server cannot decrypt the packet, it cannot read its Type or Request Sequence Number fields. It MUST use sequence number 0 in its response and MUST NOT cache this response. The data contains a list of supported encryption types and as much of the original packet as will fit in a single UDP packet. The MARP client MAY decrypt this packet to recognize which request failed and try sending it again with a different encryption type. The format of the data is shown in Figure 9. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | E. Type Count | +-+-+-+-+-+-+-+-+ | Sptd. Enc. | + Types + ... + (ETC bytes) + | | +-+-+-+-+-+-+-+-+ | Pkt Data Len | | (PDL) | +-+-+-+-+-+-+-+-+ | Packet | + Data + ... + (PDL bytes) + | | +-+-+-+-+-+-+-+-+ Figure 9 4.2.6.1 Encryption Type Count (1 byte) The Encryption Type Count field is a one octet unsigned number Hanna [Page 23] Internet Draft draft-hanna-marp-00.txt January 1998 indicating how many supported encryption types are included in the Supported Encryption Types field. Since each entry in this list is 1 byte long, this value is also the length of that field in bytes. 4.2.6.2 Supported Encryption Types (variable length) The Supported Encryption Types field is a series of one octet numbers indicating which encryption types are supported by the MARP server. These numbers need not be sorted in any way, although they should not include duplicates. 4.2.6.3 Packet Data Length (2 bytes) The Packet Data Length field is a two octet unsigned number giving the length of the following Packet Data field in bytes. 4.2.6.4 Packet Data (variable length) The Packet Data field contains as much of the packet that could not be decrypted as will fit into the response. This data starts with the Version field, thus skipping the UDP header of the original packet. 4.2.7 Decryption Failed Permanent Error (type 83) The Decryption Failed Permanent Error response indicates that a packet cannot be processed because the MARP server supports the value in the Encryption Type field but was unable to decrypt the packet. Since the MARP server cannot decrypt the packet, it cannot read its Type or Request Sequence Number fields. It MUST use sequence number 0 in its response and MUST NOT cache this response. The data contains the complete contents of the original packet (although the end of the packet may need to be clipped in order to fit in a single UDP packet). The MARP client MAY verify that it sent this packet and decrypt it to recognize which request failed and what the problem was. 4.2.8 Signature Type Not Supported Permanent Error (type 84) The Signature Type Not Supported Permanent Error response indicates that a packet cannot be processed because the MARP server does not support the value in the Signature Type field. No data is included. For a description of how to handle this response, see section 2.2.2. The data contains a list of supported signature types. The format of the data is shown in Figure 10. Hanna [Page 24] Internet Draft draft-hanna-marp-00.txt January 1998 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | S. Type Count | +-+-+-+-+-+-+-+-+ | Sptd. Sig. | + Types + ... + (STC bytes) + | | +-+-+-+-+-+-+-+-+ Figure 10 4.2.8.1 Signature Type Count (1 byte) The Signature Type Count field is a one octet unsigned number indicating how many supported signature types are included in the Supported Signature Types field. Since each entry in this list is 1 byte long, this value is also the length of that field in bytes. 4.2.8.2 Supported Signature Types (variable length) The Supported Signature Types field is a series of one octet numbers indicating which signature types are supported by the MARP server. These numbers need not be sorted in any way, although they should not include duplicates. 4.2.9 Signature Not Verified Permanent Error (type 85) The Signature Not Verified Permanent Error response indicates that a packet cannot be processed because the MARP server supports the value in the Signature Type field, but could not verify the signature. No data is included. For a description of how to handle this response, see section 2.2.2. 4.2.10 Clock Skew Permanent Error (type 86) The Clock Skew Permanent Error response indicates that the current time supplied by the client differs from that maintained by the server by more than 90 minutes. The current time included in the packet and the server's idea of the current time are included in the data. It is suggested that the MARP client log an error noting these values along with the server identity or IP address. It is not suggested that the MARP client adjust its clock automatically, since the server clock may in fact be in error. In any case, the client SHOULD NOT send any more requests to this server until the clock skew problem is Hanna [Page 25] Internet Draft draft-hanna-marp-00.txt January 1998 addressed. The Data Length is always 8. The format of the data is shown in Figure 11. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Client | | Current | | Time | | | +-+-+-+-+-+-+-+-+ | Server | | Current | | Time | | | +-+-+-+-+-+-+-+-+ Figure 11 4.2.11 Generic Transient Error (type a0) The Generic Transient Error response indicates that a request cannot be completed, but this may be a transient condition. No data is included. For a description of how to handle this response, see section 2.2.2. 4.2.12 No Addresses Available Transient Error (type a1) The No Addresses Available Transient Error response indicates that no addresses were available that would satisfy a request. This response is sent if no addresses are available that satisfy an Allocate Multicast Address request, for instance. No data is included. For a description of how to handle this response, see section 2.2.2. 4.2.13 Generic Progress Report (type c0) The Generic Success response indicates that a request is still being processed. The data contains an estimated completion time. The Data Length is always 4. The format of the data is shown in Figure 12. Hanna [Page 26] Internet Draft draft-hanna-marp-00.txt January 1998 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Estimated | | Completion | | Time | | | +-+-+-+-+-+-+-+-+ Figure 12 4.2.13.1 Estimated Completion Time (4 bytes) The Estimated Completion Time is an estimate of when the request will be completed. It is an unsigned 32-bit number of seconds from the time the progress report is sent. It is NOT a MARP time. See section 2 for descriptions of how this time is used by the client. 5 Comparison with MDHCP Because MDHCP is based on DHCP, it includes several features that were required for DHCP's problem set but are not required for multicast address allocation. For instance, compatibility with BOOTP forwarders. MDHCP requires the presence of a DHCP server to get the MDHCP server multicast address and multicast scope list (or static configuration). MARP uses AAP to find servers, therefore avoiding lots of extra complexity. A different version of MDHCP will be required to support IPv6. MARP supports both IPv4 and IPv6. MDHCP uses the same port number as DHCP on the server, so it will not be possible to colocate an MDHCP and DHCP server unless they are the same process. MARP does not have this problem. Security is crucial for multicast address allocation, but MDHCP does not include support for security. It refers to ongoing DHCP security work, but this is not complete. MARP includes security support. MDHCP uses a single multicast address for all MDHCP servers. This may cause problems when there are different multicast scopes. MDHCP requires two multicast packets and two unicast packets for a protocol exchange. MARP requires only three unicast packets. MDHCP does not include support for a requested interval, just a required one. Hanna [Page 27] Internet Draft draft-hanna-marp-00.txt January 1998 MDHCP may be able to leverage some code from DHCP servers. 6 Security Considerations Authenticating the MARP client allows for per-user limits on address allocation and charging for addresses (if desired), and prevents deallocating someone else's address. Authenticating the MARP server prevents creating a fake MARP server that gives out invalid addresses. Caching requests for 2 hours and rejecting requests with a current time that differs from the servers by more than 90 minutes prevents replay attacks (assuming authentication is required). Encryption is somewhat useful, but probably not essential. Knowing who is requesting multicast address allocation services and what the response is might make it easier for attackers to jam multicast sessions. Or simply learning who's doing what might be interesting. IPsec or TLS could be used for this application, but IPsec currently does not support different security associations for different processes on a single machine and TLS would require lots more overhead per request. 7 References [1] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast Address Allocation Architecture", draft-handley-malloc-arch-00.txt, Internet Draft, December 1997. [2] Patel, B. and M. Shah, "Multicast address allocation extensions to the Dynamic Host Configuration Protocol", draft-ietf-dhc-mdhcp-03.txt, Internet Draft, November 1997. [3] Handley, M., "Multicast Address Allocation Protocol", draft-handley-aap-00.txt, Internet Draft, December 1997. [4] Handley, M., "Multicast Scope Zone Announcement Protocol", draft-ietf-mboned-mzap-00.txt, December 1997. 8 Open Issues * We need a reserved port number for the MARP server. * Do we need to support future allocation (where the server returns a token instead of an address)? We could use a new address type for this. Hanna [Page 28] Internet Draft draft-hanna-marp-00.txt January 1998 * We should change AAP so that AAP servers that are willing to act as a MARP server send some sort of periodic message when they don't have any addresses in use. This is excess multicast traffic, but it's no worse than AAP in its stable state. 9 Author's Address Steve Hanna Sun Microsystems, Inc. 2 Elizabeth Drive M/S CHL03-205 Chelmsford, MA 01824 Tel: +1.978.442.0166 Fax: +1.978.250.5067 Email: steve.hanna@sun.com Hanna [Page 29]