On Thu, 24 Feb 2000, Crispin Cowan wrote: > > Out-of-band control channels, > > This doesn't defend against DDoS attacks that are data requests instead of control > packets. It does if the control channel ensures that only valid data gets to the target. While routing information is in-band, data attacks are easier to do. Once control and routing information come out of band, it's possible to limit data to authenticated nodes, appropriately tagged frames at the link layer, etc. This is an extension of the "marker dye" stuff that some people have been playing with in ATM clouds to trace packets out of band. > > end-to-end QoS, > > Also won't stop attackers from flooding your pipe with requests. In fact, it may > make it worse, as the attackers could spoof data requests that result in QoS > bandwidth allocations to spoofed clients, further choking the server's bandwidth. > QoS will have to be carefully tied to authentication, or else it just makes DDoS much > worse. If it's end-to-end and it's not in-band, then how will the data even be able to request any service, let along high-bandwidth service? With control nodes in the middle you start to get to a controlled network fairly quickly. My definition of end to end is that everyone participates in the QoS negotiation, including the destination- either directly, or through their upstream's connectivity arrangements. > > traffic flow-based routing/flood control protocols, > > I don't think I understand this proposal. Intermediate routers can tag every N packets to a destination that's from the last hop and roll squelching that traffic down by null0-ing packets over a certain threshold. The window slides upstream, hop-by-hop until you hit the edge router doing the control process. With enough intercooperation, it places the bandwidth issue right at the host network's boundary. I'm sure I've partially misrepresented it, since I've seen a bunch of close or similar proposals recently. > > > authenticated gatewaying and/or redirection, authenticated routing, > > All the authentication schemes have two problems: > > * you need a global PKI that works for everyone, which is, er, problematic :-) No you don't. BGP4 works pretty will without PKI. OSPF works well with private keys. You're fogetting that exchanging traffic (creating peering relationships) doesn't have to happen at every node, and is already controlled. > * it does not stop an attacker from flooding a machine with packets that fail > authentication. Authenicated routing moves the probelm up-stream, which only > helps somewhat If you authenticate at the closest gateway to the user, the flood won't transit the interconnect, and therefore remains a local customer problem which is rather easily solved. Also, end-to-end authentication with proxy authentication at gateways and borders negates a global trust scheme. > > > slow-start egress routing, > > This needs to be globally deployed to be effective. It is more or less equivalent to > saying "secure all Internet nodes", because the attacker could compromise an inside > node, and use it to change the egress filtering policy. Routers tend to be easier to secure than hosts, and it can be a routing policy issue, not a host network issue (though I'm sure that there are those who would wish to move it to the host.) > > upstream artificial clocking, > > I don't understand this proposal. Instead of slow-start traffic flooding, clock outbound packets based on a peering arrangement to your downstream routing nodes. The backbones are the logical change point to me for this, and like going to BGP4, it'll hurt some, but it's still mostly-managble. I don't think getting hosts to play nicely is realistic in this decade, but perhaps with some V4-toV6 gatewaying the performance difference would make it worth persuing for the majority. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions probertsat_private which may have no basis whatsoever in fact." PSB#9280
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:08:16 PDT