Internet DRAFT - draft-glenn-ippt-arch
draft-glenn-ippt-arch
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
<draft-glenn-ippt-arch-01.txt>
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
<draft-partridge-ippt-discuss-00,txt>)
[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]
