Re: [pim] Replacing unicast BSMs with multicast

[Cao Wei <caowayne at huawei.com>]

----- Original Message ----- 
From: "Stig Venaas" <stig.venaas at uninett.no>
To: <pim at ietf.org>
Sent: Thursday, April 20, 2006 6:24 PM
Subject: [pim] Replacing unicast BSMs with multicast


> 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.

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) {
>   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
  
> 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
>

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