zebra: improve display of NEXTHOP_IPV4_IFINDEX in show ip route

Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgpd, zebra: Support NEXTHOP_IPV4_IFINDEX in nexthop_lookup api

Since commit ba281d3d040, ospfd uses NEXTHOP_IPV4_IFINDEX
routes. The API between zebra and bgpd which is used to query
nexthops for recursive routes did not support this nexthop
type and therefore, ospf changes (or any other IGP changes
which use NEXTHOP_IPV4_IFINDEX) would never trigger any
recursive route update.

Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgpd, zebra: support NEXTHOP_IPV4_IFINDEX in bgp import check

Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
ospfd: protect vs. VU#229804 (malformed Router-LSA)

VU#229804 reports that, by injecting Router LSAs with the Advertising
Router ID different from the Link State ID, OSPF implementations can be
tricked into retaining and using invalid information.

Quagga is not vulnerable to this because it looks up Router LSAs by
(Router-ID, LS-ID) pair.  The relevant code is in ospf_lsa.c l.3140.
Note the double "id" parameter at the end.

Still, we can provide an improvement here by discarding such malformed
LSAs and providing a warning to the administrator.  While we cannot
prevent such malformed LSAs from entering the OSPF domain, we can
certainly try to limit their distribution.

cf. http://www.kb.cert.org/vuls/id/229804 for the vulnerability report.
This issue is a specification issue in the OSPF protocol that was
discovered by Dr. Gabi Nakibly.

Reported-by: CERT Coordination Center <cert@cert.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
doc: Update NEWS for pending 0.99.22.4 release.