2.3.4 ICMP Traceback (itrace)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-12

Marcus Leech <mleech@nortelnetworks.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@sun.com>
Tom Taylor <taylor@nortelnetworks.com>
Mailing Lists:
General Discussion: ietf-itrace@research.att.com
To Subscribe: majordomo@research.att.com
In Body: subscribe ietf-itrace
Archive: http://www.research.att.com/lists/ietf-itrace
Description of Working Group:
It is often useful to learn the path that packets take through the Internet. This is especially important for dealing with certain denial-of-service attacks, where the source IP is forged. There are other uses as well, including path characterization and detection of asymmetric routes. There are existing tools, such as traceroute, but these generally provide the forward path, not the reverse.

We propose an ICMP Traceback message to help solve this problem. When forwarding packets, routers can, with a low probability, generate a Traceback message that is sent along to the destination. With enough Traceback messages from enough routers along the path, the traffic source and path can be determined.

The output of this group will be a standards-track RFC describing the format of such a message, along with guidelines for generation and interpretation of such messages.

Major issues to be addressed include end user privacy, the desire of some ISPs to keep their network structure proprietary, authentication of these messages, and the structure of any necessary PKI.

Goals and Milestones:
SEP 00  Submit Implementation-grade Internet-Draft
JAN 01  Submit draft to IESG for proposed standard
  • - draft-ietf-itrace-04.txt
  • No Request For Comments

    Current Meeting Report

    ITRACE Minutes
    1. Proposed Agenda:
         Introduction - 5 minutes
         Don Eastlake - XML public-key data  10 minutes
         Yamada Tatsuya - Active ITRACE      10 minutes
         Pekka Savola -                      10 minutes
                o public-key formats X.509/XML or something else
                o simplified ITRACE can we do without PK for now?
                o document nits
         Open discussion
             o existing implementation experience
             o are we missing anything truly vital?
    2.  XML public-key data
    Don ran over a set of slides that can be found at ....  He remarked that he 
    would be covering the same material in a full-day session in Boston in the 
    coming week.  In any event, the material presented may potentially be used in 
    our design of the public signature aspects of the ITrace packet.
    3.  Pekka Savola presentation
    This was moved up because Pekka had to leave early for another 
    engagement.  Pekka's slides are at ...   They contain comments on the 
    current ITrace draft.
    One of the issues raised concerned the peer address on the forward or 
    backward link.  The question is what to place in the Itrace packet when 
    this address is unknown or does not exist.  Marcus confirmed that the 
    intent from the beginning was that the address should be 
    A second issue is that the link identification is 
    ethernet-oriented.  The draft should also consider other link 
    technologies.  Marcus agreed and called for volunteers to work on this, 
    possibly in another draft.
    The third point was the question of whether the cryptographic aspects of the 
    draft were essential, or whether they could be a refinement to the basic 
    draft.  There was no real opinion on the topic, one way or the other, 
    within the room.  The question will be taken to the list.
    4.  Active Itrace Presentation
    Yamada Tatsuya presented the basic principles of active Itrace.  His 
    slides are available at ...
    The basic idea is that tracing is made more effective because it is 
    triggered by the host or network under attack.  Triggering is 
    addressed to successive routers, walking back through the chain toward the 
    source.  This differs from intention-driven Itrace, which relies on 
    flooding an intention bit via BGP to trigger packet sampling.
    5.  Recent Changes in the Draft
    Tom Taylor reviewed the changes going from -02 to -04.  His slides are 
    available at ...
    6.  General Discussion
    Marcus asked whether we should provide support for 
    intention-driven Itrace.  BGP support is a difficult issue -- the BGP 
    community may resist the proposal.  It would improve the usefulness of 
    Itrace by allowing the collector to trigger generation.  There was some 
    support for this proposal in the room.
    It was noted that the original proposal was to introduce a new 
    community attribute to BGP.  This would limit the need for router 
    We still have the problem of Itrace faking and effects on key 
    disclosure.  Unfortunately, Mikael Olsson was not available to lead 
    discussion on this point.  It will have to be dealt with on the list.
    One implementation is available, from Felix Wu (I think).  He has not yet 
    been able to obtain an ICMP number from IANA.  He is willing to make the 
    implementation available for testing with the obvious caveat that 
    packets should not be sent on the network.  Marcus mentioned that he had 
    created an implementation of the original proposal, but it would now be 
    The point was made that we need to minimize packet overhead, to 
    maximize the amount of the traced packet captured.
    Marcus raised what he viewed as the main issue: is this work worth the 
    effort, now that we know what sorts of attacks can be out there (e.g. 
    diffuse DDOS attacks)?  Itrace would be one more tool, and tools have 
    forensic usefulness, even if they are not as effective as desired.  The 
    room showed strong support for continuation of the work.
    We should be able to get this before the IESG some time before 


    None received.