Subject: [pim] Proposed update of draft-ietf-pim-bsr-11

From: Stig Venaas <[email-masked]>
Date: Fri, 27 Jul 2007 17:58:19 +0200

As was discussed between Sandy Murphy and me in a previous mail
on the list (and in the wg meeting yesterday), there is little
value in the ACLs recommended in the security considerations
for filtering BSMs by the BSR address. I also realized that the
draft did not recommend BSR Border functionality which is common
in implementations and quite simple and useful.

Below is the new text I propose for 6.3 Bootstrap Message Security.
Apart from the change above there should be no changes apart from
the text being partly restructured.

Unless I get any negative comments I'll submit revision 12 with this
change beginning of next week.

Stig

6.3.  Bootstrap Message Security

If a legitimate PIM router in a domain is compromised, there is little
any security mechanism can do to prevent that router subverting PIM
traffic in that domain.

Implementations SHOULD provide a per interface configuration option
where one can specify that no Bootstrap messages are to be sent out of
or accepted on the interface.  This should generally be configured on
all PMBRs in order to not receive messages from neighboring domains.
This avoids receiving legitimate messages with conflicting BSR
information from other domains, and also prevents BSR attacks from
neighboring domains.  This option is also useful on leaf interfaces
where there are only hosts present.  However, the Security
Considerations section of [1], say that there should be a mechanism for
not accepting PIM Hello messages on leaf interfaces and messages are
only accepted from valid PIM neighbors.  There may however be additional
issues with unicast Bootstrap messages, see below.  In addition to
dropping all multicast Bootstrap messages on PMBRs we also recommend
configuring PMBRs (both towards other domains and on leaf interfaces) to
drop all unicast PIM messages (Bootstrap message, Candidate RP
Advertisement, PIM register and PIM register stop).

6.3.1.  Unicast Bootstrap Messages

There are some possible security issues with unicast Bootstrap Messages.
The Bootstrap Message Processing Checks prevent a router from accepting
a Bootstrap message from outside of the PIM Domain, as the source
address on Bootstrap messages must be an immediate PIM neighbor.  There
is however a small window of time after a reboot where a PIM router will
accept a bad Bootstrap message unicast from an immediate neighbor, and
it might be possible to unicast a Bootstrap message to a router during
this interval from outside the domain, using the spoofed source address
of a neighbor. This can be prevented if PMBRs perform source-address
filtering to prevent packets entering the PIM domain with IP source
addresses that are infrastructure addresses in the PIM domain.  The best
way to protect against this is as mentioned above to configure border
and leaf interfaces to drop all bootstrap messages, including unicast
messages.

The use of unicast BSMs is for backwards compatibility only.  Due to the
possible security implications, implementations supporting unicast BSMs
SHOULD provide a configuration option for whether they are to be used.

6.3.2.  Multi-access subnets

We recommend that implementers provide a configuration option to drop
Bootstrap messages on leaf interfaces and interfaces facing other
domains.  On multi-access subnets with both PIM routers in the domain
and PIM routers outside the domain or non-trusted hosts, we recommend
that IPsec AH is used to protect communication between the PIM routers
in the domain, and that such routers are configured to drop and log
communication attempts from any host that do not pass the authentication
check.  When all the PIM routers are under the same administrative
control, this authentication may use a configured shared secret.  In
order to prevent replay attacks one will need to have one SA per sender
using the sender address for SA lookup.  The securing of interactions
between PIM neighbors is discussed in more detail in the Security
Considerations section of [1], and so we do not discuss the details
further here.  The same security mechanisms that can be used to secure
PIM Join, Prune and Assert messages should also be used to secure
Bootstrap messages.  How exactly to secure PIM link-local messages is
still being worked on by the PIM working group, see [10].

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Fri, 27 Jul 2007 09:08:48 -0700

On Jul 27, 2007, at 8:58 AM, Stig Venaas wrote:

>  There
              shouldn't this be "may"?
> this interval from outside the domain,

Doesn't this depend on whether or not PIM comes up with the border
in place or not?  ie, an implementation shouldn't accept any BSR
messages so it shouldn't have sent out a hello until it is completely  
up.

> 6.3.2.  Multi-access subnets
this section seems to assume that there are two routers for the same
domain on the same multi-access link.  In this case, shouldn't the
interfaces be configured with the "ip pim border" anyway so that no
BSMs are accepted or sent on these interfaces.  Any RP messages
should arrive at these border routers through some internal connections
so you shouldn't have to worry about setting up any shared secrets
here.

(which doesn't mean that administrators might not do this.)

---

From: Stig Venaas <[email-masked]>
Date: Fri, 27 Jul 2007 21:33:41 +0200

John Zwiebel wrote:
> messages so it shouldn't have sent out a hello until it is completely up.

Note that at the end of that section I say that this can be avoided
using BSR Border. Perhaps I should try to rephrase it so that it says
earlier in the section that this applies to when BSR border is not used.
> so you shouldn't have to worry about setting up any shared secrets

Agree. It depends on the topology and the location of the e-BSR, but
this should generally be fine. I'll try to add some text to clarify
that.

Thanks, at least someone is reading my posts :)

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 30 Jul 2007 14:18:50 +0200

> earlier in the section that this applies to when BSR border is not used.

I've now changed 6.3.1 to the following:

There are some possible security issues with unicast Bootstrap Messages.
The Bootstrap Message Processing Checks prevent a router from accepting
a Bootstrap message from outside of the PIM Domain, as the source
address on Bootstrap messages must be an immediate PIM neighbor.  There
is however a small window of time after a reboot where a PIM router will
accept a bad Bootstrap message unicast from an immediate neighbor, and
it might be possible to unicast a Bootstrap message to a router during
this interval from outside the domain, using the spoofed source address
of a neighbor.  The best way to protect against this is to use the
above mentioned mechanism configuring border and leaf interfaces to drop
all bootstrap messages, including unicast messages.  This can also be
prevented if PMBRs perform source-address filtering to prevent packets
entering the PIM domain with IP source addresses that are infrastructure
addresses in the PIM domain.

> this should generally be fine. I'll try to add some text to clarify

I've now changed the first part of 6.3.2 to the following:

As mentioned above, implementations SHOULD provide a per interface
configuration option so that leaf interfaces and interfaces facing other
domains can be configured to drop all bootstrap messages.  In this
section we will consider multi-access subnets where there are both
multiple PIM routers in a PIM domain and also PIM routers outside the
PIM domain or non-trusted hosts.  On such links one should if possible
configure the PMBRs to drop Bootstrap messages.  This is possible
provided that the routers in the PIM domain receive Bootstrap messages
on other internal links.  That is, for each of the routers on the
multi-access link that are in our domain, the RPF interface for each of
the candidate BSR addresses must be an internal interface (an interface
not on a multi-access link).  There are however network topologies where
this is not possible.  With such topologies, we recommend that  IPsec AH
is used to protect communication between the PIM routers in the domain,
and that such routers are configured to drop and log  communication
attempts from any host that do not pass the authentication check.  When
all the PIM routers are under the same administrative
...

Unless I get any negative feedback I'll submit a new revision with this
new text shortly.

Stig