Network Working Group Glenn Mansfield Keeni Internet Draft Cyber Solutions Inc. Expires: February 6, 2003 Y. Kuwata NTT-Data September 7, 2002 An Architecture for IP Packet Tracing Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 February 6, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Expires: February 6, 2003 [Page 1] Internet Draft September 7, 2002 Abstract This document presents an architecture for use in packet tracing. Table of Contents 1. Introduction .................................................. 3 2. An Architecture for Packet Tracing ............................ 3 3. Components of the Architecture ................................ 4 4. Limitation of Scope ........................................... 5 5. Protocol Issues ............................................... 5 6. Intellectual Property ......................................... 7 7. Acknowledgements .............................................. 6 References ........................................................ 8 Security Considerations ........................................... 8 Authors' Addresses ................................................ 8 Full Copyright Statement .......................................... 9 Expires: February 6, 2003 [Page 2] Internet Draft September 7, 2002 1. Introduction The route of an IP datagram is of great interest for Internet operations and security. But, determining the route an IP datagram has taken is a difficult problem. If the source address of a datagram is known, the path of the packet may be "traced", but since routing happens dynamically in the Internet the "trace" that is obtained is generally one of the possible paths an IP datagram will take. This problem is further compounded by the fact that the source addresses in IP datagrams can be "spoofed". In such cases the packet itself does not contain any clue about the path it has taken. A mechanism for tracing the path of IP datagrams will involve maintaining "monitors" at several observation points on the network. Each monitor will maintain a record of every datagram it "sees". An agent that has access to the records maintained by a monitor can say with reasonable accuracy whether a particular IP datagram was actually seen at the point in the network that is monitored by the monitor. Given sufficient number of monitors it may be possible to track the actual path of the packet along the network. The granularity of the path (in terms of network hops) will depend on the number of monitors available along the path. It must be noted that the above mechanism works only if the invariant part of the IP datagram is used to generate the record. The IP- protocol requires that, at each network hop the time-to-live of the IP datagram is decremented by 1 and the header checksum is recomputed. Moreover, some of the flags and options may be changed too. IP datagrams may also have their source and/or destination addresses changed as they traverse NAT-routers. This document describes an architecture for tracing IP datagrams across the Internet. 2. An Architecture for Packet Tracing. The packet tracing architecture comprises of Packet Monitors, Packet Record Bases, Packet Record Agents, and Packet Tracer Applications. The Packet Monitor maintains a record of each IP datagram "seen" at the point of observation. The collection of these records constitutes the Packet Record Base (PRB). A PRB is served by a Packet Record Agent (PRA). On receiving a query from a Packet Tracer Application (PTA) about a particular IP datagram, the PRA refers to the records in its PRB to determine whether the IP datagram was "seen" at the point of observation by the monitor that is maintaining the PRB. Expires: February 6, 2003 [Page 3] Internet Draft September 7, 2002 +-----------+ (Query Key) +-----------------+ | Packet | <------- Query ------------- | Packet Tracer | | record | | Application(PTA)| | agent(PRA)| ------- Response ----------> | | +-----+-----+ (Supplementary Information) +-----------------+ | | /-----V-----\ | Packet | | Record | | Base(PRB)| \-----+-----/ | | | +-----+-----+ | Packet | | Monitor | | | +-----------+ Fig. 1. Packet tracing architecture. 3. Components of the Architecture. 3.1 Packet Monitor(PM): These are entities responsible for monitoring the IP datagrams at a specific point in the network. A monitor may be built into a router or it may be a passive device that watches all the traffic traversing the point of observation. 3.2 Packet Record Base(PRB): A Packet Monitor maintains a record for each IP datagram that it "sees", in the Packet Record Base. A primary requirement is that the contents and format of a Packet Record in the PRB must be sufficient to determine whether a record for a particular IP datagram exists in the PRB, or not. In general a Packet Record will be a transform of the packet. In the simplest case it will be a null transform. In other cases it will be a non-null transform (hash/digest) of a part or all of the packet with some parts of the packet masked. Supplementary information pertaining to the packet e.g. time-to-live, timestamp, etc. may be stored in the PRB. 3.3 Packet Record Agent(PRA): These are entities that respond to queries about IP datagrams. The Packet Record Agent accepts a Query Key, carries out the appropriate transforms, if any, to generate the corresponding Packet Record. It then refers to the Packet Records in the PRB to determine if a record for the IP datagram exists or not. If a Packet Record is found, the PRA sends Expires: February 6, 2003 [Page 4] Internet Draft September 7, 2002 back a positive response alongwith supplementary information, if any, corresponding to the Query Key, to the PTA. 3.4 Packet Tracer Application (PTA): This is the entity that is interested in tracing the path traversed by an IP datagram. It applies the appropriate transforms, if any, to the IP datagram to generate the Query Key. The PTA then queries one or more Packet Record Agents to check if Packet Records corresponding to the Query Key exists in their respective Packet Record Bases.If an agent replies that no record exists for the IP datagram then the Packet Tracer Application determines that the IP datagram was not observed at the observation point corresponding to the PRB of the PRA. 4. Limitation of scope. In attempting to address the problem of tracing the paths of packets across the internet a conscious effort has been made to keep the architecture simple. The Packet Tracer Application (PTA) needs to know which Packet Record Agent it should query. How the PTA knows this information is outside the scope of the architecture presented in this document. The tracing application also needs to employ some algorithm to reconstruct the path of the packet using the information obtained from the Packet Record Agents. The details of how this is done is outside the scope of the present architecture. 5. Protocol Issues. The IP datagram traceback may happen on small, medium or large networks. It may span several networks and/or political and geographical domains. The Internet is heterogeneous in nature and the views and requirements of the participating entities are diverse. (There is also a total lack of experience with traceback mechanisms). In this context the protocol that will be used for the traceback should be simple and at the same time flexible. In the following we discuss the basic protocol issues. 5.1 The Packet Record Protocol: The Packet Monitor maintains a record for each IP-datagram it observes. The exact details and format may differ between systems. In some cases the entire packet may be recorded, in other cases some transform of the datagram may be recorded. The Packet Record Protocol will define the following. 5.1.1 The type of transform used by the Packet Monitor to generate a record of an IP-datagram. Expires: February 6, 2003 [Page 5] Internet Draft September 7, 2002 5.1.2 The attributes of the Packet Record Base - e.g. its size, the time span of the present packet records, etc. 5.1.3 The primary contents of the Packet Record Base: the primary requirement of the contents of the packet record is that when presented with the appropriate details of an IP datagram (the Query Key) it should be possible for the Packet Record Agent to refer to the Packet Record Base and say whether a record for the IP-datagram exists or not. 5.1.4 The supplementary information of the Packet Record Base: Other information that may be helpful in (confirming and/or corroborating) the tracking information. For example the time-to-live value, the timestamp of the packet etc. 5.2 The communication protocol: It is necessary to have a standard protocol for communicating between the Packet Tracker Application and the Packet Record Agent. The basic communication between the Packet Tracker Application and the Packet Record Agent is of a simple query response pattern. It does not involve long conversations or data transfers. The requirements for this communication are that it should be efficient and secure. 5.2.1 The Communication Protocol must provide for mechanisms that will allow the Packet Tracker Application and Packet Record Agent to authenticate each other. 5.2.2 The Communication Protocol should provide for mechanisms that will allow the Packet Tracker Application and the Packet Record Agent to ensure non-repudiation. 5.2.3 The Communication Protocol must provide for mechanisms that will allow the Packet Tracker Application to query the Packet Record Agent about the elements of the Packet Record Protocol employed by the Packet Monitor. 5.3 The monitoring and control protocol: The elements in the packet trace architecture need to be monitored and controlled. The Internet standard protocol for network management SNMPv3 [3] can be used to monitor and control the elements in a secure manner. An appropriate Management Information Base (MIB) needs to be designed to meet the specific requirements of the packet tracing architecture. Expires: February 6, 2003 [Page 6] Internet Draft September 7, 2002 6. Intellectual Property Some of the concepts and ideas discussed in this draft are the subject of pending patent applications by NTT-Data, Japan and Cyber Solutions Inc. Japan. 7. Acknowledgments. Several persons have actively contributed to the ideas in this document. The discussions at the WIDE-NetMan-WG have had significant impact on the ideas in this document. Expires: February 6, 2003 [Page 7] Internet Draft September 7, 2002 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Partridge, C., Jones, C., Waltzman, D., Snoeren, A., BBN Technologies, New Protocols to Support Internet Traceback, Work In Progress http://www.ietf.org/internet-drafts/draft-partridge-ippt-discuss-00,txt [3] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 Security Considerations This does not describe a protocol by itself it describes the architecture for tracing packets across the Internet. The architecture does not preclude the use of packets for tracing the paths of the packets. This has security implications and must be dealt with care. Including the packet itself as data in the query is not a recommended practice. The architecture does not preclude the use of maintaining full records of packets - this has privacy and security implications. This is not a recommended practice and if employed should be used with great care and deliberation. Query and the results may have serious security implications. To ensure safety, the authentication and non-repudiation mechanisms should be used. Authors' Addresses Glenn Mansfield Keeni Cyber Solutions Inc. Sendai Japan EMail: glenn@cysols.com Yoshitaka Kuwata NTT-Data, Tokyo Japan Email: kuwatay@nttdata.co.jp Expires: February 6, 2003 [Page 8] Internet Draft September 7, 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires: February 6, 2003 [Page 9]