--- 1/draft-ietf-mboned-ssmping-05.txt 2008-11-03 18:12:09.000000000 +0100 +++ 2/draft-ietf-mboned-ssmping-06.txt 2008-11-03 18:12:09.000000000 +0100 @@ -1,18 +1,18 @@ Network Working Group S. Venaas Internet-Draft UNINETT -Intended status: Informational September 18, 2008 -Expires: March 22, 2009 +Intended status: Standards Track November 3, 2008 +Expires: May 7, 2009 Multicast Ping Protocol - draft-ietf-mboned-ssmping-05 + draft-ietf-mboned-ssmping-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,21 +23,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 22, 2009. + This Internet-Draft will expire on May 7, 2009. Abstract The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast related information like multicast tree setup time etc. This protocol is based on an implementation of tools called ssmping and asmping. @@ -49,47 +49,47 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Message types and options . . . . . . . . . . . . . . . . . . 11 - 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 13 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Intellectual Property and Copyright Statements . . . . . . . . . . 18 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . . . . 20 1. Introduction The Multicast Ping Protocol specified in this document allows for checking multicast connectivity. In addition to checking reception of multicast (SSM or ASM), the protocol can provide related information like multicast tree setup time, the number of hops the packets have traveled, as well as packet delay and loss. This functionality resembles, in part, the ICMP Echo Request/Reply - mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires - both a client and a server implementing this protocol. Intermediate - routers are not required to support this protocol. They forward - Protocol Messages and data traffic as usual. + mechanism, but uses UDP RFC 768 [2] and requires both a client and a + server implementing this protocol. Intermediate routers are not + required to support this protocol. They forward Protocol Messages + and data traffic as usual. The protocol here specified is based on the actual implementation of - the ssmping and asmping tools [5] which are widely used by the + the ssmping and asmping tools [4] which are widely used by the Internet community to conduct multicast connectivity tests. 2. Architecture Before describing the protocol in detail, we provide a brief overview of how the protocol may be used and what information it may provide. The typical protocol usage is as follows: A server runs continuously to serve requests from clients. A client can test the multicast reception from this server, provided it knows a unicast address of the server. It will then send a unicast message to the server asking @@ -131,23 +131,21 @@ variation of Round Trip Times (RTT). For unicast, the RTT is the time from when the unicast request is sent to when the reply is received. The measured multicast RTT also references the client's unicast request. By use of the TTL option specifying the TTL of the replies when they are originated, the client can also determine the number of router hops it is from the source. Since similar information is obtained in the unicast replies, the host may compare its multicast and unicast results and is able to check for differences in the number of hops, RTT, etc. The number of multicast hops and changes in the number of hops over time, may also reveal - details about the multicast tree and multicast tree changes. E.g., - with PIM-SM one may be able to tell whether the forwarding is on a - shared or source-specific tree and when an eventual switch occurs. + details about the multicast tree and multicast tree changes. Provided that the server sends the unicast and multicast replies nearly simultaneously, the client may also be able to measure the difference in one way delay for unicast and multicast on the path from server to client, and also differences in delay. Servers may optionally specify a timestamp. This may be useful since the unicast and multicast replies can not be sent simultaneously (the delay depending on the host's operating system and load). 3. Protocol specification @@ -173,20 +171,29 @@ simple Multicast Ping Protocol server. However, the server SHOULD add a TTL option, and there are other options that a server implementation MAY support, e.g., the client may ask for certain information or a specific behaviour from the server. The Echo Replies (one unicast and one multicast) MUST first contain the exact options from the request (in the same order), and then, immediately following, any options appended by the server. A server MUST NOT process unknown options, but they MUST still be included in the Echo Reply. A client MUST ignore any unknown options. + The size of the protocol messages is generally smaller than the Path + MTU and fragmentation is not a concern. There may however be cases + where the Path MTU is really small, or that a client sends large + requests in order to verify that it can receive fragmented multicast + datagrams. This document does not specify whether Path MTU Discovery + should be performed, etc. A possible extension could be an option + where a client requests Path MTU Discovery and receives the current + Path MTU from the server. + This document defines a number of different options. Some options do not require processing by servers and are simply returned unmodified in the reply. There are, however, other client options that the server may care about, and also server options that may be requested by a client. Unless otherwise specified, an option MUST NOT be used multiple times in the same message. 3.1. Option format All options are TLVs formatted as specified below. @@ -217,30 +224,31 @@ This document defines the following options: Version (0), Client ID (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), Option Request Option (5), Server Information (6), TTL (9), Multicast Prefix (10), Session ID (11) and Server Timestamp (12). Values 7 and 8 are reserved. The options are defined below. Version, type 0 Length MUST be 1. This option MUST always be included in all messages, and the value MUST be set to 2 (in decimal). Note - that there are older implementations of ssmping that only - partly follow this specification. They can be regarded as - version 1 and do not use this option. If a server receives a - message with a version other than 2 (or missing), the server - SHOULD (unless it supports the particular version) send a - Response message back with version set to 2. Client ID and - Sequence Number options SHOULD be echoed if present. It SHOULD - not include any other options. A client receiving a response - with a version other than 2, MUST (unless it supports the - particular version), stop sending requests to the server. + that there are implementations of older revisions of this + protocol that only partly follow this specification. They can + be regarded as version 1 and do not use this option. If a + server receives a message with a version other than 2 (or + missing), the server SHOULD (unless it supports the particular + version) send a Response message back with version set to 2. + Client ID and Sequence Number options SHOULD be echoed if + present. It SHOULD not include any other options. A client + receiving a response with a version other than 2, MUST (unless + it supports the particular version), stop sending requests to + the server. Client ID, type 1 Length MUST be non-zero. A client SHOULD always include this option in all messages (both Init and Request). The client may use any value it likes to be able to detect whether a reply is a reply to its Init/Request or not. A server should treat this as opaque data, and MUST echo this option back in the reply if present (both Server Response and Reply). The value might be a process ID, perhaps process ID combined with an IP address @@ -279,21 +287,21 @@ from the Request message). It MUST NOT be used in Init messages. The format of the option value is as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Multicast group address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | The address family is a value 0-65535 as assigned by IANA for - Internet Address Families [4]. This is followed by the group + Internet Address Families [3]. This is followed by the group address. Length of the option value will be 6 for IPv4, and 18 for IPv6. Option Request Option, type 5 Length MUST be greater than 1. This option MAY be used in client messages (Init and Request messages). A server MUST NOT send this option, except that if it is present in a Request message, the server MUST echo it in replies (Reply message) to the Request. This option contains a list of option types for @@ -377,21 +385,21 @@ Request/Reply messages. Note that this option MAY be included multiple times to specify multiple prefixes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Prefix Length |Partial address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | The address family is a value 0-65535 as assigned by IANA for - Internet Address Families [4]. This is followed by a prefix + Internet Address Families [3]. This is followed by a prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special 'wildcard' use discussed below), and finally a group address. For any family, prefix length 0 means that any multicast address from that family is acceptable. This is what we call 'wildcard'. The group address need only contain enough octets to cover the prefix length bits (i.e., the group address would have to be 3 octets long if the prefix length is 17-24, and there need be no group address for the wildcard with prefix length 0). Any bits past the prefix length MUST be ignored. For IPv4, the option value length will be 4-7, while for IPv6, @@ -638,136 +646,184 @@ message. This may happen when the server restarts or if a client sends a Request with no prior Init message. The server may go ahead and respond if it is okay with the group used. In the responses it may add a Session ID which will then be in later requests from the client. If the group is not okay, the server sends back a Server Response. The Response is just as if it got an Init message with no prefixes. If the server adds or modifies the SessionID in replies, it must use the exact same SessionID in the unicast and multicast replies. - By default, a server should perform rate limiting and for a given - client, respond to at most one Request message per second. A leaky - bucket algorithm is suggested, where the rate can be higher for a few - seconds, but the average rate should by default be limited to a - message per client per second. - 8. Recommendations for Implementers The protocol as specified is fairly flexible and leaves a lot of freedom for implementers. In this section we present some recommendations. Server administrators should be able to configure one or multiple group prefixes in a server implementation. When deploying servers on the Internet and in other environments, the server administrator should be able to restrict the server to respond to only a few multicast groups which should not be currently used by multicast applications. A server implementation should also provide flexibility for an administrator to apply various policies to provide one or multiple group prefixes to specific clients, e.g., site scoped addresses for clients that are inside the site. Clients could be identified by their IP address provided that clients are required to send Init messages, and they receive an unpredictable Session ID. + See also Section 11. - Servers must perform rate limiting, to guard against this protocol - being used for DoS attacks. By default, clients should send at most - one request per second, and servers should perform rate limiting if a - client sends more frequent requests. Server implementations should - provide administrative control of which client IP addresses to serve, - and may also allow certain clients to perform more rapid requests. + Clients should by default send at most one request per second. + Servers should perform rate limiting, to guard against this protocol + being used for DoS attacks. The server should for a given client, + respond to at most one Request message per second. A leaky bucket + algorithm is suggested, where the rate can be higher for a few + seconds, but the average rate should by default be limited to a + message per client per second. Server implementations should provide + administrative control of which client IP addresses to serve, and may + also allow certain clients to perform more rapid requests. Implementers of applications/tools using this protocol should - consider the UDP guidelines [6], in particular if clients are to + consider the UDP guidelines [5], in particular if clients are to send, or servers are to accept, requests at rates exceeding one per - second. + second. If higher rates are allowed for specific IP addresses, then + Init messages and the Session ID option should be used to help + prevent spoofing. See Section 11. -9. Acknowledgements +9. Acknowledgments The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Specific Multicast, and also the Internet Draft draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave Thaler have contributed in different ways to the implementation of - the ssmping tools at [5]. Many people in communities like TERENA, + the ssmping tools at [4]. Many people in communities like TERENA, Internet2 and the M6Bone have used early implementations of ssmping and provided feedback that have influenced the current protocol. Thanks to Kevin Almeroth, Toerless Eckert, Gorry Fairhurst, Alfred Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and providing feedback on this draft. In particular Hugo, Gorry and - Bharat have provided lots of input on several revisions of the draft + Bharat have provided lots of input on several revisions of the draft. 10. IANA Considerations - IANA is requested to provide a UDP port number for use by this - protocol, and also to provide registries for message and option + IANA is requested to provide a well-known UDP port number for use by + this protocol, and also to provide registries for message and option types. There should be a message types registry. Message types are in the - range 0-255. Message types 0-191 can be assigned referencing an RFC - (it may be Informational), while types 192-255 are freely available - for experimental, private or vendor specifc use. The registry should - include the messages defined in Section 5 + range 0-255. Message types 0-191 require specification (an RFC or + other permanent and readily available reference), while types 192-255 + are for experimental use and are not registered. The registry should + include the messages defined in Section 5. A message specification + must describe the behaviour with known option types as well as the + default behaviour with unknown ones. There should also be an option type registry. Option types 0-49151 - can be assigned referencing an RFC (it may be Informational), while - types 49152-65535 are freely available for experimental, private or - vendor specifc use. The registry should include the options defined - in Section 3.2. + require specification (an RFC or other permanent and readily + available reference), while types 49152-65535 are for experimental + use and are not registered. The registry should include the options + defined in Section 3.2. An option specification must describe how + the option may be used with the known message types. This includes + which message types the option may be used with. + + The initial registry definitions could be as follows: + + Multicast Ping Protocol Parameters: + + Registry Name: Multicast Ping Protocol Message Types + Reference: [this doc] + Registration Procedures: Specification Required + + Registry: + Type Name Reference + ----------- ------------------------------------ ---------- + 65 Echo Reply [this doc] + 73 Init [this doc] + 81 Echo Request [this doc] + 83 Server Response [this doc] + 192-255 Experimental + + Registry Name: Multicast Ping Protocol Option Types + Reference: [this doc] + Registration Procedures: Specification Required + + Registry: + Type Name Reference + ----------- ------------------------------------ ---------- + 0 Version [this doc] + 1 Client ID [this doc] + 2 Sequence Number [this doc] + 3 Client Timestamp [this doc] + 4 Multicast Group [this doc] + 5 Option Request Option [this doc] + 6 Server Information [this doc] + 7 Reserved [this doc] + 8 Reserved [this doc] + 9 TTL [this doc] + 10 Multicast Prefix [this doc] + 11 Session ID [this doc] + 12 Server Timestamp [this doc] + 49152-65535 Experimental 11. Security Considerations There are some security issues to consider. One is that a host may send a request with an IP source address of another host, and make an arbitrary multicast ping server on the Internet send packets to this other host. This behaviour is fairly harmless. The worst case is if the host receiving the unicast replies also happen to be joined to the multicast group used. In this case, there would be an amplification effect where the host receives twice as many replies as - there are requests sent. + there are requests sent. See below for how spoofing can be + prevented. + + For ASM (Any-Source Multicast) a host could also make a multicast + ping server send multicast packets to a group that is used for + something else, possibly disturbing other uses of that group. The + main concern is bandwidth. Since there is a well-known port, it + should not be received by other applications. Due to this, a server + on the Internet SHOULD perform rate limiting. In order to help prevent spoofing, a server SHOULD require the client to send an Init message, and return an unpredictable Session ID in the response. The ID should be associated with the IP address and have a limited lifetime. The server SHOULD then only respond to Request messages that have a valid Session ID associated with the source IP address of the Request. Server implementations should allow administrators to restrict which groups a server responds to, and also perform rate limiting. This is - discussed in Section 8). + discussed in Section 8. 12. References 12.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. - [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - - [4] "IANA, Address Family Numbers", + [3] "IANA, Address Family Numbers", . 12.2. Informative References - [5] "ssmping implementation", + [4] "ssmping implementation", . - [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for - Application Designers", draft-ietf-tsvwg-udp-guidelines-10 (work - in progress), August 2008. + [5] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for + Application Designers", draft-ietf-tsvwg-udp-guidelines-11 (work + in progress), October 2008. Author's Address Stig Venaas UNINETT Trondheim NO-7465 Norway Email: venaas@uninett.no