NAP/ISP Saturation WAS: Re: Exchanges that matter...

why even do that? i'm not sure i want you triggering security
  mechanisms on my routers. Especially with the overhead
  implications, though that is the thread we're currently in [may it
  die soon].

  building an acl that allows packets matching those you're
  interested in, and applying it to 'debug ip packet ACL detail'
  is fairly simple.

  just sit there doing 'clear ip cache A.B.C.D W.X.Y.Z'. Find
  the next hop it's coming from, trace it along, mail your
  friendly peer or transit provider, or mail your friendly hacker's
  admins.

  granted, this is limited to the domain of routers you control,
  but it's pretty effective for finding out where the syn attack is
  coming from.

  this assumes the people who are dumb enough to keep syn-ing
  continue to be stupid enough to use originating source addresses
  like 234.231.0.33.

  -alan

] > 3) Deal with it legally. This is what the telco's do. It implies that we
] > would need real mechanisms for tracking down offenders.
]
] Personally, I'd like to see a protocol that allows you to ask a
] router to which you were directly connected to stamp an interface ID on
] all incoming packets bound for a particular network. You could then trace
] back router by router, interface by interface, where the packets were
] entering a block of cooperating providers.
]
] Thus if I saw an incoming flood of SYN packets or ICMP echoes
] with forged origin addresses, I could ask my router to ask all its direct
] peers to begin stamping interface numbers (and/or interface IPs) on the
] packets they send to me. My router would eat those numbers/IPs so traffic
] would appear unaffected.
]
] Then my tracing tool would know which interface the packets were
] coming in on and could ask that router to do the same thing (on a
] hop-by-hop basis for security reasons). Thus I could track it back to a
] specific enough interface path that perhaps an automated method to
] install a filter would be sufficient.
]
] This stuff needs a lot of work, but might be a direction that
] would both facilitate emergency filtering and effective tracing for IP
] packets with forged origin addresses -- assuming the packets have enough
] in common to allow them to be detected (all pings, or heavy load, or all
] to same destination IP).
]
] David Schwartz
]

Your counter suggestion does not address the issues my suggestion
was intended to address. The primary issues I'm trying to address is:

  1) Tracking of packets with spoofed IP address should, ideally,
be automated.

  2) Tracking of packets that are or may be part of DoS attacks
should not be based upon origin IP because that can easily be forged.

  3) Tracking of malicious packets should easily cross
administrative boundaries.

  If you think I'm suggesting that implementing a plan like I
suggested is trivial or doesn't have serious privacy and/or security
implications, rest assured, I know.

  If you build a new protocol with new loopholes, people will work
around the loopholes and we'll be back where we started. I'd ideally
prefer a very solid method of tracking where packets come from. Tracing
the origin of packets you will receive anyway shouldn't have privacy
implications -- you're not supposed to be forgin origin IPs anway.

  David Schwartz

Except for one small problem, Unless you're _HUGE_ most NSP's (ie. MCI,
sprint, uunet) don't give a flying fuck and won't spend the time and
manhours it takes to track these things down. At one point one of our main
machines was being synflooded on almost every port, mci refused to do a
thing about it because it would 'take too long'.

Then sue MCI for denial of service. You will win in court because it is
trivial to show that the packets came into your network from MCI and that
MCI's employees could not and would not provide any information to you
that would indicate that these packets do not originate from MCI. Thus
they are not providing you the service that they contracted to provide.

Not everything has a technical solution.

Mind you, you might do better to be a bit more diplomatic and take up the
issue with MCI's management. Just keep in mind the basic principle that
MCI is responsible for the DoS traffic unless they are willing to identify
the source as somewhere other than MCI.

Michael Dillon - Internet & ISP Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com