Subject: [pim] BSR update

From: Stig Venaas <[email-masked]>
Date: Sun, 15 Jul 2007 13:48:52 +0200

We've revised revision 10 based on feedback from the General
Area review (which Alex has posted previously and also presented
in the last pim wg meeting), and feedback from the Security
Directorate.

Below is the secdir review we got and what changes we've made
based on that. For a diff of all changes from 10 to 11, please
see 
http://tools.ietf.org/wg/pim/draft-ietf-pim-sm-bsr/draft-ietf-pim-sm-bsr-11-from-10.diff.html

Please let me know if you have further comments, disagree or
whatever on any of the below.

In March Sandy Murphy (cc-ed) wrote:
 > This draft describes the Bootstrap Router Mechanism for PIM, a
 > mechanism by which PIM routers can discover which routers are
 > Rendezvous Points and what multicast group addresses each serves.
 >
 > The security considerations section does a good job of identifying
 > the threats to the BSR Mechanism, including the types of damage that
 > can be done and mechanisms that could help to protect the domain,
 > both operational and cryptographic.
 >
 > The authors somewhat punt on the problem of Byzantine routers, noting
 > only that "If a legitimate PIM router is compromised, there is little
 > any security mechanism can do to prevent that router subverting PIM
 > traffic in that domain."
 >
 > SECURITY RELATED POINTS:
 >
 > The non-cryptographic protections suggested are of filtering
 > on the basis of source, destination, or protocol.  They also
 > recommend access lists:
 >
 >                    "we recommend that implementations have a way of
 > restricting which IP addresses the BSR accepts C-RP-Adv messages from,
 > e.g., access lists."
 >
 >                "we recommend that implementers provide a mechanism
 > whereby a PIM router using the BSR mechanisms can be configured with
 > the IP addresses of valid BSR routers, and that any Bootstrap message
 > from any other BSR should then be dropped and logged as a security
 > issue."
 >
 > First: I believe that they mean "any other host" or "any other PIM
 > router" rather than "any other BSR" - it does not seem likely that
 > there are "valid" BSRs and "other" BSRs.

This has now been changed to: "we recommend that implementers provide a
mechanism whereby a PIM router using the BSR mechanisms can be
configured with the IP addresses of valid BSR routers, and that any
Bootstrap message with a non-valid BSR address should be dropped and
logged as a security issue. Due to the RPF check of the BSR address, it
it will not be trivial to inject messages with a spoofed BSR address."

 > Second: Use of access lists is useful if the data origin can be
 > authenticated.  The draft later suggests the use of IPSEC AH for both
 > Bootstrap messages and C-RP-Adv messages.  It recommends a single
 > domain wide shared secret for all PIM routers, which means
 > authentication is to that group, not to any specific sender.  That is
 > in keeping with their statement that nothing can protect against
 > Byzantine PIM routers.  However, with that key management, an access
 > list of valid BSR routers does not help - any valid PIM router could
 > spoof the address of a valid BSR router.  (It might protect against
 > accidental misconfiguration of a non-BSR router.)  Furthermore, even
 > if other key management were used, Bootstrap messages, which are
 > flooded from PIM router to PIM router using the ALL-PIM-ROUTER
 > multicast address on each link, would be difficult to authenticate
 > with IPSEC to a specific data origin (the immediate sender of a BSM is
 > not the source of the BSM).

My comment to her was:
We recommend a single domain wide shared secret for all PIM routers,
assuming that you trust all PIM routers in your management domain.
You are right that any of these can spoof the address. It is difficult
to restrict this further, since in general, any PIM router should be
able to authenticate the message and take part in hop-by-hop forwarding
of the messages. No changes made to the draft regarding this.

 > --------------
 >
 > The draft says:
 >
 >   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.
 >
 > Ref [1] is RFC 4601, which says that "The anti-replay option for IPsec
 > SHOULD be enabled on all SAs."  However, the BSMs are flooded over the
 > link-local ALL-PIM-ROUTERs multicast address.  RFC4302 says that it
 > does not specify mechanisms for providing anti-replay for a
 > multi-sender SA.  This is a problem in RFC 4601, but it could be noted
 > here that anti-replay is not likely to be available for BSMs, and,
 > depending on the number of (manually) configured SAs, not for C-RP-Adv
 > messages.

