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

[Tim Kleefass <[e-mail]>]

Hi there,

Some comments and thoughts.

* next-hop filtering possible

(If had sent this only to the authors, but maybe the list is also
interested.)

Regarding Section 9.  Next-Hop Filtering

With IOS XR one can match the next-hop in a route-policy (but I have
never used it, so no real-life experience):

Example on Cisco ASR 9000, IOS XR 4.1.1:

route-policy test
  if not next-hop in (192.0.2.1) then
    drop
  endif
  ...
end-policy

One can also state a prefix-list instead a single IPv4/IPv6 address.  So
this could by an alternative to setting the next-hop by hard.

This could be interesting if you have on an IXP two peering sessions to
the same ISP and want to allow this ISP to play with the next-hop.

Or you could apply an prefix-list to the peering with the route-server
of an IXP to make sure that through this peerings only valid next-hops
are announced.  But probably one trusts this route-servers and such a
setup would be overkill...


* About route flap dampening

"""
6.  BGP route flap dampening

   BGP route flap dampening mechanism makes it possible to give
   penalties to routes each time they change in the BGP routing table.
   Initially this mechanism was created to protect the entire internet
   from multiple events impacting a single network.  RIPE community now
   recommends not using BGP route flap dampening [20].  Author of this
   document proposes to follow the proposal of the RIPE community.
"""

On that topic there are some "updates" at the RIPE-64:

  Randy Bush, Route Flap Damping Considered Usable @ RIPE-64
  https://ripe64.ripe.net/presentations/136-120418.ripe-rfd.pdf
  https://ripe64.ripe.net/archives/video/80

  [routing-wg] Route flap damping considered usable
  http://www.ripe.net/ripe/mail/archives/routing-wg/2012-July/002163.html

So maybe the recommendation of the RIPE community will change in the
future...


* stable eBGP announcement

Talking about route flap dampening, it could be a good idea to prevent
routes from flapping in the first place and I haven't seen that in the
draft (the focus is on security, but as route flap dampening is named...).
If you are the origin of a prefix you want to announce that prefix in a
very stable way.  For example, if you are stub, configure on two router
a null-route for that prefix and inject it into BGP.

There are also situations where an ISP can help stub customers with an
stable eBGP announcement.  We have several single-homed customers
(customers that are only connected to us and no other ISP).  These
customers have their own IPv4 (legacy) space.  In the RIPE region the
requirement for IPv6 PI space to be at least dual-homed was canceled.
So there could also be single-homed customers with an own IPv6 space.

Such customers are connected to us with static routes (then we put their
prefix in BGP) or via BGP (and private AS numbers; which we strip before
announcing to others).  For them we put a "backup null-route" on two of
our core routers, so that if the connection to the customer fails we
still have a route to the prefix and the prefix is injected into BGP and
announced into the Internet.

Example on Cisco ASR 9000, IOS XR 4.1.1:

router static
 address-family ipv4 unicast
  192.0.2.0/24 Null0 240
  !                  ^^^ administrative distance of 240
  !                      higher than OSPF and BGP
 !
!
router bgp 553
 address-family ipv4 unicast
  ! BelWue
  network 192.0.2.0/24 route-policy ebgp-null-route
  !                    ^^ the route-policy sets (only) a community
 !
!


* private AS numbers

In Section 8.  AS-path filtering

"""
   o  Do not advertise private AS numbers.  Exception: Customers using
      BGP without having their own AS number must use private AS numbers
      to advertise their prefixes to their upstream.  The private AS
      number is usually provided by the upstream.
"""

An then strip the private AS number before announcing that prefix to
others ISPs.


Cheers,
	Tim