--- 1/draft-ietf-mboned-ssmping-04.txt 2008-09-18 15:12:21.000000000 +0200 +++ 2/draft-ietf-mboned-ssmping-05.txt 2008-09-18 15:12:21.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group S. Venaas Internet-Draft UNINETT -Intended status: Informational February 21, 2008 -Expires: August 24, 2008 +Intended status: Informational September 18, 2008 +Expires: March 22, 2009 Multicast Ping Protocol - draft-ietf-mboned-ssmping-04 + draft-ietf-mboned-ssmping-05 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,25 +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 August 24, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on March 22, 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. @@ -56,21 +52,21 @@ 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 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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 1. Introduction @@ -227,37 +223,37 @@ 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 + 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 simply leave it unchanged in the reply - (both Server Response and Reply). The value might be a process - ID, perhaps process ID combined with an IP address because it - may receive multicast responses to queries from other clients. - It is left to the client implementer how to make use of this - option. + 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 + because it may receive multicast responses to queries from + other clients. It is left to the client implementer how to + make use of this option. Sequence Number, type 2 Length MUST be 4. A client MUST always include this in Request messages and MUST NOT include it in Init messages. A server replying to a Request message MUST copy it into the Reply (or Server Response message on error). This contains a 32 bit sequence number. The values would typically start at 1 and increase by one for each request in a sequence. @@ -265,21 +261,21 @@ Length MUST be 8 bytes. A client SHOULD include this in Request messages and MUST NOT include it in Init messages. A server replying to a Request message MUST copy it into the Reply. The timestamp specifies the time when the Request message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the last second since the Epoch. - Multicast group, type 4 + Multicast Group, type 4 Length MUST be greater than 2. It MAY be used in Server Response messages to tell the client what group to use in subsequent Request messages. It MUST be used in Request messages to tell the server what group address to respond to (this group would typically be previously obtained in a Server Response message). It MUST be used in Reply messages (copied from the Request message). It MUST NOT be used in Init messages. The format of the option value is as below. @@ -396,31 +392,33 @@ '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, it will be 4-19, and for the wildcard, it will be 3. Session ID, type 11 - Length MUST be non-zero. A server MAY include this in Server - Response and Reply messages. If a client receives this option - in a message, the client MUST echo the Session ID option in - subsequent Request messages, with the exact same value, until - the next message is received from the server. If the next - message from the server has no Session ID or a new Session ID - value, the client should do the same, either not use the + Length MUST be non-zero. A server SHOULD include this in + Server Response and Reply messages. If a client receives this + option in a message, the client MUST echo the Session ID option + in subsequent Request messages, with the exact same value, + until the next message is received from the server. If the + next message from the server has no Session ID or a new Session + ID value, the client should do the same, either not use the Session ID, or use the new value. The Session ID may help the server in keeping track of clients and possibly manage per - client state. It is left to the server implementer to decide - whether it is useful and how to make use of it. + client state. The value of a new Session ID should be chosen + pseudo randomly so that it is hard to predict. This can be + used to prevent spoofing of the source address of Request + messages, see the Security Considerations for details. Server Timestamp, type 12 Length MUST be 8 bytes. A server supporting this option, SHOULD include it in Reply messages, if requested by the client. The timestamp specifies the time when the Reply message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the last second since the Epoch. @@ -542,23 +540,23 @@ the unicast address of the server. It can then send an Init message with a prefix option containing the desired address family and zero prefix length (wildcard entry). The server is then free to decide which group, from the specified family, it should return. A client may also allow a user to specify group address(es) or prefix(es) (for IPv6, the user may only be required to specify a scope or an RP address, from which the client can construct the desired prefix, possibly embedded-RP). From this the client can specify one or more prefix options in an Init message to tell the server which address it would prefer. If the user specifies a group address, that can be - encoded as a prefix of maximal length (e.g. 32 for IPv4). The prefix - options are in prioritised order, i.e., the client should put the - most preferred prefix first. + encoded as a prefix of maximal length (e.g., 32 for IPv4). The + prefix options are in prioritised order, i.e., the client should put + the most preferred prefix first. If the client receives a Server Response message containing a group address it can start sending Request messages, see the next paragraph. If there is no group address option, it would typically exit with an error message. The server may have included some prefix options in the Server Response. The client may use this to provide the user some feedback on what prefixes or scopes are available. Assuming the client got a group address in a Server Response, it can start pinging. Before it does that, it should let the user know @@ -597,34 +595,35 @@ 7. Server Behaviour We will consider how a typical server using the above protocol would behave. First we consider how to respond to Init messages. If the Init message contains prefix options, the server should look at them in order and see if it can assign a multicast address from the given prefix. The server would be configured, possibly have a default, specifying which groups it can offer. It may have a large pool just picking a group at random, possibly choose a group based on hashing - of the clients IP address or identifier, or just use a fixed group. - It is left to the server to decide whether it should allow the same - address to be used simultaneously by multiple clients. If the server - finds a suitable group address, it returns this in a group option in - a Server Response message. The server may additionally include a - Session ID. This may help the server if it is to keep some state, - for instance for making sure the client uses the group it got - assigned. A good Session ID would be a random byte string that is - hard to predict. If the server cannot find a suitable group address, - or if there were no prefixes in the Init message, it may send a - Server Response message containing prefix options listing what - prefixes may be available to the client. Finally, if the Init - message requests the Server Information option, it should include - that. + of the client's IP address or identifier, or just use a fixed group. + A server could possibly decide whether to include site scoped group + ranges based on the client's IP address. It is left to the server to + decide whether it should allow the same address to be used + simultaneously by multiple clients. If the server finds a suitable + group address, it returns this in a group option in a Server Response + message. The server should additionally include a Session ID. This + may help the server if it is to keep some state, for instance for + making sure the client uses the group it got assigned. A good + Session ID would be a pseudo random byte string that is hard to + predict. If the server cannot find a suitable group address, or if + there were no prefixes in the Init message, it may send a Server + Response message containing prefix options listing what prefixes may + be available to the client. Finally, if the Init message requests + the Server Information option, it should include that. When the server receives a Request message, it may first check that the group address and Session ID (if provided) are valid. If the server is satisfied, it will send a unicast Reply message back to the client, and also a multicast Reply message to the group address. The Reply messages contain the exact options and in the same order, as in the Request, and after that the server adds a TTL option and additional options if needed. E.g., it may add a timestamp if requested by the client. If the server is not happy with the Request (bad group address or Session ID, request is too large etc), it may @@ -658,22 +657,24 @@ 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. One such policy - could be to use the client IP address if it can be trusted. + 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. 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. Implementers of applications/tools using this protocol should consider the UDP guidelines [6], in particular if clients are to send, or servers are to accept, requests at rates exceeding one per @@ -718,20 +719,27 @@ 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. + 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). 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. @@ -743,23 +751,23 @@ Specification", RFC 2460, December 1998. [4] "IANA, Address Family Numbers", . 12.2. Informative References [5] "ssmping implementation", . - [6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for - Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work - in progress), February 2008. + [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for + Application Designers", draft-ietf-tsvwg-udp-guidelines-10 (work + in progress), August 2008. Author's Address Stig Venaas UNINETT Trondheim NO-7465 Norway Email: venaas@uninett.no @@ -795,15 +803,10 @@ attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).