draft-ietf-mboned-mtrace-v2-24.txt   draft-ietf-mboned-mtrace-v2-25.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track K. Meyer Intended status: Standards Track K. Meyer
Expires: December 21, 2018 Expires: January 26, 2019
W. Lee, Ed. W. Lee, Ed.
June 19, 2018 July 25, 2018
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-24 draft-ietf-mboned-mtrace-v2-25
Abstract Abstract
This document describes the IP multicast traceroute facility, named This document describes the IP multicast traceroute facility, named
Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
requires special implementations on the part of routers. This requires special implementations on the part of routers. This
specification describes the required functionality in multicast specification describes the required functionality in multicast
routers, as well as how an Mtrace2 client invokes a query and routers, as well as how an Mtrace2 client invokes a query and
receives a reply. receives a reply.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2018. This Internet-Draft will expire on January 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 38 skipping to change at page 3, line 38
7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32
7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32
7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 33 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 33
7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 33 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 33 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 33
8.2. "Mtrace2 TLV Types" Registry . . . . . . . . . . . . . . 34 8.2. "Mtrace2 TLV Types" Registry . . . . . . . . . . . . . . 34
8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 34 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 34 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 34
9.2. Filtering of Clients and Peers . . . . . . . . . . . . . 34 9.2. Verification of Clients and Peers . . . . . . . . . . . . 34
9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 35 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 35
9.4. Characteristics of Multicast Channel . . . . . . . . . . 35 9.4. Characteristics of Multicast Channel . . . . . . . . . . 35
9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 35 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 35
9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 35 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 36
9.7. Specific Security Concerns . . . . . . . . . . . . . . . 36 9.7. Specific Security Concerns . . . . . . . . . . . . . . . 36
9.7.1. Request and Response Bombardment . . . . . . . . . . 36 9.7.1. Request and Response Bombardment . . . . . . . . . . 36
9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 36 9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 36
9.7.3. Leaking of Confidential Topology Details . . . . . . 36 9.7.3. Leaking of Confidential Topology Details . . . . . . 36
9.7.4. Delivery of False Information (Forged Reply Messages) 36 9.7.4. Delivery of False Information (Forged Reply Messages) 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Given a multicast distribution tree, tracing hop-by-hop downstream Given a multicast distribution tree, tracing hop-by-hop downstream
from a multicast source to a given multicast receiver is difficult from a multicast source to a given multicast receiver is difficult
because there is no efficient and deterministic way to determine the because there is no efficient and deterministic way to determine the
branch of the multicast routing tree on which that receiver lies. On 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 the other hand, walking up the tree from a receiver to a source is
easy, as most existing multicast routing protocols know the upstream easy, as most existing multicast routing protocols know the upstream
skipping to change at page 22, line 45 skipping to change at page 22, line 45
Standard Response Block filled in. Standard Response Block filled in.
4.2.1. Request Packet Verification 4.2.1. Request Packet Verification
If the Mtrace2 Request does not come from an adjacent router, or if If the Mtrace2 Request does not come from an adjacent router, or if
the Request is not addressed to this router, or if the Request is the Request is not addressed to this router, or if the Request is
addressed to a multicast group which is not a link-scoped group addressed to a multicast group which is not a link-scoped group
(i.e., 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be (i.e., 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be
silently ignored. The Generalized TTL Security Mechanism (GTSM) [14] silently ignored. The Generalized TTL Security Mechanism (GTSM) [14]
SHOULD be used by the router to determine whether the router is SHOULD be used by the router to determine whether the router is
adjacent or not. adjacent or not. Source verification specified in Section 9.2 is
also considered.
If the sum of the number of the Standard Response Blocks in the If the sum of the number of the Standard Response Blocks in the
received Mtrace2 Request and the value of the Augmented Response Type received Mtrace2 Request and the value of the Augmented Response Type
of 0x01, if any, is equal or more than the # Hops in the Mtrace2 of 0x01, if any, is equal or more than the # Hops in the Mtrace2
Request, it MUST be silently ignored. Request, it MUST be silently ignored.
4.2.2. Request Normal Processing 4.2.2. Request Normal Processing
When a router receives an Mtrace2 Request message, it performs the When a router receives an Mtrace2 Request message, it performs the
following steps. Note that it is possible to have multiple following steps. Note that it is possible to have multiple
skipping to change at page 34, line 31 skipping to change at page 34, line 31
9.1. Addresses in Mtrace2 Header 9.1. Addresses in Mtrace2 Header
An Mtrace2 header includes three addresses, source address, multicast An Mtrace2 header includes three addresses, source address, multicast
address, and Mtrace2 client address. These addresses MUST be address, and Mtrace2 client address. These addresses MUST be
congruent with the definition defined in Section 3.2.1 and forwarding congruent with the definition defined in Section 3.2.1 and forwarding
Mtrace2 messages having invalid addresses MUST be prohibited. For Mtrace2 messages having invalid addresses MUST be prohibited. For
instance, if Mtrace2 Client Address specified in an Mtrace2 header is instance, if Mtrace2 Client Address specified in an Mtrace2 header is
a multicast address, then a router that receives the Mtrace2 message a multicast address, then a router that receives the Mtrace2 message
MUST silently discard it. MUST silently discard it.
9.2. Filtering of Clients and Peers 9.2. Verification of Clients and Peers
A router MUST support an access control list (ACL) mechanism to A router providing Mtrace2 functionality MUST support a source
filter out Queries from clients and Requests from peer router verification mechanism to drop Queries from clients and Requests from
addresses that are unauthorized or that are beyond a specified peer router or client addresses that are unauthorized or that are
administrative boundary. This filtering could, for example, be beyond a specified administrative boundary. This verification could,
specified via a list of allowed/disallowed client and peer addresses for example, be specified via a list of allowed/disallowed client and
or subnets for the Mtrace2 protocol port. If a Query or Request is peer addresses or subnets for a given Mtrace2 message type sent to
received from an unauthorized address or one beyond the specified the Mtrace2 protocol port. If a Query or Request is received from an
administrative boundary, the Query/Request MUST NOT be processed. unauthorized address or one beyond the specified administrative
The router MAY, however, perform rate limited logging of such events. boundary, the Query/Request MUST NOT be processed. The router MAY,
however, perform rate limited logging of such events.
The required use of ACLs on the participating routers minimizes the The required use of source verification on the participating routers
possible methods for introduction of spoofed Query/Request packets minimizes the possible methods for introduction of spoofed Query/
that would otherwise enable DoS amplification attacks targeting an Request packets that would otherwise enable DoS amplification attacks
authorized "query" host. The ACLs provide this protection by targeting an authorized "query" host. The source verification
allowing Query messages from an authorized host address to be mechanisms provide this protection by allowing Query messages from an
received only by the router(s) connected to that host, and only on authorized host address to be received only by the router(s)
the interface to which that host is attached. For protection against connected to that host, and only on the interface to which that host
spoofed Request messages, the ACLs allow requests only from a is attached. For protection against spoofed Request messages, the
directly connected peer and allow these messages to be received only source verification mechanisms allow Request messages only from a
on the interface to which that peer is attached. directly connected routing peer and allow these messages to be
received only on the interface to which that peer is attached.
Note that the following vulnerabilities cannot be covered by the ACL Note that the following vulnerabilities cannot be covered by the
methods described here. These methods can, nevertheless, prevent source verification methods described here. These methods can,
attacks launched from outside the boundaries of a given network as nevertheless, prevent attacks launched from outside the boundaries of
well as from any hosts within the network that are not on the same a given network as well as from any hosts within the network that are
LAN as an intended authorized query client. not on the same LAN as an intended authorized query client.
o A server/router "B" other than the server/router "A" that actually o A server/router "B" other than the server/router "A" that actually
"owns" a given IP address could, if it is connected to the same "owns" a given IP address could, if it is connected to the same
LAN, send an Mtrace2 Query or Request with the source address set LAN, send an Mtrace2 Query or Request with the source address set
to the address for server/router "A". This is not a significant to the address for server/router "A". This is not a significant
threat, however, if only trusted servers and routers are connected threat, however, if only trusted servers and routers are connected
to that LAN. to that LAN.
o A malicious application running on a trusted server or router o A malicious application running on a trusted server or router
could send packets that might cause an amplification problem. It could send packets that might cause an amplification problem. It
skipping to change at page 36, line 26 skipping to change at page 36, line 33
9.7.2. Amplification Attack 9.7.2. Amplification Attack
Because an Mtrace2 Query results in Mtrace2 Request and Mtrace2 Reply Because an Mtrace2 Query results in Mtrace2 Request and Mtrace2 Reply
messages that are larger than the original message, the potential messages that are larger than the original message, the potential
exists for an amplification attack from a malicious sender. This exists for an amplification attack from a malicious sender. This
threat is minimized by restricting the set of addresses from which threat is minimized by restricting the set of addresses from which
Mtrace2 messages can be received on a given router as specified in Mtrace2 messages can be received on a given router as specified in
Section 9.2. Section 9.2.
In addition, for a router running a PIM protocol (PIM-SM, PIM-DM, PIM
Source-Specific Multicast, or Bi-Directional PIM), the router SHOULD
drop any Mtrace2 Request or Reply message that is received from an IP
address that does not correspond to an authenticated PIM neighbor on
the interface from which the packet is received. The intent of this
text is to prevent non-router endpoints from injecting Request
messages. Implementations of non-PIM protocols SHOULD employ some
other mechanism to prevent this attack.
9.7.3. Leaking of Confidential Topology Details 9.7.3. Leaking of Confidential Topology Details
Mtrace2 Queries are a potential mechanism for obtaining confidential Mtrace2 Queries are a potential mechanism for obtaining confidential
topology information for a targeted network. Section 9.2 and topology information for a targeted network. Section 9.2 and
Section 9.4 describe required and optional methods for ensuring that Section 9.4 describe required and optional methods for ensuring that
information delivered with Mtrace2 messages is not disseminated to information delivered with Mtrace2 messages is not disseminated to
unauthorized hosts. unauthorized hosts.
9.7.4. Delivery of False Information (Forged Reply Messages) 9.7.4. Delivery of False Information (Forged Reply Messages)
Forged Reply messages could potentially provide a host with invalid Forged Reply messages could potentially provide a host with invalid
or incorrect topology information. They could also provide invalid or incorrect topology information. They could also provide invalid
or incorrect information regarding multicast traffic statistics, or incorrect information regarding multicast traffic statistics,
multicast stream propagation delay between hops, multicast and multicast stream propagation delay between hops, multicast and
unicast protocols in use between hops and other information used for unicast protocols in use between hops and other information used for
analyzing multicast traffic patterns and for troubleshooting analyzing multicast traffic patterns and for troubleshooting
multicast traffic problems. This threat is mitigated by the multicast traffic problems. This threat is mitigated by the
following factors: following factors:
o The required filtering of permissible source addresses specified o The required source verification of permissible source addresses
in Section 9.2 eliminates the origination of forged Replies from specified in Section 9.2 eliminates the origination of forged
addresses that have not been authorized to send Mtrace2 messages Replies from addresses that have not been authorized to send
to routers on a given network. This mechanism can block forged Mtrace2 messages to routers on a given network. This mechanism
Reply messages sent from any "off path" source. can block forged Reply messages sent from any "off path" source.
o To forge a Reply, the sender would need to somehow know (or guess) o To forge a Reply, the sender would need to somehow know (or guess)
the associated two byte Query ID for an extant Query and the the associated two byte Query ID for an extant Query and the
dynamically allocated source port number. Because "off path" dynamically allocated source port number. Because "off path"
sources can be blocked by ACLs, the scope of this threat is sources can be blocked by a source verification mechanism, the
limited to "on path" attackers. scope of this threat is limited to "on path" attackers.
o The required use of source verification (Section 9.2) and
recommended use of PIM neighbor authentication (Section 9.7.2) for
messages that are only valid when sent by a multicast routing peer
(Request and Reply messages) eliminate the possibility of
reception of a forged Reply from an authorized host address that
does not belong to a multicast peer router.
o The use of encryption between the source of a Query and the o The use of encryption between the source of a Query and the
endpoint of the trace would provide a method to protect the values endpoint of the trace would provide a method to protect the values
of the Query ID and the dynamically allocated client (source) port of the Query ID and the dynamically allocated client (source) port
(see Section 3.2.1). These are the values needed to create a (see Section 3.2.1). These are the values needed to create a
forged Reply message that would pass validity checks at the forged Reply message that would pass validity checks at the
querying client. This type of cryptographic protection is not querying client. This type of cryptographic protection is not
practical, however, because the primary reason for executing an practical, however, because the primary reason for executing an
Mtrace2 is that the destination endpoint (and path to that Mtrace2 is that the destination endpoint (and path to that
endpoint) are not known by the querying client. While it is not endpoint) are not known by the querying client. While it is not
practical to provide cryptographic protection between a client and practical to provide cryptographic protection between a client and
the Mtrace2 endpoints (destinations), it may be possible to the Mtrace2 endpoints (destinations), it may be possible to
prevent forged responses from "off path" nodes attached to any prevent forged responses from "off path" nodes attached to any
Mtrace2 transit LAN by devising a scheme to encrypt the critical Mtrace2 transit LAN by devising a scheme to encrypt the critical
portions of an Mtrace2 message between each valid sender/receiver portions of an Mtrace2 message between each valid sender/receiver
pair at each hop to be used for multicast/mtrace transit. This pair at each hop to be used for multicast/mtrace transit. The use
type of node/application authentication and authorization is, of encryption protection between nodes is, however, out of the
however, out of the scope of this document. scope of this document.
10. Acknowledgements 10. Acknowledgements
This specification started largely as a transcription of Van This specification started largely as a transcription of Van
Jacobson's slides from the 30th IETF, and the implementation in Jacobson's slides from the 30th IETF, and the implementation in
mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
multicast traceroute client, mtrace (version 1), has been implemented multicast traceroute client, mtrace (version 1), has been implemented
by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the 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 "S" bit to allow statistics for a source subnet is due to Tom
 End of changes. 16 change blocks. 
47 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/