[OPSEC] Comments on draft-jdurand-bgp-security-02

[David Freedman <[e-mail]>]

Sec 9.  Next-Hop Filtering

>In direct peerings between ISPs, this is undesirable,
>peers could trick the other one to send packets into
>a black hole

Trick? I think I would want to do this in particular
circumstances, when there is a DoS ongoing.
(yes, I'm aware there are community approaches, these
aren't widely adopted, this technique works for many
networks now and is quite invaluable to preserve).

What I wouldn't want however is for a peer to set a
next-hop as something internal to my network (I.e an
internal endpoint) which could enable them to manipulate
internal traffic (say, to steal a service by causing me to
route it internally).

>Therefore, the authors recommend to, by default, apply an inbound
>route policy to IXP peerings which sets the next-hop for accepted
>prefixes to the BGP peer that sent the prefix (which is what "next-
>hop-self" would enforce on the sending side, but you can not rely on
>the other party to always send correct information).

I'm not aware of any implementations which can achieve
this in a scalable way, are the authors? at present I
would have to statically configure a next hop for each peer,
not fun.

Also, are you aware that some networks inject the IXP
LAN into their IGP for the purposes of TE? (I.e leaving
the IXP LAN next hop present in their iBGP and then
doing MPLS TE on this LAN as opposed to next-hop-self
on the border where all peering networks are collapsed
into a single loopback)

Dave.