--- 1/draft-ietf-mboned-mtrace-v2-22.txt 2018-04-02 23:13:13.032584675 -0700 +++ 2/draft-ietf-mboned-mtrace-v2-23.txt 2018-04-02 23:13:13.108586485 -0700 @@ -1,20 +1,20 @@ MBONED Working Group H. Asaeda Internet-Draft NICT Intended status: Standards Track K. Meyer -Expires: June 23, 2018 +Expires: October 4, 2018 W. Lee, Ed. - December 20, 2017 + April 2, 2018 Mtrace Version 2: Traceroute Facility for IP Multicast - draft-ietf-mboned-mtrace-v2-22 + draft-ietf-mboned-mtrace-v2-23 Abstract This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a query and receives a reply. @@ -26,25 +26,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on June 23, 2018. + This Internet-Draft will expire on October 4, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -68,91 +68,96 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 8 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 11 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 12 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 16 - 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 18 - 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 19 - 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 20 - 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 20 - 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 21 - 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 21 - 4.2.1. Request Packet Verification . . . . . . . . . . . . . 21 - 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 22 + 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 19 + 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 20 + 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 21 + 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 21 + 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 22 + 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 22 + 4.2.1. Request Packet Verification . . . . . . . . . . . . . 22 + 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 23 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 24 - 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 24 - 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 24 - 4.3.3. Appending Standard Response Block . . . . . . . . . . 24 - 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 25 - 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 25 - 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 25 - 4.4.3. Appending Standard Response Block . . . . . . . . . . 25 - 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 25 - 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 26 + 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 25 + 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 25 + 4.3.3. Appending Standard Response Block . . . . . . . . . . 25 + 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 26 + 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 26 + 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 26 + 4.4.3. Appending Standard Response Block . . . . . . . . . . 26 + 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 26 + 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 27 - 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 26 - 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 26 - 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 27 - 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 27 - 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 27 - 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 27 - 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 27 - 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 28 - 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 28 - 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 28 - 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 28 - 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 28 - 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 29 - 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 29 - 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 29 - 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 29 - 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 29 - 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 30 - 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 30 - 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31 - 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 31 - 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31 - 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31 - 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 32 - 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 32 - 8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 32 - 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 33 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 33 - 9.2. Filtering of Clients . . . . . . . . . . . . . . . . . . 33 - 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 33 - 9.4. Characteristics of Multicast Channel . . . . . . . . . . 33 - 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 33 - 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 11.2. Informative References . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 27 + 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 28 + 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 28 + 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 28 + 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 28 + 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 28 + 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 29 + 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 29 + 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 29 + 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 29 + 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 29 + 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 30 + 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 30 + 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 30 + 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 30 + 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 31 + 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 31 + 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 32 + 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32 + 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 32 + 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32 + 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32 + 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 33 + 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 33 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 33 + 8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 34 + 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 34 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 34 + 9.2. Filtering of Clients and Peers . . . . . . . . . . . . . 34 + 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 34 + 9.4. Characteristics of Multicast Channel . . . . . . . . . . 35 + 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 35 + 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 35 + 9.7. Specific Security Concerns . . . . . . . . . . . . . . . 35 + 9.7.1. Request and Response Bombardment . . . . . . . . . . 35 + 9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 35 + 9.7.3. Leaking of Confidential Topology Details . . . . . . 35 + 9.7.4. Delivery of False Information . . . . . . . . . . . . 36 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 11.2. Informative References . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction - Given a multicast distribution tree, tracing from a multicast source - to a receiver is difficult, since we do not know on which branch of - the multicast tree the receiver lies. This means that we have to - flood the whole tree to find the path from a source to a receiver. - On the other hand, walking up the tree from a receiver to a source is + Given a multicast distribution tree, tracing hop-by-hop downstream + from a multicast source to a given multicast receiver is difficult + because there is no efficient and deterministic way to determine the + branch of the multicast routing tree on which that receiver lies. On + the other hand, walking up the tree from a receiver to a source is easy, as most existing multicast routing protocols know the upstream router for each source. Tracing from a receiver to a source can involve only the routers on the direct path. This document specifies the multicast traceroute facility named Mtrace version 2 or Mtrace2 which allows the tracing of an IP multicast routing path. Mtrace2 is usually initiated from an Mtrace2 client by sending an Mtrace2 Query to a Last Hop Router (LHR) or to a Rendezvous Point (RP). The RP is a special router where sources and receivers meet in Protocol Independent Multicast - Sparse Mode (PIM- @@ -197,21 +202,21 @@ \ | / \ | / \ +---------+ / v | Mtrace2 |/ | client | +---------+ Figure 1 When an Mtrace2 client initiates a multicast trace, it sends an - Mtrace2 Query packet to the LHR or RP for a multicast group and, + Mtrace2 Query packet to an LHR or RP for a multicast group and, optionally, a source address. The LHR/RP turns the Query packet into a Request. The Request message type enables each of the upstream routers processing the message to apply different packet and message validation rules than those required for handling of a Query message. The LHR/RP then appends a standard response block containing its interface addresses and packet statistics to the Request packet, then forwards the packet towards the source/RP. The Request packet is either unicasted to its upstream router towards the source/RP, or multicasted to the group if the upstream router's IP address is not known. In a similar fashion, each router along the path to the @@ -285,65 +290,63 @@ First-hop router (FHR) The router that is directly connected to the source the Mtrace2 Query specifies. Last-hop router (LHR) A router that is directly connected to a receiver. It is also the router that receives the Mtrace2 Query from an Mtrace2 client. Group state - It is the state a shared-tree protocol, such as PIM-SM [5], uses - to choose the upstream router towards the RP for the specified - group. In this state, source-specific state is not available for - the corresponding group address on the router. + The state a shared-tree protocol, such as PIM-SM [5], uses to + choose the upstream router towards the RP for the specified group. + In this state, source-specific state is not available for the + corresponding group address on the router. Source-specific state - It is the state that is used to choose the path towards the source - for the specified source and group. + The state that is used to choose the path towards the source for + the specified source and group. ALL-[protocol]-ROUTERS group - It is a link-local multicast address for multicast routers to - communicate with their adjacent routers that are running the same - routing protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group - is '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d' + Link-local multicast address for multicast routers to communicate + with their adjacent routers that are running the same routing + protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group is + '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d' [5]. 3. Packet Formats This section describes the details of the packet formats for Mtrace2 messages. All Mtrace2 messages are encoded in the Type/Length/Value (TLV) format (see Section 3.1). The first TLV of a message is a message header TLV specifying the type of message and additional context information required for processing of the message and for parsing of subsequent TLVs in the message. Subsequent TLVs in a message, referred to as Blocks, are appended after the header TLV to provide additional information associated with the message. If an - implementation receives an unknown TLV type for the first TLV in a - message (i.e., the header TLV), it SHOULD ignore and silently discard - the entire packet. If an implementation receives an unknown TLV type - for a subsequent TLV within a message, it SHOULD ignore and silently - discard the entire packet. If the length of a TLV exceeds the - available space in the containing packet, the implementation MUST - ignore and silently discard the TLV and any remaining portion of the - containing packet. + implementation receives an unknown TLV type for any TLV in a message, + it SHOULD ignore and silently discard the entire packet. If the + length of a TLV exceeds the available space in the containing packet, + the implementation MUST ignore and silently discard the TLV and any + remaining portion of the containing packet. - All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and - Request messages MUST NOT be fragmented. For IPv6, the packet size - for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the - smallest Maximum Transmission Unit (MTU) for an IPv6 interface [2]. - The source port is uniquely selected by the local host operating - system. The destination port is the IANA reserved Mtrace2 port - number (see Section 8). All Mtrace2 messages MUST have a valid UDP - checksum. + All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 + Query/Request/Reply messages MUST NOT be fragmented. Therefore, + Mtrace2 clients and LHRs/RPs MUST set the IP header do-not-fragment + (DF) bit for all Mtrace2 messages. For IPv6, the packet size for the + Mtrace2 messages MUST NOT exceed 1280 bytes, which is the smallest + Maximum Transmission Unit (MTU) for an IPv6 interface [2]. The + source port is uniquely selected by the local host operating system. + The destination port is the IANA reserved Mtrace2 port number (see + Section 8). All Mtrace2 messages MUST have a valid UDP checksum. Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed. For example, if an Mtrace2 Query or Request message arrives in as an IPv4 packet, all addresses specified in the Mtrace2 messages MUST be IPv4 as well. Same rule applies to IPv6 Mtrace2 messages. 3.1. Mtrace2 TLV 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 @@ -352,23 +355,23 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8 bits Describes the format of the Value field. For all the available types, please see Section 3.2 Length: 16 bits Length of Type, Length, and Value fields in octets. Minimum - length required is 3 octets. The maximum TLV length is not - defined; however the entire Mtrace2 packet length SHOULD NOT - exceed the available MTU. + length required is 4 octets. The length MUST be a multiple of 4 + octets. The maximum TLV length is not defined; however the entire + Mtrace2 packet length MUST NOT exceed the available MTU. Value: variable length The format is based on the Type value. The length of the value field is Length field minus 3. All reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt. 3.2. Defined TLVs The following TLV Types are defined: @@ -389,27 +392,31 @@ followed by a sequence of Standard Response Blocks, each from a multicast router on the path towards the source or the RP. In the case more information is needed, a Standard Response Block can be followed by one or multiple Augmented Response Blocks. We will describe each message type in detail in the next few sections. 3.2.1. Mtrace2 Query - An Mtrace2 Query is usually originated by an Mtrace2 client which - sends an Mtrace2 Query message to the LHR. When tracing towards the - source or the RP, the intermediate routers MUST NOT modify the Query - message except the Type field. If the actual number of hops is not + An Mtrace2 Query is originated by an Mtrace2 client which sends an + Mtrace2 Query message to the LHR. The LHR modifies only the Type + field of the Query TLV (to turn it into a "Request") before appending + a Standard Response Block and forwarding it upstream. The LHR and + intermediate routers handling the Mtrace2 message when tracing + upstream MUST NOT modify any other fields within the Query/Request + TLV. Additionally, intermediate routers handling the message after + the LHR has converted the Query into a Request MUST NOT modify the + type field of the Request TLV. If the actual number of hops is not known, an Mtrace2 client could send an initial Query message with a - large # Hops (e.g., 0xffffffff), in order to try to trace the full - path. + large # Hops (e.g., 0xff), in order to try to trace the full path. An Mtrace2 Query message is shown as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | # Hops | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Address | @@ -421,20 +428,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mtrace2 Client Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query ID | Client Port # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 + Length: 16 bits + The length field MUST be either 20 (i.e., 8 plus 3 * 4 (IPv4 + addresses)) or 56 (i.e., 8 + 3 * 16 (IPv6 addresses)); if the + length is 20, then IPv4 addresses MUST be assumed and if the + length is 56, then IPv6 addresses MUST be assumed. + # Hops: 8 bits This field specifies the maximum number of hops that the Mtrace2 client wants to trace. If there are some error conditions in the middle of the path that prevent an Mtrace2 Reply from being received by the client, the client MAY issue another Mtrace2 Query with a lower number of hops until it receives a Reply. Multicast Address: 32 bits or 128 bits This field specifies an IPv4 or IPv6 address, which can be either: @@ -465,42 +477,43 @@ Query ID: 16 bits This field is used as a unique identifier for this Mtrace2 Query so that duplicate or delayed Reply messages may be detected. Client Port #: 16 bits This field specifies the destination UDP port number for receiving the Mtrace2 Reply packet. 3.2.2. Mtrace2 Request - The format of an Mtrace2 Request message is similar to an Mtrace2 - Query except the Type field is 0x02. + The Mtrace2 Request TLV is exactly the same as an Mtrace2 Query + except for identifying the Type field of 0x02. - When a LHR receives an Mtrace2 Query message, it would turn the Query - into a Request by changing the Type field of the Query from 0x01 to - 0x02. The LHR would then append an Mtrace2 Standard Response Block - (see Section 3.2.4) of its own to the Request message before sending - it upstream. The upstream routers would do the same without changing - the Type field until one of them is ready to send a Reply. + When a LHR receives an Mtrace2 Query message, it turns the Query into + a Request by changing the Type field of the Query from 0x01 to 0x02. + The LHR then appends an Mtrace2 Standard Response Block (see + Section 3.2.4) of its own to the Request message before sending it + upstream. The upstream routers do the same without changing the Type + field until one of them is ready to send a Reply. 3.2.3. Mtrace2 Reply - The format of an Mtrace2 Reply message is similar to an Mtrace2 Query - except the Type field is 0x03. + The Mtrace2 Reply TLV is exactly the same as an Mtrace2 Query except + for identifying the Type field of 0x03. - When a FHR or a RP receives an Mtrace2 Request message which is - destined to itself, it would append an Mtrace2 Standard Response - Block (see Section 3.2.4) of its own to the Request message. Next, - it would turn the Request message into a Reply by changing the Type - field of the Request from 0x02 to 0x03. The Reply message would then - be unicasted to the Mtrace2 client specified in the Mtrace2 Client - Address field. + When a FHR or an RP receives an Mtrace2 Request message which is + destined to itself, it appends an Mtrace2 Standard Response Block + (see Section 3.2.4) of its own to the Request message. Next, it + turns the Request message into a Reply by changing the Type field of + the Request from 0x02 to 0x03 and by changing the UDP destination + port to the port number specified in the Client Port number field in + the Request. It then unicasts the Reply message to the Mtrace2 + client specified in the Mtrace2 Client Address field. There are a number of cases in which an intermediate router might return a Reply before a Request reaches the FHR or the RP. See Section 4.1.1, Section 4.2.2, Section 4.3.3, and Section 4.5 for more details. 3.2.4. IPv4 Mtrace2 Standard Response Block This section describes the message format of an IPv4 Mtrace2 Standard Response Block. The Type field is 0x04. @@ -550,22 +563,26 @@ The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit NTP timestamp: query_arrival_time = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) is a reduction of ((tv.tv_nsec / 1000000000) << 16). - Note that Mtrace2 does not require all the routers on the path to - have synchronized clocks in order to measure one-way latency. + Note that synchronized clocks are required on the traced routers + to estimate propagation and queueing delays between successive + hops. Nevertheless, even without this synchronization, an + application can still estimate an upper bound on cumulative one + way latency by measuring the time between sending a Query and + receiving a Reply. Additionally, Query Arrival Time is useful for measuring the packet rate. For example, suppose that a client issues two queries, and the corresponding requests R1 and R2 arrive at router X at time T1 and T2, then the client would be able to compute the packet rate on router X by using the packet count information stored in the R1 and R2, and the time T1 and T2. Incoming Interface Address: 32 bits This field specifies the address of the interface on which packets @@ -573,25 +590,25 @@ or unnumbered. Outgoing Interface Address: 32 bits This field specifies the address of the interface on which packets from the source or the RP are expected to transmit towards the receiver, or 0 if unknown or unnumbered. This is also the address of the interface on which the Mtrace2 Query or Request arrives. Upstream Router Address: 32 bits This field specifies the address of the upstream router from which - this router expects packets from this source. This may be a + this router expects packets from this source. This MAY be a multicast group (e.g., ALL-[protocol]-ROUTERS group) if the upstream router is not known because of the workings of the - multicast routing protocol. However, it should be 0 if the - incoming interface address is unknown or unnumbered. + multicast routing protocol. However, it MUST be 0 if the incoming + interface address is unknown or unnumbered. Input packet count on incoming interface: 64 bits This field contains the number of multicast packets received for all groups and sources on the incoming interface, or all 1's if no count can be reported. This counter may have the same value as ifHCInMulticastPkts from the Interfaces Group MIB (IF-MIB) [12] for this interface. Output packet count on outgoing interface: 64 bit This field contains the number of multicast packets that have been @@ -636,24 +653,26 @@ masking the source address with the Src Mask field. Src Mask: 7 bits This field contains the number of 1's in the netmask the router has for the source (i.e. a value of 24 means the netmask is 0xffffff00). If the router is forwarding solely on group state, this field is set to 127 (0x7f). Forwarding Code: 8 bits This field contains a forwarding information/error code. Values - with the high order bit set (0x80-0xff) are intended for use as - error or exception codes. Section 4.1 and Section 4.2 explain how - and when the Forwarding Code is filled. Defined values are as - follows: + with the high order bit set (0x80-0xff) are intended for use with + conditions that are transitory or automatically recovered. Other + forwarding code values indicate a need to fix a problem in the + Query or a need to redirect the Query. Section 4.1 and + Section 4.2 explain how and when the Forwarding Code is filled. + Defined values are as follows: Value Name Description ----- -------------- ---------------------------------------------- 0x00 NO_ERROR No error 0x01 WRONG_IF Mtrace2 Request arrived on an interface to which this router would not forward for the specified group towards the source or RP. 0x02 PRUNE_SENT This router has sent a prune upstream which applies to the source and group in the Mtrace2 Request. @@ -834,32 +853,32 @@ Augmented Response Type: 16 bits This field specifies the type of various responses from a multicast router that might need to communicate back to the Mtrace2 client as well as the multicast routers on the traced path. The Augmented Response Type is defined as follows: Code Type - ==== =============================================== - 0x01 # of the returned Standard Response Blocks + ====== ============================================== + 0x0001 # of the returned Standard Response Blocks When the NO_SPACE error occurs on a router, the router should send the original Mtrace2 Request received from the downstream router as a Reply back to the Mtrace2 client and continue with a new - Mtrace2 Request. In the new Request, the router would add a - Standard Response Block followed by an Augmented Response Block - with 0x01 as the Augmented Response Type, and the number of the - returned Mtrace2 Standard Response Blocks as the Value. + Mtrace2 Request. In the new Request, the router adds a Standard + Response Block followed by an Augmented Response Block with 0x01 + as the Augmented Response Type, and the number of the returned + Mtrace2 Standard Response Blocks as the Value. - Each upstream router would recognize the total number of hops the + Each upstream router recognizes the total number of hops the Request has been traced so far by adding this number and the number of the Standard Response Block in the current Request message. This document only defines one Augmented Response Type in the Augmented Response Block. The description on how to provide diagnosis information using the Augmented Response Block is out of the scope of this document, and will be addressed in separate documents. @@ -1221,32 +1240,36 @@ Query packet to that router; otherwise, it MAY send the Mtrace2 Query packet to the all-routers multicast group (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6. This will ensure that the packet is received by the LHR on the subnet. See also Section 5.4 on determining the LHR. 5.1.2. Source Address An Mtrace2 Query MUST be sent with the client's interface address, - which would be the Mtrace2 Client Address. + which is the Mtrace2 Client Address. 5.2. Determining the Path An Mtrace2 client could send an initial Query messages with a large # Hops, in order to try to trace the full path. If this attempt fails, one strategy is to perform a linear search (as the traditional unicast traceroute program does); set the # Hops field to 1 and try to get a Reply, then 2, and so on. If no Reply is received at a - certain hop, the hop count can continue past the non-responding hop, - in the hopes that further hops may respond. These attempts should - continue until the [Mtrace Reply Timeout] timeout has occurred. + certain hop, this hop is identified as the probable cause of + forwarding failures on the path. Nevertheless, the sender may + attempt to continue tracing past the non-responding hop by further + increasing the hop count in the hopes that further hops may respond. + Each of these attempts should be initiated only after the previous + attempt has terminated either because of successful reception of a + Reply or because the [Mtrace Reply Timeout] timeout has occurred. See also Section 5.6 on receiving the results of a trace. 5.3. Collecting Statistics After a client has determined that it has traced the whole path or as much as it can expect to (see Section 5.8), it might collect statistics by waiting a short time and performing a second trace. If the path is the same in the two traces, statistics can be displayed as described in Section 7.3 and Section 7.4. @@ -1280,28 +1303,28 @@ because a failure requires waiting for the [Mtrace Reply Timeout] period. 5.7. Non-Supported Router When a non-supported router receives an Mtrace2 Query or Request message whose destination address is a multicast address, the router will silently discard the message. When the router receives an Mtrace2 Query which is destined to - itself, the router would return an Internet Control Message Protocol + itself, the router returns an Internet Control Message Protocol (ICMP) port unreachable to the Mtrace2 client. On the other hand, when the router receives an Mtrace2 Request which is destined to - itself, the router would return an ICMP port unreachable to its - adjacent router from which the Request receives. Therefore, the - Mtrace2 client needs to terminate the trace when the [Mtrace Reply - Timeout] timeout has occurred, and may then issue another Query with - a lower number of # Hops. + itself, the router returns an ICMP port unreachable to its adjacent + router from which the Request receives. Therefore, the Mtrace2 + client needs to terminate the trace when the [Mtrace Reply Timeout] + timeout has occurred, and may then issue another Query with a lower + number of # Hops. 5.8. Mtrace2 Termination When performing an expanding hop-by-hop trace, it is necessary to determine when to stop expanding. 5.8.1. Arriving at Source A trace can be determined to have arrived at the source if the Incoming Interface of the last router in the trace is non-zero, but @@ -1325,21 +1348,24 @@ (seconds), and can be manually changed on the Mtrace2 client and routers. 5.9. Continuing after an Error When the NO_SPACE error occurs, as described in Section 4.2, a router will send back an Mtrace2 Reply to the Mtrace2 client, and continue with a new Request (see Section 4.3.3). In this case, the Mtrace2 client may receive multiple Mtrace2 Replies from different routers along the path. When this happens, the client MUST treat them as a - single Mtrace2 Reply message. + single Mtrace2 Reply message by collating the augmented response + blocks of subsequent Replies sharing the same query ID, sequencing + each cluster of augmented response blocks based on the order in which + they are received. If a trace times out, it is very likely that a router in the middle of the path does not support Mtrace2. That router's address will be in the Upstream Router field of the last Standard Response Block in the last received Reply. A client may be able to determine (via mrinfo or the Simple Network Management Protocol (SNMP) [11][13]) a list of neighbors of the non-responding router. The neighbors obtained in this way could then be probed (via the multicast MIB [13]) to determine which one is the upstream neighbor (i.e., Reverse Path Forwarding (RPF) neighbor) of the non-responding router. This @@ -1472,21 +1498,21 @@ If the routers have synchronized clocks, it is possible to estimate propagation and queuing delay from the differences between the timestamps at successive hops. However, this delay includes control processing overhead, so is not necessarily indicative of the delay that data traffic would experience. 8. IANA Considerations The following new registries are to be created and maintained under - the "RFC Required" registry policy as specified in [4]. + the "Specification Required" registry policy as specified in [4]. 8.1. "Mtrace2 Forwarding Codes" Registry This is an integer in the range 0-255. Assignment of a Forwarding Code requires specification of a value and a name for the Forwarding Code. Initial values for the forwarding codes are given in the table at the end of Section 3.2.4. Additional values (specific to IPv6) may also be specified at the end of Section 3.2.5. Any additions to this registry are required to fully describe the conditions under which the new Forwarding Code is used. @@ -1510,28 +1536,31 @@ 9.1. Addresses in Mtrace2 Header An Mtrace2 header includes three addresses, source address, multicast address, and Mtrace2 client address. These addresses MUST be congruent with the definition defined in Section 3.2.1 and forwarding Mtrace2 messages having invalid addresses MUST be prohibited. For instance, if Mtrace2 Client Address specified in an Mtrace2 header is a multicast address, then a router that receives the Mtrace2 message MUST silently discard it. -9.2. Filtering of Clients +9.2. Filtering of Clients and Peers - A router SHOULD support a mechanism to filter out queries from - clients beyond a specified administrative boundary. Such a boundary + A router MUST support a mechanism to filter out Queries from clients + and Requests from peer router addresses that are unauthorized or that + are beyond a specified administrative boundary. This filtering could, for example, be specified via a list of allowed/disallowed - client addresses or subnets. If a query is received from beyond the - specified administrative boundary, the Query MUST NOT be processed. - The router MAY, however, perform rate limited logging of such events. + client and peer addresses or subnets for the Mtrace2 protocol port. + If a Query or Request is received from an unauthorized address or one + beyond the specified administrative boundary, the Query/Request MUST + NOT be processed. The router MAY, however, perform rate limited + logging of such events. 9.3. Topology Discovery Mtrace2 can be used to discover any actively-used topology. If your network topology is a secret, Mtrace2 may be restricted at the border of your domain, using the ADMIN_PROHIB forwarding code. 9.4. Characteristics of Multicast Channel Mtrace2 can be used to discover what sources are sending to what @@ -1547,37 +1576,82 @@ fairness in processing queries, or prevent traffic amplification. The rate limit is left to the router's implementation. 9.6. Limiting Reply Rates The proxying and NO_SPACE behaviors may result in one Query returning multiple Reply messages. In order to prevent abuse, the routers in the traced path MAY need to rate-limit the Replies. The rate limit function is left to the router's implementation. +9.7. Specific Security Concerns + +9.7.1. Request and Response Bombardment + + A malicious sender could generate invalid and undesirable Mtrace2 + traffic to hosts and/or routers on a network by eliciting responses + to spoofed or multicast client addresses. This could be done via + forged or multicast client/source addresses in Mtrace2 Query or + Request messages. The recommended protections against this type of + attack are described in Section 9.1, Section 9.2, Section 9.5, and + Section 9.6. + +9.7.2. Amplification Attack + + Because an Mtrace2 Query results in Mtrace2 Request and Mtrace2 Reply + messages that are larger than the original message, the potential + exists for an amplification attack from a malicious sender. This + threat is minimized by restricting the set of addresses from which + Mtrace2 messages can be received on a given router as specified in + Section 9.2. + +9.7.3. Leaking of Confidential Topology Details + + Mtrace2 Queries are a potential mechanism for obtaining confidential + topology information for a targeted network. Section 9.2 and + Section 9.4 describe required and optional methods for ensuring that + information delivered with Mtrace2 messages is not disseminated to + unauthorized hosts. + +9.7.4. Delivery of False Information + + Forged Reply messages could potentially provide a host with invalid + or incorrect topology information. This threat is mitigated by the + following factors: + + o The required filtering of permissible source addresses specified + in Section 9.2 eliminates the origination of forged Replies from + addresses that have not been authorized to send Mtrace2 messages + to routers on a given network. + + o To forge a Reply, the sender would need to somehow know the + associated two byte query ID for an extant Query and the + dynamically allocated source port number. + 10. Acknowledgements This specification started largely as a transcription of Van Jacobson's slides from the 30th IETF, and the implementation in mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original multicast traceroute client, mtrace (version 1), has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the "S" bit to allow statistics for a source subnet is due to Tom Pusateri. For the Mtrace version 2 specification, the authors would like to give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner. Also, extensive comments were received from David L. Black, Ronald Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, John - Kristoff, Mankamana Mishra, Heidi Ou, Pekka Savola, Shinsuke Suzuki, - Dave Thaler, Achmad Husni Thamrin, Stig Venaas, and Cao Wei. + Kristoff, Mankamana Mishra, Heidi Ou, Eric Rescorla, Pekka Savola, + Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, Stig Venaas, Cao + Wei, and the Mboned working group members. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, July 2017.