Routing and security

Henrique de Moraes Holschuh hmh at hmh.eng.br
Thu Dec 5 12:38:54 CET 2013


On Tue, 03 Dec 2013, Martin Kraus wrote:
> On Tue, Dec 03, 2013 at 01:04:03PM +0100, Alessandro Brega wrote:
> >    Setup firewall (iptables) rules so that only traffic with a destination
> >    of my own IP space is accepted from other IXP participant. Drop any other
> >    traffic from IXP participants.
> 
> Hi. Implementing BCP38 on your outgoing interfaces, where you allow only ip
> packets with source ip address from your address allocation should prevent
> that and also protect others from spoofing attacks from your own network.
> 
> on the down side you'd have to process their traffic on the router or even
> route it through your internal network if your upstream is somewhere else but
> I don't think they would be pointing their static route at you for long if 
> you drop the packets in the end.

The best practice for connecting to an IXP in Brazil is to:

1. Have BCP38 and BCP46 ingress and egress filtering deployed (strict!)
2. Have paranoid filtering on the control plane (BGP)
3. Don't be shy at depeering with anyone that causes repeated issues
4. Monitor closely the routing table received from the IXP, and traffic
   levels
5. Deploy flow collection and monitoring on the IXP interface
6. Keep historical (and hysterical ;-) ) data to know the baselines and
   trends for (4) and (5).

We've seen "default gateway" and static route "transit stealing" attacks in
IXPs around here.   The IXPs have rules that allow participants to be
removed with prejudice from the IXP should they statically route packets to
others without permission, but the IXP is not going to police its L2 matrix
hunting for violators: if the victim doesn't notice and complains, such
abuse would go on unpunished and undetected.

Besides, you need all that filtering to be able to sleep in peace anyway
because the IXPs are always a few operator errors away from massive
packet-loss events (be them restricted to some routes/participants, or
IXP-wide).

There are alternatives to ingress and egress "firewall/ACL" filtering, the
most commonly used around here is strict uRPF.  However, this requires a
router (or VR instance) dedicated to interface with the IXP, *and* it causes
some incoming (good) traffic to be droped due to the lack of return routes
for that traffic inside the IXP.

As for operating the IXP itself, there are some best-practices and
operational reports published by several IXPs.  I don't have the links to
those readly available, but Google can find them reasonably easily, and
they're well worth a read.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



More information about the Bird-users mailing list