North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: !white.house, !panacea, new traceback paper from stefan savage

  • From: John Hawkinson
  • Date: Tue Feb 15 11:42:33 2000

> > new relevant paper worth checking out by stefan savage et al 
> >   
> >   	http://www.cs.washington.edu/homes/savage/traceback.html
> 
> This is definately a must read.

I'd concur.

> The idea is to mark packets with path information so that after you have
> recieved enough packets from a given source you can determine all of the
> routers it passed through.

It's important to state the operational impact here, which the paper
doesn't do very clearly in the abstract or the front matter, and I think
that's suboptimal structuring -- marking the packets is done by
placing localtional information in the ip_id field of the packet.

Quoting from my response to the authors and my inquiry cisco about
implementation feasability:

    a) I don't like it because I must be the sole person (ok, ok, blatant
    exaggeration) in the universe who likes to use the ip_id field of ip
    packets as a debugging key when looking at packet traces; ip_id is
    typically monotonically increasing and a great way to check duplicates,
    etc., etc.

    b) It marks packets and marking packets is Bad and reduces the
    cleanliness of the model.

    c) Nevertheless, it seems like this could be an incredibly valuable tool
    for doing tracebacks, and despite the recent focus of the community on
    distributed denial-of-service attacks, the ability to do this sort of
    traceback between multiple providers without involving provider personnel
    in each "AS island" is much-needed.

    d) I think that c) almost certainly outweighs b) and a) in terms of
    operational necessity.

    e) There exists an argument that states that even with distributed
    denial of service attacks the ability to trace individual ones remains
    quite valuable. I don't want to go into it here right now.

I also suggest 2 minor modifications to the model:

    i) Triggering this behavior off of a bgp community (opt-in and opt-out
    variants.

    ii) Allowing last-hop routers to collect this information instead of merely
    allowing the targetted hosts to collect it.

--jhawk