Internet DRAFT - draft-hilt-pim-tree-unreachability
draft-hilt-pim-tree-unreachability
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]