Rev 10 says:

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.

In Rev 11 we have in front of this text added "In order to prevent
replay attacks one will need to have one SA per sender using the sender
address for SA lookup." and right after the above text we added "How
exactly to secure PIM link link-local messages is still being worked on
by the PIM working group, see [10]." where reference 10 is to 
draft-ietf-pim-sm-linklocal-00.

 > -------------
 >
 > There are multiple uses of phrases like "We recommend", "It might also
 > be a good idea", "it may also be useful".  (Such phrases were not
 > restricted to the security consideration section.)  Would any of these
 > uses be better written as RFC 2119 key words, i.e., SHOULD, MAY,
 > RECOMMENDED, etc?  For the security consideration section, the use of
 > key words might be important, such as "For true security, we recommend
 > that all C-RPs are configured to use IPsec authentication."  What does
 > that "recommend" mean?

My response to her was:
At least to me it seems more reasonable to use these phrases than the
normative language from 2119. I believe we could have used the terms
SHOULD/RECOMMENDED instead, but is that really better?

 > NON SECURITY RELATED:
 >
 > In Section 4.1, the discussion of the fields in a single fragment
 > points out that the Fragment Tag (duh) and the Hash Mask Len are the
 > same for all fragments belonging to the same Bootstrap message.  It
 > does not make the same comment about any other field.  Does that mean
 > that "No forward bit", "BSR Priority", "BSR Address", etc.  could be
 > different?  It seems like the fragment format is divided into a common
 > area at the beginning that looks like it should remain the same over
 > all fragments, and an area that would differ from fragment to
 > fragment.  If so, that might be explained.

Rev 11 now says in 4.1.1 on semantic fragmentation:

All fragments of a given Bootstrap message MUST have identical values
for the Type, No-forward bit, Fragment Tag, Hash Mask Len, BSR Priority
and BSR Address fields. That is, only the group-to-RP mappings may
differ between fragments.

She pointed out a few nits, the interesting one is:

 > There are cases where multiple terms, which seem to be synonymous, are
 > used.
 >
 > Group addresses/ group ranges/ group prefixes/ admin scope range
 >
 > admin scope /admin scope zone/ scope zone/ admin-scope region
 >
 > Trying to figure out if a different term is just a synonym is an
 > annoyance to the reader.  Some of these terms are used in the same
 > paragraph.  Sure would be nice to be consistent.  (OK, I'll grant you
 > that "admin scope zone" and "scope zone" was easy.)

Revision 11 now tries to avoid synonyms. It defines the term "scope
zone" and avoids the term "region". Also it uses the term "group ranges"
rather than "group addresses" and "group prefixes".

Stig

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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Jul 2007 17:43:31 +0200

Sandy Murphy wrote:
> Perhaps I don't understand your intended use of access lists.  I
> thought the text I quoted meant that you wanted the access lists to
> give you a way to tell the valid BSR PIM routers from the PIM routers
> that are not valid BSRs.  If that is true, then your access list does
> protect you against PIM routers that are accidentally mis-configured
> as being BSR capable, but not those that are also misconfigured to use a 
> valid BSR address.  A PIM router could assume the address of a valid BSR
> router undetectably, because all the PIM routers use the same domain
> wide shared secret.
> 
> If the above is correct, I wonder why you go to the trouble of recommending
> access lists - is the protection against only-half-mis-configured
> PIM routers what you are after?  If so, it would be good to state what
> protection the access lists give you.

OK, maybe we need to be more explicit. First of all, access lists might
give some protection against misconfiguration. You would typically have
very few Candidate BSR routers and should only get BSMs with one of
those specified as the BSR (the originator of the hop-by-hop flooded
BSM). They can also be used to block BSMs from PIM neighbors that are
outside your core network (say customer/peer/ISP router). Note that
the RPF check done on the BSR address protects you from spoofed external
BSMs that appear to come from one of your own BSRs.

