[mat-wg] [MAT-WG]: Attributing inbound traffic from an IX

[This email has also gone to the EIX-WG ]

 

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'll be in Dublin too, if a discussion is worthwhile.

 

Regards

Steve Nash

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/mat-wg/attachments/20130225/4f0a3c5d/attachment.html>