Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

[Eric C Rosen <[e-mail]>]

While I think a BGP neighbor auto-discovery protocol would be useful in 
certain scenarios, I don't think the WG should adopt this document at 
the current time.

There is so much overlap with the idr-lldp-peer-discovery draft that I 
don't see how the WG could adopt both of them.  The 
idr-neighbor-autodiscovery draft thus should not be adopted unless the 
intention is to reject the idr-lldp-peer discovery draft. Is that the 
intention?  I don't recall seeing much discussion comparing and 
contrasting the two.

For neighbor auto-discovery, I'd think that the biggest issue by far 
would be security.  All this draft really suggests about security is 
"don't use this in any environment where it is possible for the Hellos 
to be spoofed".   A somewhat more detailed set of applicability 
restrictions would seem to be warraned.

The draft does propose to use the Generalized TTL Security Mechanism on 
the BGP sessions established as a result of receiving Hellos, but 
doesn't seem to suggest using the GTSM on the Hellos themselves. Either 
way, whether GTSM actually provides any signficant amount of security 
would have to be examined.

Even if there's no need for security in DC networks, what will happen 
when someone uses this to auto-discover neighbors on, e.g., an EVPN 
Broadcast Domain or other overlay.  Also, someone will want to use 
scoped IP multicast to allow the Hellos go to several hops, in order to 
auto-discover multi-hop EBGP peers.  (Compare to Targeted LDP Hellos.)  
Are these possible use cases supposed to be prohibited?  How?  Is there 
even an analysis of DC networking security needs?

I'm a little surprised to see LDP Hellos held up as model of something 
that is proven to work well.  In LDP, the Hello stuff is really a major 
complication (one might even say "a big mess"), because you have both 
"Hello adjacencies" and "session adjacencies", and you have to handle 
all the possible interactions between them. At least the LDP Hello stuff 
is an integral part of the LDP state machine; this sort of relationship 
between state machines is not really discussed in the 
idr-neighbor-autodiscovery draft.

LDP Hellos are also a known security problem (especially, but not only, 
when targeted to non-neighboring nodes).  In fact Targeted LDP Hellos 
provide no value other than to create an attack vector. However, it is 
hard to remove the Targeted Hellos because the Hello mechanism is such 
an integral part of the LDP state machine.  We should make sure we don't 
drive BGP down the same road.

The competition between BGP keepalives and periodic Hellos for deciding 
whether to bring the session down is also a potential source of problems 
that needs to be discussed.

It is interesting that routes are automatically created due to receipt 
of Hellos.  But the talk of giving these routes a smaller admin distance 
than certain other routes is a bit scary.  Attempts to adjust the admin 
distance never seem to work quite right, and frequently have unintended 
side-effects.  Also, there's very little protection against having 
several mechanisms that each create routes under the assumption that 
their own routes will have a smaller admin distance than any other.

I'm surprised to see the Hellos carrying a list of ASNs from which the 
transmitter will accept connections.  Isn't that a little like saying "I 
won't let you log in unless you type one of the following passwords"?

Something needs to be said about interaction with existing BGP security 
measures (TCP-MD5), such as they are.

My take on Sue's questions would be:

> 1) Does BGP need to have an autodiscovery mechanism for peers within Data 
Centers?

An autodiscovery mechanism certainly seems useful.  However, its use 
needs to be carefully restricted, and the applicability restrictions 
needs to be very clearly stated.

 > 2) Does this mechanism work for other deployments?

Unknown.  It's somewhat surprising that this issue is not even addressed 
in the draft.

 >3) If so, should be passed in BGP Hello message?  Or should it be a 
part of another protocol (e.g. LLDP, BFD, etc).

Unknown.  It's somewhat surprising that this issue is not even addressed 
in the draft.

BTW, it's not at all clear whether the "BGP Hello" mechanism can be 
regarded as part of the BGP protocol.  It seems like a brand new 
UDP-based mechanism, and adding it doesn't seem to be any simpler than 
adding a more generic neighbor discovery protocol.

In the DC, one could also ask whether whatever procedure is used to tell 
a node what its IP address is should not also be used to tell it who its 
BGP neighbors are.

 > 4)Does this interact with any of the LSVR work?

Unknown.  It's somewhat surprising that this issue is not even addressed 
in the draft.

I think more work needs to be done on the draft before we can really 
evaluate whether it is a good basis for future work.