[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 first look at the specification in the latest draft, and
>    then look at RFC 2362.
>


Para 3.1.3 has BSM processing checks.
Para 3.5 is where unicast BSMs are defined.
Para 6.3.1 discusses rejecting unicast BSMs with RA
Para 6.3.2 talks about AH and leaf networks and then points to the
    pim-sm draft, which then points back to the BSR draft.
Para 8 says "usually sent with TTL=1" and then refers to 3.5 for
    unicast BSMs


>    A unicast BSM is accepted if no previous BSM has been accepted and
>    less than BS Period has elapsed since startup. Else it is silently
>    discarded. There is no RPF performed,

> and no check of the source
>    address.
  Para 3.1.3 first checks all BSMs for "DirectlyConnected" or PIM neighbor
    so the source is checked.

> The destination address is required to be the address we
>    sent the hello from on the interface where it is received.
    The RA inspection of 6.3.1

> Unicast   BSMs are to be sent with TTL 1.
 Para 8 says BSMs are "usually" sent with TTL 1.  (multicast is in there
but its open for interpretation.)

> The source address for all BSMs
>    (unicast and multicast) is required to be the address PIM hello's
>    are sent from. The BSMs have Router Alert option set to help secure
>    the unicast BSMs. A router must drop a unicast BSM that is not
>    destined to itself, it does this by inspecting all packets with
>    Router Alert set.



> There is nothing in the draft saying that unicast
>    BSMs are not to be forwarded, but this is possibly an oversight.
Perhaps the TTL of 1 is a hint.  :-)
But one could look at the BSM processing checks in 3.1.3 and note that
the unicast BSM passes, then refer to 3.1.5 where the "Forward BSM" paragrah
doesn't distinguish between unicast and multicast reception of the BSM

>    I'm not sure how to interpret RFC 2362, see 3.6.3 for details. It
>    does talk about the behaviour for a number of cases where it says
>    that the BSM should be forwarded. Then it goes on to talk about
>    unicast BSMs. In the unicast BSM section it does not mention
>    forwarding at all, which I believe means that it should not be
>    forwarded. It says:
>
>       3 If the Bootstrap message includes a BSR address that is
>         preferred over, or equal to, the currently active BSR, the
>         router restarts its Bootstrap-timer at [Bootstrap-Timeout]
>         seconds. and stores the BSR address and RP-Set information.
>
>         The Bootstrap message is then forwarded out all PIM interfaces,
>         excluding the one over which the message arrived, to `ALL-PIM-
>         ROUTERS' group, with a TTL of 1.
>
>       4 If the receiving router has no current RP set information
>         and the Bootstrap was unicast to it from a directly connected
>         neighbor, the router stores the information as its new RP-set.
>         This covers the startup condition when a newly booted router
>         obtains the RP-Set and BSR address from its DR.
>
>    In 2362 it might appear that RPF is performed for unicast BSMs as
>    well, at least they are not specifically excluded. But there are
>    several places where the text does not consider unicast BSMs. E.g,
>    in 4.6 it says that bootstrap messages are multicast, and no
>    mention of unicast BSMs.
>
>
> 2. Issues with unicast BSMs
>
>    First of all, the behaviour is not defined clearly enough. In 2362
>    it's not clear whether RFP or forwarding should be performed, I
>    believe that neither should though. At least I read 2362 as saying
>    that forwarding is not performed.  RPF is clearly problematic if
>    the unicast BSMs can only be sent by DRs, since the DR may not be
>    the RPF neighbour.

IGP will probably converge after the PIM neighbor is discovered and
a unicast BSM is triggered anyway.

>
>    For 2362 it is easy to send a unicast BSM multiple hops, a host
>    might send a unicast BSM to a router with a forged source address
>    to a restarting router. The security is improved in the new draft
>    by the use of Router Alert. This does however work only if all
>    routers are able to enforce it. At last working group meeting there
>    appeared to be consensus for skipping RAs and rather require
>    unicast BSMs to be sent with TTL of 255 (so that receiving router
>    can verify that it still is 255). Currently the TTL is supposed to
>    be 1, so there may be issues with backwards compatibility (if the
>    DR on the link is a router sending with TTL 1).
>
>    There are several BSR implementations that have not implemented
>    unicast BSMs. As an example, one big router vendor has the issue
>    that a unicast BSM would be discarded by the sending 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.
>
>
> 3. Replacing unicast BSMs with multicast BSMs
>
>    It's been suggested to always use multicast BSMs in the new
>    draft. Assuming that unicast BSMs should not have RPF checked and
>    not being forwarded (but as described above, 2362 and the current
>    draft are not as clear as one would like), one can replace unicast
>    BSMs with multicast and get the exact same behaviour, as proposed
>    by John Z. and Dino.
>
>    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.
>
>    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,

Not really.  Someone could still sent unicast BSMs.  However, the RA
is required for C-RP messages and so would still apply to unicast BSMs.

>    there is no need for router alert or use of ttl 255. By not using
>    unicast, implementations can to some degree be simplified, both in
>    that the previously mentioned security measures are not needed, and
>    also that one does not need to have an ARP cache entry or perform
>    ARP before one can send the BSM.
>
> 3.1. Backwards compatibility
>
>    There is one issue with replacing unicast BSMs, and that is
>    backwards compatibility. But first, note that several
>    implementations don't do unicast BSMs today, and also 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.
>
>    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.

FWIW: I don't see any reason to not accept the unicast BSM since
RA on C-RP messages is required.  Perhaps this could be a MAY.

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


> The pros and cons of
>    forwarding unicast BSMs (or their replacement) would require a long
>    analysis. There are potential benefits; the worst case is that some
>    routers get stale RP information until the periodic BSM is
>    received.
This only happens in a broken network.  I think the examples you gave
are broken networks.  (the examples aren't ;-)

> Another issue is that the router not supporting this, may
>    leave the flag set when forwarding the BSM. This means that this
>    BSM might get forwarded router by router (provided RPF is okay). If
>    it at some point is received by a router supporting this
>    specification, the message would be used (provided the router has
>    recently restarted) with no RPF check. The message would not be
>    forwarded past this router.
>
>    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.

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