Subject: [pim] Replacing unicast BSMs with multicast

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Apr 2006 12:24:23 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Cao Wei <[email-masked]>
Date: Fri, 21 Apr 2006 16:03:52 +0800

----- Original Message ----- 
From: "Stig Venaas" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 20, 2006 6:24 PM
Subject: [pim] Replacing unicast BSMs with multicast

> waiting for the next periodic BSM originated by the BSR.

Yes, the main purpose of bringing addtional BSM is to make a newly restarted router learn RP-set quickly.
I think it is better not to bother other routers, so indicating who should receive the addtional message is preferred.  
And another  concern about replacing unicast BSMs with mulitcast BSMs is compatibility. 
As described in section 4,  mcast-BSM may also bring some confusion to current implementations and the same problem of forwarding
ucast-BSM will appear again. 

And about the ARP cache problem,  I guess it means the Source Mac Checking. It may bring some security benefits but it is not a compulsive 
step for receiving unicast packet. As I know, some of the products make this an optional feature and it is turned off by default.

In the end, I am not clear about the issure "prevent unicast BSM travel multihop". If the a router abide by the protocol, it will not send BSM to 
a router several hops away. Also because PIM protocol don't require authentication before build neighbour relationship, a PIM router has to
trust its neighbours by default. It a malicious appear on network, it can bring more severe danger than multi-hops unicast BSM.

I have an idea that  keeping unicast BSM and changing the conditions to accept unicast BSM may be useful:
When unicast BSM arrives, it will be accepted by satisfying the following condition:
    1.BSM.dst_ip is my primary address on the interface
    2. No previous MULTICAST BSMs are received (current standard requires no previous BSM is received)
    3. During the first BS_Period since startup
    4. the BSM.src_ip is a neighbour's address in this interface
Notice that the second condition means that the new router can receive multiple unicast BSM. By this way, if we premise DR can send
correct messages,  BSM fragments can be processed by the new router. (Of course this is not a perfect solution to BSM fragments, 
but it may alleviate the problem.)
The fourth condition requires a router only accept unicast BSMs from its neighbours, so a ucast-BSM from multiple hops away will 
not do any harm.

Thanks!

Current:
> else if (BSM.dst_ip_address is my primary address on the interface) {

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Apr 2006 15:58:38 -0700

>>     4. the BSM.src_ip is a neighbour's address in this interface

    This doesn't handle the case where the router has been up past BS_period
    and the BSR information/RP-set has timed out and a new interface is
    configured to run PIM on it. In this case, you want the BSM to come
    quickly to this router. The above rules won't allow it to.

Dino