Due to the RPF check someone compromising a non-BSR router (one that is
not allowed to be the BSR) will only be able to originate BSMs and get
them flooded to parts of the domain (they must pass the RPF check for
one of the valid BSD addresses).

I admit access lists give limited protection. What I think one should
do in general is simply to discard all BSMs from non-trusted neighbors.
That is, drop BSMs on interfaces facing customer/peer/ISP routers.

We are currently saying:

   6.3.1.  Rejecting Bootstrap Messages from Invalid Neighbors

   Most hosts that are likely to attempt to subvert PIM BSR are likely to
   be located on leaf subnets.  We recommend that implementers provide a
   configuration option that specifies an interface is a leaf subnet, and
   that no PIM packets are accepted on such interfaces.

Here we are however talking about invalid neighbors, not non-trusted
neighbors.

I think we should modify this text so that it recommends a configuration
option for dropping BSMs on interfaces in general. This would then be
useful on both leaf subnets and on external links. This text talking
about "no PIM packets" is kind of leftover from when BSR was part of the
PIM specification.

Next the text says:

   On multi-access subnets with multiple PIM routers and hosts that are
   not trusted, we recommend that IPsec AH is used to protect
   communication between PIM routers, 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.

We should update this text to talk about both hosts and non-trusted
(or external?) PIM routers. That is, IPsec is needed if you want to only
receive BSMs from some routers but don't trust everyone on the link.

The only real value I see with ACLs is when you don't use IPsec and have
these non-trusted multi-access links. It depends on the topology, but it
should be possible to choose the location of the candidate BSRs so that
any forged BSM coming from a multi-access subnet with one of the valid
BSR addresses will fail RPF. E.g. if the multi-access subnets are close
to the edge, and the C-BSRs are centrally located, only those routers
further towards the edge will accept the forged BSM.

I agree this is not all that good. I'm fine with removing the ACL
recommendation and instead recommend the config option for dropping all
BSMs on external interfaces. I guess it should even be a SHOULD as this
is fairly important for most BSR deployments.

I'm familiar with implementations that can drop all BSMs, but not with
anyone doing the ACLs. What does the rest of you think of dropping the
ACL recommendation for BSMs and just recommend configuration option for
BSR border interfaces?

Thanks Sandy for helping me finally see this. What do you think of this
BSR border interface configuration instead of the more vague ACLs?

Stig

> --Sandy

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Jul 2007 18:52:16 +0200

One additional comment below

Stig Venaas wrote:
>> as being BSR capable, but not those that are also misconfigured to use 
>> a valid BSR address.  A PIM router could assume the address of a valid 
>> BSR
> the RPF check donFrom [email-masked] Mon Jul 16 12:52:41 2007
Date: Mon, 16 Jul 2007 18:52:16 +0200
From: Stig Venaas <[email-masked]>
To: Sandy Murphy <[email-masked]>
Subject: Re: [pim] Re: BSR update
Cc: [email-masked]

One additional comment below

Stig Venaas wrote:
>> as being BSR capable, but not those that are also misconfigured to use 
>> a valid BSR address.  A PIM router could assume the address of a valid 
>> BSR

I should also have said that ACLs are useful on these multi-access links
for blocking benign BSMs from other domains while still using BSM
between your own routers. As I say above you would still be vulnerable
to attacks though.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Jul 2007 18:52:29 +0200

Stig Venaas wrote:
> one of the 43) id 1IAToG-00045h-64
	for [email-masked]; Mon, 16 Jul 2007 12:52:32 -0400
Date: Mon, 16 Jul 2007 18:52:29 +0200
From: Stig Venaas <[email-masked]>
To: Sandy Murphy <[email-masked]>
Subject: Re: [pim] Re: BSR update
Cc: [email-masked]

Stig

valid BSD addresses).

Stig

---

From: [email-masked] (Sandy Murphy)
Date: Mon, 16 Jul 2007 10:01:54 -0400 (EDT)

--Sandy