Network Working Group Glenn Mansfield Keeni Internet Draft Cyber Solutions Inc. Expires: April 24, 2005 Y. Kuwata NTT-Data October 25, 2004 An Architecture for IP Packet Tracing Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" Comments on this draft should be addressed to the authors. This Internet-Draft will expire on April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Expires: April 24, 2005 [Page 1] Internet Draft October 25, 2004 Abstract This document presents an architecture for use in tracing packets across the Internet. It envisages a two-tier model wherein at the top level a Packet Tracer Application (PTA) queries relevant Autonomous System (AS) packet tracers (ASPT) with details of the packet to be traced. The PTA constructs the complete path from the responses of the queried ASPTs. At the lower level an ASPT receives queries from a PTA, traces the path of a packet within the AS and sends back the result to the PTA. Table of Contents 1. Introduction ................................................. 3 2. An Architecture for Packet Tracing ........................... 4 3. Components of the Architecture ............................... 5 4. Limitation of Scope .......................................... 6 5. Protocol Issues .............................................. 7 6. Security Considerations ...................................... 9 7. IANA Considerations .......................................... 9 8. References ................................................... 10 9. Intellectual Property ........................................ 10 10. Acknowledgements ............................................. 10 11. Authors' Addresses ........................................... 11 Full Copyright Statement ......................................... 12 Expires: April 24, 2005 [Page 2] Internet Draft October 25, 2004 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 a two- tier model. At the top level a Packet Tracer Application (PTA) queries relevant Autonomous System (AS) packet tracers (ASPT) with details of the packet to be traced. The PTA constructs the complete path from the responses of the queried ASPTs. At the next level an ASPT receives queries from a PTA, traces the path of a packet within the AS and sends back the result to the PTA. An ASPT may service queries from a management station in the AS or outside the AS. Servicing queries about the path of a packet within an AS will probably involve "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 trace the actual path of the packet in the AS. 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Expires: April 24, 2005 [Page 3] Internet Draft October 25, 2004 2. An Architecture for Packet Tracing The architecture realizes Internet Packet Tracing which does the inter-AS tracing of packets and intra-AS packet tracing that traces the packet inside an AS. 2.1 Internet Packet Tracing A Packet Tracer Application (PTA) communicates with AS packet tracers (ASPT) in one or more ASes and constructs the path of the packet over the Internet from the results. +-----------+ | | | Packet | | Tracer | |Application| | (PTA) | +-----+-----+ / | \ / | \ / | \ / | \ / | \ AS1 / ASi| \ ASn | +------+-----+ | | | | +---V---+ | | | ASPT | | | +-------+ | | | | | +------------+ Fig. 1. Internet packet Tracing 2.2 Intra-AS Packet Tracing The intra-AS 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 Expires: April 24, 2005 [Page 4] Internet Draft October 25, 2004 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. +-----------+ (Query Key) +-----------------+ | Packet | <------- Query ------------- | AS Packet Tracer| | record | | (ASPT) | | agent(PRA)| ------- Response ----------> | | +-----+-----+ (Supplementary Information) +-----------------+ | | /-----V-----\ | Packet | | Record | | Base(PRB)| \-----+-----/ | | | +-----+-----+ | Packet | | Monitor | | | +-----------+ Fig. 2. Intra-AS packet tracing 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 Expires: April 24, 2005 [Page 5] Internet Draft October 25, 2004 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 back a positive response alongwith supplementary information, if any, corresponding to the Query Key, to the ASPT. 3.4 AS Packet Tracer Application (ASPT): This is the entity that is works within an AS, has knowledge about the the packet tracing infrastructure and configuration within the AS and has access to the other packet tracing components in the AS. It receives a request from a Packet Tracing application along with details of the packet that needs to be traced, 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. 3.5 Packet Tracer Application (PTA): This is the entity that is interested in tracing the path traversed by an IP datagram. It needs to have the minimal knowledge of the network topology to know which ASPTs need to be queried and in what sequence. The PTA attempts to determine the path of the packet from the response it receives from the ASPTs. 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 AS Packet Tracers it should query. The AS Packet Tracer application (ASPT) on the other hand (PTA) needs to know which Packet Record Agent it should query. How the PTA or the ASPT knows this information is outside the scope of the architecture presented in this document. The ASPT and the PTA also need to employ some algorithm to reconstruct the path of the packet using the information obtained from the PRAs and the ASPTs, respectively. The details of how this is done is outside the scope of the present architecture. Expires: April 24, 2005 [Page 6] Internet Draft October 25, 2004 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. 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 intra-AS communication protocol(IASCP): It is necessary to have a standard protocol for communicating between an ASPT and a PRA. The basic communication between the AS Packet Tracer 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 intra-AS Communication Protocol must provide for mechanisms that will allow the Packet Tracer Application and Packet Record Agent to authenticate each other. Expires: April 24, 2005 [Page 7] Internet Draft October 25, 2004 5.2.2 The intra-AS Communication Protocol should provide for mechanisms that will allow the Packet Tracer Application and the Packet Record Agent to ensure non-repudiation. 5.2.3 The intra-AS Communication Protocol must provide for mechanisms that will allow the Packet Tracer Application to query the Packet Record Agent about the elements of the Packet Record Protocol employed by the Packet Monitor. 5.3 The inter-AS communication protocol(ICP): It is necessary to have a standard protocol for communicating between a PTA and an ASPT. The basic communication between the Packet Tracer Application and the AS Packet Tracer is of a simple query response pattern. It does not involve long conversations or data transfers. But it will include the verifiable credentials of the PTA. The requirements for this communication are that it should be efficient and secure. 5.3.1 The inter-AS Communication Protocol must provide for mechanisms that will allow the Packet Tracer Application and AS Packet Tracer to authenticate each other. 5.3.2 The inter-AS Communication Protocol must provide for mechanisms that that will allow the Packet Tracer Application and the AS Packet Tracer to ensure non-repudiation. 5.4 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 SNMP [RFC 3410] 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: April 24, 2005 [Page 8] Internet Draft October 25, 2004 6. 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. 7. IANA Considerations This document has no actions for IANA. Expires: April 24, 2005 [Page 9] Internet Draft October 25, 2004 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. 8.2 Informative References [IPPT] Partridge, C., Jones, C., Waltzman, D., Snoeren, A., BBN Technologies, "New Protocols to Support Internet Traceback", work in progress (currently ) [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 9. 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. 10. 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: April 24, 2005 [Page 10] Internet Draft October 25, 2004 11. 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: April 24, 2005 [Page 11] Internet Draft October 25, 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Expires: April 24, 2005 [Page 12] Internet Draft October 25, 2004 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 currently provided by the Internet Society. Expires: April 24, 2005 [Page 13] Internet Draft October 25, 2004 Expires: April 24, 2005 [Page 14]