From steve.nash at theiet.org Mon Feb 25 16:36:40 2013 From: steve.nash at theiet.org (Steve Nash) Date: Mon, 25 Feb 2013 15:36:40 -0000 Subject: [eix-wg] RIPE EIX-WG: Attributing inbound traffic Message-ID: <009f01ce136d$e93d6140$bbb823c0$@theiet.org> Bad traffic is coming into my IX Peering interface. How do I find out where that bad traffic is coming from? How do I get it to stop? Customers of Internet Exchanges get a good deal on peering. Life is easy. Until something goes wrong. DDoS traffic starts coming into the IX interface.. I work for Arbor Networks and I have seen such questions many times. cFlow, Netflow, IPFIX can show that there is anomalous traffic arriving, but not where it is coming from (last hop). I have a suggestion and I would like to know if it is already in use, or considered of any use.. The answers are in Layer-2, of course. The MAC addresses identify which of the routers of my Peers actually transmitted a packet to my router. Problems: 1/ I could try to tap off the interface and get a packet trace, but I have to capture and identify a sample of the offending traffic, 2/ My peering router generates Netflow/IPFIX, but only populates Layer-3 data. Even if it did populate field 56 - Src MAC.. 3/ In either case I need to get into the ARP cache to figure out which IP address the MAC address belongs to.. Suggestion: Ask all IX customers to Embed the ASN into a Locally Administered MAC address on each peering interface. First byte for Local flag, second byte for interface number, others for four-byte ASN 02:00:00:00:01:00 for ASN 256 02:00:00:00:04:F9 for ASN 1273 (first interface) 02:01:00:00:04:F9 for ASN 1273 (second interface) Now, if all peers have their router interfaces configured with these Local MAC Addresses, then a customer can capture the traffic and very quickly extract the identity of each Peer that is sending packets. And peers can change their router hardware and still transmit from the same MAC address. Also, if I can get a peering Router to populate the Src MAC field of IPFIX and Netflow then I can start monitoring it all with flow reporting tools. Such MAC level encoding of ASN could be part of the peering agreement between organisations, or part of the requirement to connect to an IX RouteReflector. Even as a voluntary recommendation it could cut down the workload of identifying where traffic is coming from. I would appreciate your comments. I know that I am coming from the monitoring angle and have had few dealing with the business of an IX, so you may have tried and rejected such things. I'll be in Dublin too, if a discussion is worthwhile. Regards Steve Nash -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.pels at ams-ix.net Mon Feb 25 19:12:37 2013 From: martin.pels at ams-ix.net (Martin Pels) Date: Mon, 25 Feb 2013 19:12:37 +0100 Subject: [eix-wg] RIPE EIX-WG: Attributing inbound traffic In-Reply-To: <009f01ce136d$e93d6140$bbb823c0$@theiet.org> References: <009f01ce136d$e93d6140$bbb823c0$@theiet.org> Message-ID: <20130225191237.47f21259@fizzix> Hi Steve, On Mon, 25 Feb 2013 15:36:40 -0000 "Steve Nash" wrote: > Suggestion: > > Ask all IX customers to Embed the ASN into a Locally Administered MAC > address on each peering interface. > > First byte for Local flag, second byte for interface number, others for > four-byte ASN > > 02:00:00:00:01:00 for ASN 256 > > 02:00:00:00:04:F9 for ASN 1273 (first interface) > > 02:01:00:00:04:F9 for ASN 1273 (second interface) > > > > Now, if all peers have their router interfaces configured with these Local > MAC Addresses, then a customer can capture the traffic and very quickly > extract the identity of each Peer that is sending packets. > > And peers can change their router hardware and still transmit from the same > MAC address. On our exchange we regularly encounter issues where several customer routers misbehave in the same way. It is not uncommon that these issues are caused by a software bug on routers of a particular brand and model. Using locally administered MAC addresses means we loose the ability to narrow down problems to a particular vendor. In addition, not all routers have the configuration option to modify the MAC address on a single interface. For these routers it would not be possible to implement the scheme you propose. To focus on your problem: Several exchanges collect sFlow samples of traffic that is transmitted between customers. Of these samples the L2 header information is stored, and out of this MAC2MAC graphs can be generated. This allows the customer to see how much traffic they are receiving from each of their individual peers. In case of a DDoS it is usually very easy to determine the source peer(s) without doing any traffic capturing, simply by looking at sudden increases in traffic on these graphs. Kind regards, Martin