Network and Protocol Team B. Hilt Internet-Draft MIPS Expires: November 4, 2007 J-J. Pansiot LSIIT M. Hoerdt IL21 May 3, 2007 Join failure notification for PIM-SM multicast routing draft-hilt-pim-tree-unreachability-00.txt 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 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." 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 November 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Currently, PIM-SM is the most widely deployed multicast routing protocol in the Internet. Nevertheless this multicast protocol lacks connectivity debugging function, making it difficult to identify for example; -multicast routing problem, -source unavailability, -RP failure, etc... When a host wants to receive a multicast group/ Hilt, et al. Expires November 4, 2007 [Page 1] Internet-Draft Multicast Tree Unreachability May 2007 channel, if for any reason the associated tree branch cannot be built, nothing exists to inform the receiver or its network about this failure. We propose here a new PIM message suitable for Join forwarding error notification. It is able to inform where and why such an error happened in the network and this without using a multicast traceroute mechanism. This message is also suitable to reduce globally the impact of useless branches in a PIM domain. Furthermore it should be used to block DDoS (Distributed Denial of Service) attacks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol description . . . . . . . . . . . . . . . . . . . . . 5 2.1. Sending PIM/TU Message . . . . . . . . . . . . . . . . . . 5 2.2. Receiving/Forwarding PIM/TU Message . . . . . . . . . . . 6 3. Taking PIM/TU message into account . . . . . . . . . . . . . . 7 3.1. Edge Routers . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Core routers . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Multi-access LANs . . . . . . . . . . . . . . . . . . . . 9 3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. DDoS traceback . . . . . . . . . . . . . . . . . . . . . . 9 4. PIM/TU Message format . . . . . . . . . . . . . . . . . . . . 10 4.1. PIM Version . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. PIM Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Reserved . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. L : 'Last TU Record' bit . . . . . . . . . . . . . . . . . 13 4.6. Reserved1 . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Number of Group Records . . . . . . . . . . . . . . . . . 13 4.8. Router Address . . . . . . . . . . . . . . . . . . . . . . 13 4.9. Group Record . . . . . . . . . . . . . . . . . . . . . . . 13 4.10. Error Code . . . . . . . . . . . . . . . . . . . . . . . . 14 4.11. R : 'shaRed tree' bit . . . . . . . . . . . . . . . . . . 14 4.12. S : 'Source or RP' bit) . . . . . . . . . . . . . . . . . 14 4.13. Res . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.14. Error Code . . . . . . . . . . . . . . . . . . . . . . . . 14 4.15. Holdtime . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.16. Number of Unicast Address . . . . . . . . . . . . . . . . 14 4.17. Multicast Address . . . . . . . . . . . . . . . . . . . . 14 4.18. Unicast Address [i] . . . . . . . . . . . . . . . . . . . 15 5. PIM/TU message Error Codes . . . . . . . . . . . . . . . . . . 15 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Hilt, et al. Expires November 4, 2007 [Page 2] Internet-Draft Multicast Tree Unreachability May 2007 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Hilt, et al. Expires November 4, 2007 [Page 3] Internet-Draft Multicast Tree Unreachability May 2007 1. Introduction With the current specification of PIM-SM [1], when a router cannot build a tree branch, the first possible operation will be to send (if available and configured) a trap message to a management station to inform about this failure. If this failure cannot be removed quickly, or is the result of misuse, nothing is available to inform downstream routers or possibly receivers. Therefore useless multicast branches or full trees can be maintained from several receivers to a point of failure, while these receivers needlessly wait for multicast data. Such a failure may be due for example to temporary routing problem (source or RP unreachability), configuration problem (RP adressing, ...) or user error (source address of an SSM channel which is not a valid or existing address). The main idea proposed here is to send through the builded part of the tree an error message informing downstream that a Join message propagation failed at some point in the network. This may occur toward a source (S) both for a PIM-SM[5] SSM channel or for a SPT tree for a PIM -SM[1] ASM group. This may also occur between the DR and the rendez-vous point (RP) for an ASM group. This new error message, called Tree Unreachability (TU) message, will be a new PIM-SM message (also further called PIM/TU message). In the following tree will designate either an (S, G) tree or a (*, G) tree. The associated mechanism proposed here is to take into account this message in all the routers of the trees of the group(s)/channel(s) concerned by the failure. A router receiving this message will forward it through the outgoing interfaces of the embedded group(s)/ channel(s) builded tree part after a possible message trimming. At the same time, the PIM/TU Tree unavailability information is stored in a soft-state cache for a specific duration (See Section 4.15). As long as a multicast entry exists and is marked as unreachable a routeur stops sending upstream Join message for the failed trees. Due to this, useless branche(s) will be automatically pruned out. This mechanism is different and complementary from multicast traceroute. It is a push model where error indications are forwarded downstream whereas multicast traceroute is more of a pull model in which queries are triggered from downstream but still very useful. It can provide multicast listeners with a report including both problem location and problem description. It can help network user or administrator reporting the problem to the person responsible of the good operation of multicast routing for the indicated location. The information carried by this message could be a ground information to use by diagnostic applications such as ssmping or asmping[6] to locate the point of failure in case of unreachability. In a multicast domain, the use of this new message can suppress multicast Hilt, et al. Expires November 4, 2007 [Page 4] Internet-Draft Multicast Tree Unreachability May 2007 useless banches and because of this reduce globally routers bandwidth consumption and memory use. Of course, PIM/TU information can be sent via trap to a network management station to inform about failure. The Prune part of a failed Join message is not considered in this draft. The PIM/TU failure information could be forwarded to networks with receivers, for example using a new ICMP message. Some user applications COULD use it to warn for example the user and/or to leave the corresponding group or channel. But this is out of the scope of this draft. As this mechanism requires to be deployed on all multicast routers of a multicast domain to operate properly, it requires standardisation. This draft specifies: - the rules used to send and forward this message down the multicast tree, - where and how PIM/TU message could be taken into account to suppress multicast useless banches, - PIM/TU message format, - PIM/TU associated error codes. 2. Protocol description This new proposed PIM-SM message, like the PIM/Join message, is forwarded hop-by-hop by multicast PIM-SM capable routers. It is sent to the ALL-PIM-ROUTERS group address. It is not sent to the group address contained in the failed Join message. When a router R is unable to send a Join message towards a rendez- vous point (RP) or a source (S), it triggers the sending of a PIM/ Tree Unreachability (PIM/TU) message. PIM/TU messages MAY aggregate Join failure reasons for several trees. In order to locate the point of failure, the PIM/TU message contains the address of R. 2.1. Sending PIM/TU Message PIM/TU messages are sent both when a failure occurs on an existing tree (triggered by a periodic Join) or when a new branch is constructed. In both cases, a Join message forwarding failure triggers the sending of a PIM/TU message. If the failure is due to a transient error such as a temporary routing problem, the router may choose to not send PIM/TU message. On interdomain links and routers, the number of maintained groups/ channels can be high. A single failure on those links may trigger a Hilt, et al. Expires November 4, 2007 [Page 5] Internet-Draft Multicast Tree Unreachability May 2007 high number of PIM/TU messages sharing the same point of failure. To reduce the cost of the protocol in this case, PIM/TU messages sent on a link MAY aggregate unreachability information for several trees sharing this link. Because the PIM/TU message size is limited to the link MTU, if the number of tree to aggregate makes the message exceeding this size, unreachability information will be fragmented into multiple PIM/TU messages. To avoid the sending of a burst of PIM/TU messages, these messages should be rate limited. When a multicast router R is unable to send a Join message, it builds for each failed group/channel a Group Record containing its failure information such as group/channel identification, router R address, error code, etc... (detailled message format in Section 4). For each outgoing interface of at least one failing tree, the corresponding Group Records are gathered in the same TU Record. Then a PIM/TU message, possibly aggregating several Group Records for this interface is built. The destination address of the PIM/TU messages using this interface MUST be the ALL_PIM_ROUTERS group address (224.0.0.13 in IPv4 or FF02::D in IPv6). This ensures that for the failed group(s)/channel(s) all PIM-SM Routers will receive the PIM/TU message. It could be helpful to forward PIM/TU messages (or a subset of them) in leaf networks to inform hosts about group/ channel unavailability. Further work will determine if this can be interesting. And if answer is positive, what is the best way to achieve this. 2.2. Receiving/Forwarding PIM/TU Message PIM/TU messages are forwarded hop-by-hop according to the TIB (Tree Information Base) maintained by the multicast routing protocol. When a router R receives a PIM/TU message on an interface: - If the source address of the received message is not the address of a PIM neighbor for the interface the PIM/TU message MUST be silently ignored. - If there is no group/channel in the PIM/TU message for which the receiving interface is the incoming interface, the message must be silently ignored. A PIM/TU message is forwarded on all interested interfaces after a possible trimming. An interface i is interested by the PIM/TU, if and only if, the PIM/TU contains a group or channel such that: Hilt, et al. Expires November 4, 2007 [Page 6] Internet-Draft Multicast Tree Unreachability May 2007 (1) PIM/TU message was received by the incoming interface for this group/channel. (2) interface i is an outgoing interface for this group/channel. The PIM/TU message sent through interface i is possibly trimmed such that it contains only group(s)/channel(s) satisfying conditions (1) and (2). (3) Channel unreachability information (concerning a specific source S and group G) is only forwarded down to a shared tree (*,G) using TIB states if the bit R is set in the TU Record. RP unreachability information is propagated on the shared (*,G) tree without setting this bit. Normally, if a Join (S,G) fails, PIM/TU message is sent only down the (S,G) tree. In some ASM cases, a join (S,G) may fail between the RP and the FHR. In this case a PIM/TU message will travel down to the RP, and if the RP has no outgoing interface for (S,G), the PIM/TU message will stop there. So the RP may choose to forward the PIM/ TU(S,G) message down the shared tree. In this case, care must be taken that this message MUST be distinguished from regular PIM/ TU(S,G) messages. The R bit tells that. Such a message may help debug a problem between the RP and the source, but this problem may have no direct impact on receivers, if they reach the source by another route. This bit is set by the router forwarding a PIM/TU(S,G) through the shared tree, and then this PIM/TU message should be transparently forwarded down the shared tree. Several PIM/TU messages parts concerning a same interface, possibly originating from different routers MAY be aggregated in a same new PIM/TU message. As long as a multicast router is aware about upstream failure for a group/channel (i.e. has this information in its cache), it stops forwarding PIM/TU messages for this group/channel. This avoids networks to be flooded by PIM/TU messages. 3. Taking PIM/TU message into account PIM/TU messages are triggered by routers when Join forwarding failure appears on either new tree branch construction or periodic tree maintenance. PIM/TU messages gives the possibility to inform downstream the point of failure that some group/channel is not available. After a Join message failure detection, PIM/TU messages are forwarded down the builded part of trees of all the concerned trees. If the case of non transient error, the failure of a Join message forwarding triggers a PIM/TU message. One PIM/TU message can Hilt, et al. Expires November 4, 2007 [Page 7] Internet-Draft Multicast Tree Unreachability May 2007 gather information about several trees. Because PIM/TU taking in account will be freeze Join sending, only one PIM/TU should be sent per failed Join message. In a multicast domain, we can split the multicast routers into two categories: Edge Routers (ER) and Core Routers (CR). Edge Routers are those that either; (1) executes a Group Management Protocol on at least one interface, (2) are connected to non PIM/TU capable PIM neighbors. This information should be available using PIM/HELLO messages or by configuration, (3) are connected to unreliable PIM neighbors (mostly the case in interdomain routing). whereas Core Routers are all the other routers of a multicast domain. To manage useless branches and to reduce multicast routers bandwith and/or resource consumption Section 3.1 shows how PIM/TU will be taken into account in the Edge Routers (ER) of a multicast managed domain. Section 3.2 shows how the routers located in the core of the multicast managed network, can take PIM/TU message into account and interacts with Edge routers to suppress useless branches. The forwarding of unavailability information for trees to receivers and/or their networks is out of the scope of this draft. 3.1. Edge Routers Because the PIM-SM multicast model is fully receiver driven, the best point to take into account the PIM/TU failure information is in the last-hop routers of multicast trees (above mentioned as Edge Routers). So each Edge Router having at least one registered multicast receiver for a group/channel of PIM/TU message, stops sending upstream Join message for the concerned tree. To avoid a new branch construction for an unavailable tree, this freezing state(s) will be maintained up to the PIM/TU message embedded Group Record Holdtime. This Holdtime will be necessarily greater than the maximum forwarding state duration (PIM Expiry Timer). It will be chosen according to the type of failure. Further work is needed to specify the duration associated to each error type. This freezing function is maintained per group/channel. Because this freezing time is greater than the Expiry Timer, the forwarding states in the routers toward the point of failure will be automatically flushed and useless branches will disappear. 3.2. Core routers When a PIM/TU message flows from the point of failure to the Edge Routers of the PIM/TU concerned tree, each intermediate Core Router Hilt, et al. Expires November 4, 2007 [Page 8] Internet-Draft Multicast Tree Unreachability May 2007 will mark the tree T with an unreachability flag and stores associated information (point of failure, error type and Holdtime). Suppose now that this Core Router receives a new Join message for a tree T whose unreachability is known, which is one of the PIM/TU concerned group(s)/channel(s), and that this Join message arrives before T TIB state is flushed by Join Time countdown. The receiving interface of this Join message is not a part of the initial tree of the group/channel for T. Because T is marked as unavailable, this Join message will be discarded and the Core Router will send a PIM/TU message through this new downstream interface. The Holdtime of this PIM/TU message will be the current value of the stored Holdtime. The Edge Router of this branch will then stop sending join for T for Holdtime time. 3.3. Multi-access LANs When a link connects more than two routers, if a PIM/TU message is sent to this link, only the routers having a state in their TIB for the trees concerned by this PIM/TU message mark them as Unreachable. If a new branch for one of an unavailable tree cross over this network, the upstream router toward the RP or the source of this tree sends a new PIM/TU message back to the shared network. So routers without unreachability information for this tree (i.e. the router from which the Join message for this tree is coming from) mark it as unreachable and forward the PIM/TU message to the freshly built branch. While other routers connected to the shared network update their holdtime for the concerned tree. 3.4. Discussion The presented solution describes two behaviors based on router function. In both cases Join forwarding is frozen. On Edge Routers Unreachability information will be maintained for Holdtime whereas in Core Routers Unreachability information will be maintained until forwarding state is flushed. In certain cases, due to periodic new branches construction initiated by new receivers, it is possible to maintain for a long/undefined time an Unreachability information for a tree. But, because the forwarding states in the other routers of this tree will be flushed, the global resource consumption will decrease. 3.5. DDoS traceback A DDoS attack against a multicast infrastructure may consist in flooding the network with join messages addressed to randomly selected trees, thereby overloading routers with tree states, and possibly staturating routers memory. Similar attacks already occurred through the MSDP infrastructure. In such cases, one Hilt, et al. Expires November 4, 2007 [Page 9] Internet-Draft Multicast Tree Unreachability May 2007 possible use of PIM/TU message should be: one (or several) router on the attacked site detects the DDoS attack (through a new join message rate trigger of new join messages, or possibly the proportion of new join message causing some sort of failures such as source host unreachable). This router sends then back PIM/TU messages (possibly with an error code of a "DDoS attack detected" type). Edge routers receiving sufficiently many such messages (but much less than the attacked site, since this is a distributed attack) may take appropriate actions (message sent to the network administrator, automatic filtering of new joins from suspected interfaces,...). 4. PIM/TU Message format Join messages sent by a router summarizes for a given interface the group (*,Gn)/channel (Sn,Gn) join state information. These messages are sent either to maintain a connection towards the root of the tree (Rendez-vous Point or Source) or to create a new tree branch. To inform downstream the builded tree part of a Join propagation failure, each group/channel which cannot be connected to its tree root will be included into a Tree Unreachability message. Since the proposed tree unreachability mechanism is an extension of the PIM-SM protocol, the Tree Unreachability message inherits of all PIM-SM message properties. Its protocol number will be 103, it will need new PIM message type number, and it will use sources and groups addresses encoding. Like Join/Prune messages, it will be sent by routers only but downstream the builded parts of several trees. PIM/TU messages are sent to inform downstream PIM neighbors about Join progagation failure. This information can then be used to avoid building and/or maintainig useless tree branches. IPv4 PIM/TU messages MUST only contain unreachability information about IPv4 addresses while IPv6 PIM/TU messages MUST be sent with a link-local source address and MUST only contain unreachability information about IPv6 addresses. A PIM/TU message can carry several Tree Unreachability Records concerning each an error location (i.e. router interface). In the following text we use PIM/TU to refer to IPv4 or IPv6 PIM/TU messages. So, if specific to a protocol family (IPv4/IPv6) information is necessary, it will be specified explicitely. A single TU Record informs about a single group address associated with a single problem notification. TU Records MAY agregate Group Records with the same failing router address. PIM/TU messages Hilt, et al. Expires November 4, 2007 [Page 10] Internet-Draft Multicast Tree Unreachability May 2007 agregate TU Records which MAY come from different router address. Figures 1,2 and 3 explicit respectively the format for PIM/TU messages, TU Records and Group Records. The PIM/TU header presented in Figure 1 is common to several TU Records (until reaching MTU value). Each of them regarding failure on a specific router. TU Records on figure 2 have the format presented for 32 bits IPv4 addresses. When using IPv6, all addresses will have a size of 128 bits. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . TU Record [1] . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . TU Record [2] . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . TU Record [N] . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 : PIM/TU Message format Hilt, et al. Expires November 4, 2007 [Page 11] Internet-Draft Multicast Tree Unreachability May 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved1 | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [1] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [M] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 : TU Record format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|Res|Err Cde| Holdtime | Number of Unicast Address (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Address [1] | +--- ---+ . . . +--- ---+ | Unicast Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 : Group Record format 4.1. PIM Version PIM Version number is 2. 4.2. PIM Type Type for specific PIM message. The value of this field is to be defined to extend existing PIM messages list (i.e. 9). Hilt, et al. Expires November 4, 2007 [Page 12] Internet-Draft Multicast Tree Unreachability May 2007 4.3. Reserved Set to zero on emission. Ignored upon receipt. 4.4. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the whole ICMP/ICMP6 PIM/TU message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum must be verified before processing the message. 4.5. L : 'Last TU Record' bit When a PIM/TU message carries several TU Records, flag L of the last TU Record MUST be set to 1. All intermediate TU Records MUST have flag L set to 0. If a PIM/TU message carries a single TU Record, flag L of this record MUST be set to 1. 4.6. Reserved1 The Reserved1 field is reserved for future usage. It is set to zero on emission and ignored upon reception. 4.7. Number of Group Records The Number of Group Records (M) specifies how many Group Records (information regarding individual group/channel unreachability) are present in a TU Record. 4.8. Router Address The Router Address is used to identify the router on which the Join message forwarding failure occurs. This address MUST be chosen among the router addresses. Because of router reachability this address should be the address of the interface used to send out the PIM/TU message. This address must be with the largest scope (i.e. public address for IPv4, global address for IPv6, if available). 4.9. Group Record Each Group Record of a TU Record contains information belonging to a group/channel which Join message could not be forwarded by the router designated by the Router Address (section Section 4.8). Hilt, et al. Expires November 4, 2007 [Page 13] Internet-Draft Multicast Tree Unreachability May 2007 4.10. Error Code The four fields R, S, Res, Err Cde (Error Code) pertains to the same global error code which gives an indication about the type of failure occuring during the Join message forwarding. 4.11. R : 'shaRed tree' bit The R bit is set when a PIM/TU information triggered by a Join(S,G) must be propagated in the shared tree. It is typically used to propagate a failure related to the PIM-SM RP-SPT switching. 4.12. S : 'Source or RP' bit) The S bit indicates if the Join error is related to a forwarding failure towards a Rendez-vous Point (S is set to 0) or towards a Source (S is set to 1). 4.13. Res These two bits are reserved for a future usage. They are set to zero on emission and ignored upon reception. 4.14. Error Code The Err Cde (Error Code) field is a code that defines as precisely as possible the error type (if known). A first list of possible error Code values and their signification is given in Section 5. 4.15. Holdtime The Holdtime field is a duration value (in seconds) which indicates how long the unavailability information for the concerned group/ channel should be cached in downstream routers. This value should be at least a small multiple (e.g. three) of the PIM join interval timer. 4.16. Number of Unicast Address The Number of Unicast Address (N) field specifies how many unicast IPv4/IPv6 addresses (RP/Sources) are present in this Group Record. This information allows too, to determine the current size of the Group Record. 4.17. Multicast Address The Multicast Address field contains the IPv4/IPv6 multicast group address to which this Group Record pertains. Hilt, et al. Expires November 4, 2007 [Page 14] Internet-Draft Multicast Tree Unreachability May 2007 4.18. Unicast Address [i] The Unicast Address list is a vector of n IPv4/IPv6 unicast addresses, where n is the value in this record's Number of Unicast Addresses (N) field. The unicast addresses are either Rendez-vous Point or Source addresses depending on the S flag of this record. If the S bit is set to 0, this means that the Join forwarding failure occurs in a shared tree, on the way toward the RP. RP information can differ between Join message carried and local router. In this case Unicast Address [0] is the RP address contained in the failed Join message, while Unicast Address [1] is the RP address known for this group on the local router. If there is no local RP information for this group, Unicast Address [1] is set to NULL. If the S bit is set to 1, this means that the Join forwarding failure occurs in an SSM or an ASM SPT tree. The list of Unicast Adresses is then the list of the failed sources for the same group, usually only one in the SSM case. 5. PIM/TU message Error Codes The error code indicates the reason of the failure incured by a Join message forwarded toward a source (S), if bit S is set or towards a Rendez-vous Point (RP), if bit S is cleared. Code values and signification are proposed in the table below. They are only suggestions and must in the future to be defined by IANA. Hilt, et al. Expires November 4, 2007 [Page 15] Internet-Draft Multicast Tree Unreachability May 2007 S | Value | Name | Description ------------------------------------------------------------------- x | 0x1 | NO_MCAST_IF | The interface pointing to the nexthop | | | towards the source or the RP is not | | | enabled for multicast. ---|-------|----------------|-------------------------------------- x | 0x2 | NO_MCAST_NEIGH | The next hop towards the source or | | | the rendez-vous point is not a | | | multicast capable neighbor. ---|-------|----------------|-------------------------------------- x | 0x3 | NO_ROUTE | The router has no route for the | | | source or for the RP of the group. ---|-------|----------------|-------------------------------------- 0 | 0x4 | NO_RP | The router cannot match a proper | | | Rendez-vous point for the desired | | | joined group. The RP of the Join | | | message is used to forward the Join | | | message. This is an informational | | | message. ---|-------|----------------|-------------------------------------- 0 | 0x5 | ERR_RP | The RP mentioned in the (*,G) part | | | of a Join message is different from | | | the local RP information for that | | | group. ---|-------|----------------|-------------------------------------- x | 0x6 | SCOPED | The group or channel is subject to | | | administrative scoping at this hop. ---|-------|----------------|-------------------------------------- x | 0x7 | FILTERED | The group or channel is subject to | | | administrative filtering at this hop. ---|-------|----------------|-------------------------------------- 0 | 0x8 | NO_ASM_ADDR | The group address specified in an ASM | | | Join pertains to a SSM group address | | | for that router. ---|-------|----------------|-------------------------------------- x | 0xF | NOT_FWD | The router is not forwarding this | | | group/source for an unspecified | | | reason. ---|-------|----------------|-------------------------------------- Table 1 : TU error codes The x value indicates that the error code may be used for both values of S. Hilt, et al. Expires November 4, 2007 [Page 16] Internet-Draft Multicast Tree Unreachability May 2007 6. Security Consideration The new proposed PIM/TU message is an informational message. In this proposal it is only forwarded by routers and does not interact much more with other systems. In section Section 3 we make some assumptions about how PIM/TU message could be used to reduce global multicast signaling. With this proposal, an important number of non-existent trees could be joined by a set of malicious hosts in the network, possibly triggering a storm of TU messages and exhausting the ressources available by trying to signal a malicious error case. This control plane attack is already possible without the TU message [4]. TU messages rate limitation MUST be available in order to minimize the additionnal cost on the network ressources in this kind of attack. The detailed usage of information carried by the TU message is out of the scope of this draft but Forged TU messages could be sent in non failing trees making the receivers believe that the multicast connection failed at some point in time. To prevent that, only TU messages from known neighbors SHOULD be accepted by routers propagating the unreachability information. 7. References 7.1. Normative References [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", mar 2006. [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [3] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. 7.2. Informative References [4] Savola, P., Lethonen, R., and D. Meyer, "PIM-SM Multicast Routing Security Issues and Enhancements (draft-ietf-mboned-mroutesec-04.txt)", oct 2004. [5] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", jul 2003. Hilt, et al. Expires November 4, 2007 [Page 17] Internet-Draft Multicast Tree Unreachability May 2007 [6] Venaas, S., "Source Specific and Any Source multicast ping (http://www.venaas.no/multicast/ssmping/)", apr 2005. Authors' Addresses Benoit Hilt MIPS/GRTC IUT de Colmar BP 50568 Colmar Cedex 68008 FRANCE Phone: +33 3 89 20 23 64 Email: benoit.hilt@uha.fr Jean-Jacques Pansiot LSIIT Universite Louis Pasteur Strasbourg Pole API, bureau C447 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: +33 3 90 24 45 63 Email: pansiot@clarinet.u-strasbg.fr URI: http://clarinet.u-strasbg.fr/~pansiot/ Mickael Hoerdt Infolab21 e Lancaster N UNITED KINGDOM Phone: + Email: mhoerdt@lancs.ac.uk URI: http:// Hilt, et al. Expires November 4, 2007 [Page 18] Internet-Draft Multicast Tree Unreachability May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an 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). Hilt, et al. Expires November 4, 2007 [Page 19]