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
