[pim] Replacing unicast BSMs with multicast

[Stig Venaas <stig.venaas at uninett.no>]

It has been proposed to replace unicast BSMs with multicast.  I would 
like to try to get some discussion around this to see if we can agree on 
some solution.

Unicast BSMs are sent by DR on a link when a new PIM neighbour comes up. 
Their sole purpose is to let the new neighbour learn the RP-set without 
waiting for the next periodic BSM originated by the BSR.

There is another thread where we've been discussing forwarding of 
unicast BSMs, and it seems we have consensus that it should be optional 
to do that. If we choose to replace unicast BSMs with multicast as 
described below, we would still have exactly the same semantics. I.e., 
the multicast replacement would be sent exactly when unicast BSM would 
be sent, and optionally the contents of the multicast BSM can be forwarded.

1. Current unicast BSM behaviour

I will try to go through the places in the current BSR draft where 
unicast BSM behaviour differs from the normal multicast one. Note that 
RFC 2362 is generally the same, but there are some differences.

In section 3.1.3 on BSM processing checks we have:

if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
  if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
    drop the Bootstrap message silently
  }
} else if (BSM.dst_ip_address is my primary address on the interface) {
  if ((any previous BSM for this scope has been accepted) OR
      (more than BS_Period has elapsed since startup)) {
    #the packet was unicast, but this wasn't
    #a quick refresh on startup
    drop the Bootstrap message silently
  }
} else {
  drop the Bootstrap message silently
}

So as you can see, a separate test is needed for the unicast destination 
address, and unicast BSMs should only be accepted right after startup. 
To only accept first BSM for a scope seems simple enough, but it's not 
so easy if there is semantic fragmentation of the BSM.

The unicast BSM is defined in 3.5 where it also says:

Before unicasting a Bootstrap message in this manner, the DR must wait
until it has sent a triggered Hello message on this interface;
otherwise, the new neighbor will discard the Bootstrap message.

The more interesting part is perhaps the security considerations. 
Section 6.3.1 talks about the use of Router Alert to prevent the 
possibility of unicast BSMs travelling multiple hops. It also talks 
about how to turn off this for backwards compatibility. RA is new since 
RFC 2362, and I know several implementations not using it (actually, I 
don't know any that do use it, but I haven't checked that many).

At the last wg meeting we agreed that we could manage without RAs. But 
to have the same level of security, we then may need some trick like 
setting ttl to 255 on unicast BSMs where the receiver can also check 
that ttl is 255. There would be issues with backwards compatibility 
here, since current implementations would send with ttl 1.

2. Issues with unicast BSMs

The main issue I see with unicast BSMs, is the added complexity as 
described above in order to limit when to accept them, and to prevent 
unicast BSMs from travelling multiple hops, e.g. from some attacker 
outside the network to a restarting router inside the network.

Another issue is that RPF can't be used because the the restarting 
router often will not have complete routing information until after it 
has received the unicast BSM.

One well known router vendor has the issue that a unicast BSM would be 
discarded by the originating router if no ARP cache entry exists for the 
destination unicast address. The newly restarted neighbour (or new 
neighbour) will often not have an entry in the ARP cache. I don't know 
whether this problem is unique or if other vendors have it as well.

3. Replacing unicast BSMs with multicast BSMs

It's been proposed to always use multicast BSMs in the new
draft. The proposal of John Z. and Dino is as follows:

The proposal is to add a flag bit to BSMs. The flag would mean,
don't do RPF and don't forward. BSMs that today are multicast
would have the flag cleared, while BSMs that today are unicast
would be multicast with this flag set. The flag bit would come from the 
existing reserved field in the beginning of the BSM.

In this way one would get the exact same behaviour as unicast BSMs
today, but with several advantages. First of all, the security
concerns regarding unicast BSMs travelling multiple hops are gone. We 
don't need RAs or ttl of 255 or other tricks, and no special rules for 
checking the destination address. The rules would be exactly like other 
multicast PIM (including BSMs) messages. It also solves the ARP issue 
mentioned above.

4. Backwards compatibility

There is one issue with replacing unicast BSMs, and that is backwards 
compatibility. But first, note that if one is to secure unicast BSMs by 
using TTL 255 as there appeared to be consensus for at the WG meeting, 
then there would also be backwards compatibility issues. There would 
also be some backwards compatibility issues with using Router Alerts.

Let's look at a couple of scenarios. First we'll look at DR using
current specifications, and a restarting router using the proposed
multicast replacement. In this case, the restarting router would
receive a unicast BSM, provided the DR supports unicast BSMs, but
this would be ignored. The restarting router would then have to
wait for the periodic BSM. An implementation could possibly choose
to also accept unicast BSMs for backwards compatibility.

The other case is a DR using the proposed multicast replacement,
and the restarting router implementing current specs. The restarting 
router would never get a unicast BSM. When receiving a multicast BSM 
with this flag set, the flag would be ignored. It would perform RPF, 
which is likely to fail since it in many cases have not yet learnt a 
route for the BSR address, and the DR may not be the RPF neighbour. If 
this fails, it will have to wait for the periodic BSM. If RPF succeeds, 
it will get the RP configuration just as for unicast BSMs, however, the 
BSM would also be forwarded which may not be desired. This forwarding 
would be just like the forwarding of unicast BSMs today.

A vendor caring about backwards compatibility, could have an 
configuration option allowing sending/receiving of unicast BSMs in
addition to the proposed multicast BSM replacement.

This summarises my thinking regarding replacing unicast BSMs, and I 
would like to hear your thoughts.

Stig

_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim